Persistent States of Containerized xUML Services

Modeling integration scenarios frequently involves asynchronous processes. For example, a purchase order process is initialized by the first order. Then, the user adds new items until the process is closed by receiving the payment and sending the goods to the customer.
Such processes are also known as long running transactions. All activities involved in this process may be separated by days or even weeks making it necessary to hold the states of such a purchase order persistent.

The persistent state management of containerized xUML services involves the following functions:

• Querying the persistent state database by state, creation date / time and update date / time

• Viewing persistent state object details

• Deleting single and multiple persistent state objects

Open the details page of a containerized xUML service and switch to the Persistent State section. The initial page displays an overview of all persistent state classes and their states, in this example Ticketcreation. Each class corresponds to a Designer process:

Click on a persistent state class to display its different states. Refer to Querying the Persistent State Database for details:

Click on a state or use Expand to inspect the list of persistent state objects:

Click on an object in the list to open the persistent state object details page:

Querying the Persistent State Database

In the persistent state objects list, the names of all persistent state elements are displayed in normalized UML. Normalized means, all white spaces are replaced by underscores ('_'). The page displays the following:

(1) Breadcrump Navigation: Use the navigation to switch back to the list of persistent state classes.

(2) Filter: Use the filter to search for single persistent state objects.

(3) Persistent State List: Shows all available persistent states.

The list contains separate lists for each state:

A single persistent state object can be in various states at once.

Icon	Description
	Use this option to reload the persistent state list.
	Use this option to expand all listed states.
	Use this option to collapse all listed states.

Expand a list to display all persistent state objects in this state. For each object, the following information is displayed:

• Primary key

• Creation date

• Date of the last update

Use the filter field to search for specific objects. Use the icons in the footer to toggle between pages. In the footer, you can also specify the count of rows to be displayed for each table (Items per page):

If you want to inspect a single object, click on the primary key (refer to Viewing Persistent State Object Details for further information):

The list of states may contain a large amount of data. You can use the extended filter in the upper part of the page to minimize the list:

Filter	Usage
Count	Enter the number of objects you want to display. Always the latest objects are displayed. In order to see all objects, enter 0. Be careful using option 0, the database can contain a large amount of data!
Creation from... to...	Enter a date/time range. Use the calender to enter the date.
Last Update from... to...	Enter a date/time range. Use the calender to enter the date.
Apply Filter	Use this option to apply your filter.
+ Attributes	Use this option to add filters and specify a query.
Reset Filter	Use this option to clear the filter settings.

All persistent state information can also be viewed, if the service is stopped. This is helpful in case of debugging a service. But, in this case, browsing the persistent state details may be slower, as for each request the xUML Runtime is started to collect the information and stopped afterwards. The persistent state objects will not be changed in this case!

Viewing Persistent State Object Details

In the persistent state objects overview, for each persistent state object you can see primary key, creation date/time and date/time of the last update. When clicking on the primary key of an object, more details can be viewed in the object details view:

Content	Description
Primary Key	All key fields are displayed, separated by comma.
Creation	The timestamp of the creation of the persistent state object.
Last Update	The timestamp of the last update of the persistent state object.
States	In this box, the state of the persistent state object and all substates are listed with Creation timestamp and status. The state name is the normalized UML name. Normalized means, all white spaces are replaced by underscores ('_'). You have also two options to send signals to the object, refer to Sending Signals to Persistent State Objects for details. The name of the final state will never be seen because by entering the final state the object ceases to exist. However, while destroying the object, the state machine is in the state --8<-- . Think of --8<-- as an internal state name for the final state. So every object will reach this state before it gets deleted from the database. The state name --8<-- is strange by design to prevent a clash with other state names. If the state engine has a low load you will perhaps never see objects in this state. If the state engine is very busy you can see a lot of such objects but this is no problem.
Events	A list of all events that occurred on this state object and are not yet finished is displayed. Click on the event name to display further details, refer to Inspecting Event Details for more information.
Object Information	The json editor contains the persistent state data, displayed in json format. Use option Download to download a json file with the object information. Use option Copy to clipboard to copy the content of the editor to the clipboard.

Sending Signals to Persistent State Objects 

In the States section, you can find several icons to send signals: Retry Transitions and Send Signal (one for each signal that can be send to the displayed persistent state object).

• Use Retry to resend the last signal to the persistent state object, if that last transition has failed.

• Click on one of the other buttons to send the indicated signal.

Sending signals can be useful

• during development, if you want to test a persistent state service.

• when the service is running in production, to release a persistent state object that got stalled in a state.

Inspecting Event Details

In the persistent state object list, a list of all events that occurred on this state object and are not yet finished is displayed. Click on the event name to display further details:

The following information is displayed:

Deleting Persistent State Objects

You have two options to delete persistent state objects. You can delete...

• ... multiple objects at once using the list of persistent states.

• ... single objects on the the object details page.

Deleting Multiple Objects 

You can use the persistent state objects list to delete several persistent state objects at once. Select the checkbox in front of the objects that you want to delete, then click option Delete:

Since an object can be in different states at once, a selected object will be deleted from all states.

You can also select all displayed objects by using the checkbox in the header of the list:

This option does only select the objects that are displayed in the current table view, not all objects in this state.

You need to confirm your choice:

Deleting a Single Object

Use option Delete Object on the object details page to delete a single persistent state object:

You need to confirm the deletion: