participants/docs/overview.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. SPDX-License-Identifier: CC-BY-4.0
   3 .. Copyright (C) 2023 OpenInfra Foundation Europe. All rights reserved.
   4
   5 DME Participant
   6 ~~~~~~~~~~~~~~~
   7
   8 A Participant is a component that acts as a bridge between the Automation Composition Management runtime and components such as the Kserve, A1PMS, DME, or a Kubernetes cluster that are taking part in automation composition management. It listens to DMaaP to receive messages from the ACM runtime and performs operations towards components that are taking part in acms. A participant has an Automation Composition Management Element for each automation composition in which it is taking part.
   9
  10 More information about ACM can be found `here <https://docs.onap.org/projects/onap-policy-parent/en/latest/clamp/acm/acm-architecture.html#introduction>`_.
  11
  12 The DME participant receives Information Type/Data Producer/Data Consumer information from the ACM runtime and creates it in ICS(NONRTRIC). The participant acts as a wrapper around the ICS and creates the entities.
  13
  14 Supported message Broker are DMaap and Strimzi-Kafka.
  15
  16 This participant is a part of :doc:`NONRTRIC <nonrtric:index>`.
  17
  18 ************
  19 Architecture
  20 ************
  21
  22 .. image:: ./images/architecture.png
  23    :width: 500pt
  24
  25 When an automation composition is initialized, the DME participant starts a DME Automation Composition element for the automation composition. It reads the configuration information sent from the Automation Composition Runtime and runs a REST client to talk to the ICS(DME) endpoint receiving the REST requests.
  26
  27 ***************************************
  28 Prerequisites for using DME participant
  29 ***************************************
  30
  31 * A running ICS(DME). ICS(DME) base url should be configured in DME participant to make REST calls.
  32
  33 ***********************
  34 Supported Element Types
  35 ***********************
  36 Supported Element Types for DME participant will be used to define the DME participant Element Definition Types in tosca template. Participant Supported Element Types is defined in DME participant application.yaml.
  37
  38       .. code-block:: yaml
  39
  40         participantSupportedElementTypes:
  41           -
  42             typeName: org.onap.policy.clamp.acm.DMEAutomationCompositionElement
  43             typeVersion: 1.0.1
  44
  45 **************************************************
  46 Defining a TOSCA CL definition for DME participant
  47 **************************************************
  48
  49 A Info Type Entity/ Data Producer Entity/Data Consumer Entity describes a information type entities that is managed by the DME participant. A Info Type Entity/Data Producer Entity/Data Consumer Entity can be created, Read and Deleted. The user defines the entities that it wants its DME Automation Composition Element to manage and provides the parameters to manage each Information Type/Data Producer/Data Consumer.
  50
  51 Sample tosca template defining a participant and a AC element definition ':download:`link <./tosca-dme-participant.yml>`'
  52
  53
  54 **************************************************************************************************
  55 Configuring a Automation Composition Element on the DME participant for a Automation Composition
  56 **************************************************************************************************
  57
  58 The user defines the following properties in the TOSCA template for the DME participant
  59
  60
  61 *Information Type Entities*
  62
  63 .. list-table::
  64    :header-rows: 1
  65
  66    * - Property
  67      - Type
  68      - Description
  69    * - infoTypeEntityId
  70      - ToscaConceptIdentifier
  71      - The name and version of the information type that needs to be managed by the DME participant
  72    * - infoTypeId
  73      - String
  74      - Id of information type
  75    * - payload
  76      - String
  77      - The payload of the information type entity. This will be used as  payload to call DME API
  78
  79 *Data Producer Entities*
  80
  81 .. list-table::
  82    :header-rows: 1
  83
  84    * - Property
  85      - Type
  86      - Description
  87    * - dataProducerEntityId
  88      - ToscaConceptIdentifier
  89      - The name and version of the data producer that needs to be managed by the DME participant
  90    * - dataProducerId
  91      - String
  92      - Id of the data producer
  93    * - payload
  94      - String
  95      - The payload of the data producer entity. This will be used as  payload to call DME API
  96
  97 *Data Consumer Entities*
  98
  99 .. list-table::
 100    :header-rows: 1
 101
 102    * - Property
 103      - Type
 104      - Description
 105    * - dataConsumerEntityId
 106      - ToscaConceptIdentifier
 107      - The name and version of the data consumer that needs to be managed by the DME participant
 108    * - dataConsumerId
 109      - String
 110      - Id of the data consumer
 111    * - payload
 112      - String
 113      - The payload of the data consumer entity. This will be used as  payload to call DME API
 114
 115 Sample Automation Composition instances. In that example the user fills the properties defined in the TOSCA for the DME participant ':download:`link <./automation-composition-dme.yml>`'
 116
 117 ****************************
 118 DME participant Interactions
 119 ****************************
 120
 121 The DME participant interacts with Automation Composition Runtime on the northbound interface via Message Broker. It interacts with the ICS(DME) API on the southbound interface for the operations.
 122
 123 The communication for the Automation Composition updates and state change requests are sent from the Automation Composition Runtime to the participant via Message Broker. The participant performs appropriate operations on DME via REST based on the received messages from the Automation Composition Runtime.
 124
 125 ************************
 126 DME participant Workflow
 127 ************************
 128 Once the participant is started, it sends a “REGISTER” event to the Message Broker topic which is then consumed by the Automation Composition Runtime to register this participant on the runtime database. The user can commission the tosca definitions from the Policy Gui to the Automation Composition Runtime. Once the automation composition definitions are available in the runtime database, the user can prime them and further updates the participant with these definitions via Message Broker. After priming, the Automation Composition can be instantiated with the default state “UNDEPLOYED” from the Policy Gui.
 129
 130 When the state of the Automation Composition is changed from “UNDEPLOYED” to “DEPLOYED” from the Policy Gui, the DME participant receives the automation composition state change event from the runtime and deploys the information type/data producer/data consumer associated with each Automation Composition Elements by calling the ICS(DME) api in the cluster.
 131
 132 When the state of the Automation Composition is changed back from “DEPLOYED” to “UNDEPLOYED”, the participant also undeploys the related information type/data producer/data consumer from DME.