BizTalk in the Cloud, One Step Closer Part 2

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″?>
<SourceSchema xmlns=”http://MyFirstAzureEAI.SourceSchema”>
  <FirstName xmlns=””>FirstName1</FirstName>
  <LastName xmlns=””>LastName1</LastName>
  <Age xmlns=””>1</Age>
  <Country xmlns=””>Country1</Country>
  <BirthDate xmlns=””>1900-01-01</BirthDate>
</SourceSchema>

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

BizTalk in the Cloud, One Step Closer

We all know Microsoft is putting an enormous amount of effort in their cloud initiative called Azure. It started with compute and storage but in the mean time it has grown and more and more products are released in a cloud version before the on-premise version is released. An example is Microsoft Dynamics CRM Online.

Since the September 2011 release of Azure the Service Bus is part of it. In the service bus we find things we know from BizTalk. The most well-known ones are Queues, Topics and Subscriptions. This so called ‘Brokered Messaging’ introduces message queuing and durable publish/subscribe messaging, which is the basis of BizTalk messaging.

Of course BizTalk is capable of a lot more, but Microsoft released today the CTP of Windows Azure Service Bus EAI and EDI. If we take a look at this release we immediately recognize the BizTalk influences in there. It is a CTP but it is showing the direction Microsoft is going.

Let’s focus on EAI for now. To install the SDK you just need a regular development machine with Windows 7/2008, .NET4 and VS2010. Download the SDK here. Installing the SDK will install some new VS templates under the section ‘ServiceBus’.

When the EAI project is created, the Solution Explorer looks like this:

And also new toolbox items are present, in which you’ll recognize the ServiceBus features Queues and Topics:

So the first step in BizTalk development would typically be to add a schema. This can be done by the regular ‘Add Item’ option in the Solution Explorer. There the first real BizTalk items show up! We all know the Maps and Schemas!

One thing that caught my eye was the extension of the mapping file, not BTM but TRFM. I can only speculate what the extension stands for.

Adding the schema is nothing new since adding XSD’s has been part of Visual Studio 2010 from the beginning.

 

Next step is creating a map, after adding the item another familiar screen shows up!

As well as selecting the source and destination schema. Unfortunately it isn’t possible to drag the schemas onto the mapping canvas.

And of course the toolbox is also familiar, although some items are missing, new or named differently from BizTalk.

This is definitely a preview of the new mapper as it will show up in the next version of BizTalk. Although the mapper has improved in BizTalk 2010, this one is even more advanced (and worth a blog post by itself!). For example I put the ‘If-Then-Else’ expression on the canvas:

This is really awesome!

Testing the map works quite the same way as in BizTalk, however it isn’t possible yet to generate a sample message from the schema so you need to create one yourself.

Typically you would also create artifacts like orchestrations, pipelines, etc, but they are missing in this CTP. However it won’t be a surprise that at least orchestrations will show up with WF4 in the near future.

So now we have a schema and a mapping, now what to do with it? Keep in mind that this is all Azure stuff so we need to deploy it into the cloud.

I’ll discuss these steps in my next blog post, but we’re definitely moving towards BizTalk in the cloud! Exciting stuff!

Didago IT Consultancy