Logic App Standard: Calling an Azure Function from an XSLT Map

In an integration project today, many scenarios require conversion, transcoding, or specific formatting or calculations. In this particular case, this type of calculation can be done via encapsulated code within an XSL map.

When we choose this processing method, we usually share the process so it can be used again. We can do this by writing code (for example, a C# helper class) that contains all the calculations. It can then be referred to as needed. This saves us from having to “reinvent the wheel” each time.

With the introduction of various Azure components and the cloud in general, it is easy to imagine creating several Azure functions for specific processes and calling on them whenever needed. Consequently, there is no need for a C# class that you have to update and redeploy every time you find a new method or fix a bug. Instead, everything is stored in one unit, and once changes are made, they become available extremely quickly.

Using this kind of structure, we tried to develop a way of making things more modular and easier to maintain with all the benefits of the cloud and none of the disadvantages of on-premise solutions.

This post will show you how to call an Azure function from an XSLT map within a Logic App Standard.

Let’s look at a BizTalk development example to illustrate this. In XSL, we often have to do highly complex or even impossible calculations. We then have two options: we can write inline C# code directly into an XSL map or create a helper class that we will refer to.

Let’s consider the second scenario. Our first problem is that the Logic App Standard is based on the latest stable version of .NET Core. Although .NET Core supports XSL maps, it does not support encapsulated code, so executing code (in any fashion) from an XSL map is impossible. Furthermore, to use a Dynamic Link Library (DLL) in an XSL map, the DLL must be registered in the Global Assembly Cache (GAC). The GAC stores assemblies intended to be shared between multiple applications on the computer so they can be referenced.

However, there is a way to run code. This method outlines the steps you need to take.

Compatibility with the .NET 4.7.2 Framework

Firstly, to run C# code, you need to use the .NET framework. To allow the framework to be used in the Logic App Standard, you simply need to add the configuration key, as shown below. It only allows you to use version 4.7.2. This is one of the limitations we currently have.

We must therefore add a key to the Logic App Standard configuration.

You can do this by going to the “Configuration” option:

Then, add the key as follows:

C#: A DLL for a Generic Call

After developing a “generic” C# method that calls Azure functions, we retrieved and included the DLL in the Logic App Standard. Below is a description of the procedure:

The Helper Code

Here is the helper code used in this exercise:

As seen in our example, the method lets us easily call an Azure function by specifying its URL and parameters.

Note that the Azure function parameters will be passed in the body in JSON.

Once the project has been compiled, we can retrieve the DLL and place it in the “site/wwwroot/lib/custom/net472” folder.

To do this, we use the KUDU utility as follows:

Step 1: Start the KUDU Utility

Step 2: Start the Debug Console -> CMD

Step 3: Browse through the Folders and Copy the DLL to the Correct Place

If there is no “lib” folder, create one.

If there is no “custom” folder, create one.

If there is no “net472” folder, create one.

Then, you need to drag and drop your DLL file into this folder:

Step 4: Preview functionality, upload the dlls using the menu

Note:  a new way to upload DLLs is available in preview.
Click on “Assemblies”.

Then click on “Add” and drag’n’drop the DLL.

The XSLT Map

Next, we compiled this helper and used its DLL in an XSLT map:

As a reminder, maps are stored under “Maps” in the Logic App.

Context and Results

Context: the Cosmos DB Database

We created a Cosmos DB database with four documents for the exercise.

These documents are “Companies” with the following attributes: “id”, “partitionKey,” “name,” and “address.”

Example of a row:

Context: The Azure Function

We developed an Azure function that uses the “id” and “partitionKey” pair we give it to try and get the “name” attribute value for a “Company.”

Result: the Logic App Standard

We have devised a quick workflow to test the whole chain.

It consists of an HTTP trigger and a map.

After executing the workflow:

XSL map result:

As you can see, the Azure Function worked well, and we got the expected value based on the criteria given.

Calling an Azure Function from an XSLT Map: Conclusion

We were able to call an Azure Function that allowed transcoding within our XSLT map.

Of course, this type of process can be extended by adding more Azure functions. This makes maintenance easier and allows for greater flexibility.

Several new features will be released and become available in LogicApp Standard. Here are some examples:

• The XML extension directly within the LogicApp designer
• A “mapper” (similar to BizTalk) accessible from the LogicApp designer

These two examples will make easier to migrate BizTalk development from on-premise to the Azure Cloud.
We will talk about it later in a future post on this blog.

Would you like to find out more or get help with your Cloud Azure projects? Contact us!