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, based on the type of the message or the content of these messages, in runtime, we need to define the port configurations or communication channels. Classic examples of those scenarios are:
- Sending an email notification or the message through email. In 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, basically routing.
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 the destination endpoints may change frequently or when messages need to be routed to multiple endpoints based on the content of the message or business rules.
- Orchestration Support: Normally, this type of port is used inside BizTalk orchestrations, where the orchestration can set the destination of the message dynamically 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 it looks our BizTalk Server solution inside the orchestration:
We will configure the adapter properties in the context of the message. 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 in 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 by:
- Several physical send ports are configured for each partner and system we will want to exchange messages.
- On the orchestration, the logical port, instead of using a dynamic port binding, will use a Message Box direct bound, which means we will be publishing 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 promote some kind of metadata to the context of the message that will allow us to identify and subscribe the 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 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 requirements in Azure Integration Services is that, with the exception of a few connectors like the HTTP connector, connectors don’t allow us in runtime to set up the configurations of the channel dynamically. 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 in 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, or if this communication is One-way send communication (doesn’t require a response) 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 present 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?
The solution I will present will be inspired by the SQL Server ports in BizTalk Server, where we specify what is the SQL Server, the database, authentication, and many other properties of that channel in order for us to perform that communication but also what are the operations we will be doing on that database.
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.
- And based on the operation we will 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 context of the message.
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.
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 some secrets, to increase security, we could use Azure Key Vault to store that information.
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 secrets 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!
