Some days ago I had to implement a data transfer for a customer working this way:

A source system (e.g. SAP) provides provides invoices in a relational data fashioned style that looks like that:

So I got two lists of entities. First all invoices (namely the invoice head) below the <Invoices> node and second all invoice positions for all invoices under the <InvoicePositions> node.

But in the target I had to deliver the data in that way:

They want the invoice positions sub ordered below the invoice.

Initial Solution:
To achieve this I build up very quickly a BizTalk map with a custom xslt transformation. A very clean xslt which was working fine. Good.

But the problem…
with this solution was that I just did some small data tests initially. When starting tests with large real data transports my process got so damn slow that it became a “showstopper” at all.

What happened?
With larger sets of data the transformation got slower and slower because the iterations increased by every record dramatically. So if you are a software developer and loop two arrays to become all elements from the first array mapped to the second one you may very well know the problem. The invoices in the source side appear in a average ratio of 1:3 (Invoice : Positions). So for example you have 100 invoices and 300 invoice positions than your xsl processor has to perform 100 x 300 (30.000) rounds to loop all positions for all invoices. Well that sounds still “affordable”.
But lets go ahead increase the number of invoices a bit. Say 1000 invoices. Means: 1000 x 3000 (3.000.000) rounds to go.
In my case the maximum of set of data (full initial data transfer) was 325.000 x 895.000. Which means 290.875.000.000 rounds for mapping data. The transformation (map) run for a bit more than 4 days on my BizTalk server with a CPU usage of nearly 100%. => Total overkill

After some days of reflection I came up with the following…

Solution:
First of all I have to say that this solution is pragmatic and working safe and well but in my personal opinion it is not a very clean and straight xsl alike solution.
To solve my performance issues I created embedded custom code in the xslt template.
In my custom code I created the possibility to create in-memory lookup tables (dictionaries) which are of course pretty faster.
With the new template the transformation performed in nearly under 20 seconds!

Here is a sample of this xslt. Feel free to adopt or copy it.

Any comments about this appreciated.

Some days ago I implemented web harvesting functionality for a customer working this way:

A business analysts places a request (trigger) file with some meta data on a network folder and BizTalk catches it up, performs a http post (HTTP Adapter) containing the meta data from the request file.
Easily achieved with the great RawString class from Microsoft.
The result of the post is a html which I caught up with a multi-part message with one body part of type XmlDocument.
Using RawString as type for the result body part as well would only work in case you have a pipeline which sets the message type to RawString in the message context.
Otherwise you receive some error like “Type “” of message is unknown…”

But using XmlDocument isn’t that nice at all too. When you try to access the XmlDocument in the orchestration it is “just in time” parsed and the XmlReader will perform a DTD validation because of the html root element. So it tries to download the DTD from “http://www.w3.org/1999/xhtml” and maybe fails because there is a firewall blocking this.
A web request timeout error message will appear in the log.

So you have the option to strip off the html root element in a custom pipeline (which I didn’t want to do) or you can extend the nice RawString class by a further constructor accepting a XLANGMessage as parameter. The code looks like this:

public RawString(XLANGMessage message, int bodyPartIndex)
{
    if (message == null)
        throw new ArgumentNullException("message");

    using (var stream = (Stream)message[bodyPartIndex].RetrieveAs(typeof(Stream)))
    {
        using (var sr = new StreamReader(stream, true))
        {
            internalRepresentation = sr.ReadToEnd();
        }
    }
}

You can use it in this way in order to get your html from the result message. Afterwards you can easily access the html as string directly or maybe send it to a file.

 If that helps feel free to leave a comment below….

Recently I stumbled upon a problem hat has definitely touched me so many times in the last years before, that I decided to write this little blog post about it.

Problem:
You extract a value of type xs:date from a BizTalk message and use it for further processing e.g. calling a web service, query a database or something else.
But the date changed. In my case I got a request message with a valuation date of “2013-09-01”.
After extracting the date from the message in an orchestration shape and assigning it to a variable of type System.DateTime I recognized that the value seem to be changed.
I see the value “2013-08-31”. 

Reason:
Of course it did not. Just the “representation” changed.
BizTalk internally works with UTC. So what appears is the UTC representation of the date-time value.
In my case (GMT+1) the date time value appears as “2013-08-31 23:00:00”

Solution:
Just perform the .ToLocalTime() function on the date you extracted from the message. And than you are fine. (normally)

Furthermore I deeply recommend the blog post “DateTime considerations for BizTalk” by Michael Stephenson.