Designing Workflows

Pre-requisites

Please ensure you have read the following topics before reading this page:

• Rubix Orchestration Overview
• How Rubix Orchestration Works
• Getting Started with Rubix Orchestration

It is also required that you have an understanding of our Domain Model and Domain Driven Bounded Contexts.

Workflow Boundaries

Fluent follows Domain Driven Design Principles and has defined our various sub-domains as bounded contexts. This means that we have not built direct strong links between these domains, rather we use loosely coupled reference links between these contexts.

For example, the relationship between products and inventory is by reference, rather than by a direct relationship.

Furthermore, workflows are also defined per the root entity and the type field. A Workflow encompasses the child entities that form a part of its aggregate root.

For example, an Inventory Catalog is the aggregate root entity, which contains inventory positions and inventory quantities. The workflow for the Inventory Catalog includes the lifecycle flows for its child entities.

Workflow Patterns

The Rubix Orchestration Engine processes Rulesets within a single event execution in sequence, and each Rule within each Ruleset in sequence. Conditional flow control is implemented by directing events to different Rulesets, to trigger the appropriate logic intended for the next inline execution.

To learn more about how Rubix handles and processes an event, see Understanding Event Execution.

Flow Control

Almost all workflows include logical gates. A logical gate is where the direction of the workflow execution is dependent on specific conditions being met. Not all entities or executions follow the same path through the workflow. In order to implement a logical gate behaviour in workflows, you need to send an event to a named Ruleset when the condition is met, or another named Ruleset when the condition is not met.This often involves a simple Ruleset containing 2 instances of the same type of Rule. The first instance may validate the condition as TRUE, and send event A, while the second instance validates the condition as FALSE, and sends event B.

Cross-Retailer

In a multi-retailer scenario, workflows may need to notify or trigger a process execution in another retailer workflow. When this occurs, Rubix will automatically detect if the source event retailer reference and the produced event retailer reference are different, and ensure that the event is processed in a separate thread.

For more information, see Notify Another Retailer in Rule Actions.

Cross-Workflow

In many cases, workflows may need to trigger a process within another workflow. This involves sending an event from a Rule, only these events are not executed immediately within the same execution context or thread.

Workflow Versioning

Each workflow is versioned and saved using the standard format: 

`<major>.<minor>`

Creating the First Workflow

A workflow is based on the orchestrateable entity and its sub-type. For example, you can define a workflow for 

`ORDER`

`CC`

`HD`

Workflows are identified by the following format: 

`<ENTITY>::<SUB-TYPE>`

`ORDER:CC`

Creating workflows is done via the Workflow API. Please read the Worklfow API docs for more information.

Entity Workflow Matching

When an orchestrate-able entity is created within our system, it will be assigned to a valid workflow based on its type and sub-type. It will also be assigned to the latest currently active major version of the matching workflow.

For example, if you have an 

`ORDER::CC`

`1.2`

`O_CC_1`

`1`

When you update the 

`ORDER::CC`

`1.3`

`O_CC_1`

`1.3`

Should you choose to create a new major version of a given workflow, existing entities will not use new major versions. Only entities created after a new major workflow version will be assigned the new major version.

For example, if you have created 

`ORDER::CC`

`2.0`

`O_CC_1`

If you then create a new CC Order (let's call this 

`O_CC_2`

`ORDER::CC`

`2.0`

`2`

`O_CC_2`

When to Create New Major Versions

Major version changes are meant to be used to separate incompatible changes from existing entities using prior versions of workflows.

Originally, the Fluent platform automatically set either a major or minor version change, based on whether or not it detected structural change to the workflow. It considered things such as, new or different rules and rulesets, new user actions, trigger states, etc.

For the most part, workflow version changes are made more frequently during development, than after go-live. During development, the requirement is usually such that all entities should start using the new workflow, regardless of how different it is.

While this can result in certain entities being orphaned, or left in an incompatible state, we recognize that the decision to set the version number should be in the hands of the workflow configurator / developer.

To this end, Fluent will no longer automatically make a major version bump. The platform will make a minor version bump on update, since this supports the backward compatible behavior of the Workflow API. Only the latest minor version of a workflow is ever active, and available for execution.

If any of your existing entities require "migration" to your new workflow, this will be the responsibility of the workflow configurator / developer.

Examples of such activities may include state changes, sending webhooks, adding / updating attributes, etc.

Simply put, if you intend all existing and future entities to start using the new version of your workflow, make sure to only increase the minor version.

If you want to create a new version of a workflow that will only be used by newly created entities, then use a major version increase.

Defining Rulesets

Rulesets are configured by providing a name, valid trigger states, and one or many rules and user actions.

It is recommended to provide meaningful descriptive names for Rulesets, so that the workflow becomes self-describing and intuitive.

While Rulesets can be triggered by multiple states, it is recommended to minimize these, and most Rulesets would typically only have 1 trigger state.

Workflow Settings

There are a number of Workflow Settings that are designed ensure you get the most out of your Workflows. These settings can improve your workflows performance or change the behaviour of Actions. See the Workflow Settings page to see the full list of Workflow Settings.

What's Next?

The next document covers Understanding Event Execution, which is fundamental to designing workflows.

Thereafter, we highly recommend reading Designing Rules next, which provides some additional guidelines on how to break down your requirements into compose-able reusable rules.