Unless you've been under a rock for a while, you've probably noticed that cloud technology moves FAST. Well, being born in the cloud, so do we at ServiceNow, and so can YOU as a Discovery/Mapping customer! If you haven't seen it already, I recommend checking out how you can stay up to date on the latest content releases from ServiceNow: Content shipping of discovery patterns via ServiceNow store.
Even with our out-of-band content releases, there may be new cloud capabilities that you want to build support for on your own. In this post, I want to cover a capability that has been around for a while now, but is not widely known about: the "Cloud REST Call" pattern operation. This little operation is key to all our API-driven cloud discovery operations, and can be used very quickly to build support for new cloud capabilities in AWS and Azure.
Let's pick apart what first got me to use this: adding support for AWS ALB (Application Load Balancer). Beginning in Kingston, this support is standard, but that was not the case in Jakarta! And even if you are on Kingston, these steps are exactly the same to take advantage of other AWS/Azure APIs.
So, first let's take a look at what happens when you try to discover a cloud artifact that is not supported. You will probably get a nice little caution sign (if you're doing mapping), and an error that looks something like:
Boooo, that's no fun! Let's fix it! In this case, I'm trying to discover an ALB, and the discovery pattern log tells me that the pattern I might have expected to work, did not work at all:
Looks like it's time to create an additional identifier. If you look at the existing identifier for AWS Load Balancer Service, you'll notice that it's calling the "Version 1" of the ELB APIs (available docs from AWS). To understand how to make this all work, I recommend taking those docs for a spin, and then comparing with the latest/Version 2 API docs from AWS. You'll notice the calls are almost identical, but there are a few critical differences - the version that you pass, and some of the parameters accepted. In the past, when our original ELB pattern was authored, there was no JSON parser, so that pattern is a little large. Since we now have the Cloud REST Call operation, with the JSON parsing strategy, we can make our ALB pattern in only a few steps:
You'll notice that we don't have to worry about credentials (the operation's plumbing does it all for us!), nor do we have to worry about too many parameters for this particular request --> it's just a straightforward GET with a couple query parameters. Specifically, we build a request URL of the form: "https://elasticloadbalancing." + region + ".amazonaws.com/?Action=DescribeLoadBalancers&Version=2015-12-01&Names.member.1=" + nameOfOurALB
That's not so bad, is it?!? It get's pretty cool when you do this in debug mode and hit "Run Operation". You'll get a nice structured JSON response from AWS that you can easily build into a table just by selecting the values you want to capture:
Now, just lather/rinse/repeat to get any additional properties you want, and be sure to create a connection section to the pattern (if you're in mapping and want to see what this ALB is routing you to). After that work, you should get a much happier picture:
I was blown away how quickly this support can be added. Try taking it for a spin! Or, if you're feeling *really* adventuresome, try creating your own Custom Operation and I'll be really impressed 😉
