Platform

This guide helps to select the correct IDP configuration and plan SSO implementation.

• Single sign-on (SSO) is exclusive to the OMX framework, and API users are managed in Fluent IdP, not Corporate IdP, with creation possible through API.
• SSO, enabled for each Fluent account, involves creating a corresponding SSO Ping Identity environment managed by the SRE team, covering admin user setup, password policy configuration, branding, and application enablement.
• SSO Environment Admin Users, Fluent IdP Configuration, Password Policy, and other guides provide comprehensive details for SSO enablement, Corporate IdP integration, user management, authentication policies, multi-factor authentication, and configurations with Azure AD and Okta.

This is a guidepost for Developers highlighting important guides and articles to speed up Fluent Commerce's learning process. 

• Workflows that consist of states, rulesets, triggers, user actions, and Modules, used for distributing workflows and it's artifacts, are a key part of the Fluent Commerce platform.
• Settings are used to adjust Workflow execution

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. It provides a complete and easy-to-understand description of the data in your API. Its ability to return select fields enables it to be used with powerful developer tools and ensures that APIs are easily scalable.

Fluent's GraphQL API has two operations:

• Queries 
• Mutations

Queries include predefined Queries and Custom Queries, both of which will be covered below.

• Operations
• Queries
• Mutations
• Custom Queries

If a company has an internal IdP then this IdP can be integrated with our SSO Vendor and used for future user authentication.

API user is always managed in the SSO vendor environment and doesn't have an MFA authentication option.

• For SSO to work, you need to establish a connection between your Corporate IdP and our vendor IdP. Once the relationship is established then your password policies and MFA configuration will be used during user authentication in Fluent.

The Ready for Launch process (RFL) is an engagement with the Fluent Commerce Expert Services team throughout the lifecycle of a Fluent project. The process is initiated at the beginning of a Fluent Commerce project and completed with the go-live of the project in production.

The final review ("RFL Launch Gate") should be planned for 3-4 weeks before the desired Go-Live event to receive the approval to move into production.

• The Kickoff stage covers the introduction to the Ready for Launch process and the initial project & solution overview.
• The Design Review stage covers a detailed presentation of the solution by the partner and the review of the implementation by Fluent Commerce.
• The Launch Gate stage covers the presentation of the final solution and performance test results as well as the confirmation of the desired launch date. After a final review, Fluent Commerce provides the production go-live approval.

The following guidelines and specifications apply to the entire schema, with any exceptions documented in the schema of the relevant entity.

• The GraphQL request size is limited to 2MB
• There is no validation on any of the GraphQL fields (except for enums)
• The GraphQL query complexity is limited and checked in accordance with the Query Complexity Calculation Algorithm (11,111 Total Complexity is Max)

A detailed explanation of Fluent OMS entities and how they can be used throughout the order journey.

• Entities in Fluent OMS are data objects that store and process information throughout the order journey, such as orders, fulfilments, and financial transactions.
• Entities are managed via GraphQL, with mutations and queries used to create, update, and retrieve entity data.
• Entities should not be deleted but controlled using status fields, although some "remove" mutations can disconnect entities.
• Orchestrated Entities trigger a CREATE event upon successful creation, enabling workflow automation.
• Entities in Fluent OMS serve unique purposes to enable an end-end digital commerce journey and their statuses determine at what stage they sit.

The Fluent platform generates unique IDs internally, which serve as the primary key for each new record. They are unique and enforced to avoid ambiguity. Users cannot set these via API. Whereas refs are typically from third-party integrations, they represent external system IDs and occasionally are generated internally with guaranteed uniqueness. It is the integrator's responsibility to ensure refs are unique in Fluent Commerce.

• IDs are generated by the Fluent platform and are guaranteed to be unique at the time of creation. 
• Refs are typically values passed in via third-party integrations and should represent the IDs from external systems.
• Despite the system not enforcing the uniqueness of refs, it is highly recommended to have unique refs for all entities. Every ref should be unique within it's nearest container, for example Retailer refs need to be unique across all . Catalogue or Account.
• If your refs are not unique then there are API's that will not work as expected. This means that our reference modules may not work as expected if you set ref's as non-unique values.

Exponential backoff is a standard error handling policy for network communications such as the Fluent APIs. 

Exponential backoff involves a client periodically retrying a failed request over an increasing amount of time.

• Retries & Exponential Back-offs

The Fluent Order Management Cloud Platform is underpinned by a comprehensive infrastructure designed to support order management and inventory availability processes, comprising of technical capabilities organized into Services and Frameworks, each facilitating specific functionalities critical to platform operations.

• Included Services and Frameworks:
  • Orchestration Engine, APIs, Logging, SSO, Cloud Infrastructure
  • Workflow, UX and Connect Frameworks