Thursday, July 07, 2005

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.

7/7/2005 10:27:30 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]Trackback
 Wednesday, July 06, 2005

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.

7/6/2005 7:38:44 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [3]Trackback

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)
7/6/2005 7:31:26 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [12]Trackback

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)

7/6/2005 7:28:43 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [7]Trackback
Indigo is comming, that is sure. But is it here to stay?
7/6/2005 7:26:40 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [8]Trackback
Ohhh LOLA. No, not the 'certain type of pictures one', not my girlfriend (thats Grazzi!), not 'The Kings' song, but I think even you know her!
7/6/2005 7:22:57 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [15]Trackback
Everything has a beginning.... Sometimes even more than 1!
7/6/2005 7:16:59 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]Trackback