When attempting to retrieve API data using IBM's Concert Workflows (CW) "no-code/low-code" solution, there are "more than one way to skin a cat!" 

For you cat lovers, no cats were harmed during the writing of this blog!

When you need to get some data from another third-party system, you can go about it using several methods.  What are these methods?  Which ones should I use?  Let's explore the subject to find out!

CW is a "no-code/low-code" automation platform that allows you to automate your world so you can accomplish more with less effort.  It does this by providing an easy-to-use drag and drop interface to construct automation workflows by selecting and then arranging "action blocks" to accomplish your task.  Your task might be integrating systems, updating a CMDB, deploying resources, or maintaining your network infrastructure.  The possibilities are endless.  

• cURL action block
• HttpRequest action block
• API action block

Using our "skin the cat" theme, I've built a simple workflow to demonstrate each of these.  Depending on the cat type, a "SwitchCase" action block will route the request to the particular data retrieval method:

• I want to retrieve information about a device that I load into a variable called "$device_name".
• The retrieved data will be loaded into the JSON object called "$data".
• I also have defined an empty variable called "$cat_type" that I will be using to give a cat type ("Calico", "Tabby" and "Black") later on in the example.
• There is an $api_key variable for use in the cURL and HttpRequest action block requests.
• There is an $NMSAuthentication variable so we can securely request the data using the API endpoint action block.
• The $SevOne_NMS_IP variable contains my test system's IP address that I will be querying in this example.

Let's start out by trying the cURL method by setting our $cat_type to "Calico".

Scrolling downward, we see the workflow case that matches our $cat_type value of "Calico”.

We can modify the cURL_1 block by clicking on it.  The Object Editor is displayed.  It expects one variable to be populated -- "command".

In the Object Editor we can see that in the command setting it has the normal stuff you'd find if you ran a CURL command from the command-line.  It also has some variable values in it, which are populating using the Start Block variable values we entered at the start.

Scrolling downward a bit more, we see that the result is loaded into the $data variable, then formatted using a "JsonEncodePretty" block.  Finally the result is saved to the $result variable.  When the workflow runs, the $result variable value will be displayed in the log.

Here's our log result.  We see that our device info is returned in a "pretty printed" JSON object.

Now what about those other methods?  Let's look at the HttpRequest action block next.  In our example we can use it by setting our $cat_type = "Tabby".

Our SwitchCase block directs the flow to use the "Tabby" case branch, which is where our HttpRequest block lives.

Let's examine our HttpRequest_1 block by clicking on it.  The Object Editor is displayed.  This block has a lot of possible settings we can use.  We are able to populate the values using the variables we defined in the Start Block.

The result of the HttpRequest_1 block is loaded into the $data variable.  Then it is passed on for beautification using the JasonEncodePretty_1.   Finally the output is saved to $result.

Now let's run it and view the $result output in the log.  Notice that the identical payload is returned.  Since we are calling the same API endpoint, that is to be expected.

Finally, let's try the API endpoint method.  CW contains a large number of popular API libraries from well-known products whose API endpoints have been converted into action blocks.  In this example I added a SevOne APIv3 endpoint block that retrieves the device information we are after.

Let's set our $cat_type = "Black".

In this case, the SwitchCase block doesn't find a match for $cat_type = "Black" so it routes us along on the "Default" case path.  This is where our SevOne API action block lives.  This particular block retrieves data from the SevOne Metadata Devices endpoint.  The result is written to the $data variable.

Clicking on the SevOne_API_1 action block causes the Object Editor to be displayed.  There are two variables that we set (only one displayed here).  The first is the Authentication variable (not displayed).  We populated it using the $NMSAuthentication variable value we set in the Start Block.  The other variable we set (shown here!) is the name_value, which we set using the $device_name variable value.

Like before, the result is loaded into the $data variable. Then it is prettified and the result is saved to the $result variable.

Now when we run the workflow, we will see the result in the log.  Again, it is identical to the other methods since we are calling the same API endpoint!

Now, when would you use one method over another? 

If you have a "new" API endpoint that you want to work with that isn't already in the CW library, IBM will certify it and turn it into an action block within 15 business days.  If you can't wait that long, or if you have an API endpoint that you wish to remain private, then you can use either the cURL or HttpRequest blocks to interact with the endpoint.  If you are happy to wait for the free IBM certification process (15 business days, but typically less), then you can import the new API certification for your endpoint and can then use its shiny new API action block in your workflow.

I hope you have found this not-so catty example informative and will help you in your own Automation adventures!