To be update....
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
- Call POST /commission with a Control Loop Type Definition (Tosca Service Template) as body
- Save to DB the Tosca Service Template using PolicyModelsProvider
- if there are participants registered, it triggers to ParticipantUpdatePublisher to send a broadcast PARTICIPANT_UPDATE message
- message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition).
Design of a deletion of a Control Loop Type
- Call DELETE /commission with a Control Loop Type Definition (Tosca Service Template)
- if there are participants registered, it triggers to ParticipantUpdatePublisher to send a broadcast PARTICIPANT_UPDATE message
- message is built by ParticipantUpdatePublisher with a empty list of ParticipantDefinition
- delete the Control Loop Type from DB
Design of a creation of a Control Loop
- Call POST /instantiation with a Control Loop as body
- Validation of the Control Loop
- Save the Control Loop to DB
Design of an update of a Control Loop
- Call PUT /instantiation with a Control Loop as body
- Validation of the Control Loop
- Save the Control Loop to DB
Design of a deletion of a Control Loop
- Call DELETE /instantiation
- check that Control Loop is in UNINITIALISED status
- delete the Control Loop from DB
Design of a issues control loop commands to control loops - case UNINITIALISED to PASSIVE
- CALL /instantiation/command with PASSIVE as orderedState
- check if participants registered are matching with the list of control Loop Element
- update control loop and control loop elements to DB (orderedState = PASSIVE)
- validate the status order issued
- trigger to ControlLoopUpdatePublisher to send a broadcast CONTROL_LOOP_UPDATE message
- message is built by ControlLoopUpdatePublisher using Tosca Service Template data and ControlLoop data. (with startPhase = 0)
- update control loop and control loop elements to DB (state = UNINITIALISED2PASSIVE)
Design of a issues control loop commands to control loops - case PASSIVE to UNINITIALISED
- CALL /instantiation/command with UNINITIALISED as orderedState
- check if participants registered are matching with the list of control Loop Element
- update control loop and control loop elements to DB (orderedState = UNINITIALISED)
- validate the status order issued
- trigger to ControlLoopStateChangePublisher to send a broadcast CONTROL_LOOP_STATE_CHANGE message
- message is built by ControlLoopStateChangePublisher with controlLoopId
- update control loop and control loop elements to DB (state = PASSIVE2UNINITIALISED)
Design of a issues control loop commands to control loops - case PASSIVE to RUNNING
- CALL /instantiation/command with RUNNING as orderedState
- check if participants registered are matching with the list of control Loop Element.
- update control loop and control loop elements to DB (orderedState = RUNNING)
- validate the status order issued
- trigger to ControlLoopStateChangePublisher to send a broadcast CONTROL_LOOP_STATE_CHANGE message
- message is built by ControlLoopStateChangePublisher with controlLoopId
- update control loop and control loop elements to DB (state = PASSIVE2RUNNING)
Design of a issues control loop commands to control loops - case RUNNING to PASSIVE
- CALL /instantiation/command with UNINITIALISED as orderedState
- check if participants registered are matching with the list of control Loop Element.
- update control loop and control loop elements to db (orderedState = RUNNING)
- validate the status order issued
- trigger to ControlLoopStateChangePublisher to send a broadcast CONTROL_LOOP_STATE_CHANGE message
- message is built by ControlLoopStateChangePublisher with controlLoopId
- update control loop and control loop elements to db (state = RUNNING2PASSIVE)
SupervisionAspect
- 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
HandleCounter
- remove(id) -> used to remove from monitoring
- clear(id) -> used to clear/start monitoring
Design of a PARTICIPANT_REGISTER message
- the message is collected by ParticipantRegisterListener
- the participant is save to db if not present with status UNKNOWN
- if is present a Control Loop Type, it triggers to ParticipantUpdatePublisher to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming).
- message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition).
- trigger to ParticipantRegisterAckPublisher to send a PARTICIPANT_REGISTER_ACK message to the participant registered
- from MessageIntercept the event is intercepted and if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner
- in SupervisionScanner start the monitoring for participantUpdate
Design of a PARTICIPANT_UPDATE_ACK message
- the message is collected by ParticipantUpdateAckListener
- from MessageIntercept the event is intercepted and it add a task to handle PARTICIPANT_UPDATE_ACK in SupervisionScanner
- in SupervisionScanner remove the monitoring for participantUpdate
- update the status of the participant to db
Design of a PARTICIPANT_STATUS message
- the message is collected by ParticipantStatusListener
- from MessageIntercept the event is intercepted and it add a task to handle PARTICIPANT_STATUS in SupervisionScanner
- in SupervisionScanner clear and start the monitoring for participantStatus
Design of a CONTROLLOOP_UPDATE_ACK message
- the message is collected by ControlLoopUpdateAckListener
- from the control loop into the message check the status of all control loop element and check if the control loop is primed
- update the CL into the db if it is changed
- from MessageIntercept the event is intercepted and it add a task to handle a monitoring execution in SupervisionScanner
Design of a CONTROLLOOP_STATECHANGE_ACK message is similar to CONTROLLOOP_UPDATE_ACK
Solution Design of retry, timeout, and reporting for all Participant message dialogues
Design of startPhase into monitoring execution in SupervisionScanner
- phaseMap is map that contains (CL -> last startPhase sent)
- during the monitoring is calculate the the minimum startPhase where the status of a Element is not equal to the orderstatus (minSpNotCompleted).
- if the last startPhase sent is different to minSpNotCompleted and CL order status is UNINITIALISED2PASSIVE then send the CONTROLLOOP_UPDATE message with minSpNotCompleted as startPhase
Design of a monitoring execution in SupervisionScanner
- for each CL
- check if the status of the CL is equal to the order status; if they are equal, clear the monitoring counter for this CL and continue the loop.
- for each CL Element check if the status of an Element are equal to the orderstatus
- if all CL Element status are equal to the orderstatus, update the CL status, clear the monitoring counter for this control loop and continue the loop.
- the message CONTROLLOOP_UPDATE/CONTROL_LOOP_STATE_CHANGE to participant will be sent if:
Note |
---|
This page is Work in Progress |
...