Deploy is an example how state machine concepts can be used with an uml modeling to provide a generic error handling state. This state machine is a relatively complex example of how various features can be used to provide a centralized error handling concept.
![[Note]](images/note.png) | Note |
|---|---|
|
Above statechart is designed using Eclipse Papyrus Plugin Chapter 33, Eclipse Modeling Support and imported into Spring StateMachine via its uml model file. Actions and Guards defined in a model are resolved from a Spring Application Context. |
In this state machine scenario we have two different behaviors,
DEPLOY and UNDEPLOY what user tries to execute.
What is happening a above statechart:
-
In
DEPLOYstateINSTALLandSTARTstates are entered conditionally. We enterSTARTdirectly if product is already installed and no need to try toSTARTif install fails. -
In
UNDEPLOYstate we enterSTOPconditionally if application is already running. -
Conditional choices for
DEPLOYandUNDEPLOYare done via Choice pseudostate within those states and choices are selected by Guards. -
We used Exit Point pseudostates to have more controlled exit from
DEPLOYandUNDEPLOYstates. -
After exit from
DEPLOYandUNDEPLOYwe go through a Junction pseudostate to make a choice if we want to go throughERRORstate in case error was added into an Extended State. -
Finally we go back to
READYstate to process new requests.
Let’s get into actual demo. Run the boot based sample application:
# java -jar spring-statemachine-samples-deploy-2.1.0.M1.jar
In a browser you see something like:
![[Important]](images/important.png) | Important |
|---|---|
|
As we don’t have a real install, start or stop functionality we simulate failures by checking existence of particular message headers. |
Now you can start to send event to a machine and choose various message headers which will drive a different functionality.