Author:
Fluent Commerce
Changed on:
9 July 2024
Fluent Commerce is a flexible platform with two core components: the UX component for rendering UI and the Workflow Framework responsible for order processes. The platform comes with a range of SDKs for custom development and a set of reference modules.
Author:
Fluent Commerce
Changed on:
9 July 2024
The OMX UX Framework, or Mystique, delivers configuration-based solution implementation for UIs (Web Apps) that understand the Fluent Platform. It enables UIs to react to changes within workflows and provides best-in-class user experience and design. Web apps can be built using code-free configuration, utilising a rich library of ready-to-use UI Components. Customising UIs to meet specific business requirements using Component SDKs is also possible. Configuration is managed in a JSON document called the OMX Web App Manifest.
The OMX UX Framework consists of the following parts:
Additionally, it provides Role and User context to support organisational structure and processes,
Component SDK provides the ability to develop new custom components for extending the standard library.
Areas of extension include:
Some Utility Components are also provided to make building custom components easier and more consistent.
Author:
Fluent Commerce
Changed on:
6 June 2024
The Workflow Engine (aka Rubix) is the engine that drives the Fluent platform. The Workflow Engine enables business process orchestration, workflow automation, and underpins the specific feature sets and functionality for each of the Fluent apps. Additionally, the Workflow Engine is built to be highly scalable, and provide high-performance workflow execution across any domain.
Check a video of the Rubix Orchestration Engine Overview below.
Understand the role and purpose of the Rubix Orchestration Engine through this 3-minute overview video.
The Workflow Engine has a rich rule library and pre-built workflows, including industry-tested reusable rules for Order Management, Store Fulfillment, Product Availability, Global Inventory, and Insights. Reference Modules that contain sample Workflows to use as is or as a starting point for customization.
The Workflow Builder is the business user-friendly user interface that manifests the Workflow Engine. The Workflow Builder is used to create, configure, view, and edit workflows and automation processes.
The User Action Editor of the Workflow Builder can be used to Integrate user-driven activities with workflow rules and automation. Additionally, the User Action Editor provides configurations for adding buttons to Fluent OMS or Fluent Store applications, that trigger automated workflow behavior.
Using the Workflow Builder, business users can customize the pre-built workflows with additional rules from the Rule Library, or reconfigure the existinthatg rules.
Developers can customize, extend, and integrate additional capabilities and rules into workflows with the Rules SDK. The Rules SDK provides Java Developers with the ability to build custom client-specific business logic, rules, and integrations into a plugin which can be uploaded and used in the Fluent Platform.
Learn more about how the Workflow Engine works here.
Author:
Fluent Commerce
Changed on:
1 July 2024
Connect SDK is the launchpad to connect any external system with Fluent Commerce in a predictable way. It reduces implementation timelines and costs so customers can see faster ROI. Technically, Connect SDK is a Java Maven Archetype and Java Library Utils that form a toolkit for building Spring Boot micro-service applications that communicate with the Fluent Order Management System and any external system.
Connect SDK is the launchpad to connect any external system with Fluent Commerce in a predictable way. It reduces implementation timelines and costs so customers can see faster ROI.
If the customer needs to create a new application or service that requires integration with multiple devices and services, then Connect SDK is beneficial to provide standardized APIs and pre-built functionality to simplify the development process connecting to the Fluent platform. Each connector built on Connect SDK can be deployed and scaled independently, giving flexibility for a multi-cloud deployment strategy to reduce risk at a lower cost than replicating the existing middleware across clouds.
It would also depend on the existing middleware. One can expose the connectors built on Connect SDK using endpoints and build wrappers specific to middleware. The Mule and WSO2 adapters will wrap that interface so that any handler built on the Connect SDK will be portable across different ESB solutions.
With that, you can import our functionality (auth, API calls, common use cases like paginating a connection, loading settings, etc.) and have them appear as configurable nodes in the Integration Studio low-code experience.
Any connector built using Connect SDK is cloud-agnostic, and the integration layer is still owned and maintained by the solution integrator and becomes part of the project codebase.
Here is the support matrix for Connect SDK:
The Connect SDK offers incredible flexibility in building synchronous and asynchronous endpoints with a common credential, logging, and configuration interface. Customers and partners can easily customise the logic within the endpoint to meet specific requirements. If real-time responses are needed for front-end applications, synchronous calls can be made directly to Fluent by bypassing the queue logic. For example, the product availability integration uses synchronous calls to access the Fluent fulfilment option mutation directly. This same approach can be applied to virtual position calls or time-bound order searches. We recommend an asynchronous approach for all other integrations for scalability and flexibility.
Author:
Fluent Commerce
Changed on:
8 July 2024
General Principles and the Features of the SDK
The Component SDK allows clients and partners to develop new components to extend the functionality of the Fluent web apps.
Areas of extension include:
new cards to display information from Fluent APIs or external sources | new form field types that work with rules to extend user action capability | entirely new customised pages |
Custom components are generic React components, but via provided hooks can also take advantage of core features of the UX framework, including:
Custom components can easily interact with OMX functionality via the provided hooks.
Some utility components are provided to make building custom components easier and more consistent.
Before a custom component can be used in an OMX web app, it must be registered with one of the three registries:
Details on each can be found on the registries page.
Information on getting started, setting up your project, and unit testing can be found here.
Author:
Fluent Commerce
Changed on:
15 May 2024
This section covers the fundamentals of the Workflow Engine, provides an overview of the architecture, identifies key concepts, and prepares clients to build and use their workflows.
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:
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:
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.
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.
Below are the key concepts that make up the capability of the Workflow Engine:
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.
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.
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:
Essentially, events are notifications within the system that can be consumed by various internal or external systems in order to take further action.
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.
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:
Any changes to be made as a result of running a Rule by the Workflow Engine are returned in the form of an Action.
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.
An Action represents an outcome of a Rule.
Some common examples of Actions include:
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 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.
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:
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.
Author:
Fluent Commerce
Changed on:
20 Sept 2024
This article introduces the concept of a Fluent Commerce Module, describing it's basic structure and content.
A Module is a group of Artifacts bundled together to achieve a domain functionality. Artifacts can be built by:
Artifacts also include Settings.
A valid Module can contain any combination of Artifacts, however, they must also contain Metadata. Together, the Artifacts in a Module should provide a single package of domain capability or a reference to create or extend domain capability. Modules work together and extend each other.
There are two categories of Module, Reference Modules and Extensions.
A module must contain Metadata, but can otherwise have any combination of the following Artifacts:
Artifact Name | Mandatory |
Metadata | Yes |
Rules | No |
Workflows | No |
Settings | No |
Web App Manifests | No |
Translations | No |
UI Components | No |
Structural data | No |
Metadata contains information about the Module's name, publisher, version, author(s), Dependencies, and Contracts.
Dependencies are either Modules or Contracts that must exist on an account before the Module with the dependency can be installed.
A Contract is a document that defines what input and output events are required for a Module to work. Contracts offer a convenient way to specify workflow compatibility between Reference Modules, Extensions and Connectors”
A Rule represents an atomic piece of 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. Learn more about Rules here.
Workflows describe business process orchestration that underpin specific feature sets and functionality for each of the Fluent apps. Workflows run on the Workflow Engine.
Settings are key-value pairs set in a Context (Account, Retailer, Location/Agent) that the Fluent Platform, Workflows and Web App Manifests use to drive their logic. Learn more about Settings.
A Web App Manifest is a type of Setting that describes an App. A Web App Manifest may extend an existing app, like Fluent OMS or Fluent Store, or could create an entirely new app. The Manifest also describes the layout and components of a page within an app. Learn more about the UX Framework.
Translations are a type Setting that enables the translation of an app into another language. Learn more about Translations.
Components are referenced in Web App Manifests and used to control how a user interacts with an app. See available components in our Component Library. Learn more about building UI Components.
Author:
Fluent Commerce
Changed on:
2 July 2024
A Reference Module is a Module provided by Fluent Commerce that is designed to provide reference artifacts that you can use to create your own solutions. While an Extension contains an entire solution within itself, Reference Modules provide Domain Artifacts that can be used to speed up building your solutions. Structurally, Reference Modules are identical to Modules, as are Extensions.
Authors:
Randy Chan, Esma Tuzovic, Cille Schliebitz, Holger Lierse, Ben Harrison
Changed on:
6 May 2024
The Fluent platform provides a comprehensive user role management system, allowing for the assignment of diverse permissions via roles to regulate platform access and functionalities. Custom roles can be created and fine-tuned, ensuring users only have access to appropriate functionality and data. The system provides flexibility to specify the scope for a role at different context levels, such as Accounts, Retailers, and Locations.
The Fluent platform comes with user role management, which defines the actions a user can undertake, such as modifying a workflow or editing a location. To configure a user, permissions must be assigned to roles, and then roles must be assigned to users at a specific context level. Users may be assigned one or multiple roles at different context levels.
The user
`Type`
Represents a single access right. Permissions follow a naming convention of NOUN_VERB (e.g. ORDER_UPDATE). They allow users to perform specific actions on an entity, such as VIEW, CREATE, and UPDATE. For example, the ORDER_UPDATE permission allows a user to edit the Order entity.
Permissions are assigned to roles, enabling the role to perform specific actions. The list of permissions defined by the Fluent platform can be found in the GraphQL Permissions list.
Permissions currently protect every GraphQL operation
A collection of permissions that can apply to a User in a given Context. Users can be assigned one or multiple roles. Roles can be created using GQL mutation or in the OMS web apps. For more on Role creation and editing within OMS web apps, consult How to create and edit a Role.
Some
`ROLE`
There is a set of roles that come with every account, this is how you retrieve them:
1{
2 roles(first:1000){
3 edges{
4 node{
5 name
6 permissions{
7 name
8 }
9 }
10 }
11 }
12}
Language: plain_text
Name: Retrieving Roles
Description:
[Warning: empty required content area]You can also create your own custom roles to fit your unique business requirements, either in the OMS Webapp (consult the Role Creation and Editing Mutations article), or via GraphQL mutation here is an example:
1mutation createRole {
2 createRole (
3 input: {
4 name: "${role}",
5 permissions: [
6 {name:"${name}"}
7 ...
8 ]
9 }
10 ) {
11 id
12 name
13 }
14}
Language: plain_text
Name: GraphQL mutation to create a custom Role
Description:
[Warning: empty required content area]When a user as the ROLE_MANAGER and the USER_MANAGER roles assigned on ACCOUNT context level, it can perform user management tasks.
Users who have these roles assigned are allowed to perform the following actions:
Check the above "Viewing all permissions" callout to see all available User permissions.
You can configure Users (create, add, and delete) via SSO (using a Corporate IDP Integration) or directly in the User admin section in the Fluent OMS app (read User Configuration Overview to learn more). However, Roles & Permissions are currently managed via Fluent, unless you decide to use the Fluent-supported SCIM Connector. Learn about Exploring Roles & Permissions via the UI.
`{{activeRetailer.id}}`
`{{activeLocation.ref}}`
`fulfilments`
Copyright © 2024 Fluent Retail Pty Ltd (trading as Fluent Commerce). All rights reserved. No materials on this docs.fluentcommerce.com site may be used in any way and/or for any purpose without prior written authorisation from Fluent Commerce. Current customers and partners shall use these materials strictly in accordance with the terms and conditions of their written agreements with Fluent Commerce or its affiliates.