Participant Intermediary

The CLAMP Participant Intermediary is a common library in ONAP, which does common message and state handling for participant implementations. It provides a Java API, which participant implementations implement to receive and send messages to the CLAMP runtime and to handle Automation Composition Element state.

Terminology

  • Broadcast message: a message for all participants (participantId=null and participantType=null)

  • Message to a participant: a message only for a participant (participantId and participantType properly filled)

  • MessageSender: a class that takes care of sending messages from participant-intermediary

  • GUI: graphical user interface, Postman or a Front-End Application

Inbound messages to participants

  • PARTICIPANT_REGISTER_ACK: received as a response from clamp-acm runtime server as an acknowledgement to ParticipantRegister message sent from a participant

  • PARTICIPANT_DEREGISTER_ACK: received as a response from clamp-acm runtime server as an acknowledgement to ParticipantDeregister message sent from a participant

  • AUTOMATION_COMPOSITION_STATE_CHANGE: a message received from clamp-acm runtime server for a state change of clamp-acm

  • AUTOMATION_COMPOSITION_UPDATE: a message received from clamp-acm runtime server for a clamp-acm update with clamp-acm instances

  • PARTICIPANT_UPDATE: a message received from clamp-acm runtime server for a participant update with tosca definitions of clamp-acm

  • PARTICIPANT_STATUS_REQ: A status request received from clamp-acm runtime server to send an immediate ParticipantStatus from all participants

Outbound messages

  • PARTICIPANT_REGISTER: is sent by a participant during startup

  • PARTICIPANT_DEREGISTER: is sent by a participant during shutdown

  • PARTICIPANT_STATUS: is sent by a participant as heartbeat with the status and health of a participant

  • AUTOMATIONCOMPOSITION_STATECHANGE_ACK: is an acknowledgement sent by a participant as a response to AutomationCompositionStateChange

  • AUTOMATIONCOMPOSITION_UPDATE_ACK: is an acknowledgement sent by a participant as a response to AutomationCompositionUpdate

  • PARTICIPANT_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ParticipantUpdate

Design of a PARTICIPANT_REGISTER message

  • A participant starts and send a PARTICIPANT_REGISTER message

  • ParticipantRegisterListener collects the message from DMaap

  • if participant is not present in DB, it saves participant reference with status UNKNOWN to DB

  • if participant is present in DB, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming)

  • the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition)

  • It triggers the execution to send a PARTICIPANT_REGISTER_ACK message to the participant registered

  • MessageIntercept intercepts that event, if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner

  • SupervisionScanner starts the monitoring for participantUpdate

Design of a PARTICIPANT_DEREGISTER message

  • A participant starts and send a PARTICIPANT_DEREGISTER message

  • ParticipantDeregisterListener collects the message from DMaap

  • if participant is not present in DB, do nothing

  • if participant is present in DB, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of DePriming)

  • the message is built by ParticipantUpdatePublisher using Tosca Service Template data as null

  • ParticipantHandler removes the tosca definitions stored

  • It triggers the execution to send a PARTICIPANT_DEREGISTER_ACK message to the participant registered

  • Participant is not monitored.

Design of a creation of an Automation Composition Type

  • If there are participants registered with CL-runtime, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message

  • the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition)

  • Participant-intermediary will receive a PARTICIPANT_UDPATE message and stores the Tosca Service Template data on ParticipantHandler

Design of a deletion of an Automation Composition Type

  • if there are participants registered, CL-runtime triggers the execution to send a broadcast PARTICIPANT_UPDATE message

  • the message is built by ParticipantUpdatePublisher with an empty list of ParticipantDefinition

  • It deletes the Automation Composition Type from DB

  • Participant-intermediary will receive a PARTICIPANT_UDPATE message and deletes the Tosca Service Template data on ParticipantHandler

Design of a creation of an Automation Composition

  • AUTOMATION_COMPOSITION_UPDATE message with instantiation details and UNINITIALISED state is sent to participants

  • Participant-intermediary validates the current state change

  • Participant-intermediary will recieve AUTOMATION_COMPOSITION_UPDATE message and sends the details of AutomationCompositionElements to participants

  • Each participant performs its designated job of deployment by interacting with respective frameworks

Design of a deletion of an Automation Composition

  • AUTOMATION_COMPOSITION_STATE_CHANGE message with UNINITIALISED state is sent to participants

  • Participant-intermediary validates the current state change

  • Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of AutomationCompositionElements to participants

  • Each participant performs its designated job of undeployment by interacting with respective frameworks

Design of “issues automation composition commands to automation compositions” - case UNINITIALISED to PASSIVE

  • AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from UNINITIALISED to PASSIVE is sent to participants

  • Participant-intermediary validates the current state change

  • Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants

  • Each participant performs its designated job of state change by interacting with respective frameworks

Design of “issues automation composition commands to automation compositions” - case PASSIVE to UNINITIALISED

  • AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from PASSIVE to UNINITIALISED is sent to participants

  • Participant-intermediary validates the current state change

  • Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants

  • Each participant performs its designated job of state change by interacting with respective frameworks

Design of “issues automation composition commands to automation compositions” - case PASSIVE to RUNNING

  • AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from PASSIVE to RUNNING is sent to participants

  • Participant-intermediary validates the current state change

  • Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants

  • Each participant performs its designated job of state change by interacting with respective frameworks

Design of “issues automation composition commands to automation compositions” - case RUNNING to PASSIVE

  • AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from RUNNING to PASSIVE is sent to participants

  • Participant-intermediary validates the current state change

  • Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants

  • Each participant performs its designated job of state change by interacting with respective frameworks

Design of a PARTICIPANT_STATUS message

  • A participant sends a scheduled PARTICIPANT_STATUS message

  • This message will hold the state and healthStatus of all the participants running actively

  • PARTICIPANT_STATUS message holds a special attribute to return Tosca definitions, this attribute is populated only in response to PARTICIPANT_STATUS_REQ

Design of a AUTOMATIONCOMPOSITION_UPDATE_ACK message

  • A participant sends AUTOMATIONCOMPOSITION_UPDATE_ACK message in response to a AUTOMATIONCOMPOSITION_UPDATE message.

  • For each CL-elements moved to the ordered state as indicated by the AUTOMATIONCOMPOSITION_UPDATE

  • AutomationCompositionUpdateAckListener in CL-runtime collects the messages from DMaap

  • It checks the status of all automation composition elements and checks if the automation composition is primed

  • It updates the clamp-acm in DB accordingly

Design of a AUTOMATIONCOMPOSITION_STATECHANGE_ACK is similar to the design for AUTOMATIONCOMPOSITION_UPDATE_ACK