BizTalk Migration To Azure (Routing)

In the previous article I wrote about the Message box and a Biztalk Message. Another thing we need to address is the routing. In BizTalk the routing is done based on context properties or an Itinerary (if you use the ESB components from BizTalk). Once a message is Received the routing will make sure the message is processed until it reaches the destination.

I will keep things simple and let’s say that routing consists of a list routing items. A single routing item will basically consist of two things:

• A routing Endpoint (basically a queue name)
• Parameters for the Endpoint

In the previous post I Talked about an unzip Example. But what should be unzipped, The payload, Or an attachment? That’s what the parameters are for, to give instructions to the routing Endpoint. But there is nothing in place to perform the routing. So that is why we have to create the OnRamp router.

?

The OnRamp Router

The OnRamp is a Function app that listens to the OnRamp queue. Whenever a message is put on the OnRamp queue, it will trigger the OnRamp function. Below is the functionality of the onramp router:

?

Try

Delete the message from the queue (no dead lettering)

Deserialize the claim to get an instance of the class

Get the first Routing Item from the Routing Slip

Read the queue

Write the message to the queue of the Endpoint

Catch

???????????????Set error information (more on this later)

???????????????Persist Claim to Blob Storage

The Endpoint

A routing Endpoint is Basically a Service Bus triggered Function app. The function app can only succeed or fail, there is no maybe here. It will serve as the entry point for whatever you want to do. In my example I want to unzip the attachment. So let’s see what the steps are to perform the unzip operation:

?

Try

1. Delete the message from the queue (no dead lettering)
2. Deserialize the claim to get an instance of the class
3. Get the first Routing Item from the Routing Slip
4. Get the endpoint parameters
5. Parse parameters
6. Unzip Attachment
7. ???????????????Create a new Attachment for each zip entry.
8. Remove first Routing Item from the Routing Slip
9. Persist Claim to Blob Storage
10. Send Back to Onramp

Catch

1. ???????????????Set error information (more on this later)
2. ???????????????Persist Claim to Blob Storage

?

This is enough to get a message flowing in Azure. To really get it going you will have to perform the following steps when a message is received.

1. Create a claim
2. Set routing slip (from a template)
3. Enrich the claim with properties (filename / size / location / Uri etc.)
4. Persist Payload of the claim
5. Add Attachments
6. Persist The Claim
7. Send to Onramp

Voila, there is, ?we have a ?message routing solution. With this mechanism it is possible to create workflows. You just have to make sure that routing is added to a message (Itinerary) and send it to the OnRamp router.

One thing to keep in mind is to keep the Function Apps simple and do one only 1 thing. You could compare each Function App with a BizTalk Pipeline Component. You can chain as many as you like. This will promote reuse and will shorten development time of integrations.

?

Some of the Function apps that I have created are:

Unzip

• Unzip the payload or attachments
• Use parameters to describe what should be unzipped

Xls2Csv

• OpenXml implementation that converts Xlsx spreadsheets to csv
• Use Parameters for encoding and separator

Csv2Xml

• Convert a simple CSV file with a header to Xml
• Use parameters to set Document root Name / Namespace
• Use parameters for encoding and ?separator

Payload2Blob

• Write a Payload to a specific blob Location
• Use parameters to describe location / name etc.

XpathPromoter

• Run a bunch of Xpath Queries against an xml instance
• Write the values to the claim as properties

Digital Signature

• Validate or Create a digital signature
• Use parameters to read keys/secrets from Azure AppConfiguration

?

With these components (Claim, OnrampRouter, RoutingSlip) we have the most important parts of a solid integration solution. We have a versioned claim so we can handle really large messages, we have a routing mechanism to get the flow going. But what's missing is the link to the message Box.

I started with the messagebox in the first post but haven’t mentioned it until now. In the next part I will dive into what we have now?and how we can get messagebox functionality as well.