Happily surprised, i found the 'WinFS Beta 1' to be available on MSDN subscribers as of yesterday.

The WinFS team blog is also up to relay info.

New stuff... New stuff... New Stuff.... :)

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

With pride I'm happy to announce the upcomming Guerrila (5 days of 12hours coding fun) version of BizTalk. And to go "All the way", we are going to do this with BizTalk 2006, at the Microsoft campus.

Be sure to visit the place to sign up for this amazing week of indept tech, fun & be the first to work with BT'06.

Windows Vista (codename Longhorn) Beta 1 has become available to MSDN (Subscribers), MVP's , etc. etc.

Go get it now!

Ps: It does run in VMWare 4.5 (using XP as guest OS).

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.

Another shock came today when hearing of the 'explosions in London's tube'. A bus was to follow.

The first thing that springs to mind is family & friends. Having friends living in London, I had to contact them, and hear they where fine. But, the mobile net seems to have been out-capacitated, because i heard lots of people couldn't get through. A number of my UK friends where currently in Amsterdam, at the Microsoft TechEd conference. IM's gave the confirmation none of my direct friends where effected.

That’s when the bigger picture of it all comes into play. Slowly more information was released. Although we still are far from the picture of 'what really happened', it was becoming clear it was an attack and no incident(s). Both the tube and a bus where hit. A number of explosions happened at the same time in different places.

Makes you all stand still for a moment and think about the priorities we set in life, and how we end up in that book.

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.

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)