You are currently viewing Building a Trading Platform – Part 8: Modelling Process Flows

Building a Trading Platform – Part 8: Modelling Process Flows

We determined that your world consists of Entities which can either be objects or orders. Orders can be either transactional or master data orders. Transactional orders trigger a booking, while Master Data Orders create or modify objects. Both order types exist to model and execute process flows. The only different being, what they do within each of their processes. 

Since the creation and balancing of transactions that trigger bookings is a lot harder than the creation of modification of objects, we will begin the creation of our process flows based on master data orders. In this blog, we will adhere to the basic principles of BPMN to model the processes we want to create. For reference, let us have a look at the process flow from the previous article:

Every process consists of process states and process actions that transition the order from one state to the next. There is a start state and one or more final states. Moreover, some process actions execute additional operations, like persisting an object into the database. Both process states and process actions are control data and therefore modelled as complex enumerations in our application. That helps enhance our systems performance by reducing database operations.

Process States

A process status is an attribute of an order that describes, where in the process flow the order currently is and if the order attributes can be modified. A process status can either be generic, meaning it available for all Business Types of its Data Kind, or it can be business type specific, like only usable for OBJ_USER.

Process Actions

Based on process actions, our application can determine which actions are allowed at which status and which status any action will lead to. Like process states, process actions can be business type specific or generic. Besides pure process control capabilities, master data process actions also contain properties that affect their underlying objects, like the ability to lock, persist and release them.

How do we move our order through the process?

Using Actions and States, we have been able to build a process flow for our orders. With additional properties on process actions, we also found a way to allow a limited range of operations based purely on the modelled process.

Order transitions

This is where order transitions come in. Order transitions are like vessels that carry our order from one harbour (process status) to the next, along the lines of our defined shipping canals (process actions).

The navigator of the vessel is the @Service bean of the order. It selects the right process action and executes the transition. While doing so, it respects all required rules and executes any additional operation as advised by the order action. Once the work is done, the transition gets documented in the logbook, which in our application is the order transition @Entity. The transition therefore simply documents the order that was transferred, the action used to define the path of the transition and the involved process states, that is the old and the new process status of the order.

For now, that is all we need to implement a simple workflow. The next article will demonstrate, how we can historize our object data based on the orders that modify our master data.

Leave a Reply