What’s new in BizTalk Server 2020: Logic App Adapter

What’s new in BizTalk Server 2020: Logic App Adapter

Azure Logic Apps adapter is used by BizTalk Server to communicate with the Azure Logic Apps. This could also be possible using the HTTP adapter, but the Logic App adapter provides a better and straightforwardly experience.

You may be thinking that I’m out of my mind. Logic App Adapter was already available in BizTalk Server 2016. Indeed you are right. However, the Logic App adapter was an optional feature and a separate download in BizTalk Server 2016. You can know more about how to install it on this white paper I wrote some time ago:  Step-by-Step Logic App Adapter Installation Guide. But it is now installed with the BizTalk Server 2020 default installation process, so you do not need to install it and configure it manually. Everything or almost everything will be already configured for you automatically.

The Logic App Adapter is one of the adapters that support two-way communications:

  • The Logic App Receive Adapter that is responsible for receiving messages from Logic Apps and delivering them to BizTalk is, in fact, a WCF Service that runs inside Internet Information Services (IIS).
    • Install and Configure an On-premises Data Gateway;
      • Go to On-premises data gateway, and downloads the gateway installer.
      • Run the downloaded file when the download is complete. The Terms of use and privacy statement dialog box appears.
      • Review the terms and click the Accept button to accept the terms of use and privacy statement.
      • Specify the destination folder where you want to install the package.
      • Click the Install button to proceed.
      • Once the installation is done, a Sign in page appears wherein you are required to provide your Azure credentials.
        • Enter the email address that has a subscription on the Azure portal.
        • Click the Sign in button
      • After sign-in, the On-premises data gateway window opens a new page to register the gateway.
        • Select the Register a new gateway on this computer checkbox to register a new gateway and then click Next.
        • The next page of the On-premises data gateway window appears where you need to provide the data gateway details.
          • Enter the name of the data gateway in the New on-premises data gateway name text box.
            • We will be using BTS2020LAB01-gw.
          • Enter the desired recovery key in the Recovery key text box and confirm the recovery key on the text box below.
          • Notice that the default region is North Europe, if you want another one you should change it here.
          • Click Configure to continue.
      • Once the configuration is complete, the On-premises data gateway window displays the status that the gateway is online and ready to be used
      • Click Close.
    • Create a Data Gateway Resource on Azure
      • Sign-in into the Azure Portal using the credentials used for configuring the on-premises data gateway.
      • Search for On-premises data gateway and from the result list select the On-premises data gateway option
      • On the On-premises Data Gateways page, click + Add to create a new On-premises Data Gateway
      • On the Create connection gateway page, provide the following details:
        • Type the desired name in the Resource Name text box. For example, BTS2020LAB01-cg
        • Select the desired subscription option from the Subscription drop-down list.
        • Select the desired resource group option from the Resource Group drop-down list or create a new one.
        • Select the desired location from the Location drop-down list.
          • This region should need to be the same as that you used on the On-premises gateway installation
        • Select the desire On-premises gateway from the Installation Name drop-down list
        • Click the Create button to create a data gateway resource
    • Create BizTalk Server Application to receive a message from Logic App
      • Open the Internet Information Services (IIS) Manager, expand the <Server Name> à Sites à Default Web Sites
      • Right-click the Default Web Site option and select the Add Application option from the context menu.
      • On the Add Application window perform the following configurations:
        • Enter the desired alias (name) for your application in the Alias text box.
        • Select the application pool that you selected in the Management IIS application.
        • Click the Browse button to navigate to the folder that you want to set for the Physical path text box
          • C:Program Files (x86)Microsoft BizTalk ServerLogicApp AdapterReceiveService
        • Click the Test Settings button to verify the application pool identity and pass the authentication and authorization tests.
        • Click the OK button to save the changes.
      • Open BizTalk Server Administration, expand BizTalk Server Administration à BizTalk Group > Applications, and expand our application.
        • Right-select Receive Ports, select New, and select One-way Receive Port.
        • In the Receive Port properties window, enter the following configurations:
          • Name: Enter a name for the receive port.
        • Select Receive Locations, and select New
        • In the Receive Location properties window, enter the following configurations:
          • Enter a Name for the receive location
          • For the Type, select LogicApp from the list, and select the Configure button.
            • In the General tab, configure the endpoint address for your logic app:
            • Address: Required. Enter the BizTalk ReceiveService IIS application URL. In our case: /LogicAppTestService/Service1.svc
            • Public Address: Required. This is the public full URL of the service. In our case: http:///LogicAppTestService/Service1.svc
          • In the Binding tab, you can configure any timeout and encoding-related properties of the underlying WCF-WebHttp binding. These properties are helpful when dealing with large messages.
          • In the Security tab, configure any security properties.
        • Click the OK button, to save your configurations.
        • For the Receive handler, select PassThruReceive from the list and select OK to save your configurations.
    • And finally, create our Logic App to send messages to BizTalk Server
      • Sign in to the Azure portal. Create a blank logic app.
      • After Logic App Designer opens, in the search box, enter Request as your filter, and from the triggers list, select the When a HTTP request is received trigger
      • Select + New step
      • In the search box, enter BizTalk Server as your filter
        • From the connector list, select the Send message action form the BizTalk Server connector
      • Once the action is added to your logic app, you need to setup the connections, perform the following actions:
        • Select the option Connect via on-premises data gateway and on the gateway properties, select the Subscription and the desired Connection Gateway.
        • On the Connection Name property, provide a proper name for your connector
        • On the BizTalk Server URL property, provide a public UTL for the Management Application on the BizTalk Server IIS
        • On the Authentication Type property, set Windows and provide a proper Username and Password to access the above service (BizTalkManagementService)
        • Select Create
      • Once you create the connector, the Send message action will appear on the Logic App designer
        • From the Receive Location list, select the receive location we just create above
        • On the Input Message, specify the Body token of the When a HTTP request is received trigger
  • The Logic App Send Adapter is responsible for sending messages from BizTalk Server to Logic Apps.
    • We need to first create a Logic App in our Azure Subscription has as a trigger the When a HTTP request is received present in the Request built-in Connector.
      • Note: The Logic App adapter doesn’t support the new Logic App (preview) that are hosted on Azure Function runtime.
    • We need to configure TLS 1.2 as the default security protocol on BizTalk Server.
    • And finally, create a BizTalk Server Application to send message to Logic App
      • Right-select Send Ports, select New, and select Static One-way Send Port
      • In the Send Port properties, enter the following:
        • Name for the send port. For example, enter POC_SEND_MSG_LOGIC_APP.
        • For the Type, select LogicApp from the list, and select the Configure button
          • In the General tab, configure the Callback URI of your logic app trigger by selecting Configure…
            • On the Logic App Details Page, select Sign-in to Azure and authenticate with an Azure account
            • After you authenticate, you can be able to access your Azure and select the Subscription, the Resource Group that contains the Logic Apps, and finally the Logic App and the Trigger
            • The Trigger will be always manual
            • Select OK to save your configurations.
          • In the Messages tab, set the content-type header as:
            • Content-Type:application/json

Setting up the BizTalk Server 2020 Logic App adapter

I told above that almost everything will be already configured. However, there is a critical bug in the default installation of the Logic App adapter that will affect the process of receiving messages from Logic Apps using the BizTalk Server Connector.

The Logic App Receive handler, or what we normally call the Logic App Receive adapter is by default configured to use the default In-Process Host, normally the BizTalkServerApplication, in this case as you saw in the picture bellow BizTalkServerReceiveHost.

If you leave this configuration, you will end up having errors when trying to activate a Receive Location that uses the Logic App adapter:

The receive location “Receive Location name” with URL “/iis-application-name/Service1.svc” is shutting down. Details

See more about this error here.

This happens assigned because the Receive handler is associated with the In-process Host and it should be bound to the Isolated Host.

To fix this bug we need to:

  • Remove the adapter from all assigned send ports and receive locations in my applications
    • Therefore, is important to do this immediately after the installation and configuration of your BizTalk Server environment. Otherwise, it will affect your existing application that uses the Logic App adapter to send messages to Logic Apps.
  • Download the BizTalk Server 2020: Scripts to Fix Logic App Adapter installation available on GitHub
  • Execute the RemoveLogicAppAdapter.vbs script to un-register the Logic App adapter from the BizTalk Server Configuration Console
  • Execute the AddLogicAppAdapter.vbs script to properly register the Logic App adapter from the BizTalk Server Configuration Console

The post What’s new in BizTalk Server 2020: Logic App Adapter appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server 2020 Logic App Adapter: The Messaging Engine failed to add a receive location “Receive Location” with URL “…/Service1.svc” to the adapter “LogicApp”. Reason: “80070057”

BizTalk Server 2020 Logic App Adapter: The Messaging Engine failed to add a receive location “Receive Location” with URL “…/Service1.svc” to the adapter “LogicApp”. Reason: “80070057”

Until now, I usually have used the Logic App adapter to send messages to Azure Logic Apps and extend the BizTalk Server capabilities with the Azure Services. Yesterday, once I was trying the inverse capabilities, i.e., receiving a message from Logic App into BizTalk Server using the Logic App Adapter and, of course, the BizTalk Server Connector available on Logic App. I was surprised with the following error while I was trying to access the exposed service to receive messages from Logic App:

Receive location for address “/LogicAppTestServoce/Service1.svc” not found. (The BizTalk receive location may be disabled.)

This is a common error. It means that the Receive Location doesn’t exist or it is disabled. So I went to the BizTalk Server Administration Console and Enabled the Receive Location, but it automatically disabled again.

Once I check the Event Viewer for errors I found the 3 following errors:

The Messaging Engine encountered an error when creating the receive adapter “LogicApp”. The Assembly is: “Microsoft.BizTalk.Adapter.LogicApp.Runtime.LogicAppReceiver, Microsoft.BizTalk.Adapter.LogicApp.Runtime”. The error occurred because the component does not implement the mandatory interface “IBTTransportControl”.

The Messaging Engine failed to add a receive location “POC_LOGICAPP_TO_BIZTALK_LA” with URL “/LogicAppTestService/Service1.svc” to the adapter “LogicApp”. Reason: “80070057”.

The receive location “POC_LOGICAPP_TO_BIZTALK_LA” with URL “/LogicAppTestService/Service1.svc” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.

Cause

There is a critical bug in the default installation of the Logic App adapter that will affect the process of receiving messages from Logic Apps using the BizTalk Server Connector.

The Logic App Receive handler, or what we usually call the Logic App Receive adapter, is, by default, configured to use the default In-Process Host, normally the BizTalkServerApplication, in this case, as you saw in the picture bellow BizTalkServerReceiveHost.

Like what happens with the HTTP adapter, the Logic App Adapter is one of the adapters that support two-way communications. Still, unlike other adapters, this adapter has two characteristics that define it:

  • The Logic App Receive Adapter that is responsible for delivering messages to BizTalk is, in fact, a WCF Service that runs inside Internet Information Services (IIS).
  • And for that reason, it must be configured in IIS – it is not there out-of-the-box.

This means that when we create and configure a receive location that uses the Logic App adapter inside the BizTalk Server Administration Console, this receive location uses an application within IIS.

So, if you leave this Logic App Adapter default configuration, you will end up having the above errors when trying to activate a Receive Location. This happens assigned because the Receive handler is associated with the In-process Host and it should be bound to the Isolated Host.

Solution

To fix this bug we need to:

  • Remove the adapter from all assigned send ports and receive locations in my applications
    • Therefore, it is essential to do this immediately after the installation and configuration of your BizTalk Server environment. Otherwise, it will affect your existing application that uses the Logic App adapter to send messages to Logic Apps.
  • Download the BizTalk Server 2020: Scripts to Fix Logic App Adapter installation available on GitHub.
  • Execute the RemoveLogicAppAdapter.vbs script to un-register the Logic App adapter from the BizTalk Server Configuration Console.
  • Execute the AddLogicAppAdapter.vbs script to properly register the Logic App adapter from the BizTalk Server Configuration Console.

The post BizTalk Server 2020 Logic App Adapter: The Messaging Engine failed to add a receive location “Receive Location” with URL “…/Service1.svc” to the adapter “LogicApp”. Reason: “80070057” appeared first on SANDRO PEREIRA BIZTALK BLOG.

December 07, 2020 Weekly Update on Microsoft Integration Platform & Azure iPaaS

December 07, 2020 Weekly Update on Microsoft Integration Platform & Azure iPaaS

Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform and Azure iPaaS?

Integration weekly update can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.

Microsoft Announcements and Updates

Community Blog Posts

Videos

Podcasts

How to get started with iPaaS design & development in Azure?

  • Robust Cloud Integration with Azure
  • Microsoft Azure for Developers: What to Use When
  • Serverless Computing: The Big Picture
  • Azure Logic Apps: Getting Started
  • Azure Logic Apps: Fundamentals
  • Microsoft Azure Developer: Creating Enterprise Logic Apps
  • Microsoft Azure API Management Essentials
  • Azure Functions Fundamentals
  • Cloud Design Patterns for Azure: Availability and Resilience
  • Architecting for High Availability in Microsoft Azure

Feedback

Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.

What’s new in BizTalk Server 2020: XSLT 3.0 Support

What’s new in BizTalk Server 2020: XSLT 3.0 Support

Last weekend I delivered a session about BizTalk Server 2020 in action on Global Integration Bootcamp 2020 Madrid, where I spoke about the new features available in the most recent version of the product.

Today I will start this series of blog posts about what’s new in BizTalk Server 2020 by beginning to speak about one of the most expected and log time requested features: XSLT 3.0 Support.

XSLT 3.0 represents a significant upgrade of the XSLT 1.0 (and even XSLT 2.0) standards to become a general-purpose transformation language for the most common data storage and messaging formats.

There are a lot of advantages to using XSLT 3.0 compare with the XSLT 1.0 or, in fact, XSLT 2.0, and the goal here is not to address every single of them, but we can highlight the following one:

  • Extended Function Set, Sequences, Arrays, and Maps: The initial function set for XSLT1.0 was the same as XPath 1.0 functions and was very limited. Minimal math support, no regular expression support, minimal string manipulation capabilities, no support for set (sequence) operations, no support for dates.
    • Grouping:
      • xsl:for-each-group: a set of items can be selected and arranged into groups based on specific criteria (for example, common values); then each group can be processed in turn
        • special XPath functions within for-each-group: current-grouping-key(), currentgroup()
      • Variants of <xsl:for-each-group>:
        • group-adjacent: adjacent items are allocated to the same group if they have common values for the grouping key
        • group-starting-with: whenever an item matches the pattern, a new group is started with this item
        • group-by: whenever an item matches the pattern, a new group is started after this item
    • Sorting:
      • xsl:sort: can be used inside of <xsl:for-each>, <xsl:for-each-group>, <xsl:applytemplates> and <xsl:perform-sort>. It defines the order in which the data is processed by the instruction.
      • Several subsequent sort keys can be defined

BizTalk’s default XSL transform engine implementation is based on .Net Framework XSLT Transformations. This support is limited to XSLT 1.0.

Starting with BizTalk Server 2020, users can choose Saxon:registered: 9 (Saxon 9 HE) as the XSLT transform engine. But most importantly, it will be possible to plug-in your own custom XSLT transform engine.

  • YYou can implement a custom XSLT transform engine by defining XSLT transform implementation derived from abstract class Microsoft.XLANGs.BaseTypes.ITransform2 in assembly Microsoft.XLANGs.BaseTypes.dll.
  • See more details at: Custom XSLT transform implementation.

This makes it possible for BizTalk server maps to support newer versions of XSLT. Using Saxon 9 HE, we can readily use XSLT3.0.

Use XSLT Transform Engine property to specify the XSLT transform engine you wish to use:

This was one of the most expected features, but be careful, this can be a poisoned gift because Saxon 9 HE doesn’t support embedded scripting. As a result, functoids shipped as part of BizTalk may not function well. And for many cases, this can be a showstopper.

The advantages of using XSLT 3.0 with Saxon 9 HE:

  • Development: The XSLT file can be developed separately and hosted in a BizTalk map. It will simplify specific scenarios, especially scenarios that grouping and sorting are required. As we mentioned above, XSLT 3.0 provides an extended set of functions, which was very limited within XSLT 1.0.

Disadvantages when using XSLT 3.0 with Saxon 9 HD:

  • Level of effort: Not quite as intuitive, Functoids are easier to read visually on the map grid and therefore Requires “geeky” coding skills.
  • Overview: You lose the visual map representation. You can conjugate Saxon 9 HE with the BizTalk Mapper, but it is harder to do it.
  • BizTalk Mapper Editor limitations: except for a few built-in Functoids like Scripting Functoid (not all script types will work properly) or advance Functoids, BizTalk Functoids will not work while using the Saxon 9 HE XSLT Transformation Engine.
  • BizTalk Development Tool Integration: it is a brand new feature, and it seems that doesn’t have, at least for now, the same level of integration capabilities with the BizTalk Server development tools that we are usual to have and use if we compared with the default transformation engine

The post What’s new in BizTalk Server 2020: XSLT 3.0 Support appeared first on SANDRO PEREIRA BIZTALK BLOG.