3 Apr, 2018
'/%3E%3Cdefs%3E%3ClinearGradient id='a' x1='0' y1='-5' x2='11' y2='-5' gradientUnits='userSpaceOnUse'%3E%3Cstop stop-color='%2300F'/%3E%3Cstop offset='.339' stop-color='%23A0A'/%3E%3Cstop offset='.677' stop-color='red'/%3E%3Cstop offset='1' stop-color='%23FA0'/%3E%3C/linearGradient%3E%3C/defs%3E%3C/svg%3E)
3 min read
The Data Handbook
How to use data to improve your customer journey and get better business outcomes in digital sales. Interviews, use cases, and deep-dives.
Get the book
Many times the integration with other services is not so straightforward. Sometimes they have complex APIs with unfamiliar technology and poor documentation, all the while communication with the maintenance team takes a long time via email or ticketing system.
When finally we’ve gathered an understanding of how the API works, we need to write a good amount of code and bear the burden of its maintenance for such a common task, which, in essence, is just connecting one service to another.
Azure to the rescue
Meet my favourite tool from Azure: Logic Apps, which essentially is a composite serverless solution. You can connect with 3rd party APIs via out-of-the-box connectors without writing a single line of code. If you use other Azure services such as database or storage, integrating with them is easy peasy with CRUD support and event triggers. Scaling is handled automatically and you need to pay only for what you use. Sounds pretty great, right?
Let’s get to know Logic Apps in more detail
I’ll present a practical example on how Logic Apps can be used.
Let’s say you’re working with a logger service, which sends daily logs as a CSV file attached to an email. You want to save it for later use, then analyse it and send an alert if there is something suspicious. Should you need to build all of that by yourself, the steps would be something like this:
- Build a server which accepts the CSV log file
- Write integration logic with storage service (after reading documentation)
- Write code to analyse the log
- Write integration logic with Slack API (after reading documentation)
Using Logic Apps, the logic flow would be the following:
- Setup trigger on receiving email with attachment
- Using storage connector, save the attached file
- Write code to analyse the log
- Using Slack connector, send alert if appropriate
Let’s take a look at how that logic would be created on the Azure portal
Notice that this also works as simple documentation by naming each function well.
Let’s dig deeper into each function.
One of the good things about Logic Apps is that they have many triggers to start the run. You can react on events, be it Twitter, Trello, Slack, Storage or HTTP post. Gmail integration is one of them, and it is connected by just clicking a button. Then set the criteria for which email should trigger the run.
Here Logic Apps saves the file in Azure Storage. Those “Attachments” and “Content” are automatically generated from the previous connector, in our case the Gmail connector. “For each” -loop is also automatically created, as “Attachments” can be multiple instances. We can also use some generic function like “utcNow()” for simple logic.
Next, the file is passed onto Azure Functions. This is the place where you write your own code to do your custom analysis of the log data. Now that all other integrations are ready-made, you can focus on writing state-of-the-art analysis code.
Let’s say the Analyse function responds with JSON, then the next step is to parse it. You’ll find a connector for that as well.
Our custom Analyse function tells us if there is something suspicious going on. If there is, post a message to a Slack channel and let people know the situation. The Slack integration is also just a button click. No need to read their API documentation.
That’s it! Even though this scenario is made for a demo purpose, I can imagine cases where you can apply a similar workflow; an event triggers a run, which takes data, processes & saves it, then reports the result. In fact, we have built several solutions using Logic Apps similar to this one for production use.
Here are some other connectors I’ve found useful:
- Trigger on new file in storage
- CRUD operation on database
- Call other Logic Apps
- Scheduled trigger
- HTTP call and webhook
With these and many other connectors, and using custom logic by Azure Functions where needed, you can go quite far with little coding and maintenance.
Even though I focused on Azure specific tools, there are other tools which work in similar manner (eg. AWS Step Functions). The idea behind it all is applicable to many uses cases. Service integration should be a reusable commodity, enabling us developers to build a solution by composing multiple services and thus reserving focus on growing the client’s business.
P.S. We're looking for nice people with a 'get shit done' attitude to join our team at Columbia Road! Take a new leap in your career, we have open positions in all business areas. Send a message, call us, visit us — we'd be thrilled to hear from you!
