A Case Study for Serverless Integration: Customizing OpsGenie’s Zendesk Integration with AWS Lambda

by Nov 9, 2017 Fazilet Özer

zendesk_opsgenie_integration.png

OpsGenie is not a lonely cowboy. Many tools are becoming at the center of our IT world day by day and we need to adapt to them as soon as possible. This is where OpsGenie integrations and our Playground come into play. OpsGenie integrates with many tools that have specific monitoring capabilities and notification/ticketing systems to make everything related to incident response easier.

The manner in which we build each integration depends on the target tool’s capabilities. Generally, we can build an integration with HTTP requests between our APIs and the APIs of the tool that we want to integrate with, if it is supported. If OpsGenie receives an HTTP request from the tool, request body is parsed and an OpsGenie alert is created by using the meaningful parts of that parsed data. OpsGenie can send an HTTP request to that tool, as well.

opsgenie_integrations.png

Whether to send or receive data usually depends on tools’ functionalities and usage areas. I am not going to get into details of the processes of building integrations, but if you are interested you can have more information from this blog post.

Our main purpose in this blog post is to share our experience with one of our integrations, Zendesk, which we have a strong bidirectional integration yet wanted to extend its capabilities further using AWS Lambda. If you are not familiar with Zendesk, let me explain the capabilities of the tool. It is a ticketing service often used for technical service and support. Zendesk supports different user roles. There are agents, for instance, which are working on the ticket to solve it and, end-users a.k.a customers who open tickets in case they encounter with any problem.

What We Want For Zendesk Integration?

What we want in our case is basically to show the tickets created in Zendesk via OpsGenie integration to read-only Zendesk users. We will be using Zendesk for one of the use cases in our Playground and we need a read-only user to see the exact flow between Zendesk and OpsGenie. Therefore, we must have a user such that she/he can see the tickets and also what’s happening on the tickets, but cannot change username-password combination of her/his account. Zendesk end-user role is kind of a read-only user and seems like a good fit for us. Actually, it did, but with extra minor changes.

Our problem with read-only users is that tickets created via OpsGenie integration are created as private at first which means that they are visible among agents, but not visible among end-users until any agent adds a public note to that ticket. The integration’s behavior was designed this way so that only agents are able to see them in the first place. So, we have to figure out a way to make these tickets public automatically as they are created…

Using AWS Lambda to Solve the Visibility Problem

We could have followed traditional methods: write code to fix this problem, deploy it to a server and deal with server’s maintenance issues later on, if we have any. But instead, we preferred to continue with the new fancy “AWS Lambda” and use it as we are willing to try new things especially for relatively small tasks like this one. Maybe some of you have knowledge of AWS Lambda, but for the ones who’ve never heard of it before, it is kind of a new concept which is also known as Function as a Service (FaaS).

For the ones who has no clue about it, let me explain it to you first. AWS Lambda is a serverless technology that lets you write your code, load it and do nothing more for the deployment processes! Once you load your code, Lambda itself runs your code when it is triggered. So you don’t have to worry about deploying any code to a server and the maintenance issues of your servers anymore. That’s why it is called “Serverless”. To put the record straight, there is a server running your code at the background. However, maintaining the server is not your responsibility anymore but Lambda’s from now on. For more information, you can read the details from AWS documentation.

Our configurations — Serverless deploy

Let’s get back to our problem. First, I need to select a trigger for my Lambda function, then a programming language from the list Lambda provides me, also configurations for my trigger etc. I know it may sound scary, but don’t be afraid of it! There is an easy way to do these configurations, namely “Serverless Deploy”. Do not let the name mislead you, you still do not deploy your code but the configurations. With serverless deploy, you do not have to make configurations from AWS console. All you need to do is to write what you want in a file called “serverless.yml” and deploy it to AWS with a few commands, then you will have your Lambda function, Lambda trigger and the configuration between those two at once. For more information, read here.

I also used serverless deploy in order not to spend too much time while configuring Lambda. I used API Gateway as the Lambda trigger and preferred Python as the programming language. After serverless deploy, everything I wanted was ready for me. So, I strongly suggest you to use it!

After my AWS configurations and writing Lambda function, there is only Zendesk configuration left to do. As you might remember, I need to make private Zendesk tickets public whenever they are created. So, I added an HTTP target to Zendesk with the endpoint API Gateway provided me.

http_target_to_zendesk.png

Also, added a trigger so that an HTTP request is sent to that target when a ticket is created.

http_trigger.png

According to my configurations, it is supposed to work like this: When a ticket is created in Zendesk, an HTTP request is sent to API Gateway’s endpoint and API Gateway triggers my Lambda function which is written to make a request to Zendesk API to update the ticket (make ticket public). So, basically my Lambda function sends an HTTP request to Zendesk and then returns the response to API Gateway.

opsgenie_zendesk_aws_lambda.png

Using AWS API Gateway with Lambda for the First Time — The Inevitable Problem: 502 Bad Gateway

So, it seems like everything is ready to work as expected, but not — I am constantly getting 502 bad gateway error from API Gateway! After a little bit of search, I found out that the cause of 502 bad gateway is the communication problem between Lambda and API Gateway. You know, my Lambda function returns a response to API Gateway and it appears that it should have a format that API Gateway can understand:

{
“statusCode”: 200,
“headers”: ”headers,
“body”: “body”
}

Then, I re-arranged my response object so that it returns in this format. However, still getting the same error again and again! After a while, I realized that I was passing json object to body of my response object which is something like:

{u’audit’: {u’via’: {u’source’: {u’to’: {}, ... }}}}

However, it should be string instead of json object, like this:

‘{“audit”: {“via”: {“source”: {“to”: {}, ...}}}}’

So, I changed it to string, tried again and it worked!

...

If you want to see how it all works, you can visit our Playground! Additionally, you can watch our webinar with Zendesk to learn more about how this integration enhances customer experience!