BizTalk Migrator tool is one of the latest releases of Microsoft, which helps to migrate your BizTalk solutions to Azure in a much simpler and automated way.
So to keep you informed about the recent enhancements of the tool, the Azure Logic Apps team had a live remote session exclusively on that topic.
Without any further delay, let us jump in as there are tons of updates are waiting
Agenda of the session
- Recap of the BizTalk Migrator tool
- What is new
- What is on plan
- Demo
- Question & answer session
Before beginning the session, the team wanted to know what the customers expect to improve in the BizTalk Migrator tool.
Click the link to fill in the feedback survey and, here is another GitHub link where you can raise a request if you face any issues while migrating.
BizTalk Migrator Recap
- The private preview started in June 2020 & later released in October 2020 (The team announced the tool at Integrate event last year)
- Works well with BizTalk MSIs
- Tested with BizTalk 2013R2+
- Should work with BizTalk 2010+
- Might work with BizTalk 2006R2
- Supports three adapters: FTP, File, HTTP
- Generates a report showing what or what cannot get converted
- Basic orchestration support
- Generates resources in Azure that users cannot use to extend or create Integration solutions
Roadmap
What is new?
- Logic Apps Standard support
- SFTP Adapter
- MQ Adapter
- SAP Adapter
Also, not yet been published to chocolatey software, but it will be available soon.
Now, let us start by seeing a bit of Logic App Standard.
Logic App Standard
Logic App now supports Standard as a target. If you have looked through the options on the tool, you will see that there used to be the target of Consumption or Integration Service Environment (ISE). That has now got replaced with Standard.
You can now choose whichever runtime, but when you do not specify a target as default, it will get set to Consumption. This option will get changed as the default target will soon be set to Standard.
- One of the things it is doing now is that the Logic Apps that the App independently generated are now appearing as workflows in a single Standard Logic App.
- Not everything is working in Logic Apps Standard, e.g., Flatfile processor
- It is not yet possible to deploy it all locally
- Missing support for Service Bus and App configuration locally
- APIM self-hosted gateway is expensive
- But you can run it by connecting to cloud connectors and the managed API connectors so that you can debug some parts of it locally.
- They are also planning to remove dependency on APIM when executing routes.
More about Logic Apps Standard
- It’s a new offering from Microsoft
- Uses the Functions Runtime to execute Logic Apps
- It runs on a single-tenant (i.e., your own set of infrastructure)
- Uses an App Service plan for pricing (i.e., monthly cost)
- Develop and run locally in VS Code
- Some connectors are built-in, but others you have to connect to the cloud
- Integration Account no longer needed
Logic App Consumption vs Standard Runtime
In Consumption, we have a separate resource group, and we would have an independent Logic App where each Logic App is a workflow.
So, it is in the designer to see the Logic Apps deployed as a separate resource in Azure. Then, we have some API connections that support the connections actions inside the Logic Apps and the Integration Accounts. You can also connect other resources like Service Bus, Functions Apps, etc.
In Standard, we still have a resource group, and we have also got the other things in Consumption but what is different is that your Logic App now has multiple workflows. So, everything that used to be a Logic App in Consumption is now a workflow in Logic App Standard
It is essential to realize the difference between these two tiers. It significantly impacts how the product team decided to package up what they have generated on migrating from BizTalk Server.
For better understanding, imagine a scenario where there are three resource groups A, B, and C with 15, 5, and 2 Logic Apps, respectively, in a Consumption model. But in Standard, you can have one Logic App with all the 22 workflows, or you can split it up, as shown in the picture below.
Issues in Logic App Standard (From the BizTalk migration point of view)
- No Flat File support
- No ability to call a workflow by expression
- Cannot use ARM expressions to call parameter values
- No tokens in Parameter files
- There is a single shared parameter file for all workflows in a Logic App
- The only solution to solve the above problem is to add the workflow name to the parameter name to make it specific to a workflow
No Integration Account in Logic App Standard
An Integration Account was a star score for the schemas & maps, but we do not have that anymore. Instead, we have got schemas and maps that get stored as artifacts in each Logic App. All the workflows in that Logic App can access them, but another Logic App with its workflows doesn’t directly have access. So, you have to call the other workflow in Logic App 1 that has access to those schemas and maps, as shown below.
What gets deployed?
Here is a clear explanation of what can get deployed using the Consumption version of the BizTalk Migrator tool.
- A Message Bus Resource Group has App config, an Integration Account, APIM, Functions, etc.
- Then there is a System Application Resource Group made up of Logic Apps.
- And each of your applications, you get another Resource Group with Receive Port, Send Port, Topic Subscriber, Process Manager & API connections.
- In the Standard version, you don’t have Routing Slip Router (RSR) in Message Bus Resource Group. That’s moved into the System Application, so there is now another workflow as part of it.
- And in the current iteration of the tool, you will end up after deployment with a more significant System Application. All the Consumption Logic App now appear as workflows in there. So, the JSON decoder, encoder and all the rest are now workflows in the Systems Application.
- You will also get the Receive Port, Send Port, Topic Subscriber, Process Manager & API connections inside the System Application itself.
How much does the Consumption & Standard version of BizTalk Migrator Costs?
The below images clearly show the difference between these two versions,
Demo – Standard Support
Before starting the demo, first, we will see how Consumption support looks. It has several Resource Groups, including Message Bus Resource Group, System Application Resource Group, which consists of several Logic Apps. Then we have got a migrated application Resource Group.
We have already seen in the above images what gets deployed in each of these Resource Groups.
Now, let’s look at what the tool generates in the Standard version. The Message Bus hasn’t changed, and the only thing new you might see is that there is now a new App Service plan for Logic Apps and the below image shows the Standard workflow pattern.
You can see more changes in the System Application. This Resource Group will still have a Service Bus and many API connections, but the significant difference is that it will have only one Logic Apps containing several workflows.
Let’s also see what it looks like inside a workflow of that Logic App. FTP pass-through adapter gets deployed, consisting of an FTP Receive Adapter, Topic Subscriber, an FTP send adapter, Process Manager, etc.
So, everything gets deployed inside a single Logic App. We will also test this scenario by moving over to FileZilla and transferring a file.
Now let’s switch back to the Logic App and check out the FTP Receive Adapters. This is how the trigger history in the Receive Adapters looks like
The workflows inside the Logic Apps will work in the same way as Consumption ones, and we will see how it looks like in the new designer. The workflow shows how it runs through, gets configured, and then check if we can process the File.
The below image shows a part of the workflow with new Inline JavaScript (which requires an Integration Account but doesn’t anymore). So, what happens is the File is first converted into a BizTalk File Mask, then to some regex and checks if the File is to be processed (yes or no).
If the output is yes, it runs through, constructs an envelope around it, and then off it to call the Routing Slip Router (RSR), which finally publishes the File to the Message Box. Now you will be able to see a new file in the inbound at File Zilla.
That’s the same demo that we used to do with Consumptions, but now we are running in Standard against these new Logic Apps.
Logic App Standard Support
Simplifying Routing Slip Router
The way the BizTalk migrator tool works is to read a Routing Slip Router (RSR), then at the end of each Logic App, we call the Routing Slip Router, which makes a call to the following Logic.
Let’s find how it works. First, the Receive Adapter calls the RSR, which then calls the Flat File Process and again, the RSR gets called to call the XML processor; this process goes on until the message gets published to the Message Box. Also, in this case, the Receive Adapter doesn’t know where the next point in the pipeline is, but the RSR does. In the same way, Flat File Processor doesn’t know where they are going next. This process means that they are entirely independent components.
The RSR needs to go to an API Management to get the Callback URL, signature, and endpoint for the Logic App to implement this today. Every call to the RSR needs to do this, so we end up with a somewhat convoluted way of going RSR to APIM and back out again. But there is latency introduced by this method.
With Standard Logic Apps, all the workflows are within the same Logic App, and this allows to call the Routing Slip Router directly, i.e., instead of having to go out to APIM, it would directly call the next point, say Flat File Processor.
This method is not possible today, but that’s the next step the team is working on currently.
New Adapters
- SFTP
- Send and Receive – Consumption only
- It works the same as BizTalk, although not all properties get mapped
- MQ
- Send and Receive – Consumption Only (for now)
- Uses recurrence trigger for receive
- SAP (Preview)
- Send only – Consumption only (for now)
- May need attention to differentiate between calling IDOC or BAPI
- Requires OPDG
Roadmap
- What’s Planned?
- WCF-BasicHTTP Adapter
- WCF-WebHTTP Adapter
- Business Rules Engine
- BTDF MSI support
Question & Answer Session
SAP RFC connector – Does that have to be different from the BizTalk SAP Adapter?
SAP RFC connector is up on the same framework; although it’s using the SAP.NET connector, it implements everything that the BizTalk SAP Adapter does and can also perform more. So, it’s a superset of what you can do with the BizTalk SAP Adapter.
If you have got any other questions or feedback, get in touch with us via this email address – BizTalkMigrator@microsoft.com
