Suspended Messages - get notification and access to...

Darren Jefford on accessing suspended messages: Suspended Messages

BizTalk 2004 & Pipelines

BizTalk 2004 & Pipelines - explains the differences between the XML Receive pipeline, and the passthrough pipeline.

Microsoft.BizTalk.CrossReferencing

The Microsoft.BizTalk.CrossReferencing.CrossReferencing class is available to use from expressions, and in the database functoids - it allows you to crossreference IDs and values between different systems. For example, you might be dealing with the same customer on 3 different systems - they all have their own ID for the customer and every time you need to work out what the CustomerID is for ExternalSystemX, you can use the CrossReferencing class and functoids to look it up for you.
The SDK documentation basically ends there (cheers) - but there's a bit more online now. The cross referencing database functoids use data from tables stored in the BizTalkMgmtDb SQL Server database, and you need to import your seed data (what systems there are, what IDs you want to track, etc) using a little command line job in the BTS2004 install directory (BTSXRefImport.exe). Otherwise you'll get errors like:
Unhandled Exception: Microsoft.BizTalk.CrossReferencing.RuntimeException: IDXRef <CustomerID> or AppInstance <OldSystem> is not registered.

The data model is modelled as
Applications->Application Instances->IDXrefs (the type of ID you want to persist - in this case the type is "CustomerID"). To set the CrossReferencing database up to use this you simply need to create a number of XML files to store this seed data, and then run the tool on it. Then you can write code like:
CrossReferencing.SetCommonID("CustomerID", "OldSystem_Production", "23", "5");
MessageBox.Show(CrossReferencing.GetAppID("CustomerID", "OldSystem_Production", "5"));

Should you so desire.
There doesn't seem to be any particularly useful way of removing or resetting this seed data (not that I can find anyway) - but the tables are simply all the tables in BizTalkMgmtDb that are prefixed xref_*

I'm not sure any of that was quicker than writing the logic one'self, but its nice having it in the functoids.
There appears to be a hotfix for the bit of the API they forgot to write:
FIX: You cannot remove an application ID after you create it by using a database functoid in BizTalk Server 2004
:)

What is MSMQT?

Interesting little overview on why there's an MSMQT at all -
What is MSMQT?:

MSMQT ships with BizTalk 2004 primarily to get around the 4MB MSMQ limit which was a pain in previous versions of BTS and any other application that used MSMQ, this means you can now chuck big messages at BTS via MSMQ with ease, and BTS implements streaming of messages so it doesn't have to load it up in memory to do any processing (unless you want it to).

Another good reason to make sure your pipeline components properly support message streaming!

How to Display an Assembly in the Add Reference Dialog Box

It is a common misconception, and one I also held, that components added to the GAC automatically appear in the .NET Add Reference Dialog. I guess this is a hangover from seeing registered COM components automatically appear in the add references dialog for all those years.
No, instead, you have to furtle around in the registry to make it happen, as "How to Display an Assembly in the Add Reference Dialog Box" describes. Very 1998.

Operating Systems: What Works and What Doesn't in Microsoft Virtual PC 2004

An exhaustive list of "What Works and What Doesn't in Microsoft Virtual PC 2004"

Handy BizTalk Server 2004 FAQ

Includes lots of niggly and useful details

BizTalk Server 2004 FAQ - netologi.se

Posting Messages Back to the Message Box - Again

Posting Messages Back to the Message Box - Again
I appear to be at least the third person to come to this solution, so it must be a good one. Ok what we’ve got is a scenario where if something goes wrong (we cannot connect to a certain system because its down, authorisation by a human is required, or there’s an exception we can’t handle, etc), we send the message to a holding area where its sorted out. On returning from the holding area, the messge can either carry on from where it left off or start again from the beginning.

So to start from the beginning, I thought, we’ll just call the orchestration again (the whole thing from the start) but with the message as it was before. The message holds details of what irreversible things its done, and so we won’t do them again.

But you can’t directly call an orchestration from itself – the compiler won’t let you create a circular ref.

Instead I found I could send it direct to the message box (direct port) with a field that marks it as resubmitted. I then have another orchestration which subscribes to the message box (direct receive port) with a filter saying “resubmitted=true”. This picks up the message/payment instruction and resubmits it to /calls directly the main orchestration.

Christof Claessens said:

Instead of using a "Process flag", I just created another schema that I transform processed messages to. The other ochestration then only listens for messages conforming to that schema.

Which is in some ways neater. But for me they really are the same message so I prefer to keep them the same schema. What would be great would be if I could wrap a message in a resubmit message. This would be the envelope schema stuff I presume? I might have a go at this when I get a minute...

DTC Transactions from BizTalk 2004

DTC Transactions from BizTalk - this is a hot topic. Nobody blogging on this seems to have run a quick test on this yet?
Anyway, a colleague did the other day - it turns out that if you use a serviced component set to "supports" or "requires transactions" in an atomic scope with a send shape, the work the component does is enlisted in the DTC transaction that inserts the message into the message box.
Correspondingly, if its set to "requires new", its not enlisted in that transaction.

What does this mean? Well for a start, when you send the message, although control will pass to the next shape in the scope as if the message has been sent, the message won't have been sent. Remember that a send shape doesn't really put the message on whatever transport you're targeting through your port, it just puts it in the message box and marks it for the port specified in the orchestration and its bindings. Later on, the subscriber (the send pipeline), picks up the message and forwards it on. You can see this in those "transport ID" tags in BTSSubscriptionViewer.exe. So if you do this put inside a running DTC transaction, the message will have been written but not committed to the message box (which is, of course, simply a SQL Server database). Only when the scope shape is finished can the message be committed to the database. This is the point at which the message is picked up by the send pipeline, and handed to the adapter specified by your physical port, which puts it on the target transport.

So don't try listening for a reply in an atomic scope shape.