| liamfallon | e206a10 | 2021-10-07 19:00:18 +0100 | [diff] [blame] | 1 | .. This work is licensed under a Creative Commons Attribution 4.0 International License. |
| 2 | |
| 3 | .. _clamp-controlloop-participant-intermediary: |
| 4 | |
| 5 | Participant Intermediary |
| 6 | ######################## |
| 7 | |
| 8 | The CLAMP Participant Intermediary is a common library in ONAP, which does common message and |
| 9 | state handling for participant implementations. It provides a Java API, which participant |
| 10 | implementations implement to receive and send messages to the CLAMP runtime and to handle |
| 11 | Control Loop Element state. |
| 12 | |
| Sirisha_Manchikanti | 0f40950 | 2021-10-19 13:16:02 +0100 | [diff] [blame] | 13 | Terminology |
| 14 | ----------- |
| 15 | - Broadcast message: a message for all participants (participantId=null and participantType=null) |
| 16 | - Message to a participant: a message only for a participant (participantId and participantType properly filled) |
| 17 | - MessageSender: a class that takes care of sending messages from participant-intermediary |
| 18 | - GUI: graphical user interface, Postman or a Front-End Application |
| 19 | |
| 20 | Inbound messages to participants |
| 21 | -------------------------------- |
| 22 | - PARTICIPANT_REGISTER_ACK: received as a response from controlloop runtime server as an acknowledgement to ParticipantRegister message sent from a participant |
| 23 | - PARTICIPANT_DEREGISTER_ACK: received as a response from controlloop runtime server as an acknowledgement to ParticipantDeregister message sent from a participant |
| 24 | - CONTROL_LOOP_STATE_CHANGE: a message received from controlloop runtime server for a state change of controlloop |
| 25 | - CONTROL_LOOP_UPDATE: a message received from controlloop runtime server for a controlloop update with controlloop instances |
| 26 | - PARTICIPANT_UPDATE: a message received from controlloop runtime server for a participant update with tosca definitions of controlloop |
| 27 | - PARTICIPANT_STATUS_REQ: A status request received from controlloop runtime server to send an immediate ParticipantStatus from all participants |
| 28 | |
| 29 | Outbound messages |
| 30 | ----------------- |
| 31 | - PARTICIPANT_REGISTER: is sent by a participant during startup |
| 32 | - PARTICIPANT_DEREGISTER: is sent by a participant during shutdown |
| 33 | - PARTICIPANT_STATUS: is sent by a participant as heartbeat with the status and health of a participant |
| 34 | - CONTROLLOOP_STATECHANGE_ACK: is an acknowledgement sent by a participant as a response to ControlLoopStateChange |
| 35 | - CONTROLLOOP_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ControlLoopUpdate |
| 36 | - PARTICIPANT_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ParticipantUpdate |
| 37 | |
| 38 | Design of a PARTICIPANT_REGISTER message |
| 39 | ---------------------------------------- |
| 40 | - A participant starts and send a PARTICIPANT_REGISTER message |
| 41 | - ParticipantRegisterListener collects the message from DMaap |
| 42 | - if participant is not present in DB, it saves participant reference with status UNKNOWN to DB |
| 43 | - if participant is present in DB, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming) |
| 44 | - the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition) |
| 45 | - It triggers the execution to send a PARTICIPANT_REGISTER_ACK message to the participant registered |
| 46 | - MessageIntercept intercepts that event, if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner |
| 47 | - SupervisionScanner starts the monitoring for participantUpdate |
| 48 | |
| 49 | Design of a PARTICIPANT_DEREGISTER message |
| 50 | ------------------------------------------ |
| 51 | - A participant starts and send a PARTICIPANT_DEREGISTER message |
| 52 | - ParticipantDeregisterListener collects the message from DMaap |
| 53 | - if participant is not present in DB, do nothing |
| 54 | - if participant is present in DB, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of DePriming) |
| 55 | - the message is built by ParticipantUpdatePublisher using Tosca Service Template data as null |
| 56 | - ParticipantHandler removes the tosca definitions stored |
| 57 | - It triggers the execution to send a PARTICIPANT_DEREGISTER_ACK message to the participant registered |
| 58 | - Participant is not monitored. |
| 59 | |
| 60 | Design of a creation of a Control Loop Type |
| 61 | ------------------------------------------- |
| 62 | - If there are participants registered with CL-runtime, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message |
| 63 | - the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition) |
| 64 | - Participant-intermediary will receive a PARTICIPANT_UDPATE message and stores the Tosca Service Template data on ParticipantHandler |
| 65 | |
| 66 | Design of a deletion of a Control Loop Type |
| 67 | ------------------------------------------- |
| 68 | - if there are participants registered, CL-runtime triggers the execution to send a broadcast PARTICIPANT_UPDATE message |
| 69 | - the message is built by ParticipantUpdatePublisher with an empty list of ParticipantDefinition |
| 70 | - It deletes the Control Loop Type from DB |
| 71 | - Participant-intermediary will receive a PARTICIPANT_UDPATE message and deletes the Tosca Service Template data on ParticipantHandler |
| 72 | |
| 73 | Design of a creation of a Control Loop |
| 74 | -------------------------------------- |
| 75 | - CONTROL_LOOP_UPDATE message with instantiation details and UNINITIALISED state is sent to participants |
| 76 | - Participant-intermediary validates the current state change |
| 77 | - Participant-intermediary will recieve CONTROL_LOOP_UPDATE message and sends the details of ControlLoopElements to participants |
| 78 | - Each participant performs its designated job of deployment by interacting with respective frameworks |
| 79 | |
| 80 | Design of a deletion of a Control Loop |
| 81 | -------------------------------------- |
| 82 | - CONTROL_LOOP_STATE_CHANGE message with UNINITIALISED state is sent to participants |
| 83 | - Participant-intermediary validates the current state change |
| 84 | - Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of ControlLoopElements to participants |
| 85 | - Each participant performs its designated job of undeployment by interacting with respective frameworks |
| 86 | |
| 87 | Design of "issues control loop commands to control loops" - case UNINITIALISED to PASSIVE |
| 88 | ----------------------------------------------------------------------------------------- |
| 89 | - CONTROL_LOOP_STATE_CHANGE message with state changed from UNINITIALISED to PASSIVE is sent to participants |
| 90 | - Participant-intermediary validates the current state change |
| 91 | - Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants |
| 92 | - Each participant performs its designated job of state change by interacting with respective frameworks |
| 93 | |
| 94 | Design of "issues control loop commands to control loops" - case PASSIVE to UNINITIALISED |
| 95 | ----------------------------------------------------------------------------------------- |
| 96 | - CONTROL_LOOP_STATE_CHANGE message with state changed from PASSIVE to UNINITIALISED is sent to participants |
| 97 | - Participant-intermediary validates the current state change |
| 98 | - Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants |
| 99 | - Each participant performs its designated job of state change by interacting with respective frameworks |
| 100 | |
| 101 | Design of "issues control loop commands to control loops" - case PASSIVE to RUNNING |
| 102 | ----------------------------------------------------------------------------------- |
| 103 | - CONTROL_LOOP_STATE_CHANGE message with state changed from PASSIVE to RUNNING is sent to participants |
| 104 | - Participant-intermediary validates the current state change |
| 105 | - Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants |
| 106 | - Each participant performs its designated job of state change by interacting with respective frameworks |
| 107 | |
| 108 | Design of "issues control loop commands to control loops" - case RUNNING to PASSIVE |
| 109 | ----------------------------------------------------------------------------------- |
| 110 | - CONTROL_LOOP_STATE_CHANGE message with state changed from RUNNING to PASSIVE is sent to participants |
| 111 | - Participant-intermediary validates the current state change |
| 112 | - Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants |
| 113 | - Each participant performs its designated job of state change by interacting with respective frameworks |
| 114 | |
| 115 | Design of a PARTICIPANT_STATUS message |
| 116 | -------------------------------------- |
| 117 | - A participant sends a scheduled PARTICIPANT_STATUS message |
| 118 | - This message will hold the state and healthStatus of all the participants running actively |
| 119 | - PARTICIPANT_STATUS message holds a special attribute to return Tosca definitions, this attribute is populated only in response to PARTICIPANT_STATUS_REQ |
| 120 | |
| 121 | Design of a CONTROLLOOP_UPDATE_ACK message |
| 122 | ------------------------------------------ |
| 123 | - A participant sends CONTROLLOOP_UPDATE_ACK message in response to a CONTROLLOOP_UPDATE message. |
| 124 | - For each CL-elements moved to the ordered state as indicated by the CONTROLLOOP_UPDATE |
| 125 | - ControlLoopUpdateAckListener in CL-runtime collects the messages from DMaap |
| 126 | - It checks the status of all control loop elements and checks if the control loop is primed |
| 127 | - It updates the controlloop in DB accordingly |
| 128 | |
| 129 | Design of a CONTROLLOOP_STATECHANGE_ACK is similar to the design for CONTROLLOOP_UPDATE_ACK |