In this article I will provide a detailed overview of how to build an event driven architecture that enables trigger based data inflow and outflow in context of Outsystems and multiple external data inflow/outflow services. With event based architecture one can achieve easy decoupling of multiple dependent child services/applications with the parent application assuring minimum scope for error delta.

What is event driven architecture?

In the modern world most of the applications are developed using the microservices architecture which allows easy fault detection and prevention. An event-driven architecture uses events to trigger and communicate between decoupled services and is common in modern applications built with microservices. An event is a change in state, or an update, like an item being placed in a shopping cart on an e-commerce website. Events can either carry the state (the item purchased, its price, and a delivery address) or events can be identifiers (a notification that an order was shipped).

Event based architecture has 3 essential components:

1. Event Producers
2. Event Routers
3. Event Consumers

A producer publishes an event to the router, which filters and pushes the events to consumers. Producer services and consumer services are decoupled, which allows them to be scaled, updated, and deployed independently.

When to use event-driven architecture?

As explained by AWS there are 4 key areas where one should use event driven architecture to simplify complex event based triggers to communicate with multiple decoupled services.

1. Scale and fail independently

By decoupling your services, they are only aware of the event router, not each other. This means that your services are interoperable, but if one service has a failure, the rest will keep running. The event router acts as an elastic buffer that will accommodate surges in workloads.

2. Develop with agility

You no longer need to write custom code to poll, filter, and route events; the event router will automatically filter and push events to consumers. The router also removes the need for heavy coordination between producer and consumer services, speeding up your development process.

3. Audit with ease

An event router acts as a centralized location to audit your application and define policies. These policies can restrict who can publish and subscribe to a router and control which users and resources have permission to access your data. You can also encrypt your events both in transit and at rest.

4. Cut costs

Event-driven architectures are push-based, so everything happens on-demand as the event presents itself in the router. This way, you’re not paying for continuous polling to check for an event. This means less network bandwidth consumption, less CPU utilization, less idle fleet capacity, and less SSL/TLS handshakes.

Without knowledge action is useless and knowledge without action is futile

-Abu Bakr

The applications defined below play an important role in building the event-driven architecture on the Outsystems Platform

1. Event Producer — Shopify
2. Event Router — Celigo Integrations Platform
3. Event Consumers — Outsystems API

For this integration I will trigger events from Shopify and those events will be routed to an Outsystems endpoint (Learn more here) using the Celigo Integrations Platform.

Celigo Integrations Platform

Celigo Integrations Platform is an iPaas which acts as a bridge between the event producer(Shopify) and any external decoupled services. In Celigo, an “integration flow” is considered as the movement of a record type plus any dependent sub-record types, from one application to the another. With over 250+ inbuilt connectors and custom REST integration capabilities Celigo offers a one stop solution for system-to-system data flow with minimum error delta.

Create a new integration in Celigo

1. Login to the Celigo dashboard and select the create connection option.
2. Once you click on the create connection tab. Input the connection name and description and hit the Save & Close button.

Once a new integration is created it will show up in the connections list on the Celigo dashboard.

Adding a connection in Celigo

1. Navigate inside the newly created integration (Dev Integration) and select the create connection option.
2. Give the connection a name and enter all the necessary details like base uri, authentication mechanism, mode, media type, rate limit, concurrency and hit the test connection button. If the entered values are correct you will get the screen below.

Creating a flow

1. Click on the Flows tab and select the Create Flow(export) option.
2. A dropdown list with multiple pre-created connectors will be presented on clicking of Add sources. In our case we will select the Shopify options as we will be triggering events from Shopify and creating records in Outsystems.
3. Give a name to the source listener, generate the public url by clicking on the “+” icon and setup the listener.
4. If all works fine the the above steps you should see a screen like the one below.

Creating a destination

1. After creating the listener, click on the “+” icon to add any branching logic based on the input received from the listener.
2. If no branching logic is required proceed to adding a destination into which the data must flow.
3. After selecting the connection(In this case Outsystems Connection) select the appropriate HTTP method , relative URI, export type, paging if any and click on Save and close. Your Screen should look like below.

4. Learn more about creating API’s in outsystems here.

5. Click on the enable flow option on the top right hand corner and enable this flow to capture requests made to the listener URL generated in the earlier steps. After completion of all steps you should see a flow dashboard like the one below

References

1. https://aws.amazon.com/what-is/eda/
2. https://www.celigo.com/ipaas-integration-platform/

If you found this article helpful do share it with a wider audience and help simplify learning.