(how to) Build a MOM a-like solution with BizTalk.

October 24, 2005 / Comments Off on (how to) Build a MOM a-like solution with BizTalk.

Sometimes when you create a BizTalk solution you have several servers that submit data to a BizTalk Server. If those servers don’t deliver any data, BizTalk won’t process anything. There could be several reasons why the systems don’t deliver any data but most of the times something went wrong on the other systems. There are times that you as a BizTalk admin want to know if other systems fail.

There is a solution to this problem.

Have a simple BizTalk adapter read the Eventlog of the machines involved and simply publish every event in the messagebox. This causes another problem, cause if there is no subscription the published message will generate an eventlog entry on the BizTalk Server itself. This is where the NOPE adapter comes in (No Output Producing Endpoint).
Simply install this adapter and add a filter to consume all the messages coming from a specific receive port. From now on every Eventlog entry will be consumed. (they will dissapear in thin air).

Once the eventlogadapter is installed you can get it’s schema bij setting a up a receive location (passthru pipeline) and dump the message to disk somewhere. From now on you can inspect one of the evenlog messages and see what kind of XML they produce. Simply generate an XSD from it and add a property schema to it. Make all the important xml nodes properties and from now on you can filter on those properties….

The next step.

Have some Email groups set up in Exchange, for example ‘Biztalk Administrators’, ‘Database Administrators’ etc. Then add the correct recipients to these groups. Now Create Send ports that will send messages to each of these groups. From now on you can add filters to the send ports on the properties of the eventlog entry and have an entry send to the correct group.

Below is an example of an eventlogentry :

    <TimeGenerated>24-10-2005 9:47:52</TimeGenerated>
    <TimeWritten>24-10-2005 9:47:52</TimeWritten>
    <CategoryString>Service Control</CategoryString>
    <Message>SQLServerAgent service successfully stopped.</Message>

By filtering on <SourceName>,<Type>,<ComputerName> and possibly <EventCode> a lot is possible and you can make sure that people get warned if a problem arises on a machine. And for sure you can use this as well to monitor the bizTalk Server itself to see if messages get suspended….

    <SourceName>BizTalk Server 2004</SourceName>
    <TimeGenerated>24-10-2005 9:54:03</TimeGenerated>
    <TimeWritten>24-10-2005 9:54:03</TimeWritten>
    <CategoryString>BizTalk Server 2004</CategoryString>
    <Message>There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "XML disassembler" Receive Location: "D:TempBlaat*.*" Reason: Finding document specification by message type "EventLogEntries" failed. Verify that the schema is deployed properly. </Message>

Simply setting the filter to : eventcode = ‘12588631’ would have warned you via email about a suspended message. You cannot filter on the message itself because it could be larger then 255 characters.

Get the NOPE adapter here, and get the Eventlog Adapter here. Remember to fill the receive Adapter properties for the EventlogAdapter when you add the adapter to the BizTalk configuration.  Just open them and then save them, that’s enough….

Whooooo…. Watch out with the latest MS Security Patches……

Watch out with the latest Security patches from MS (they messed up my machine pretty bad)

Today I was poking around on my BizTalk 2006 machine (windows server 2003) and was looking at some web service functionality…For some reason I had to open the HAT ( for the people who don’t know it is the Health And Activity Tracking Tool from BizTalk (2004 and 2006) ) and i just wanted to look at some tracking data …… Everything worked fine yesterday but today I got all kind of script errors… oNavCtrl errors etc… Lots of grey screens showing script error messages…… Hmm I looked a littlebit around with some sysinternals stuff (they make brilliant stuff) but even that showed no problems whatsoever….

Ok i decided to go to Windows Update and see if that fixes something…..

Hey WHAT THE F..K……. my windows update was broken as well….. Everything looked fine but the two buttons with express / custom weren’t showing….. So i could do nothing with it….

I poked a littlebit more in  my system and decided to DE-Install some of the MS security patches…..

The patches I de-installed were :


and guess what……Everything is working again…. I thought that windows updates were safe by now and it is the first time since years that something like this happens…..But i am going to be more cautious about installing MS_Updates in the future………….


Finally got the BizTalk FTP adapter running smooth and fast….(sigh)

October 18, 2005 / Comments Off on Finally got the BizTalk FTP adapter running smooth and fast….(sigh)

At a customers site we use a BizTalk orchestration and dynamic send ports to deliver documents to a remote FTP site.
Everything worked without problems only the FTP deliveries were VERY slow….

It looked as if there was a gap of approximately 5 seconds between every FTP connection. And the delivery itself would take less
then a second. I tried almost everything to see if the problem was BizTalk related but as soon as I send the documents to another server, everything
was fast. So the problem was most liekly in the VPN connection.

Somebody wrote a small .Net FTP application that would mimic the BizTalk behaviour.  And this test app was very fast as well…..
Finally I used the combination of Netmon to capture the frames and Etherreal to anylise the output to figure this one out…..

Screenshot of the Slow delivery :

As you can see BizTalk send a Quit command at 13:15:27, and the next connection made to the FTP Server was made at 13:15:31 (Titan FTP server xxyyzz Ready).
So between every send there was a time gap of approx 4 to 5 seconds…..
in between you see some yellow NBNS name queries that are the bottleneck. I really don’t know what these NBNS queries are but I thought the BizTalk Server is trying to resolve
the IP address to a name, this doesn’t succeed, so BizTalk tries again and fails again. Then BizTalk decided it cannot get this information and continues to send the data anyway.
( I guess BizTalk needs this data for reporting purposes somewhere. )

Once I obtained a MS-Certificate about MS-TCPIP (a long time ago) and  remembered that a lot of name resolution stuff could be resolved by modifying the HOSTS file. So this is what i did.
I modified the host file of the BizTalk server and added the TCP/IP address and name of the Target FTP site.

Screenshot of the Fast delivery :

As you can see the QUIT is send at 13:56:36 and the new connection is set up at 13:56:36 (Titan FTP server xxyyzz Ready).  So now there was no time gap inbetween two sends. And the
problem was solved. The FTP is now just as fast as on the local network.

I think it is strange that BizTalk will try to resolve the IP address to a host name regardless of the FTP adress entered. (The FTP Adress enetered is an IP adress).
Lotsa tools that do FTP don’t show this strange behaviour. So if you experience the same problem of very low FTP trougput, have a look at netmon to see if you experience the
same problem…..



BizTalk 2006 Bulk delete of service instances is Supported

October 3, 2005 / Comments Off on BizTalk 2006 Bulk delete of service instances is Supported

The new Biztalk 2006 administration console lets you group results. Below is a screenshot of this..

The nice thing of BT 2006 is that you can click on a group and terminate all instances, In 2004 this was impossible, And if you have to terminate 800.000 entries (this happened once) it would take a day or so in BT 2004. In BT 2004 you could only terminate 2000 instances at a time.

Now in BT 2006 just hit the terminate button (right-click with mouse to get the context menu) and it will start deleting all instances….


And in the end everything is deleted as expected

Note there are 2821 records deleted, so not the limit of 2000 that existed in BT 2004.

If you have an orchestration that’s in a loop or for some reason orchestrations pile up to huge amounts you can now easily delete those instances

  • Recent Posts
  • Recent Comments
  • Archives
  • Categories
  • Meta