Gobbledygooks by Richard Hallgren

I’ve often been told that one of the biggest mistakes people make when implementing a service oriented architecture is that they don’t re-architect their current architecture to become service oriented. I’ve never really understood what they meant by that until I read this article. SOA is not about adding a service based call to expose your current procedure calls as a service - it’s so much more. It’s about enabling ease of change and to create a more agile architecture.

Each of these assumptions exist in a Remote Procedure Call.  They are forms of coupling, pure and simple.  They fly in the face of SOA.

What do you think? Does it make sense in your world?

This post is only for Technorati claim. Ignore it.

Technorati Profile

I’ve blogged about the Visual Studio extension XPathmania before. It’s a very simple little tool that lets you write and test XPath inside of Visual Studio 2005. No big deal if you already have tools like XMLSpy or XML Notepad but still. I like not having to start another application, opening the XML document I’m working with and so on. Doing stuff inside of Visual Studio just feels right and saves some time anyway.

One of the last episodes of dnrTV hosted Dom Demsak (Don XML), the creator of XPathmania. The show is 30% about XPathmania and 70% about XPath and XPath syntax in general. It’s kind of basic XPath but I think it can be useful for someone who feels they haven’t got full control of the language. 

During the show they touch on XML namespaces and XML default namespaces. However they don’t really explain the difference between them and how it effects the document. Something that’s sad as I feel that XML namespaces (and especially default namespaces) is something that most people haven’t fully understood.

Anyway, if you got some spare time watch it or forward it someone you think should watch it.

There was a question on the Microsoft newsgroup the other day where someone had to split a message into parts. But some of the information that was supposed to go in to the different parts were part of the envelope. I thought I’d give my solution to the problem a try - here it is.

Say for example that we receive the following message.

<ns0:EmployeeSalesReport ReportID="R100" EmployeeID="0012345" xmlns:ns0="http://Example.TransformAndSplit.EmployeeSalesReport">
    <Sales>
        <ns1:Sale xmlns:ns1="http://Example.TransformAndSplit.Sale">
            <ItemID>100</ItemID>
            <Amount>10</Amount>
        </ns1:Sale>
        <ns1:Sale xmlns:ns1="http://Example.TransformAndSplit.Sale">
            <ItemID>200</ItemID>
            <Amount>20</Amount>
        </ns1:Sale>
    </Sales>
</ns0:EmployeeSalesReport>

In the above message we have different sales information from one employee but all the global employee and report information (the ReportID and EmployeeID attributes) exists in the root node (what we’ll call the envelope of the message).

What we like to achieve is to split this envelope message into it’s different sale item so we get separate message looking something like the below where each item contains the global information from the envelope.

<Sale xmlns="http://Example.TransformAndSplit.Sale">
    <ItemID xmlns="">200</ItemID>
    <Amount xmlns="">20</Amount>
    <EmployeeID xmlns="">0012345</EmployeeID>
    <ReportID xmlns="">R100</ReportID>
</Sale>

There might be different needs for doing this in a pipeline but much of it comes down to choice of architecture style in your BizTalk solution. Personally I’d refuse to introduce another orchestration for splitting a message like this. I don’t believe that’s what orchestrations are for (they should deal with possible logic and workflow in my world). I’m sure other people feel different - feel free to use the comments.

Step 1 - Transforming the envelope message using XSLT

The first thing we’ll need to do is to transform the envelope message so that the information from the root node (the ReportID and the EmployeeID) get into every single Sale-node. There are a couple of ways of achieving this but I’ll use the XSLT-transformation pipeline component that ships with the BizTalk 2006 SDK.

All this component does is to let you point out a XSLT stylesheet you like to use to transform your message.

The stylesheet I’ve used is part of the solution that you can download here. I will not show the stylesheet full script here but rather the result after the message travel through the component.

<?xml version="1.0" encoding="utf-8"?>
<EmployeeSalesReport EmployeeID="0012345" ReportID="R100" xmlns="http://Example.TransformAndSplit.EmployeeSalesReport">
    <Sales xmlns="">
        <Sale xmlns="http://Example.TransformAndSplit.Sale">
            <ItemID xmlns="">100</ItemID>
            <Amount xmlns="">10</Amount>
            <EmployeeID xmlns="">0012345</EmployeeID>
            <ReportID xmlns="">R100</ReportID>
        </Sale>
        <Sale xmlns="http://Example.TransformAndSplit.Sale">
            <ItemID xmlns="">200</ItemID>
            <Amount xmlns="">20</Amount>
            <EmployeeID xmlns="">0012345</EmployeeID>
            <ReportID xmlns="">R100</ReportID>
        </Sale>
    </Sales>
</EmployeeSalesReport>

Ok, nice. Now we have all the information we like in each of the Sale-nodes! All we have to do now is to split the message!

Step 2 - Splitting the message

We’ll use the standard XmlDisassembler component for splitting the message. All we have to do is to make sure we done the following.

1. Set the schema envelope property to “true” in the schema editor. 
2. Set the Body Xpath property on the EmployeeSalesReport-node to point to the Sale-node.
3. Configure the Document Schemas and Envelope Schemas (same properties are called DocumentSpecNames and EnvelopeSpecNames if your doing the configuration after deployment in the administration console) properties of the XmlDisassember component to match the names of your schemas.

This is what the envelope schema looks like in this example.

This is what the XmlDisassembler configuration looks like.

There, we’re done! Now we can drop a test file containing two Sale-nodes and all the report/employee information on the top and have the two following separate files as a result when using a file send port.

Setting up the test solution

1. Download a zipped version of the solution.
2. You’ll have to unzip the project to C:\Example.TransformAndSplit. If that isn’t possible you’ll have to change the path to the XSLT stylesheet in the XsltComponent in the pipeline as this is a fixed path.
3. When you build the XsltComponent the Output path is set to the Pipeline Components folder. This assumes that BizTalk is installed at C:\Program Files\Microsoft BizTalk Server 2006\. If that isn’t the case make sure to change the output path of the component.
4. If you’d like to run the pipeline component in debug I’ve set this up using the pipeline.exe tool. There are however some paths in the debug setting of the XsltComponent project also that assumes that your BizTalk solutions is installed at C:\Program Files\Microsoft BizTalk Server 2006\. If this isn’t the case you’ll have to change some values in the Command lines arguments property, but that only if you like to run debug.
5. Build and deploy.
6. Set up a receive port and location using the TransformAndSplitSales pipeline.
7. Set up a send port with for example a filter on the name of the Receiveport you’ve just set up.
8. Drop the example message that’s part of the solution!

Final thoughts

This example didn’t really take much more than an hour to put together. I do however realize that this is a simplified incoming message and that in the case of a more complex message we’d get a messy XSLT stylesheet to maintain. It’s also important to remember that using this method with XSLT transformation means that we will load the entire incoming Xml document into memory, so when we’re dealing with bigger Xml documents we’ll have manipulate the incoming message using other techniques.

Hope this is useful for someone!