...
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).
Design of a creation of a Control Loop Type
- Gui GUI calls POST "/commission" endpoint with a Control Loop Type Definition (Tosca Service Template) as body
- saves to DB the Tosca Service Template using PolicyModelsProvider
- if there are participants registered, 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).
...
- ThreadPoolExecutor: in this context is configured to execute task in ordered manner, one by one.
- Scheduling: is used to schedule retry task.
- MessageIntercept: is used to intercept messages from participants
Design of a PARTICIPANT_REGISTER message
- A Participant starts and send a PARTICIPANT_REGISTER message
- ParticipantRegisterListener collects the message from DMaap
- if not present, saves participant reference with status UNKNOWN to DB
- if is present a Control Loop Type, 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).
- 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
- in SupervisionScanner starts the monitoring for participantUpdate
Design of a PARTICIPANT_UPDATE_ACK message
- Participants sends PARTICIPANT_UPDATE_ACK messages in response to a PARTICIPANT_UPDATE message
...
- ParticipantUpdateAckListener collects the message is collected by ParticipantUpdateAckListenerfrom DMaap
- MessageIntercept intercepts that event and adds from MessageIntercept the event is intercepted and it add a task to handle PARTICIPANT_UPDATE_ACK in SupervisionScanner
- in SupervisionScanner remove removes the monitoring for participantUpdate
- update updates the status of the participant to db DB
Design of a PARTICIPANT_STATUS message
- A participant sends a scheduled PARTICIPANT_STATUS message
- ParticipantStatusListener collects the message is collected by ParticipantStatusListenerfrom DMaap
- MessageIntercept intercepts that event and adds from MessageIntercept the event is intercepted and it add a task to handle PARTICIPANT_STATUS in SupervisionScanner
- in SupervisionScanner clear clears and start starts the monitoring for participantStatus
...
Participants sends CONTROLLOOP_UPDATE_ACK messages in response to a CONTROLLOOP_UPDATE message. It will send a CONTROLLOOP_UPDATE_ACK for each CL-elements moved to the state as indicated by the CONTROLLOOP_UPDATE.
- ControlLoopUpdateAckListener collects the message is collected by ControlLoopUpdateAckListenerfrom DMaap
- from the control loop into the message check the status of all control loop element and check if the control loop is primed
- update updates the CL into the db to DB if it is changed
- from MessageIntercept the intercepts that event is intercepted and it add adds a task to handle a monitoring execution in SupervisionScanner
...
Monitoring is designed to process the follow operations:
- determination to determinate of the next startPhase in a CONTROLLOOP_UPDATE message.
- to upgrade CL state: in a scenario that CL state are in kind of transitional state (example UNINITIALISED2PASSIVE), if all CL-elements are moved properly to the specific state, the CL state will be upgrade to that.
- to retry CONTROLLOOP_UPDATE/CONTROL_LOOP_STATE_CHANGE messages. if there is a CL Element not in the proper state, will be retry a broadcast message.
- to retry PARTICIPANT_UPDATE message to the participant in a scenario that CL-runtime do not receive PARTICIPANT_UPDATE_ACT from it.
- to send PARTICIPANT_STATUS_REQ to the participant in a scenario that CL-runtime do not receive PARTICIPANT_STATUS from it,
The solution Design of retry, timeout, and reporting for all Participant message dialogues are implemented into the monitoring execution.
- Spring Scheduling start inserts the task to monitor retry execution any heartBeatMs milliseconds into ThreadPoolExecutor
- task is executed under the ThreadPoolExecutorThreadPoolExecutor executes the task
- a message will be retry if CL-runtime do no receive Act message before MaxWaitMs milliseconds
...