Azure BizTalk Services
Windows Azure BizTalk Services provides integration capabilities for the Windows Azure Platform, to extend on-premises applications to the cloud.
It provides common integration capabilities such as bridges, transforms, and B2B messaging on windows azure.
So this means, that now we can build our business process using a hybrid model, where part of this process continues to be running on the on-premise BizTalk Server, while the other part can be running on Azure.
Of course – at least at this stage – do not think of BizTalk Services as BizTalk Server on the cloud.
While BizTalk Services provide certain integration services, its still in its early stages. BizTalk Server on the other hand is a complete integration platform.
The hybrid business process
The business case itself is trivial, but is enough to deliver a high level message into building hybrid applications.
I will use BizTalk Services to convert a Payment Notification process into a hybrid model.
In this process, the bank sends the gateway a message containing a set of payments, and the gateway assembles a response and sends it back to the bank.
Now assume that the process must receive messages from a variety of banks, and based on a certain ID of the message, it must detect the sender and perform a certain message processing…
So now the process goes as follows:
A bank sends a message to the BizTalk Service…the service inspects the message, and based on an ID field, performs a custom mapping for that specific bank to change the message format…
The biztalk service then sends the message to a service bus queue…
The on-premis payment notification process is listening on this queue…it gets the message, and same as before, creates a response.
It then pushes the response to another service bus queue…
The bank then should be listening to this queue…
As I said, the business process itself is fictional and somewhat trivial…but it will provide an overview of building hybrid applications with BizTalk Server 2013.
You develop BizTalk Services, much like almost everything you develop for Azure: you use your local VS and then deploy to the cloud.
The following tools are available for download:
–The Windows Azure BizTalk Services feature, includes the Visual Studio project templates for creating the BizTalk Service projects – known as bridge – and BizTalk Service Artifacts projects – known as Transform.
–It also includes the Visual Studio Server Explorer plug-in for creating LOB Relays and LOB Targets used by the BizTalk Adapter Service.
Another tool is the BizTalk Adapter Service.
This includes a runtime component that manages connectivity to on-premises LOB applications.
For our scenario, I will not be using the BizTalk Adapter Service. So I only need the BizTalk Services SDK.
Upon installation, you will have new VS templates to create BizTalk Services and deploy to Azure:
Creating the Access Control Service Namespace
Moments later, the namespace will be created, and from this moment, you will use the Active Directory tab in the left navigation menu to manage this namespace. From there click Manage:
Once you do so, the old Access Control Service management portal is opened. Click on the Management Service link:
In the next page, you are presented with the accounts that grants access to the ACS we’re managing. There is one created by default, and you can add more accounts. For now, click on the default account which is named “ManagementClient”:
Now, we need to get the password for this account. In the next screen, click on the password link:
From, there copy and save the password, as you’ll need it when creating the BizTalk Service…
So what we did here is getting the required access information for this ACS namespace. This information will be used when creating the BizTalk Service so that it can authenticate itself against the ACS.
In this case I will be using the default account, named “ManagementClient” and the password which I copied and saved.
Creating an SSL Certificate
Before creating the BizTalk Service, there is one more thing we need to do. After the BizTalk Service is created, just like ACS or service bus endpoints, it will be exposed using a URL. Of course, clients will be communicating with this URL over HTTPs. So, you will a need a SSL certificate for server authentication. This certificate will be deployed along with the BizTalk Service.
In real applications, this certificate must be from a trusted Certificate Authority, for the sake of this demo however, I will use the makecert tool to create a self-signed certificate.
The highlighted part of common name is the name I will be going to use as the name of my BizTalk Service. Of course, again recall that this certificate will go into the server actually hosting the BizTalk Service in Azure, so you will have to use the fully qualified domain name as I did above.
Now, you will see the certificate added to the Personal Store of the current user account:
Now export this certificate – along with the private key – and save it. You will upload it later when creating the BizTalk Service.
Now, one final thing you need to do. In this sample, my machine will be playing the role of the client that is communicating with the BizTalk Service. Since I am using a self-signed certificate instead of one being issued from a trusted CA. this means that the certificate will not be trusted on my machine, which will cause SSL handshake problems. To get what I mean, double click the certificate, and check the chain path. As you see, the certificate authority is not trusted since the certificate is self-signed:
To resolve this, just copy the certificate and paste it in the Trusted Root Certificate Authorities. This way, when the machine tries to establish SSL handshake with the BizTalk Service, it will succeed:
Creating the BizTalk Service
Finally we’re ready to create the BizTalk Service.
Start in the BizTalk Services tab in the left navigation menu. In the first screen, the most important thing is to remember to supply the same service name that you used as the common name for the certificate. In my case, it was pluralsightbts:
Next, I specify the database settings of the tracking database. One detail which is important here, is that selecting the DB in the same region as the one you selected when creating the service will give better performance due to lower communication hubs…
In the next screen, you will now use the ACS information previously configured. Use the password you saved back then:
In the final screen, select the certificate you exported in the previous step. Just note that the password required here is the one you were asked to create by the wizard when exporting the private key:
Register BizTalk Service
The final step is to register the service in the BizTalk management portal. You can reach the management portal by clicking the MANAGE button of the bizalk service:
Once you do, you will be redirected to a new biztalk management portal, where you will be asked to register the biztalk service. Remember, again to supply the key of the ACS namespace authenticating our biztalk service:
Creating the Service Bus
As I said when I described the process, the BizTalk Service will send the message to Service Bus queue. It’s from this queue, that the on-premise BizTalk Server will pick up the message.
So, now lets create the service bus:
Once created, click on the namespace, and create the queue that will hold the messages:
This wraps up part 1. In part 2 I will use the demo solution to show you how the interaction between the on-premise biztalk and biztalk services.