Thursday, August 24, 2006
Most of us know that messages received inside biztalk are immutable, meaning they cannot be modified. If we need to modify the message say for example, if you want to change the price of the product inside the message, then a new message needs to be constructed (Inside orchestration you use Construct, Transform shape etc, inside pipeline you create a temporary stream). So, whats the reason for this immutable message behaviour. Reasons:
1. A received message might have multiple subscribers (orchestration, sendports etc) means each subscriber of a particular message references the same, single copy of that message. So, it make sense the message is not modified by any single service like Orchestration or pipelines.
2. Since single copy is referenced by multiple subscribers, it minimize storage. ( A ref counter is maintained for each message and messages with ref count of 0 are periodically removed.)
3. The concept of messages being immutable also allows for detailed tracking of message state as messages flow through the system.
Labels: BIZTALK
Wednesday, August 23, 2006
When you write custom disassembler code for pipeline components, you must make sure that you do not close the incoming data stream in the custom disassembler code. The incoming stream from the input message is a shared resource. The incoming stream is also used by the message body tracking component in the BizTalk Server message engine.
If you either implicitly or explicitly close the incoming stream, tracking data may be lost. Therefore, you cannot examine the data in the Health and Activity Tracking (HAT) tool in BizTalk Server.
Additionally, you must make sure that you read from the incoming data stream until the end of the stream is reached. For example, if the custom code makes a read request for 300 KB of data and the code only receives 34 KB of data, do not assume that the end of the stream has been reached. The custom code must always read from the incoming stream until 0 bytes is returned.
At the end of a custom pipeline component, make sure that you "rewind" the data stream pointer back to the start of the stream. Typically, you do this just before returning the data stream near the end of the custom component logic. For example, use the following code.
msgDataStream.Seek(0, SeekOrigin.Begin);
return msgDataStream;If you do not do this and the stream is read to the end in the current component, the next component receives what appears to be an empty stream because the data stream pointer was not rewound. This can cause unexpected parsing and validation errors in follow-on pipeline components.
Summary:1. Don't close the stream Implicitly or Explicitly
2. Read till the end of the stream, until 0 bytes is returned.
Labels: BIZTALK
MessageBox_DeadProcesses_Cleanup_BizTalkMsgBoxDbDetects when a BizTalk Server host instance (BTSNTSvc.exe) has stopped responding. The job then releases the work from the host instance so a different host instance can finish the tasks.
MessageBox_Message_Cleanup_BizTalkMsgBoxDbRemoves all messages that are not referenced by any subscribers in the BizTalk MessageBox (BizTalkMsgBoxDb) database tables.
MessageBox_Parts_Cleanup_BizTalkMsgBoxDbRemoves all message parts that are no longer referenced by a message in the BizTalkMsgBoxDb database tables. All messages are composed of one or more message parts that contain the message data.
PurgeSubscriptionsJob_BizTalkMsgBoxDbPurges unused subscription predicates from the BizTalkMsgBoxDb database.
TrackedMessages_Copy_BizTalkMsgBoxDbCopies the message bodies of tracked messages from the BizTalkMsgBoxDb database to the Tracking (BizTalkDTADb) database.
TrackingSpool_Cleanup_BizTalkMsgBoxDbPurges inactive tracking spool tables to free database space.
Labels: BIZTALK
A
byte order mark is appended to a message when the assembler component or the disassembler component is used to process a message in BizTalk Server. If you use a PassThruReceive pipeline or a PassThruTransmit pipeline, a byte order mark is not appended to a message.
In UTF-16 encoding, a byte order mark is the FE FF byte sequence or the FF FE byte sequence at the start of the encoded string. The FE FF byte sequence indicates that the encoded characters that follow use the big-endian byte order. The FF FE byte sequence indicates that the encoded characters that follow use the little-endian byte order. In UTF-8 encoding, a
byte order mark is the EF BB BF byte sequence at the start of the encoded string.
To delete a byte order mark from an outgoing message in BizTalk Server 2006, use a custom pipeline. In the assembler component in the custom pipeline, set the
Preserve Byte Order Mark property to False.
To delete a
byte order mark from an outgoing message in BizTalk Server 2004, use a custom pipeline. In the custom pipeline, create a custom component that deletes the byte order mark.
Labels: BIZTALK
Home
About Me
Email
