Yossi Dahan [BizTalk]


Friday, July 29, 2005

Multiple send handlers in BizTalk 2006

I'm sure now that the beta version of BizTalk 2006 is out we will start seeing more and more postings about new cool features.

I'll contribute my two cents by highlighting an addition I believe is quite significant - the ability to configure multiple send handlers for an adapter.

In BizTalk 2004, while it was possible to configure several receive handlers for an adapter, it was only possible to select a single send handler (remember that combo box in the send handler properties?). Adding more then one handler was simply not possible.

This meant that, while you could configure different receive locations to run under different hosts, each having its own credentials (for instance - permission to a specific folder when using the file adapter) , you could only specify a single host for all your send ports

This meant that all the send ports using the same adapter ran under the same host - with the same credentials and therefore the same permissions which obviously resulted in reduced security.

(This is why you we're not required to select handler on send ports, only on receive ports. The handler on the send port was determined by the adapter you selected)

BizTalk 2006 allows you to configure multiple send handlers to an adapter as well as receive handlers, and then in each port select which one should be used.
A file send port of a specific application no longer has to have the permissions for a folder used by another send port, in a totally different application.

(Adding additional send handlers for the file adapter, you can notice there are two already)

(Selecting the send handler to use in a send port)

Thursday, July 28, 2005

Unexpected behaviour with the configuration block and Xml Serialization

As been discussed so many times we're facing over and over again the issue of storing configuration, and it's quite obvious the last word has not beed heared on this (I'm probably going to deal more with this subject in the coming few weeks)

Yesterday I've been playin around with the configuration application block in the entterprise library and Xml Serialization when I found out something about serialization that surprised me (if it's obvious and I'm the only one puzzled by this forgive me for waisting your time..)

I've created a class to represent a piece of data that I will store using the config block's xml provider.

Since in my case, after the initial creation of a piece of data it is expected to be read-only I've created only getters in the properties of my class, allowing only an internal constructor to receive parameters and update the members, which meant normal access to the configuration data will not be allowed.
an additional parameter-less constructor was created to satisfy the serialization rules (as kindly instructed by the compiler)

I then created an instance of my data class (providing data throught the first constructor) and stored it witht the configuration block, but when I opened the saved xml file I found out the although data structure was saved correctly, it did not contain any values! all the members we're empty.

After a little bit of investigation I've noticed that the empty constructor was called everytime the configuration was stored. which means a new instance has been created.
My assumption was that the XmlSerializer calles the empty constructor to create a new instance at some stage of it's operation and without setters to the members, the data could not be provided to that newly created the instance and therefore it's empty.

I've added setters to all the properties and indeed now the configuration block managed to stor the information correcly.

I don't know why this is happening, and if there's another way to handle this case so I had to leave the setters for now, not a great concern after all.

Sunday, July 24, 2005

Merging two messages in BizTalk 2004

Ok, so here goes the first "serious" posting (and turned out to be a bit long...sorry...)

Yesterday afternoon I was facing a challenge I was surprised I did not stumble into earlier-

We needed to merge two messages, each containing a different subset of the information we need, into a single message. Both messages have a key field we can use to match the entries.

consider the following two files:

<?xml version="1.0" encoding="utf-8" ?>














<?xml version="1.0" encoding="utf-8" ?>













(see if you can guess what then expected result is...)

Facing this challenge three ideas came to mind:

  • Using the mapper
  • Developing a custom component
  • Going through a database table

  • Using the mapper
    Of course my first bet was the mapper.
    Initially I was thinking this was a great opportunity to take the looping functoid to the extreme. So I set up a parallel convoy accepting both messages followed by a transform shape (yes - inside a construct, of course) having both messages as the input and the result as the output.
    I was thinking I'd drop the looping functoid on the map surface, add a logical functoid or two and set up something like "for each item in list A loop through the items in list B until you find...". The looping functoid, however, thought differently.
    Now I believe I was simply giving it much more credit than I should have (and someone please correct me if I'm wrong)

    Custom coding
    frustrated from the mapper I resorted to what we do best - write custom code. Replacing the transform with a message assignment calling a .net method passing both messages as parameters and expecting the result as the return value;
    I have to say developing the code to accepts two messages and merges them using .net, DOM and XPath is easy enough and quickly done. Running it with a couple of 6MB messages might be easy but nothing even close to quick.
    But at least that's done. So now....Back to the map option.

    Using the mapper with custom xslt
    I've decided to get rid of the looping functoid and add custom xslt script. First I traditionally mapped each element from of the first part of the source (list A) to the output. Then I added a scripting functoid to the palette and set it to "Inline XSLT Call Template".
    the script itself is quite simple - receiving the value of the code element from the current item node in list A and selecting the price value from the corresponding item in list B. Had to play a bit with the XPath due to the different namespaces, but got it nicely done.

    While at it I've also gathered a full custom xslt to achieve the same result, used it instead of the map altogether.
    These two approaches more or less covered the first option.

    I did not yet test any of them with large files, this will have to wait for Monday, but I sure hope to get somewhat better results then with the custom code.

    The database option
    now - I have to admit the database option is the one I like less. Seems like too much work and hassle for something that simple. Plus - there isn't really a good way to read and write large amount of data to a database from BizTalk. The idea, however is quite simple - write all the records from message A to a database table, update records with data from list B (with just a little bit of effort the order of the messages should not be important) and then read the combined record.
    very simple really, and even avoids the need for an orchestration and convoys (required for both the previous options) if I could find a way to safely figure out when it's safe to read the data which shouldn't be a problem.
    yet it seems too much, so I would leave it for a last resort.

    If anyone has other ideas on how this could be achieved I would love to hear them, as I've said Monday is performance test day and then we'll see.

    25th Nov. 2005 - Note - I've just realised I never posted how I eventually approached this, so I did. you can real all about it here

    Saturday, July 23, 2005

    OK, I know I said I wouldn't......

    ....start a blog, but here I am anyways.

    not even sure why, or for how long. definitely not how often. but decided it's worth a shot.

    It might be that struggle today with the messages merging issue (which will definitely be my first serious post) that just requires to be blogged...

    It could be the fact that I've been reading more and more other great people's blogs for too long now and started thinking I should try and share a bit as well (not that I'm convinced I'll write things worth sharing....)

    It could be that new laptop I got just a couple of days ago, which just begs to be typed on...

    Oh - right - and it might be that glass of fine single malt that just went down my throat...

    Anyway, Here I am - Yossi Dahan - Independent consultant in the United Kingdom, working mainly with BizTalk and .net and here are my experiences...

    hope you will find them useful

    or at least somewhat amuzing...