Allowed operations in ACM-participant for the participant developer point of view.
The table show the the allowed values using the "updateAutomationCompositionElementState" method.
| StateChangeResult.NO_ERROR | StateChangeResult.FAILED | ||
|---|---|---|---|---|
| DeployState | LockState | DeployState | LockState | |
| undeploy | UNDEPLOYED | null | DEPLOYED | null |
| deploy | DEPLOYED | null | UNDEPLOYED | null |
| lock | null | LOCKED | null | UNLOCKED |
| unlock | null | UNLOCKED | null | LOCKED |
| delete | DELETED | null | UNDEPLOYED | null |
| update | DEPLOYED | null | DEPLOYED | null |
| migrate | DEPLOYED | null | DEPLOYED | null |
handleRestartInstance | DEPLOYED | UNLOCK | ||
handleRestartInstance | DEPLOYED | LOCK | ||
handleRestartInstance | DEPLOYED | null | UNDEPLOYED | null |
handleRestartInstance | UNDEPLOYED | null | DEPLOYED | null |
handleRestartInstance | DEPLOYED | null | DEPLOYED | null |
handleRestartInstance | DELETED | null | UNDEPLOYED | null |
handleRestartInstance | null | LOCKED | null | UNLOCKED |
handleRestartInstance | null | UNLOCKED | null | LOCKED |
Suggestions
DImplement actions as delete, updeploy and update could be considerate as idempotent actions. As example in a deleting or updating query (if they doesn't contain non-deterministic functional call) are idempotents.
In a scenario of an instance with more than one elements, and there is a failed undeployment, the user can try again, and the ACM-participant will try to undeploy all elements.
...
The table show the the allowed values using the "updateCompositionState" method.
| Method | StateChangeResult.NO_ERROR | StateChangeResult.FAILED |
|---|---|---|
| prime | PRIMED | COMMISSIONED |
| deprime | COMMISSIONED | PRIMED |
| handleRestartComposition PRIMED | PRIMED | |
| handleRestartComposition PRIMING | PRIMED | COMMISSIONED |
| handleRestartComposition DEPRIMING | COMMISSIONED | PRIMED |
Note:
"handleRestartInstance" and "handleRestartComposition" will be deprecated after the implementation of the BD for participants.