Vincent Scheel

When developing a custom PipelineComponent I spend quite a while overlooking the obvious. For all those who also overlook this:

When writing BAM from a PipelineComponent it is a good practice to use the PipelineContext.GetEventStream() method to get the BAM eventstream. This way your BAM events will piggyback ride along on the SQL calls already made by the BizTalk messaging engine.

Firstly I wrote a little console app to create some BAM instances from code using a DirectEventStream. When this gave the results I wanted, I developed the PipelineComponent using the same code, but with the MessagingEventstream instead of the DirectEventStream. After I wrote the PipelineComponent and created a little sample with just a receive port (which would cause a routing failure), the BAM instance did not show up in the database.

I was not sure if the PipelineContext.GetEventStream() method worked correctly, so I tried to use the DirectEventStream in the PipelineComponent to see if that would work. It did. After that I added some Debug statements in the component using the correct EventStream and ran it again. All the debug statements were hit, but nothing showed up in the database.

Then it suddenly dawned on me... Since the port was failing due to the routing failure, maybe the transaction of the MessagingEventstream was cancelled? After adding a send port to solve the routing failure, the next BAM activity did show up.

So, if you use the PipelineContext.GetEventStream() method it will only store information if the entire receive port was executed succesfully. If this is your requirement, that is fine, but if you want to store everything that goes through the pipeline, don't use the MessagingEventStream.

Update: after the comment by Thiago Almeida I tried the same for a send port. In a send port the BAM event is written even if the send port fails. Also a thing to keep in mind.