Anaplan CloudWorks API and Azure Logic Apps

You’ve already had a flavor of using Logic Apps with Anaplan API in this article, thanks to my colleague Sean Culligan.
In this post, we will do something slightly different by using Anaplan CloudWorks API with the famous Azure platform.

One way would have been to decline the previous articles using AWS or GCP and re-use the same code we wrote for those articles in the Azure similar components, as those could be assimilated to Azure Functions.
With some tweaks, the code we've delivered is still valid and can be used for that purpose.

In our previous examples, we wrote some lines of code (Python, Kotlin) that needed to be used and deployed on different platforms. But this time, I wanted to explore a no-code approach with the use of the Azure Logic Apps.

This functionality is quite promising: without a single line of code (but not without formulae), we should be capable of building production-proof data flows. Manipulating visual components and some variables should suffice.

This is quite a claim! Let's see how it went.

Note: I've explored Logic Apps briefly so I might have missed some Azure best practices. I'd like to apologize for that in advance and I strongly recommend you react in the comments. All contributions are helpful.

Also, we will not go through how to trigger an integration via API. This has been explained in this article and also it is described in the apiary.

Use case: event-based triggering

The purpose is to illustrate the triggering of a CloudWorks (CW) flow following an event on the Azure platform. The event-driven integration triggering is not supported today on the CloudWorks solution. Nevertheless, as we've already shown in our previous examples (using Amazon Web Services -AWS- or Google Cloud Platform -GCP-), this can be achieved by combining customization and CW APIs.

To achieve that, we need to address those main objectives:

annejulie_0-1650314297605.png

Azure Logic Apps & Anaplan main concepts

Building a Logic App

Technical flow

This is what we want to achieve:

annejulie_1-1650314297606.png

 

In order to have such a simple flow when many processings are at stake, we will have to nest some logic apps inside other ones or call individual processes inside a more general one.
For instance, the getIntegrationId box is a logic app on its own. The Until process involves 3 individual subprocesses.

The schema gives an idea of how I've implemented nested apps and how the output of an App is being used by another one.
The App3 is our final logic app (the same flow as the one above).

annejulie_2-1650314297611.png

Nested Azure Logic App

 

The video below shows how I've built such a flow and demonstrate how it works.

image




 

After watching this video, you can continue this article by reading some further technical details on different pieces of that data flow.

Special focus

How to handle the token expiration time?

Objective: Getting connected to Anaplan

If you have been following us for a while, you must know that the primary step of using Anaplan APIs is to generate an authentication token.
Each API call needs to encompass that token and it only lasts 35 minutes. A best practice we recommend is to address longer integration running time when a single token is not enough to go through all the steps.

One possible way would have been to integrate the token generation call within each step: that will work but the readability of the flow will be impacted. Debugging in production mode will then become harder.

To address that, as I described above, I decided to create a Logic App on its own just for that purpose: recurrent API calls will update a file located in a blob storage container. The file's content will then be updated regularly with a valid token.

For subsequent Logic Apps that will require a token, we will then simply use the content of that file by calling a nested logic app.

annejulie_3-1650314297617.png

Getting token flow

 

The first box is a recurrent schedule: every 15 mn, an HTTP request will be performed and Anaplan API server should respond with a valid token.

We've chosen 15 mn because as a token last 35 mn, if the first call fails for whatever reason, there is still time for the second call.

getClientId and getRefreshToken are secret values that are stored in a Key Vault. We will be using the refresh token to get an access token. This could be achieved by using basic credentials or certificate information as well.

annejulie_4-1650314297626.png

Key Vault storing secrets

 

As displayed below, we used HTTPS requests to get vault secrets:

annejulie_5-1650314297637.png

 

The authentication type is Managed Identity so you need to be sure that this feature is enabled in your Azure Instance.

A similar process is then done in parallel with the refresh token.

Thanks to those 2 values, you'll then be able to perform your request to the API server.

annejulie_6-1650314297642.png

Get Access Token: POST request

 

Getting the information needed

Objective: Information lookup

After securing an always-valid token, we will now focus on getting the IDs of the objects we want to use.
Like all REST APIs calls with Anaplan APIs, a great amount of work is about getting that information and generating the URLs we need for the POST call.

Like the previous step, I'll be generating a Logic App for that purpose. It will then be reusable within another logic app by simply providing the name of the integration we want to find the ID for.

In my example, the following action getIntegrationId (called via an HTTP trigger)

annejulie_7-1650314297646.png

Action getIntegrationId

 

actually refers to that logic app

annejulie_8-1650314297651.png

getIntegrationId Logic App

 

After getting authenticated via the getBlobToken, we get the whole list of CW integrations:

annejulie_9-1650314297657.png

Getting the list of available integrations

 

This list is then converted into an array:

annejulie_10-1650314297659.png

Conversion of the JSON data into an array

 

on which I apply a filter based on the value of a parameter (the name of the integration I want to execute)

annejulie_11-1650314297662.png

Filtering the array by the integration name

 

As we are supposed to get only one occurrence in that filtered array, we can then take the last (or first) element of the output and initialize a variable with that value.

annejulie_12-1650314297665.png

Formula for Value: last(body('filteredList'))['integrationId']

 

The communication between this underlying logic app and the parent one will be done through the Response action:

annejulie_13-1650314297669.png

Sending the output to the parent Logic App

 

Note that I send the tokenValue as well so that in the parent logic app, I don't need to add another action to call for that token.

Triggering Anaplan CW integration

Triggering the integration is quite simple: you need to perform a POST request based on the information you've gathered in the steps before.

annejulie_14-1650314297670.png

 

Notice the formulas.
The important fields are:

  • the token value (formula: body('getIntegrationId')['tokenValue']) and
  • the integration ID (formula: body('getIntegrationId')['integrationId'])

Checking the progress of the CW integration

As you may know, every Anaplan action is an asynchronous action, meaning that once you've triggered it, you immediately get a task ID, and as we don't know how long it will take, you need to check via the task ID the intermediate status by polling it with potentially numerous Anaplan APIs calls.

To achieve that, I've implemented a simple Until loop which is native to Azure Logic App.

annejulie_15-1650314297672.png

When expanded, this loop

annejulie_16-1650314297676.png

Checking the progress of the CW integration

 

consists of checking the message property of the JSON response when querying the progress of the task.

The main steps are:

  1. Getting a valid tokenValue
  2. Get the latest status of the CW integration
  3. Update the endDate variable

This loop will continue until message will be different from "queued".

Sharing the final status

We will use the Response action in order to provide information on our CW triggering:

annejulie_17-1650314297679.png

Sharing information for future needs

Thanks to that information, this logic app can then be integrated into another logic app or Power apps and provide good insight into how the job went.

Conclusion

This immersion in the Logic App environment is really promising: very advanced data processing can be achieved via this no-code environment.

You benefit from logging tools that are available out of the box, connectors proposed directly in the situation, giving you a more secure environment when this will move to production.

In many situations, it is much better to use this kind of solution than using code that will not leverage what the platform can offer.

 

Got feedback on this content? Let us know in the comments below.

Contributing authors: Joey Morisette and Christophe Keomanivong.