Workflow Framework

Module Breakdown

Module 1. Workflow Framework — Overview and recap of key concepts

Module 2. Workflow Builder

Module 3. Workflow Patterns and Practices

Module 4. Event Execution

Lab

Order Management Experience (OMX)

• Web Apps 
• Modules
• Order Management Experience 
• Workflow Engine (also known as Orchestration Engine, code name Rubix)

•  Flexible Customisation – Composing logic in the workflow (rather than code), allows clients and partners more control over their business processes and reduces expensive and time-consuming change requests.
•  High performance and scalable processing –  Cloud technology provides on-demand scale, enables simultaneous processing of events and ensures the platform is processing as optimally and as efficiently as possible.
•  Low-Code Configuration –Allows users to view and configure without having to open any Java development environment.   Non-technical users can simply search, find and insert a Rule into a workflow.  Low code configuration also allows users to rapidly test and make changes to workflows without having to go through weeks or months of development cycles and testing cycles.
•  User Interaction – Enables smart integration of user-specific activities within workflow logic. This is because there are specific cases where an order process simply can't be automated 100%, and needs manual intervention. 

Key components of the Workflow Framework 

Review of key concepts related to Workflow Framework

• 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.

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

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

• 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. 

• BOOKED
• PICK_PACK
• SHIPPED
• COMPLETED
• CANCELLED 

• 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)

• Confirm Pick
• Cancel Order

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

• Rule 1.  Send an Order fulfilment Event for the Entity, Order.
• Rule 2. Send an email
• Rule 4.  Send Event to change Status of order from BOOKED to FULFILLED.

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

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

What Workflow Builder allows users to do

• Add and configure rules, rulesets and triggers.
• Configure rules at every stage of the workflow.
• Configure user actions for UI integration.
• Add/change states via JSON, and save via the workflow builder. The Workflow builder always only increments the minor version number of save— if a new major version is required this can be done via the JSON and/or API.
• Configure states and transitions to match the client's business process.

• States, Events and Triggers
• Rules and Rulesets
• Actions and User Actions
• Versioning — each workflow is versioned and saved using the standard format: <major>.<minor> for more information about versioning go to Lingo

Workflow Access

Working with Workflows

• Lifecycle Phases (or Categories) — the vertical coloured columns (swim lanes) represent the lifecycle phases (or categories) of the given entity.
• Statuses — Statuses (States) within the workflow are represented by the white rounded rectangles with a border colour matching the lifecycle phase they belong to.

Working with Rulesets

• Rulesets inside of the Status rounded rectangles are triggered on that State.
• Rulesets outside of a Status transition the entity to the state in which its line and arrow indicate.

• Name of the Ruleset
• Statuses for which the Ruleset applies
• Trigger description
• List of Rules and/or User Actions

•  The panel has the following sections:
  
  • Trigger
  • User Actions
  • Rules
  • Attributes (optional depending on rule configuration)

Working with Triggers

Working with User Actions

• Button Label —is a required field and provides the label that will be printed on the button when displayed on the User Interface.
• Button Type — is a required field and can be either Primary or Secondary. This indicates whether the button is displayed as a Primary or Secondary action in the UI. Secondary actions may not be visible without clicking on an ellipses button for extended options first.
• Modules selector — allows users to assign the Button to a web app.  At least one Module is required. 
• Confirmation Required checkbox — indicates whether or not the UI should prompt the user for confirmation of the action, prior to execution.

Working with Rules

• Search box: quickly find any Rules by filtering the Rule List as you type. Clicking on a Rule within the list will add it to the Ruleset Rules section, in readiness for the configuration of required input parameters.
• Input Parameters:  Rules in most cases require specific input parameters in order to execute their intended logic. These will be displayed, and provide a mechanism with which to capture the values. Where possible, these will be data type relevant. 

• Changing Order:  You can change the order of the Rules in the Ruleset by drag and drop.
• Removing a Rule:  To remove a Rule, click the TrashCan icon on the right side of the Rule, visible on mouse over.

Ideal responses:

• Small, isolated single-purpose building blocks, that on their own are not that useful
• Reusable and composable with other rules
• Are the smallest building block for a task (ruleset) in a process

• are composed of one to many building blocks
• may reuse rules from other rulesets one or more times
• combine to perform a specific purpose or task within a process

Let’s dig a little deeper:

• Every Rule in the Ruleset is executed in sequence.
• A Rule may or may not produce an outcome - i.e. it is conditional.

• The Rule Condition
• The Outcome (Action)

• Designed for a single purpose — they should do only one thing and produce only one action (if the Rule Condition is met).
• Simple, isolated and reusable — only use a few lines of code.  The key is not to lock away logic into the code.  This idea aligns with a core value proposition we're trying to promote of flexibility and readability.   
• Reused, try and reuse as many of the Rules as possible. It might just be that their parameters are configured slightly differently or they may be in a slightly different sequence — that's our intention.

• Aim to provide meaningful, descriptive names so that the workflow becomes self-describing and intuitive.  
• Try to align the name according to the piece of logic or function the Ruleset is performing within the workflow.  This makes it easier for other people to review a workflow and understand its intention.

Examples of use cases when best practises are applied:

• If there's a change in business requirements, it's easier to go in and make one, quick change.
• Having single-purpose, isolated Rules simplifies the troubleshooting process, making it easier and faster to navigate the workflow, and pinpoint and resolve issues.

• Perform a single function (E.g: CancelOrder) OR
• Perform a logical gate for directing execution flow by using If/Else logic OR
• Perform a State Management (E.g: SetAwaitingPayment) OR
• Perform another purpose such as notifying other orchestration contexts or other domains. (E.g.  If an order comes in, notify the Inventory Catalog to reserve the product at that particular location — You will learn more about logical gates & state Management in the next lesson.

• A Logical Gate is where the direction of the workflow execution depends on specific conditions being met, i.e. some kind of a logical condition that needs to be satisfied- so that the workflow knows which branch to execute next.
• Each Logical Gate involves a simple condition that evaluates to either TRUE or FALSE. This is represented by the diagram on the right.
• As seen in the diagram here:
  • X is evaluated here, where X could be an Event Attribute, an Entity Field, etc.
  • If X is found to be TRUE, then then X is sent to Branch A for further processing
  • Else, it is sent to Branch B for further processing.

• Depending on what was selected, X will be sent to either branches A, B or C for further processing.

• Logical Gates evaluate a simple condition by composition of rules
• Only 1 event (ever) output from the Ruleset
• Used for flow control, no other actions or outcomes should be present

• Only set new Entity States when the State is meaningful
• Don't set the same state from multiple Rulesets
• If and where possible, handle all state logic within a single execution thread, including child actions
• Only Change State using the dedicated ChangeState rule/action, and not together in a different mutation
• Consider using more states to help alleviate the discrepancies in meaning
• Use Ruleset triggers appropriately for helping to guard against illegal actions on states
• Identify Intervention states, such as FRAUD_CHECK, PAYMENT_FAILED, UNFULFILLABLE

• As far as a process flow is concerned, it can be initiated at either the Root Entity level or directly at the Sub-Entity level.
• And, within a single thread of execution, a process may flow across the same entity, down to a sub-entity, or back up to the parent or root entity.

• The event is fired against the Inventory Catalogue. 
• The Inventory Catalogue is then responsible for determining whether or not the position exists, before forwarding the flow appropriately.
• Either way an Inventory Position update includes either a new Inventory Quantity, or an updated Inventory Quantity, prior to recalculating the onHand value on the position level again.

• For each event received in the workflow engine, all rulesets triggered-off that event for the same context should be executed "inline". Rather than breaking the flow for a specific set of automated tasks in a process, they should be completed as part of a single transaction.
• Business logic should be visible in the workflow
• States should be meaningful and used appropriately
• Use meaningful Ruleset names and Rule names.
• Make sure Logical Gates are in the workflow, not in the rules
• Don't build cyclic flows (loops) into your workflow
• There is no parallel processing control. Don't Split and Merge within a single event or controlled transaction. Each rule and ruleset is executed in series on a single thread, and each action is applied in the order it was produced.

• Smaller more granular rules are more composable and reusable, resulting in more configuration based flexibility and adaptability, which ultimately enables our clients with agility when requirements or market conditions change.
• Composing logic in the workflow (rather than code), allows clients and partners more control over their business processes, and reduces expensive and time consuming change requests to development teams
• Lifting business logic into the workflow also makes the logic and process detail more transparent, and not locked into a “black box” in code. Granularity in the workflow also results in richer audit events, which make triage and problem identification more efficient, and faster resolution times when issues are faced in the process.

Orchestrateable entities and contexts

Example of root and sub-entities:

• Product Catalogue workflow contains the lifecycles for the Product Catalogue root entity, products and categories.
• Order Workflow contains the lifecycles and for Order, Fulfilment, Consignment and Article.
  

Example of a Sample Event

What happens when an orchestration event is received?

• Event Name = Ruleset Name
• Entity Type - e.g: Type = ORDER
• Entity Subtype - e.g: Order.type = HD
• Entity Status - e.g: Order.status = BOOKED