Order management system, accelerated by the Fluentcommerce platform

Today we are going to talk about a new commerce platform that allows you to build an order management system for your organization. We have already tried the Fluentcommerce OMS platform, made a successful release to one of our customers, and are happy to share our impression and experience with you.

Fluentcommerce is a relatively new player on the market with a modern event-based architecture that hosts on AWS cloud and takes care of service availability and platform updates.

Let us start with a generic description of a problem you can solve with Fluentcommerce. If you are planning or already have one or more channels to sell products (e.g. you have an E-commerce webshop, physical stores, and also some partner that also sells your products) you may face a problem that you would like to have centralized storage for information about your products and orders. Why?

• Having 1 place to see all orders is much easier than logging in and switching between several systems.

• It is simpler to organize some logic on processing unified data.

• To continue point (1) it is easier to organize customer support (CS) when you have a system that contains information about all orders.

• A single source of truth decreases the probability of issues related to data inconsistency. Fluent OMS allows you to have orders and inventory at the same place.

As our customer had already decided that it is necessary to have a system to manage orders by OMS, so, it was only a matter of choice to select an appropriate strategy to implement it. Basically, all the options you usually have are:

• Build solution from the scratch.

• Take some platform to accelerate development and build your logic on top of out-of-the-box (OOTB) solutions.

Option (1) is the best choice when you have unlimited time and resources, but let be honest, usually, both the customer and implementation team are limited about both things.

Platforms come and bring you some OOTB functionality and some UI after 1 or 2 weeks of initial setup. Looks like a silver bullet, but it is always mandatory to remember that every solution comes with some limitations.

So, how can you make a choice? One of the options is to organize a discovery to map expectations from the minimum valuable product (MVP) and options we have. We had a set of meetings for a couple of weeks where all the stakeholders (business, development team, and Fluentcommerce representatives) were able to match the expectations of business, features of the platform, and estimates from the development team.

As our customer was not interested in an inventory functionality (however Fluentcommerce does have it), it will be out of the scope of this article. Other things that we have used are the following:

API

Any OMS for any customer implies integrations with a few other systems. Fluentcommerce provides a reach API built on REST and GraphQL operations. REST operations are mostly deprecated by the moment of writing of this article and mostly used to push an event to the platform or to upload a plugin (We will talk about it further). As the architecture of the platform is “event-based” each piece of logic is encapsulated into the so-called “Rules” which are linked to the event that triggers it. The rule is a small java class that extends a base class from the SDK.

In order to trigger a rule linked to some event you can push a next call to the rest:

{
    "accountId": "accountid",
    "retailerId": "retailerid",
    "entityId": "8888",
    "entityRef": "entityRef",
    "entityType": "ORDER",
    "entitySubtype": "HD",
    "name": "Eventname",
    "attributes": {
        "eventAttribute1": "attributevalue"
    }
}

All the external data you want to pass to a rule can be added into the “attributes” section, and if you write logic inside a rule that parses this data you can use it. Simple enough, doesn’t it? Roughly speaking you can consider each rule as a microservice. Rules can trigger other rules by posting a new event. Another cool thing about Fluentcommerce API is GraphQL. Originally invented and implemented by Facebook this API provides a unified API that provides exactly the data needed by the client and it keeps the system clean from a set of the DTOs (data transfer objects) for the same entity with different sets of fields. A simple example of the GraphQL POST query you would use in the Fluentcommerce:

query getOrders($createdOnFilter : DateRange, $afterCursor : String) {
   orders(createdOn : $createdOnFilter, first : 100, after : $afterCursor){
      edges{
         node{
            ref
            createdOn
            totalPrice
            totalTaxPrice
            attributes {
               name
               type
               value
            }
            financialTransactions {
               edges {
                  node {
                     ref
                     total
                  }
               }
            }
         }
         cursor
      } 
   }
}

And input variables are:

{
 "createdOnFilter": {
  "from" : "2021-06-09T00:00:00Z",
  "to" : "2021-06-09T23:00:00Z"
 },

 "afterCursor" : "dasdasdasdasdasdasdsad"
}

So, what do we do? We create a custom client-based query getOrders that wraps orders query from the server and defines by what fields this query needs to be filtered and which fields we would get as a response. Edge and node encapsulate a single record from the database and “cursor” allows us to paginate data by setting up the first record to read and “first” set up how many records we need to get.

Orchestration

The business wanted to collect orders from different sales channels into one system and orchestrate the order lifecycle by the platform. Fluentcommerce covered this requirement through the feature called “workflow” which is represented by the JSON file where we link Rules and Events and define a sequence in which rules and events are to be triggered.

The platform allows to create workflows for the next entity types:

• ORDER

• RETURN

• LOCATION

• CUSTOMER

• INVENTORY

• PRODUCT

The platform comes with a library that contains some OOTB rules that in the opinion of the platform developers are most widely used. In case if needed more, you can create your own rule by extending classes from SDK:

@RuleInfo(   
    name = "RuleExample",
    description = "RuleExample",
    accepts = {
        @EventInfo(entityType = "ORDER")
    })
public class RuleExample implements Rule {
    @Override
    public void run(C context) {
    }
}

As a platform is event-based you need to keep in mind that all events inside it are asynchronous. This should be kept in mind in case of implementing a complex logic consisting of a few events and rules. The platform allows you to create an alternative workflow for orders depending on order subtypes. The platform can’t directly communicate with the other systems by posting data to them. Instead, it can use a webhook mechanism that calls 3rd party system endpoint and passes what operation they need to do. These systems read data from OMS using GraphQL API.

Data Model

The platform has a rigid data model consisted of predefined entities like order, customer, product, etc. In general, the OOTB data model covers almost all needs but it is not possible to create a new entity or to extend an entity with an additional field. If you do need to keep more data, you can use entity attributes which are a key-value structure. The main limit we had with such attributes is that it is not possible to filter queries data by them. So, if you see that the platform data model doesn’t match your data structure and after MVP or later you need to do a lot of different queries it may be a blocker for implementation or require to use some 3rd party solution to perform a search. As there were only a few places where we needed such filtering, we implemented it by reading some portion of data and filtering it on a Java code side. Another thing you need to keep in mind is that the platform allows only to create data and edit fields that are not used as the primary key, but it is not possible to delete data from the system. So once the data is written into the system, it will stay there forever. Although it is possible to delete the data with the help of support, it is a long operation that is not welcomed by a support team.

User Interface

Fluentcommerce comes with a so-called “console” – which represents a classic web administration application and a service portal, to provide access to warehouses and service points employees.

The web application is built with help of React but currently it doesn't matter as it is not possible to develop any changes or extensions to it. The only way to make any changes is to apply the so-called “Mystique” config. It is a set of properties by which you can select what fields to display on a list view or what text you want to display for which field. So if you are fine with the OOTB solution it is a good option, but if your project requires a lot of modification, it is better to develop a standalone UI or to select another solution instead of the Fluentcommerce platform.

Integrations

As in our case OMS was expected to get order data from multiple sources, we faced a problem that all systems that we need to integrate with have to support GraphQL queries and webhook mechanism. It is hard to expect that, especially keeping in mind that some systems provide as-is or as a service (as Fluentcommerce for example). In that case one of the possible solutions is to put some data transformation service between Fluentcommerce and systems you need to integrate with. Fortunately for us, our customer already had Mulesoft between all systems, so we just needed to integrate with it.

Accounts and Environments

Fluentcommerce platform is a fully cloud-based solution. To get access to the platform you need to buy an account. An account is a virtual, isolated environment or a set of environments linked to your account name. You will never need to worry wether your account occupies a few AWS virtual servers or even shares an AWS instance with some other client.

With a production account, we also got one UAT account and one DEV account. The UAT account can be used to make a demo to end-users or to perform pre-release testing.

DEV environment instead is dedicated to supporting developers. As the platform is a fully cloud solution, you can not run your code locally and check how it works. Once you write and cover code with Junit tests you can build a plugin (a simple jar file) and upload it to a server via postman on a specified endpoint. Then on that DEV env, you can modify the orchestration workflow file (JSON) and test rules interaction on a real system.

In our case, we got only 1 DEV env per team, so we needed to synchronize between developers on who is occupying the server at what time of a workday.

Another abstraction you have is a retailer. You can have a few retailers per account and by the idea of the platform architects, each retailer represents a single brand or a sales channel of the business.

All environments, retailers, locations, and all other things you need to set up a managed by rest and GraphQL calls. Fluentcommerce recommends using Postman to organize your rest calls collections however you may use any other tool if you find it more comfortable for you.

MVP and Post MVP Experience

As for any solution and any platform we met some issues during our work with this platform. Keeping them in mind you can better understand if the platform suits your business needs and knowing such issues beforehand you will pass them easier than we had.

• The platform is young, so it has some bugs. Even mature platforms have them, but in the case of a fully cloud platform, it can be a bigger problem. So do not expect you will be able to fix bugs just for your project. As you do not have access to platform code and basically the only thing you can push to the system is a small rule class, you will not be able to influence the orchestration behavior.

• Second thing, that comes from the same fact that the platform is very young and a list of the OOTB rules a very, very limited. If order entity orchestration comes with at least some basic rules, like copy attributes from an event or call a webhook, for other entities you can miss some essential rules and you would need to write them by yourself. In our case, it affected estimates we provided originally as we expected such rules to come with the platform.

• As was already mentioned, the data layer is rigid, and we could extend the data model only with a key-value attribute map. It is not possible to filter queries by such attributes on a data layer.

• It is hard to implement the first custom rules. The problem is that even OOTB rules you will get are hosted on a platform and we were not able to see any examples. Fortunately for us at the start of the project we got a few developers recommended by the platform who had already worked with it so they provided us such examples by implementing custom rules for our project.

• The only way to work with a platform is to pass a platform training during which you will get a temporary account that will work for a couple of weeks or buy a production account. It may become a problem as the only way to prepare a new developer to extend a team or to rotate a member of the existing team is to pass that training or to let the new developer working on a DEV that is used for development by the production team.

So, what we got as a result. After 4 months of work of a small team (it was 5 developers in the beginning and 2 in the end) we have successfully released an OMS that has pretty UI and that in the end met almost all requirements we needed. Keeping in mind the resources and time we had, the platform was our only possible choice, and we would not have achieved such results if we tried to build a solution from the scratch. The way the architecture of the platform was built allows you to have a team with not very experienced developers. Even with such team, you can build a good solution as the platform requires you to granulate your logic into small rules which are easy to understand and support.