Workflow Framework and the Rules SDK

How it Works

The Workflow Engine works by shifting system logic (previously available in the platform API), code and middleware, into rule-based and code-free workflows.

The Workflow Engine allows clients to get to market quickly by making use of the Fluent platform's pre-built workflows or by customising and differentiating their Omni-channel commerce processes further by configuring workflows and custom rules with the Rules SDK.

The Workflow Engine is made of the following components:

• Pre-built workflows across a growing number of Omni-channel domains.
• Rich rule library.
• Workflow Builder provides a visual user interface for workflows and rule management.
• Rules SDK for developers to build plugins with custom rules
• Workflow core concepts.

Workflow Engine Architecture

The Workflow Engine is the foundation and engine of the Fluent platform. It sits under the Commerce apps to execute business logic driven by rules and workflows.

The Workflow Engine is made of the following key components:

• Workflow Engine - the highly scalable engine that processes and executes workflows.
• Workflow Builder - the business-friendly UI that enables configuration and management of workflows.
• Rule Plugins - separately built artifacts (both Fluent and 3rd Party) containing one or more rules that can be uploaded and installed into the Workflow Engine.
• Rule SDK - the developer-friendly tooling that enables integration, extension, and customisation of workflows and rules (APIs, Plugins, Schema).

Workflow Builder

The Workflow Builder provides an intuitive user experience for non-technical users to view, modify and create workflows and user actions. Additionally, it helps to reduce implementation costs and time to market.

To read more, see the Workflow Builder page.

Rules SDK

The Rules SDK enables developers to write custom logic into rules, which are compiled into a plugin that can be uploaded for use in workflows without affecting any other part of their system.

To read more and get started with developing custom rules, see the Rules SDK page.

Key Concepts of the Workflow Engine

Below are the key concepts that make up the capability of the Workflow Engine:

• Workflows
• States
• Events
• Triggers
• Rules
• Rulesets
• Actions
• User Actions
• Versioning

Workflows

A workflow defines the logical flow or lifecycle of a top-level entity1 within a domain2. For example, the Order Management domain has a top-level entity of 

`Order`

`Order`

`Order`

`Order`

`OrderItem`

`Customer`

`Order`

`Consignment`

`Order`

A lifecycle typically involves a number of stages in which the entity moves. The stages that an entity moves through a workflow are represented through 

`State`

The transition of an entity through its different states within the lifecycle is driven by business logic contained within Rules. 

`Rules`

`RuleSets`

`Event`

A retailer can have multiple workflows associated with a top-level entity. However, the entry trigger for each of the workflows should be unique. This allows for multiple workflows to exist with different entry triggers for the same Entity so that the system can identify one and only one workflow to execute.

Workflows can contain multiple Rulesets, and Rulesets can contain multiple Rules.

Workflows for an entity can interact with the workflows of other Entities. These interactions occur through Events.

1 An entity is an object of importance in the system that we want to model and store information about. View Fluent Commerce's entity-relationship model which represents the business data schema in graphical form.

2 A domain is an area of capability, such as Order Management, Global Inventory, Store Fulfillment, etc.

States

A State represents a specific condition and phase of the entity at any given time within the lifecycle. In other words, it represents the point at which the entity is within the workflow's business logic.

Events

An Event represents something that has, will, or is happening within the system. An Event is typically used to ask or trigger the system to do something or log activity of what has happened within the system.

For example:

• A client system might create an Event on the Fluent Platform with details about a new Order. This may trigger a specific workflow to be executed as a result.
• When an entity's state changes, such as the Order moves from "Created" to "Booked", an Event is written indicating that this happened.

Essentially, events are notifications within the system that can be consumed by various internal or external systems in order to take further action.

Triggers

A Trigger is the exact criteria for which a specific Ruleset within a Workflow will be executed upon a given Event.

A Ruleset is triggered when an Event is received that contains the exact matching criteria for that Ruleset.

A Trigger essentially defines the contract for the Event required to execute its Ruleset.

Rulesets can be triggered via events received either internally, externally, or via user-generated actions.

Rules

A Rule represents an atomic business logic which can be configured and reused. A commonly used analogy for describing Rules is LEGO bricks which we can click together in different configurations to create a different outcome.

Some common examples of use cases for Rules include the following:

• Change the state of an entity
• Send an email
• Fulfil Order From Collection Point
• Fulfil Order From DC
• Send a new Event

Any changes to be made as a result of running a Rule by the Workflow Engine are returned in the form of an Action.

Rulesets

A Ruleset is a collection of one or more Rules which get executed upon receiving a matching trigger via an Event. Rulesets are a combination of rules to deliver a piece of business logic.

The execution of a Ruleset can transition the entity through the lifecycle by changing its state, or it may just result in non-transitional actions, such as sending an email to a customer.

Actions

An Action represents an outcome of a Rule.

Some common examples of Actions include:

• Creating a new Event
• Creating or updating an entity via the API
• Triggering a third-party action (sending an email or making a service call against a client API as an example)

Actions are generally collected and run together at the end of a Ruleset. Doing so allows the system to maintain an assignable or transactional process.

For example, if one Rule fails, the entity is not left in a half-modified state, and the same Ruleset can be re-run at a later stage without risk of duplicating entities or double sending customer notifications.

User Actions

User Actions are the mechanism by which user interactions can be integrated with workflows. For example, via our mobile-friendly web applications, Fluent OMS and Fluent Store.

A User Action is essentially an external view of a Trigger, along with some additional attributes to represent UI interactions, such as buttons and labels, etc. The result is that a user can click a button on Fluent OMS, potentially supply additional data via inputs, and it fires the event that will trigger a specific Ruleset relevant to the specific business logic intended to be executed by that user action.

Versioning

Finally, it is important to understand how versioning works within the Workflow Engine. Workflows are versioned, thus any subsequent modification of an existing workflow by a Retailer results in the automatic creation of a new version of the workflow.

Workflows have a major version and a minor version associated with it:

• A major version represents a major change in the flow, such as an addition of a new state transition and new business logic.
• A minor change involves changing parameters, such as changing the email template for customer notifications or updating the expiry time of articles.

Importantly, to maintain data integrity, an entity instance executing within a workflow will continue executing within the same workflow version even if a newer version exists.

New instances of the entity will be executed within the new version of the workflow.