Our old friend Master Chef has started using a new cloud based ingredient ordering system called FoodCloud. It has amazing prices on bakery ingredients and they even deliver! Unfortunately, they deliver 24x7 and require someone to be there to accept the package. The emails they were sending were getting lost in the noise and after a couple of pounds of flour went for a walk in the middle of the night when Intern Ivan fell asleep, Chef decided he needed a better way. After seeing the recent scheduling enhancements Chef realized he could put Ivan on call at night but then still get notified during the day while at the shop. So, read on to find out how we can build a real life cloud to cloud integration.
Cloud applications are awesome. You have an application that just works. Someone else gets to deal with maintaining the servers, building out new data centers, managing VMs, dealing with database errors, the list goes on and on. Generally, you get it set up and configured and away you go.
But what happens when you want your cloud application to talk to your other cloud application? There are as many APIs for integrations as there are applications and the likelihood of one peg from one application to fit into the hole of another is generally pretty slim. Those guys use JSON and the other guys use SOAP, or maybe those guys can send JSON but only in a very rigid way and that way doesn’t fit with how the other guys can receive it.
I’ve been trying to track down documentation on this FoodCloud system, but it seems to be very lacking. I was assured however, that the outbound payload is very similar to Slack. So, let’s take the Slack Outgoing Webhook and compare that with what xMatters can receive. Slack can send a payload that looks like this:
text=googlebot: What is the air-speed velocity of an unladen swallow?
But xMatters can only receive a JSON payload as defined in the POST /trigger API call (Give or take a few properties and recipients and conferences and responses and, oh… )
"Building":["Building A", "Building B"],
"Street Number": 2453,
"Is PO Box?": true,
"Disaster Category":["Mass Movement", "Earthquake"]
"devices": ["Email", "Voice Phone"]
What are we to do? How can we get Slack to talk to xMatters? Well, this is where an integration service comes in. The xMatters Integration Agent is perfect for this. It can receive messages via SOAP, HTTP GET and Command Line and then will build the payload and send to xMatters to create new events. Sweet let’s do it… Well, the next question is where to put the IA. In a cloud to cloud integration, it gets a little silly if you have to put an IA behind your firewall. Sort of like running the water from the source to the water heater that is on the sidewalk to the shower on the second floor.
Not generally ideal. This is where a “cloud integration service” comes into play. One such integration service I’ve been playing with is Zapier. These guys are great. They have a bajillion “Zaps” for interacting with just about everything you can think of and a lot you’ve probably never heard of but sound really cool.
Let’s dig in to see how this would work. I’ve created a Zapier account and I’d like to initiate events from my Slack chat. I hop over to Zapier and create a new Zap. I select the Slack Trigger and
New Message Posted occurs. I’ve selected the venerable xMatters Action and the only option (for now) is
After jumping through the OAUTH hoops to authenticate Slack to Zapier I get the satisfying “Account is working” message. Then I do similar for xMatters using a REST User.
So, we probably don’t want to create an event for every single Slack message! Talk about communications overload. Let’s add in a filter to make it only fire when we have a message with specific text. In this case, I’ve chosen “xM SENDEVENT”. Seems like slim chances someone would start a message like that accidentally.
The next step is to map the stuff from Slack to the stuff in xMatters. My form has two properties, a Message and a Room (which Slack actually calls “Channel”, but for our purposes it is the same). So I throw in the Web Service URL from my form and select the Slack fields to go to which properties. Sweet.
Oh, scrolling down, there is one more entry for Recipients. What to do about this one? Showing all the fields from Slack doesn’t really help us. It wouldn’t make sense to target the message to the User writing the message. Text is obviously not a user nor a group and even if it were, what would the message be? Timestamp, Token, User ID and Channel ID are all out because, well, numbers are not people. Or groups. Usually. For now, let’s just enter the Channel Name and we’ll discuss options later.
So, let’s test it! Back in Slack, I entered some text:
Unfortunately no confirmation or acknowledgement an event was initiated, but we can check xMatters and see that indeed, an event was initiated:
Ok, not bad. We were able to get Slack to send events to xMatters just by typing stuff in the Slack channel and we didn’t have to use an Integration Agent. We had to use the Slack channel as the recipients because there was no logic to run to determine who to target. It also would be nice to get some kind of acknowledgement good or bad about the creation of the event. And of course this requires signing up for the Zapier service. Using another Zap, we could get the delivery status and response information posted to the originating channel.
One other option is to use the new Hubot integration for xMatters that was recently released. This provides a way to parse out the recipients and also has a listener for dealing with the callbacks.
There might be another option in the works as well. Keep watching this space