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.
Tools Installation
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
ACS provides authentication for the BizTalk Service we’re
about to create.
As you will see later, the ACS namespace I create here
will be used as an authentication mechanism when I deploy the biztalk service
from VS, as well as when I submit messages to this service.
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.
No comments:
Post a Comment