State Logic

In the previous chapters, we learned that a business process spends most of its time waiting in states. When the process is in a particular state, the application must delegate control to something that can handle that state.

This chapter introduces an important separation:

• State logic selects the correct state handler for the current business process state.
• State handler implements what should happen in that state (a UI page, a background component, etc.).

State logic is the process of selecting a state handler for the current business process state.

A Simple Example

Consider the following fragment of a state diagram. The process waits in the initial state until the trigger “Verify health card validity” starts work. After verification, business logic chooses the next state: “The health card is valid” or “The health card is not valid”.

Now imagine this process implemented in an application with a user interface. While the business process is in the initial state, the application should show a page that represents that state, for example:

The page itself is a state handler. It can remain on the screen indefinitely because the business process is waiting. When the user clicks “Verify health card”, the click acts as a trigger and starts a transition.

After the transition completes, business logic chooses the next state. If the next state is “The health card is not valid”, the application must display a different page that represents that state, for example:

State Logic vs State Handler

It is important to keep these two responsibilities separate.

A state handler is the component that handles a specific state. Depending on the application, a handler may:

• Render a UI page for that state
• Enable actions that represent triggers
• Run background work that is appropriate for that state

State logic does not do any of that work. State logic only performs selection. It answers one question: Given the current state name, which handler should handle it?

How State Logic Works

State logic is usually very small and very mechanical. It performs two steps:

• Find a state handler registered for the current state.
• Transfer control to the selected handler.

The “transfer control” step depends on the environment:

• In a UI application, transfer control means displaying the selected page/component.
• In a background process, transfer control means invoking or scheduling the selected handler component.

But the core responsibility remains the same: selection of the correct handler.

Visual and Non-Visual State Handlers

The same state logic concept works for both interactive and background processes.

In a visual application, state handlers are typically pages or UI components. In a non-visual application, state handlers are service components that handle states such as “Idle”, “Processing”, or “Error”.

For example, a background email processing system may stay in an “Idle” state until an email arrives. If business logic moves the process to an “Email Processing Error” state, state logic selects the handler responsible for that error state and passes control to it (for example, to log the error, notify support, or retry).

Table of Content Introduction into Business Process Previous: Data Access Logic Next: Business Process Activities