.NET Framework assembly support added to Azure Logic Apps (Standard) XSLT transformations (Preview)

Posted by

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

This blog post is a collaboration between Praveen Srivastava (Principal Software Engineering Manager) and Kent Weare (Principal Product Manager) from the Azure Logic Apps team.

 

The Azure Logic Apps team is pleased to announce the preview support of .NET Framework assembly support for XSLT maps in Logic Apps (Standard). This capability adds more extensibility options to Azure Logic Apps (Standard) and allows organizations to extract more value out of existing .NET Framework investments.

 

These investments will aid customers in moving both BizTalk Server and Azure Logic (Consumption)/(ISE) workloads to Azure Logic Apps (Standard).

 

Managing Custom Artifacts

Previously, customers were able to upload XSLT maps to an Integration Account where a consumption-based logic app could execute that map via an out of box action. We are now bringing similar capabilities to Azure Logic Apps (Standard), but without a dependency on the Integration Account.

 

Within Azure Logic Apps (Standard), developers can upload maps and schemas to their respective folder within the Artifacts folder of their project. Similarly, we will now support a folder where developers can place compiled assemblies that are called from XSLT maps.

The folder structure for uploading .NET Framework assemblies includes a path with the following folders \lib\custom\net472. The .NET Framework assemblies that you want to call should be placed within the net472 folder as highlighted below.

 

 

1-folderStructure.png

 

 

Enabling Multi Language Worker feature

In the public preview of this functionality, a feature flag needs to be enabled for this feature to work. In the future, this capability will be enabled by default and a feature flag will not be required. To enable the multi-language worker, navigate to Configuration link found in your left navigation pane. Subsequently, click the New application setting link and then add the following application setting:

Name: AzureWebJobsFeatureFlags

Value: EnableMultiLanguageWorker

Once you have clicked OK and you Save your configuration, your logic app instance will restart.

 

Note: Should you have other feature flags enabled, please separate by a comma e.g. feature1,feature2. For additional details, please see our documentation.

 

13-MultiLangWorker.png

 

 

Scenarios

The XSLT + .NET Framework addresses a couple core scenarios including Azure Logic Apps Integration Service Environment (ISE) and BizTalk migrations.

 

Azure Logic Apps (ISE) Migration

Customers who currently use an ISE instance and subsequently an Integration Account to support calling data transformations can move these maps to Azure Logic Apps (Standard) without the need for an Integration Account. Other than moving the artifacts into the respective folders, there are no additional actions required.

 

BizTalk Server

Customers looking to move integration workloads from BizTalk Server to Azure Integration Services can take advantage of this capability and move their data transformations into the cloud without having to re-map nodes and elements.

In the interim, customers will need to add references to their XSLT file generated from BizTalk. However, in the near future we will support extension objects and customers can move their XSLT files as is, without further tweaking.

 

To generate an XSLT file from a BizTalk map, located you map, right mouse click on it and then click on Validate Map. Once you have done so you will a status message within your Output window the includes a link to your generated XSL file on your local hard drive. Ensure to rename this file to have a .xslt extension.

 

BTS-ValidateMap.png

 

Walk throughs

Our scenario includes uploading an XSLT map and a .NET Framework assembly which is called from our XSLT map. To implement our scenario, we will complete the following steps in either the Azure Portal or VS Code:

 

Azure Portal

Navigate to the Azure Portal and discover the Artifacts section listed in the left navigation pane. Click on Maps, followed by the Add button where you can select your .XSLT file.

2-UploadMapResult.png

 

At this point in the public preview, customers need to make some small tweaks to their XSLT file to add a reference to the assembly that will be called. This activity is required in the interim until we support extension objects in the near future.

 

Extension objects are a concept that exist in BizTalk Server. The BizTalk runtime will use extension objects to load the correct assembly at runtime so that a BizTalk map can call the correct assembly.

 

For now, we need to include some references to our assembly within our XSLT file by using the <msxsl:script xml element. Within this element, we need to provide the assembly's name and namespace. Within this element we can also provide some helper code that will allow us to instantiate the .NET class and method that we want to call.

 

From within our selector found later in our XSLT file, we can call this helper method and then set the result to a variable or embed it within an XML tag.

Once extension object support is available, the use of the <msxsl:script element will not be required.

 

10-MSScript.png

 

With our XSLT file setup, we can now upload our custom assembly by clicking on Advanced Tools in the left navigation pane of the Azure Portal, followed by clicking on the Go link.

 

4-AdvancedTools.png

 

A Kudu page will open on a new tab. Click on Debug console followed by CMD.

5-Kudo-CMD.png

 

Click on site.

6-site.png

 

Click on wwwroot.

7-wwwroot.png

In the cmd line below issue the following commands:

       mkdir lib\custom\net472

This will create the necessary 3 subfolders where we can upload our custom assemblies.

8-mkdir.png

 

Click into the lib\custom\net472 folder and then drag your assembly file from your local computer to this web page.

9-newFile.png

 

We can now construct a workflow that will call our XSLT transform from the Transform XML action.

3-ConfigureTransformXMLAction.png

 

When we call this workflow, we will see that our custom code has been executed.

11-result.png

 

VS Code

We can also accomplish deployments through VS Code. Within your VS Code project, ensure you have the following setup:

  1. Place your XSLT file into the Artifacts\Maps folder
  2. Create the lib\custom\net472 folder structure at the same level as the Artifacts folder
  3. Select your XSLT map from the Name drop down.

12-VSCode.png

 

With this configuration established, you can now deploy this project to Azure. Please ensure you have the configuration settings we established previously in this document.

 

Video Walkthrough

If you would see a video version of this content, please check out the following YouTube video:

 

Frequently Asked Questions

Q. Do I need an Integration Account to use this feature?

A. No, an Integration Account is not required to execute maps that reference .NET Framework assemblies in Azure Logic Apps (Standard). The Integration Account continues to be a dependency for Azure Logic Apps Consumption and ISE SKUs.

 

Q. Does this feature cost additional money to use?

A. There are no additional charges, beyond the Workflow Service Plan that is required when provisioning Azure Logic Apps (Standard).

 

Q. Do I need to modify my XSLT files to include references to my .NET Framework assembly?

A. During the initial stage of the Public Preview, this is something that you will need to perform by adding the <msxsl:script xml snippet to your XSLT file. In the future, this will not be required as our service will support extension objects, much like BizTalk Server does.

 

Q. Why do I need to use Kudu to upload assemblies in the Azure Portal?

A. During the initial stage of the Public Preview, we are leveraging Kudu as a way to upload assemblies. However, in a future release, we will provide Azure portal support similar to the way we support Map and Schema uploads.

 

Q. Why do I need to enable the AzureWebJobsFeatureFlags configuration setting?

A. During the public preview, this setting enables a worker that supports the .NET Framework. In the future, we will enable a multi-language worker directly in the service so you won’t have to set this manually.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.