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 and 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 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 ECPto ERP order flow (the pipeline situated at the top of the diagram). When acustomer completes the checkout, the order is stored in the eCommerce Platformand then a lightweight order created event is published via HTTP into an AzureEvent Grid (Order Events on the diagram). Azure Event Grid is a serverless andlow-cost event backplane that can scale dynamically and is perfect forintercepting and storing lightweight events triggered by the eCommerceplatform. A Logic App, called Order Events Processor, listens on the orderevents grid, picks up an event, extracts the order id, fetches the order data fromeCommerce Platform using their REST API, and then stores the entire orderinformation 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 canscale indefinitely. For each new event Azure can spin up a new Logic App toprocess that event, however it is recommended to limit the number of parallelinstances based on the throughput you would like the system to have. Second,Logic Apps require no code; you can configure them using a visual designedthrough the Azure Portal, so it allows you to quickly build it and then quicklyadjust it while running. Third, you pay for what you use and the consumptionmodel is based on pay per second.
The last component of this pipeline is the ERP Integratorthat picks up orders from the Online Orders queue, performs any needed datatransformation and then pushed the order into the ERP through their API. Forintegrators we use Azure Functions and not Logic Apps as we want to have theability to write code. Usually, this step of the process is more code intensiveand Azure Functions provide us with that flexibility.
The second pipeline that processes order updatesoriginated by the ERP and consumed by the ECP is working in a similar fashion.
Since you do not need to maintain an infrastructure, you areable to scale indefinitely. Logic Apps allow you to build and adjust quickly whileonly paying for what you use. This approach enables you to integrate the ERPthrough Azure allowing you the ability to write code unique to your currentsolution. This serverless approach is ultimately the most beneficial because ofits agility and scalability.