A while ago, I blogged about pipeline components and what you need to pay attention to. Stephen, in reply to this, was wondering (see his comment) how tracking came into play. And... to be honest - I didn't have a clue! Only recently I managed to get the answer.
It turns out that Stephen's question actually was really valuable in helping me understand how exactly things work underneath... So, here's my - somewhat delayed - response and comments to his question.
Assume that your pipeline component screws up and that tracking before the pipeline, is enabled. What happens?
- if the message's body stream is seekable:
- if the message's body stream is *not* seekable:
In both cases, the message ends up suspended. The body might be in the suspended message if the body stream was seekable, otherwise not. (You should always have the context.)
For example: in the case of HTTP, the stream will not be seekable and the body will not be tracked nor suspended in case of a fatal pipeline component failure. (Note: the client will not get an HTTP either!)
So, the only advise I can give is: *never* screw up in your pipeline component :-)))
Tracking may tend to grow fast, depending on your how intensive your needs are. Out of the box, BizTalk Server does not offer any tools to "autoclean" the tracking database. However, there's a sample in the BizTalk Server SDK directory exactly targetting the subject.
Although it's just a sample, I've never seen this fail and it seems to me that the given SQL script is really high quality coded!! In addition, I can't imagine any really bad "worsed case scenario"...
To cleanup the tracking database:
- If you've never done this procedure before, first do this:
- Open up SQL Server SQL Query Analyzer
- Connect to the BizTalkDTADb database
- "File - Open", and go to the BizTalk Server SDK directory and look for the Database Maintenance subdirectory
- Select the "Purge_DTADB.sql" SQL script file
- Hit F5
- You should see a message "Creating stored procedure dtasp_PruneTrackingDatabase", in addition the status bar below should mark the operation as: "Query batch completed".
You have just created a new stored procedure called "dtasp_PruneTrackingDatabase". This procedure allows you to prune the tracking database. It takes only one single parameter: @PruneBeforeDate. Executing this SP causes the tracking data to be purged that was older then the given (@PruneBeforeDate) date. So, let's try this.
- To execute the procedure:
- Select: "File - New - Blank Query Window"
- Type following statements in order to cleanup *all* tracking data before today:
DECLARE @Today datetime
SET @Today = GETDATE()
EXEC dtasp_PruneTrackingDatabase @Today
Depending on how much data is to be purged, after a while the Stored Procedure will notify you with its results. Possibly you may see a message in red, commented as: "Duplicate key was ignored." This is fine and is an expected result.
To verify this:
Select: "Reporting - Find Message"
Try selecting a schema
If you've cleaned everything, you should not see any schemas anymore... (Only schemas here should correspond to messages that were tracked, áfter the @PruneBeforeDate date parameter.)
Since I felt that this is certainly not clear to everyone that uses BizTalk, some comments:
Most people are passing data to their own assemblies by passing messages, typed as an XmlDocument. This, however does not give you access to multiple parts of that message and certainly not, to the message's context.
If you ever need to have access to the context of a message, outside of the BizTalk Server orchestration environment, you may do so by passing the message as a parameter of type Microsoft.XLANGs.BaseTypes.XLANGMessage to a method in an expression shape.
When you want to create new message programmatically within an orchestration, you'd normally assign an XmlDocument object to your message. However: did you ever wonder how you could create non-XML messages within BizTalk Server orchestrations? (Assigning an XmlDocument would clearly not work here :-) )
For all of you "bitheads", here it is :
Option Explicit On
Option Strict On
Public Class MyStreamFactory
Private m_mystringdata As String = ""
Public Sub New(ByVal stringdata As String)
m_mystringdata = stringdata
Public Overridable Function CreateStream() As System.IO.Stream _
return New IO.MemoryStream( _
Public Class MyMessageCreator
Public Sub CreateMyMessage(ByVal mydestmsg As XLANGMessage)
mydestmsg(0).LoadFrom(New MyStreamFactory("this is my data to create message from"))
The trick here is in the IStreamFactory. BizTalk Server is able to create messages from such a factory class. In this example, I've just created a 'binary' message from a string, using ASCII encoding. However: you could just as well assign something like a .PDF file or image to your message if you want.
No limits! BizTalk Server rocks!
So, here it is: my very first posting as a BizTalk Server MVP :-)
TechEd was great... I don't mean "just great", but rather "REALLY REALLY GREAT"! Microsoft certainly knows how to organise things.... ("Things" include parties :-) ) Now, as I'm only just back from Amsterdam, I'll point you in some directions you might like, if you like BizTalk Server. (Like you dó! I just know for sure :-) )
First of all: the BizTalk Server team has started a new blog.
Further, I'd like to welcome Kevin Smith to the blogosphere as well. This guy surely knows what BizTalk is about as he was a dev on the BizTalk 2000, 2002 and 2004 release! Even better: he immediately released a GREAT paper on BizTalk Server 2004 adapter development!
Later this month, I'll publish a paper on pipeline components. If you plan to dive into this, make sure to check out Gilles post as well.
Further, Scott has announced that the integration PAG is now online.
Love to see such movements in this community!!!
So... What about you? Feel like sharing?
Have a nice day!