Author:
Fluent Commerce
Changed on:
16 Jan 2025
In this module you'll learn about how events are executed on the Fluent platform.
In this module, you'll learn about how events are executed on the Fluent platform. Let's begin by recalling some important concepts. Refresh your knowledge of workflows, states and rulesets:
A Workflow represents the journey of a Root entity and any related Sub-entity through various stages in its lifecycle, from initiation to its completion.
The lifecycle stages through which the entities move within the workflow are represented through States.
Rulesets are a collection of one or more Rules which are combined to form a single task within a process. Rulesets represent business logic within the workflow, including movement from one state to another.
A workflow is named by its Root Entity (1) and includes the lifecycles of its Sub-Entities (2)
Event Reference (3) is the entity type value used to post an event to a specific entity.
Platform CREATE Event? (4) indicates which entities the Fluent Platform automatically generates a CREATE event for, off the back of a Create mutation. When you create a new Order using the createOrder mutation, the Fluent platform will generate a CREATE event for that entity to allow the triggering of workflow-based business logic for that new Order.
Not all entities have a platform-generated CREATE event, however if it is an orchestrated entity, an event can be generated by an external system to trigger the workflow.
Root Entities (1) | Sub-Entities (2) | Event Reference (3) | Platform CREATE Event? (4) |
Location | Location | LOCATION | ❌ |
Order | Order | ORDER | ✅ |
Fulfillment Options | Fulfillment Options | FULFILMENT_OPTIONS | ✅ |
Product Catalogue | Product Catalogue | PRODUCT_CATALOGUE | ✅ |
Inventory Catalogue | Inventory Catalogue | INVENTORY_CATALOGUE | ✅ |
Virtual Catalogue | Virtual Catalogue | VIRTUAL_CATALOGUE | ❌ |
Control Group | Control Group | CONTROL_GROUP | ❌ |
Return Order | Return Order | RETURN_ORDER | ✅ |
Billing Account | Billing Account | BILLING_ACCOUNT | ✅ |
A JSON structure of a sample event is shown below and contains a number of attributes — this is the format of the Event API.
Entity type is Order, but it could also be Fulfillment, Articles or Consignment.
Event “name” is CancelOrder. It’s quite clear that it corresponds with the matching ruleset and encapsulates all of the business logic required to cancel an order.
1{
2 "name": "CancelOrder",
3 "retailerId": "1",
4 "entityId": "1234",
5 "entityRef": "ON-1234",
6 "entityType": "ORDER",
7 "rootEntityType": "ORDER",
8 "rootEntityId": "1234",
9 "rootEntityRef": "ON-1234",
10 "attributes": {
11 "cancelReason": "Stolen Credit Card"
12 }
13
14}
Language: json
Name: CancelOrder sample
Description:
CancelOrder sample
When an orchestration event is received, the Workflow Engine loads the workflow associated with the entity defined in the event context. Next, it searches for a ruleset using the primary Ruleset matching criteria, as follows:
Once the Ruleset is matched the Workflow Engine will execute it plus any subsequent rulesets. The rules within the ruleset may produce additional flow control events — we refer to these as inline events — to in-turn trigger additional Rulesets as part of the same action execution thread. These additional Rulesets will be matched and queued for execution in sequence after the initial Ruleset has been completed.
An example of an orchestration Event being processed inside the Workflow Engine is shown below.