Building a new eCommerce Platform (ECP) comes with the responsibility of integrating many systems, both new and old, for a seamless end-user experience. It is critical for all companies who are generating online orders and potentially obtaining new customers to have an infrastructure that is reliable and scalable—regardless of the size of their existing IT team—to support the systems.
One way to scale up integrations is to use the serverless technology that is more readily available to achieve business goals without increasing the size of the IT team to manage them. Microsoft Azure offers Function and Logic apps that allow IT teams to leverage monthly services that scale up and down as the business requires without having too many separate infrastructures in place.
Processing and fulfilling online orders require the interaction of multiple systems. In the simplest case it requires the interaction between the eCommerce Platform and your ERP system. Let’s focus on this simple case. A typical scenario for fulfilling online orders can be the following: customer places the order on the ECP, order is sent to the ERP for processing, ERP sends back updates to the ECP ranging from: the ERP Order ID to track the order, payment and shipment updates. All of these updates can span a few hours or take multiple days.
A first option, and the most obvious one, is to use a synchronous request-response integration design to implement the exchange of order data between your ECP and ERP. Below you can see a high-level diagram of how this would work.
It’s an easy and straightforward implementation, however, it comes with a few negative implications. This approach assumes that both your systems and network are functioning correctly all the time. When a customer places an order, the ECP sends the order at that moment, the network and ERP need to function correctly, otherwise you will end up with your online order stuck in your ECP.
Another negative implication is that you make your entire system less flexible. Your eCommerce platform is now strongly coupled with your ECP order service, so a change to your ECP order service might require a change in the way that the ECP sends the order data to the ERP. Implementing changes will take longer as it will require a closer collaboration between your ECP and ERP Teams.
For one of our clients, we chose an event-driven architecture for the integration between their eCommerce Platform and ERP using the Azure serverless services. For keeping this short and sweet, we will focus only on the order data integration scenario. There were several reasons that have guided us in this direction. We wanted an architecture that was flexible and allowed the client to implement enhancements and changes to one system without the need to modify the other system. We wanted a fault resilient design that can recover when one of the systems is down and resume the exchange of order data between the two systems as we had concerns about the overall availability of the ERP. We also wanted to keep the infrastructure cost low and avoid paying for resources that are underutilized as the client was experiencing high traffic through out several hours and then almost no traffic outside those hours.
Now let’s see how this worked. We will describe the ECP to ERP order flow (the pipeline situated at the top of the diagram). When a customer completes the checkout, the order is stored in the eCommerce Platform and then a lightweight order created event is published via HTTP into an Azure Event Grid (Order Events on the diagram). Azure Event Grid is a serverless and low-cost event backplane that can scale dynamically and is perfect for intercepting and storing lightweight events triggered by the eCommerce platform. A Logic App, called Order Events Processor, listens on the order events grid, picks up an event, extracts the order id, fetches the order data from eCommerce Platform using their REST API, and then stores the entire order information in a service bus queue (Online Orders in the diagram).
Using Logic Apps for this job has several advantages. First, they are serverless; you don’t need to maintain any infrastructure and they can scale indefinitely. For each new event Azure can spin up a new Logic App to process that event, however it is recommended to limit the number of parallel instances based on the throughput you would like the system to have. Second, Logic Apps require no code; you can configure them using a visual designed through the Azure Portal, so it allows you to quickly build it and then quickly adjust it while running. Third, you pay for what you use and the consumption model is based on pay per second.
The last component of this pipeline is the ERP Integrator that picks up orders from the Online Orders queue, performs any needed data transformation and then pushed the order into the ERP through their API. For integrators we use Azure Functions and not Logic Apps as we want to have the ability to write code. Usually, this step of the process is more code intensive and Azure Functions provide us with that flexibility.
The second pipeline that processes order updates originated by the ERP and consumed by the ECP is working in a similar fashion.
Since you do not need to maintain an infrastructure, you are able to scale indefinitely. Logic Apps allow you to build and adjust quickly while only paying for what you use. This approach enables you to integrate the ERP through Azure allowing you the ability to write code unique to your current solution. This serverless approach is ultimately the most beneficial because of its agility and scalability.
