Welcome again to another BizTalk Server to Azure Integration Services blog post. In my previous blog post, I discussed how to send zipped messages or files. Today, we will discuss a classic requirement in BizTalk Server solutions: How do we migrate Dynamic Ports?
It is not that hard to find BizTalk Server solutions/processes that need to send messages to partners, but in some cases, at runtime, depending on the message type or content, we need to define port configurations or communication channels. Classic examples of those scenarios are:
- Sending an email notification or a message through email. At runtime, we will specify all the properties of that channel, like To, CC, From, SMTP server, and authentication.
- Sending a file to a partner FTP, where, in runtime, we will define what the partner is and set up all the properties of that channel, like FTP Server, authentication, folder, and file name.
In BizTalk Server, we can archive that to all adapters. Basically, in BizTalk Server, there are two ways to define what communication we will be using in runtime:
- The first option, and the most common option, is to use BizTalk Server Dynamic ports.
- The second, and less-used, is a combination of Message Box direct-bound ports and filters on send ports, essentially routing.
📝 One-Minute Brief
Dynamic ports are widely used in BizTalk Server to define endpoints at runtime. This article explains how to approach migrating dynamic port scenarios to Azure Integration Services by using cloud‑native patterns that preserve flexibility while improving maintainability and governance.
Implementing the BizTalk Server solutions
Using dynamic ports.
A BizTalk Server dynamic port is a type of port used in Microsoft BizTalk Server to send messages to various destination endpoints without having to pre-configure the specific address details in the port configuration. Unlike static ports, where the address is fixed and known at design time, dynamic ports allow BizTalk to decide at runtime where to send the message based on the message context or other runtime considerations.
Key aspects of BizTalk Server dynamic ports include:
- Runtime Resolution: The destination address and transport properties of a dynamic port are set at runtime using message context properties. This allows for a high degree of flexibility in message routing.
- Adaptability: Dynamic ports are particularly useful in scenarios where destination endpoints may change frequently or when messages need to be routed to multiple endpoints based on message content or business rules.
- Orchestration Support: Normally, this type of port is used within BizTalk orchestrations, where the orchestration can dynamically set the message’s destination based on logic implemented within the orchestration.
Dynamic ports are an essential feature for complex integration scenarios where the destination of messages cannot be determined upfront and may vary based on the message itself or the outcome of business processes.
And basically, this is how our BizTalk Server solution looks inside the orchestration:
We will configure the adapter properties in the message context. And, of course, those properties will change based on the adapter we use. For example, this is for connecting to a SQL database:
Request2=Request1;
Request2(WCF.Action)="TableOp/Insert/dbo/CustomerTable";
Request2(WCF.BindingType)="sqlBinding";
Request2(WCF.UserName)="myuser";
Request2(WCF.Password)="mypass";
SendPort(Microsoft.XLANGs.BaseTypes.Address)="mssql://SQL/INST/DB"; SendPort(Microsoft.XLANGs.BaseTypes.TransportType)="WCF-Custom";
There are also ways to create a static port with dynamic behavior, but I will leave that for another day.
Using a combination of Message Box, direct-bound ports, and filters.
Now, some adapters can be quite difficult to configure at runtime, like the SQL Adapter. So, in order to minimize that developer effort and to better maintain the port configuration and security. We can apply the same principles without using Dynamic ports.
In this approach, we will replace that Dynamic port with:
- Several physical send ports are configured for each partner and system with which we want to exchange messages.
- In the orchestration, the logical port, instead of using a dynamic port binding, will use a Message Box bound directly, which means we will publish the messages directly to the BizTalk Server Message Box – this is the database where all pub-sub magic of BizTalk Server happens.
- In the orchestration, it will be important to propagate metadata to the context of the message that allows us to identify and subscribe to messages to each partner or system.
- Finally, on each physical send port, we need to apply a filter to subscribe to those messages.
The real case scenario where I added to implement this approach was on a client where we had several processes running, and depending on which internal company inside the organization that the messages were related to, we had to communicate with a different database, but all those databases were equal.
The challenge
The biggest challenge in implementing this type of requirement in Azure Integration Services is that, with the exception of a few connectors, such as the HTTP connector, connectors don’t allow us to dynamically set channel configurations at runtime. Instead, we need to have an API Connection already established. If you use BizTalk nomenclature, we can only use physical ports without dynamic behavior!
You can say: Hey Sandro, we can dynamically configure the TO, email body, CC, and other properties in the Outlook connector, for example.
Yes, you can. But you cannot dynamically define the FROM! You can use the SQL connector, but you cannot at runtime define which SQL Server you will be using.
So, how can we migrate this to Azure Integration Services?
Building the Logic App Consumption Solution
As I always say, there are many ways to achieve the same goal. Here I’m going to present one that I think is an elegant one. But depending on the requirements, whether this communication is One-way (no response required) or two-way (request-response), you will find different approaches.
If it is a one-way send communication, you will find a solution in one of my previous blog posts: Migrating BizTalk Platform one-way routing solutions. But today, we are going to address a most complex scenario, which is the one I presented above, in which we need to communicate with different equal databases. How do we migrate those scenarios if SQL Connector doesn’t allow us to specify the server dynamically?
BizTalk Server SQL Operations
The solution I will present will be inspired by the SQL Server ports in BizTalk Server, where we specify what the SQL Server is, the database, authentication, and many other properties of that channel to perform that communication, and also what operations we will be performing on that database.
Logic App Workflows
So, to start this solution migration, we will be creating two or more Logic Apps that will act as the BizTalk Server SQL Send Port. I have called them:
- LA-NC-SQL-Connector-POC
- And LA-SP-SQL-Connector-POC
These Logic Apps will have:
- A Request > When a HTTP request is received trigger.
- Based on the operation we define, we will perform the corresponding SQL operation.
Of course, each Logic App is configured with a different SQL Server database, but they will implement the same business logic.
Now that we have our “SQL Server custom connector” or “SQL Server ports,” we need to create the main process to use them dynamically based on the message context.
I call this process LA-ProcessOrderRequests-POC. Now, knowing that:
- The only connector that really allows us to configure dynamically is the HTTP connector.
- This is a request-response communication, so we cannot use the Service Bus to route these messages. We may, but it will be complex and expensive.
- And that our “SQL Server custom connector” or “SQL Server ports” Logic Apps are triggered by HTTP calls.
Configuration Options
We need to find a place to store those trigger URLs in order to fetch those in runtime based on some metadata of the message, in the context of the message, or in the body, and route them inside the Logic App. For this, we could use:
- An Azure Function that reads configuration from App Configurations. (like I explained in my previous article: An Azure Function that reads configuration from App Configurations)
- Or, because those URLs contain secrets, to increase security, we could use Azure Key Vault to store them.
In this sample, we decided that the following payload will be received by the main Logic App:
{
"Company": "SP",
"Operation": "Insert",
"Data": {…}
}
Of course, the data property is dynamic.
And our main process will be something like this:
- Based on the company, it will read a secret from Key Vault that contains the URL of the child Logic App.
- The secret’s name convention is composed of static and dynamic data and, in our case, will always be “LA-<company-name>-URL
- If we successfully retrieve the URL from Key Vault, we will route the request to the correct database.
- Otherwise, we will send an error message back to the system.
And this is how we bring some BizTalk Server out-of-the-box capabilities to Azure. And also, why it is important for you to have a good knowledge of BizTalk Server to perform those migrations.
I hope you find these architecture samples useful, and stay tuned for more BizTalk Server to Azure Integration Services.
Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego!
