Friday, December 10, 2004

Will eventually be using Nant for deployment, Scott Colestock seems to have most of the issues thought out, paste that for reference!

Trace of Thought (Scott Colestock) - BizTalk 2004 "Deploy with Nant" Template Revamp

Thursday, December 02, 2004

We are having concurrency issues with a third party application. Seems the application developers knew about concurent updates and locking issues, but some of their code doesn't use locking hints to limit to single rows. Especially when they inserting a new object level record (inserts single row in all tables). Needless to say they were asking for this kind of trouble when developing such a highly non-normalized data structure, that is another blog entry or two.

Sequential convoy pattern is actually simple to impliment if you are familiar with how subscriptions work, and can decide on what uniquely identifies the group of messages you wish to correlate. I used this pattern and am correlating to the receive location, almost seems like cheating doesn't it?

Sequential Convoy Aggregator Pattern in BizTalk Server 2004

Sunday, October 10, 2004

BizTalk 2004:
Interesting problem. A requirement exists where records on destination side of map must be in specific order, and where data is empty, there must exist an empty record.

Such that the left side contains:
< record >
     < fee1 > 100.0 </fee1 >
     < fee2 > 200.0 </fee2 >
     < fee3 > 00.0 </fee3 >
< /record >

And the right side must end up thusly:

< record >
     < orderid > 1 < /orderid >
     < typeid > fee2 < /typeid >
     < dest > 200.0 < /dest >
< /record >
< record >
     < orderid > 2 < /orderid >
     < typeid > fee1 < /typeid >
     < dest > 100.0 < /dest >
< /record >
< record >
     < orderid > 3 < /orderid >
     < typeid > fee3 < /typeid >
     < dest > 300.0 < /dest >
< /record >



The business rule here is that we have the sources fee values, which specify the value of a distinct fee that both systems understand, in a flat field-name-based structure, and the destination in a hierarchiacal and ordered structure. That is to say that the destination requires fee1 to be the second RECORD in the group.

I think I have an idea about how to do this, it involves using table extractors and some funky looping. I'll update you once I have tested this out.

Chris Tucker