On Monday, June 3rd Microsoft announced the Preview of Windows Azure BizTalk Services (aka WABS or just BizTalk Services). Windows Azure BizTalk Services is a managed service provided by Microsoft. More specifically you can think of BizTalk Services as a Platform as a Service (PaaS) offering. Recently, I had an opportunity to work with this platform as I was involved in an NDA event in New York City. While I was preparing for that presentation I took the opportunity to document some of my learnings so that I could share them when the content was no longer considered NDA. With the TechEd announcement this information is now considered public hence the timing of this blog post.
The purpose of this offering is to provide customers a way to execute integration scenarios in a cloud based environment. The idea is that you would design and build your interfaces locally within Visual Studio and then deploy your interface to the cloud where it is executed.
Conceptually we can think of a Windows Azure BizTalk Services much like any other interface that utilizes an Integration platform. We have source systems, an intermediary where we can perform functions like Message Validation, Enrich, Transformation and Enrich (aka VETE). We then have the ability Route our message to the appropriate destination system. The difference with this platform is that the “heavy lifting” is occurring in the Windows Azure cloud as opposed to our On-Premise BizTalk Servers.
There are some subtle differences between Windows Azure BizTalk Services and BizTalk Server 2013 (On-Premise) solutions. I say subtle because for an experienced BizTalk person these new concepts are not that big of a leap. Below is s diagram containing some of the key artifacts and components that make up a BizTalk Service solution.
Bridges
The term that jumps out at you is probably Bridges. What is a Bridge? A Bridge is a message processing entity. Probably the closest BizTalk construct that you can relate a Bridge to is an Orchestration but there are differences. The reason why Orchestration is “kinda close” is that it groups a series of action or processes together within one logical container.
Bridges include Sources, Pipelines and Destinations. Currently within the Windows Azure BizTalk Services Preview we have 3 types of Bridges:
- Xml One-Way Bridge
- Xml Request-Reply Bridge
- Pass-Through Bridge (for message transport)
Within a Pipeline we can call transformations, perform validations, encode, decode or enrich messages.
We also have 3 types Source types:
- FTP/S
- HTTP
- SFTP
and 9 Destination types:
- FTP
- One-Way External Service Endpoint (No Service Bus connectivity)
- One-Way Relay Endpoint (Service Bus connectivity)
- Service Bus Queue
- Service Bus Topic
- SFTP Destination
- Two-Way External Service Endpoint
- Two-Way Relay Endpoint (Service Bus connectivity)
Technically this Destination list is not fully complete. We also have the ability to communicate with On-Premise LOB systems which I will go through in another Blog Post.
SDK Installation
Even though our BizTalk Services run in the cloud, we still perform our development activities within Visual Studio. Currently Visual Studio does not ship with the appropriate templates that allow us to build BizTalk Services solutions. However, we can get these templates from the Windows Azure BizTalk Services SDK.
The installation is pretty straight forward and I have included some screen shots below.
Note: On 64 bit machines only need to install the 64 bit SDK
Visual Studio Experience
When we launch Visual Studio 2012 we will discover a new C# templates under the BizTalk Services node:
If we choose BizTalk Service we see a blank diagram that allows us to drop a Bridge and Source or Destination endpoints onto it.
If we choose BizTalk Service Artifacts we will see a new project that does not include a bridge but a Transformation (map) and two sample schemas.
If we choose the BizTalk Service Project template we have more capabilities as we can drop any of the following Artifacts/Actions onto our canvas.
In the image below I have modeled a scenario just to visualize what building an interface in BizTalk Services may look like. In this scenario we are a company that specializes in managing Request For Information (RFI) processes. Organizations that have projects that they would like vendor responses to will send us these requests and we will publish this information to our trusted vendor network that allow them to be informed of these opportunities.
In this scenario I have an XML One-Way Bridge which will expose an HTTP(s) Endpoint. Within this bridge we will perform an transformation from the message type that was sent by our customer requesting RFI information into a message type that all of our Vendor partners are expecting. Once we have transformed this message, we need to drop it on a Service Bus topic.
Much like a BizTalk Server project we will start with our schemas. This schema editor is very similar, if not the same, as the BizTalk Server schema editor. The first schema that we will build represents our client request.
Next we will create a schema that we use with our strategic vendors who subscribe to our service. You will notice that there are more fields in the partner schema. This is where the value of our firm comes from as we have direct communication with client and have some additional insight into their project about whether the project is likely to proceed and will also expose the name of the customer. Typically these values would be looked up from a CRM system but for now we will keep it simple and include it in the map.
Next we will add a Transformation(or Map) to our solution that will allow us to transform our CustomerRequest into a PartnerRequest message.
Getting deep into the mapper is outside the scope of this post but you will see some new “functoids” or what are now being called Message Operations. Some of these new capabilities include ForEach, MapEach, If-Then-Else, List Operations and YES you can call custom code.
Once we have defined our Schemas and Maps we can now configure our XML Bridge. Within this bridge we will specify our message type that we will be receiving (CustomerRequest). We will also specify our Xml Transform (Map). Since we are not dealing with flat files and do not have any Validation requirements we will leave those stages in their defaulted stage.
We now need to wire up the output of our Bridge to our Destination endpoint which is a Service Bus Topic. We will do so by selecting a Connector operation and then connect the dots(kinda like in Viso) between our Bridge and Topic endpoint.
Now remember that we can perform message routing in BizTalk Services. To set our Routing patch we will need to click on the line that we drew from our Bridge to our Topic.
We now need to click on the Filter Condition. In this case we are not going to restrict any messages from continuing to our topic so we will select Match All but we do have the ability to create a filter based upon message content.
Next we will change our focus to the Service Bus Topic. We need to configure this endpoint by clicking on it and then modifying the PartnerTopic.config (filename will vary) file for it. Within this config file we will specify our Service Bus namespace, topic name,Issuer Name and Key. Please note that these are production Service Bus entities and have nothing to do with the BizTalk Services Preview environment.
We also want to rename our XMLOneWayBridge so that we are not using the default name since this name will makeup part of our URI.
Lastly we want to specify our endpoint where our Bridge can be contacted. To do this click on any empty space on the canvas and then modify the Deployment Endpoint. (Note the endpoint below is fictitious).
At this point we can now deploy our solution to Windows Azure BizTalk Services. We can do so by right mouse clicking on our Visual Studio Solution and selecting Deploy Solution. Here is where we want to specify our BizTalk Services environment configuration. You cannot use your Production Windows Azure credentials here.
The deployment only takes a few seconds and when it is completed we should see a message like the following:
Testing
Part of the SDK that we just installed includes utilities that can be used when Sending and Receiving messages to/from BizTalk Services. We are going to go ahead and leverage the MessageSender application.
The Message Sender Application is a command line tool that is expecting the following inputs:
- ACS Namespace (for BizTalk Services environment)
- Issuer Name
- Issuer Key
- Bridge Endpoint Address
- File location to message you want to send
- Content Type
The result is that our message has been sent to our bridge successfully.
If we go to the Windows Azure Production portal we will discover that we have a message within our Subscription.
Conclusion
If some of this looks familiar it is because it is!. This is the evolution of what use to be called Windows Azure EAI/EDI Labs. It is now being branded underneath the “BizTalk” brand which makes sense on a few levels in my opinion. For instance the team that is working on this new service is the same team responsible for the BizTalk Server product. One thing you will hear the product team speak to is that there is “ONE BIZTALK”. One platform with many capabilities including BizTalk Server On-Premise, BizTalk Server running as Infrastructure as a Service (IaaS) and now BizTalk Services which is running as a Platform as a Service offering.
There is another huge aspect to BizTalk Services that has been neglected from this post as I just am not familiar with it but EDI in the cloud also makes up a substantial part of this offering and arguably provides the greatest area of opportunity.
I am just getting started with blogging about BizTalk Services. Stay tuned for my next post on how to integrate On-Premise Line of Business Applications(SAP) with BizTalk Services.
No comments:
Post a Comment