Monish Nagisetty's Space

Building connectivity on-premise, in the cloud and beyond

DBMessageLogger – A Streaming Message Logger Pipeline component

Update (4/7/2008):

Please note that this pipeline component is not a substitute for the Message Tracking feature in BizTalk which can track messages at the port and orchestration level.   Message Tracking is a built-in feature within BizTalk and has all of these advantages:

It is important to note however that the Message Tracking feature is a system level tracking which tracks messages at an artifact level (Orchestrations and Ports).  If you need message tracking that has more context within a business process then you should consider using BAM with message body tracking.  My PC below is an alternative to the BAM solution since I provide hooks for tying the tracked message to other business level tracking data.

Thanks to Michael Stephenson for his valueable feedback regarding this topic.

Original Post (4/6/2008):

If you ever had any requirements to archive or log a BizTalk message then you have probably looked into handling this within a pipeline component (PC).  I had a similar requirement but I wanted to be able to log the message into a database table.  There is a pretty decent example of a PC that can log messages to file on Gille’s WebLog.  The sample code may be a little outdated though.

So I set out to build a PC that can log BizTalk message parts on receive or send sides and also be able to abort gracefully in the event of a failure.  Since logging is a non-critical operation, I do not want a failure during this operation to disrupt the entire process.  My primary goal for this PC was to read the message data in a streaming fashion and then save it to the database in chunks.  This design allows the PC to be scalable when dealing with large messages.

Let’s start by looking at the database tables necessary for storing the messages.

The first table is named IntegrationMessages and it has only one column named PayloadMessageId.  This table has one record for every interchange that arrives into BizTalk via receive pipelines or leaves BizTalk via send pipelines.

The second table is named IntegrationMessageParts and it is used to store the actual message parts in binary format.  Note that we are storing all message parts and not just the body part of a message.

Now let’s take a look at the design time properties available within this pipeline component.
Design time properties:

Enabled:  This property enables or disables the logging capability of this pipeline component.  If Enabled is false, then the pipeline component simply passes on the message down the pipeline without any processing.

LogContext:  This property specifies whether this pipeline component is being used in a receive pipeline or a send pipeline.

MsgReadChunkSizeInBytes:  This property is used to specify the size of the buffer used to temporarily store the message contents while reading from the stream.

ReceiveContextPropName:  This property is only applicable when the LogContext is set to Receive.  It is used to specify the property name when writing the PayloadMessageId (from the IntegrationMessages table) to the context. 

ReceiveContextPropNamespace:  This property is only applicable when the LogContext is set to Receive.  It is used to specify the property namespace when writing the PayloadMessageId (from the IntegrationMessages table) to the context. 

SendContextPropName:  This property is only applicable when the LogContext is set to Send.  It is used to specify the name of the property that allows

SendContextPropNamespace:  This property is only applicable when the LogContext is set to Send.

Download BTSMessageLogger Solution.  It includes the pipeline component project, a sample BizTalk project that uses the component and a Windows application to view the logged messages in the DB.


1) Extract the contents of the to C:\
2) Deploy the CustomerProcess project from within Visual Studio
3) Run the .\SQL\BTSMessageLogging_CREATE.sql on the local SQL instance to create the logger database
4) Import the bindings from the binding folder
5) Start the application
6) Drop the .\Sample Data\Customer3Rows.txt into C:\BTSMessageLogger\File Drops\In
7) Three (3) xml files should appear in C:\BTSMessageLogger\File Drops\Out
8) Use the MessageViewer application to view the logged messages


April 6, 2008 - Posted by | BizTalk |


  1. Hi Monish

    I am unable to dowload your example from Can you help?



    Comment by Spencer | July 15, 2008 | Reply

  2. Changed the link to skydrive instead. Try now

    Comment by monishnagisetty | July 27, 2008 | Reply

  3. Hi, Monish.

    I’ve downloaded your application, nice job. Im testing your scenario, and somethings wrong. Im not that experienced with C# so please tolerant, but the orchestration variable SrcPayloadMessageId is always given the value -1 from Promoted field PayloadMessageID. For me its weird because the MessageParts table and the Messages table have rows inserted when the receive pipeline has processed. This results in no details inserted.

    Debugging the component in design time I see that the payloadMessageID is correctly pulled from the datebase.

    Can you point me in the right direction here? what am I missing here?

    Comment by Bams | September 5, 2008 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: