Richard (Blewett) and I have talked about this subject often. Richard has finally found the time to write down what's wrong with the current implementation of 'Recoverable Interchange'. No, it's not the pipeline, messaging engine or adapter at fault. It's the XMLDisassembler!!!

It's been a while, but i hope this will make up for being quiet again. I've run across the question many times, but never found the time to really dive into it. Now that time was found. And attached is the result. It is not a 100% clean construct because BizTalk really tries to do its best to disallow access to internal classes and runtime. However, utilitzing some thread local storage and (what i think is) a reasonable assumption, this functoid is actually able to retrieve any of the message context properties in a receive port (no orchestrations required) ContextAccessor.zip (255.35 KB)

The wait has been long and difficult, but it is here.... right now!

BizTalk Server 2006 has gone RTM.

For universal subscribers

Now... the waiting for 2008 starts ;)

I already notified you of the upcomming Biztalk 2006 @ Microsoft. I'm happy to announce the European version is now also planned and availalbe for registration.

Schedule date is November 2005 in London!

Hope to see you all there.

 

I just love some artistic freedom in a message or two.

 

* Thanks too Kyle wuolle from the microsoft biztalk newgroups for sharing this with us.

I've now come across several issues, like the BizTalk service restarting all the time or not being able to run configureFramework.exe correctly.

After some searching & spelunking(tm) I've found the NT Eventlog to be the culprit!

As we all know Biztalk dumps tremendous amounts of logging information into the NT Eventlog. In certain circumstances (like configuring & un-configuring a number of times) the eventlog might run into its configured limit. When this happens Biztalk kind of chokes.

The error of not being able to write to the eventlog, is being written to the NT eventlog.

Ehhh.. anyone got a problem with that?

Just remember to set up your development system using a 'overwrite when needed' configured NT Eventlog

In one of my previous posts i mentioned an idea about using a tool i'de read about, using an RSS feed representing the eventlog. This was based on my thoughts on BizTalks 'report in NT Eventlog' behaviour.

This weekend i was together with a number of my friends and was pointed to a post from Dominick which presented the same link.

I now have to admit to either 'trying to highjack his post' or 'not being up-to-date' with it. I think i'll tell the truth this time and say; it is the latter. Sorry Dom!

Fun part is thinking about how we both thought of the use at almost the same time.

Thinking about how to 'catch that error' when it ends up in the eventlog has been a constant PITA since dealing with BizTalk 2004. Triggered by reading the EventLog RSS feed (old tool, new use) I thought; “Why not use this with BizTalk”. An RSS item being polled is “just another message comming into BizTalk”.

The source which I link to uses aspx but it should be a no-brainer to change this into asmx.

The only thing we need now is that “Polling WebService” adapter in BizTalk.

A student of mine recently contacted me to ask options for the following functionality.

An incoming message must be duplicated 3 times within a new message. So, as example

<Incoming>
  <ItemID>1</ItemID>
  <Quantity>2</Quantity>
  <CustomerID>3</CustomerID>
</Incoming>

should be transformed into

<NewMessage>
   <Incoming>
      <ItemID>1</ItemID>
      <Quantity>2</Quantity>
      <CustomerID>3</CustomerID>
   </Incoming>
   <Incoming>
      <ItemID>1</ItemID>
      <Quantity>2</Quantity>
      <CustomerID>3</CustomerID>
   </Incoming>
   <Incoming>
      <ItemID>1</ItemID>
      <Quantity>2</Quantity>
      <CustomerID>3</CustomerID>
   </Incoming>
</NewMessage>

My first instinct was to open up the mapper and use a “Looping” functoid. So, I drag & drop the “Looping” functoid, start to fill in.... Doh! That’s when I woke up and realized the “Looping” and “Table Looping” functoids are “source looping” (i.e. for each) while I was looking for a “destination looping” (i.e. for next).

Knowing the 'solves almost anything' external assembly option, I was convinced it is doable in the mapper. What I ended up with is a map with exactly 1 scripting functoid in there. An inline XSLT call-template allowed me to do exactly what I wanted.

As usual, Enjoy and comments are very welcome.

AllenSchema.zip (6.22 KB)

Finally got time to post this sample.  

The sample contains a full BizTalk solution (with several projects, including a WebService) with a few schemas, a few maps, an external .Net assembly and just one orchestration.
 
The intend of this sample is to show the “Send one message, Wait for multiple confirmations” idea.
 
I think code [0] speaks louder than words.
 
Enjoy and any feedback is welcome. 
 
Ps. RTFM !!

[0] DMOrderSystem.zip (98.82 KB)