If you are implementing transactions in an .NET 1.x enterprise application you basically have two different alternatives, (1) to use manual transactions or (2) to use automatic DTC based transactions.
Manual transactions are not very attractive if you are not certain of the transactional contexts an object can be used within. This means that the code for handling the transactions is not likely to be pretty.
Automatic transactions are compelling, but requires the use of the COM+ programming model with all its complexities.
I usually find it best to use manual transaction while awaiting .NET 2.0. I this new version of .NET, there is support for automatic transactions without the requirement of COM+. If you are going to implement manual transactions in .NET 1.x, there is a framework that can make your code more structured:
http://www.devx.com/dotnet/Article/28937
Tuesday, November 15, 2005
Friday, October 21, 2005
Tracking Message bodies in BizTalk 2004
One thing that I’ve found rather confusing when reading the BizTak documentation is how and when BizTalk message bodies marked for tracking are stored. I’m not an expert at BizTalk yet, so this is just my interpretation of the workings = )
In BizTalk 2002, a distinction was made between tracking individual fields and logging whole messages. In BizTalk 2004, tracking is used for both of these actions.
The BizTalk native XML Message bodies are automatically stored in the MessageBox for messages with the service instance status not set to completed. The tracking information
regarding the message is saved in the Tracking database. The documentation states that tracking data is cached in the MessageBox and moved to the Tracking database in intervals, which means some tracking data could be lost in the events of a failure.
When a message has received the service instance status “completed”, the message body is not guaranteed to be available anymore. If you have enabled a certain message for tracking, the native and the BizTalk internal XML representation of the message is saved in the MessageBox. This tracking can be enabled in two ways. One alternative is through configuring the port in the BizTalk Explorer. Alternatively, you could enable tracking for a whole pipeline using HAT. To get access to the message body you access HAT, but note that the message is actually stored in the MessageBox.
Eventually, the message will be purged from the MessageBox through automatically scheduled SQL jobs run by the SQL Server Agent Service. If you want to have guaranteed access to a message body you must configure your solution to archive the messages and then restore them on the Tracking Database. There are some sample scripts in the BizTalk 2004 SDK that accomplishes this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdk/htm/ebiz_sdk_samples_qico.asp
So if you’d want to have the message bodies automatically archived, I suppose you could modify the SQL job so that it archives them before the MessageBox is purged.
In BizTalk 2002, a distinction was made between tracking individual fields and logging whole messages. In BizTalk 2004, tracking is used for both of these actions.
The BizTalk native XML Message bodies are automatically stored in the MessageBox for messages with the service instance status not set to completed. The tracking information
regarding the message is saved in the Tracking database. The documentation states that tracking data is cached in the MessageBox and moved to the Tracking database in intervals, which means some tracking data could be lost in the events of a failure.
When a message has received the service instance status “completed”, the message body is not guaranteed to be available anymore. If you have enabled a certain message for tracking, the native and the BizTalk internal XML representation of the message is saved in the MessageBox. This tracking can be enabled in two ways. One alternative is through configuring the port in the BizTalk Explorer. Alternatively, you could enable tracking for a whole pipeline using HAT. To get access to the message body you access HAT, but note that the message is actually stored in the MessageBox.
Eventually, the message will be purged from the MessageBox through automatically scheduled SQL jobs run by the SQL Server Agent Service. If you want to have guaranteed access to a message body you must configure your solution to archive the messages and then restore them on the Tracking Database. There are some sample scripts in the BizTalk 2004 SDK that accomplishes this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdk/htm/ebiz_sdk_samples_qico.asp
So if you’d want to have the message bodies automatically archived, I suppose you could modify the SQL job so that it archives them before the MessageBox is purged.
Subscribe to:
Posts (Atom)