In my previous post I discussed a part of the recently released CTP of Windows Azure Service Bus EAI and EDI. I went over installation and the steps to take to create schemas and mappings (in this post I use different schemas and mapping, because of Visual Studio issues I had to start over).
This post is about how the schemas and mappings are used in Windows Azure. Like we’re used to with BizTalk we need the schemas to define the message types and we need the mappings to transform one message type to another. But how does this all fit together?
When you create a new ‘ServiceBus’ project, you’ll notice a new “BridgeConfiguration.bcs” file:
This file will contain the definition of the ‘Bridge’ between two systems connected to Azure. If you open the “bcs” file you’ll get an empty canvas and in the toolbox there are many options to fill the bridge configuration with:
For example pick the ‘Xml One-Way Bridge’. This is one-way WCF service endpoint, opposed to the ‘Xml Request-Reply Bridge’ of which you probably guessed it to be a request/response WCF service endpoint. The canvas looks like below:
In the solution explorer you’ll find the two schemas (SourceSchema.xsd and TargetSchema.xsd) and a mapping (Source_to_Target.trfm) I use to test with. The schema by the way is a simple mapping with a concatenation and the new if-then-else functoid (which isn’t called a functoid anymore).
Also a configuration file has been added to the solution: “XmlOneWayBridge1.BridgeConfig”, which in the end is just an XML configuration file but a so called ‘Bridge Editor’ has been created for ease of editing. Double clicking the file results in this.
In this we recognize the BizTalk pipeline! In the message types module you specify the schema's you wish to be accepted by this endpoint. The validator is just an XML validator of which I assume it can be replaced by a custom component in the future. However keep in mind that this is running in the cloud so Microsoft will be careful with custom components which might impact the performance and stability of Azure.
Enriching is interesting, it feels like property promotion in BizTalk. It opens the opportunity of content based routing. You can enrich from SOAP, HTTP, (SQL) Lookup and XPath. In the picture below I created XPath properties in the SourceSchema.xsd.
The transform module also looks familiar to BizTalk developers. Obviously only the maps that are defined as a message type in the bridge show up here:
If you build the solution now, you’ll get errors. The errors indicate that without a so called ‘Connected Entity’ the message send to this end point cannot be processed. So we need to add one to the bridge configuration. In this case I’ll write the message to a queue, but that can also be an external service that the message is relayed to. When the Queue is dropped on the canvas, it can be connected to the XmlOneWayBridge by using a ‘Connection’. Be aware you can only connect on the red dots and dragging the queue shape doesn’t create a queue on the ServiceBus.
Building this still results in an error about a filtering expression. This is caused by the fact that by default a filter expressing is specified on the connection to the Queue. To fix this click on the connection, select ‘Filter Condition’ and set the filter to ‘Match All’ (or specify a filter).
Now the project will build and the next step will be deploy to Azure!
Because Azure EAI still is in a lab phase, you need to go to a different portal than the regular Azure Management portal: https://portal.appfabriclabs.com/Default.aspx
Go there and create a so called “labsubscription”. If you haven’t created such a subscription before deployment you’ll receive an error: “The remote name could not be resolved: '<servicenamespace>-sb.accesscontrol.appfabriclabs.com'”
From the project file menu select ‘Deploy’ and the regular Azure deploy dialog shows up. Specify the Shared Secret and the project will be deployed:
Now it is time for fun by testing the bridge with the tools that come with the SDK. The set of tools contains the ‘MessageSender’ tool, which takes the account credentials, bridge URL, sample message and content type. This message was sent to the bridge:
<?xml version="1.0" encoding="utf-8"?>
Now the message is sent to the bridge and went through the pipeline where it was transformed from ‘SourceSchema’ to ‘TargetSchema’. After the pipeline processing has been done the message is written to the queue, TestEAIQueue in my case.
With another tool also from the SDK you can read messages from the queue: ‘MessageReceiver’.
In the message read from the queue you can derive the FirstName and LastName field from the SourceSchema have been concatenated in the TargetSchema. Also it has been derived that someone with and age of 1 is not an adult (IsAdult=false).
Wow, my first BizTalk-in-the-cloud-round-trip is working!
There is a lot more to discover and it is a CTP but this is working quite nice already. One thing we’re lacking in BizTalk today is the possibility to debug by pressing F5. I’m wondering if that will change with Azure EAI in the future.
Didago IT Consultancy