Recap of Workflow Framework

In this lesson, we'll revise some fundamental concepts and terminologies.

Workflow Framework Key Concepts

Event: An Event represents something that has, will, or is happening within the Fluent Commerce platform.  It is typically used to trigger the platform to do something (ORCHESTRATION Event) or log activity (ORCHESTRATION_AUDIT Event).

Example of use cases for events:

• A client system might send an Event to cancel an in-progress order.
• When an entity's state changes, such as the Order moves from Created to Booked, an Event is written indicating that this happened.
• An order is set to expire after a configurable period of time to ensure that it gets re-routed to another location to be fulfilled.

Rule: A Rule represents a single building block of business logic and has a single purpose.  Rules may produce a single Action, such as changing the state of an entity or sending a new Event.

Example of rules:

• Change the state of an entity
• Send an email
• Notify a Warehouse Management System (WMS) of a fulfillment request
• Send a new Event
• Updating data on an Entity

Ruleset: A Ruleset is a collection of one or more Rules that are combined to form a single step within a process. 

Example of a Ruleset:

Imagine a step to annotate an Order with some flags before continuing processing.  We could define a Ruleset that contains a rule to add an attribute to the order if the order value is greater than a configured threshold. 

We could also add rules to flag if the order is from a new customer or from a VIP customer. This Ruleset might contain the following rules:

• MarkOrderHighValue (Threshold: $200)
• MarkOrderFromNewCustomer
• MarkOrderFromVIPCustomer
• ForwardTo (EventName: ValidateBooking)

Trigger: A Trigger defines the conditions under which a specific Ruleset within a Workflow will be executed upon when a matching event is received.  A Ruleset is triggered when an Event is received that contains the exact matching criteria for that Ruleset.  Rulesets can be triggered via events received either internally (from another Ruleset), externally (another system), or via user-generated actions from a UI.

Example of a trigger:

Triggers help ensure that specific Rulesets are only executed when valid to do so. 

For example:

• We have an Order in the system with a reference HD_1234 — it was currently in a status RECEIVED.  
• The next Event is for a Ruleset called AnnotateOrder, which has a trigger status of RECEIVED. 

Since the Order is currently in the RECEIVED status, the Ruleset would be executed.   

However, if the Order was in a different status, such as BOOKED, or PICK_PACK, then the Event would not match the AnnotateOrder Ruleset, and no actions would be executed.

Status: A Status represents an entity's specific condition and state at any given time within its lifecycle. In other words, it represents the current point at which the entity is within the workflow's business logic.

Statuses are configurable, other than the first state of CREATED.

Examples of statuses:

• BOOKED
• PICK_PACK
• SHIPPED
• COMPLETED
• CANCELLED 

Action: An Action represents an outcome of a Rule.

Examples of actions:

Some common examples of Actions include:

• Creating a new Event
• Creating or updating an entity via the API
• Triggering a third-party action (sending a webhook notification to an external system)

Actions are generally collected and run together at the end of the current event execution. 

User Action:  A User Action is a UI interaction such as a button and labels.  It can be integrated with workflows on Fluent Web apps.   

Examples of user actions:

• Confirm Pick
• Cancel Order

Lego is a useful analogy to help understand the relationship between Rules and Rulesets

On the left are single Lego blocks, which represent a Rule.  Rules are the smallest building block for a task (ruleset) in a process.  Combining single Rules in different sequences makes a Ruleset, represented by the Lego blocks on the right.

Single Lego blocks are not very useful on their own, but when combined in different sequences, they form Rulesets that execute different pieces of logic — this logic could be to perform a specific task within a business process, for example .

Let's say we've defined the following Rules:

• Rule 1.  Send an Order fulfillment Event for the entity Order.
• Rule 2. Send an email
• Rule 4.  Send an Event to change the status of the order from BOOKED to FULFILLED.

Combining Rule 1, 2 & 4 produces Ruleset 1.

Ruleset 1 accomplishes the goal of sending an order fulfillment event for the Order entity, and also sending an email about confirmation of a change in the state of an order from booked to fulfilled.

All Events enter the OMX Workflow Framework via the Fluent APIs.  The Workflow Framework processes these Events via the Event Queue, matching the correct workflow and Rulesets to execute — this all occurs within the Workflow Engine.

Outbound (Actions) from the Workflows retrieved from the Rules are returned back and applied via the Fluent APIs

The Action can:

•  Trigger an outbound event, or
• Trigger a mutation — a mutation triggers a change or update in data.

Workflow phases and states

Each workflow has phases (Categories) that the entity flows through from beginning to completion. A default Order workflow for example, involves 4 phases:

Booking, Fulfillment, Delivery, and Done/Complete.

Each of these phases can contain one or many statuses:

• BOOKING: Booked Awaiting Payment, Check Fraud
• FULFILLMENT: Picking, Packing, Fulfilled
• DELIVERY: Awaiting Delivery, Delivered
• DONE: Complete, Cancel