This post was originally published here
Every year BizTalk360 releases with 3 or 4 major versions (with few minor patch releases addressing critical bugs) with new key features with every major release. From Version 8.2.2385.2511, we started to support BizTalk Server 2016 RTM. Once after the release, we faced a strange case that the customers were not able to view the Context properties and Message Content in BizTalk360, but the customer is able to view the properties and content in the BizTalk Server Administration Console.
Strange enough, before BizTalk Server 2016 RTM, we were able to view the Content properties and Message content in BizTalk360 with the BizTalk Server customer preview versions. Once after the upgrade to the RTM release, we started to face this case.
From the exception message, we found that some DLL is missing and when we asked to check that dll at the customer’s end, we found that it was missing. Then we proceeded the case on how the DLL was eliminated, we found that the DLL, Microsoft.BizTalk.Message.Interop.CompressionStreams, was removed by BizTalk itself.
Use of Microsoft.BizTalk.Message.Interop.CompressionStreams.dll
Let’s have a look at the use of Microsoft.BizTalk.Message.Interop.CompressionStreams. By default, BizTalk server stores the message body parts in the Parts table and context in the Spool table in the BizTalkMessageBoxDb. The message is inserted in the tables through the bts_InsertMessage Stored Procedure. The values in these columns of the message part and context are respectively encrypted or they might be compressed. The messages stay in the Spool table only while they’re in flight being processed by BizTalk. Then they are removed and optionally moved to the tracking database. If you stop the send port or orchestration that is subscribing to the messages (but leave them enlisted) they will sit on the Spool and Parts tables for you to check them out. There are also a few messages that stay in the Spool table that are for the messaging agent cache and not the usual BizTalk messages.
As the XML is compressed, the clue is to use a Microsoft.BizTalk.Message.Interop.CompressionStreams.Decompress method. From the Microsoft.BizTalk.Pipeline.dll the message body content and context can be retrieved and viewed. The bts_GetTrackedMessageParts stored procedure inside the tracking database expects the message GUID and will return the compressed message data back. We can then use reflection to invoke the Decompress method of the Microsoft.BizTalk.Message.Interop.CompressionStreams class inside Microsoft.BizTalk.Pipeline.dll to decompress the data returned from SQL.
Where the Microsoft.BizTalk.Message.Interop.CompressionStreams.dll went?
When we deeply investigated the case why the DLL is missing, we are able to find that the methods of the Microsoft.BizTalk.Message.Interop.CompressionStreams DLL were moved under Microsoft.BizTalk.StreamProcessing.
Use of Microsoft.BizTalk.StreamProcessing.dll
Stream processing saves programs from having to load data entirely into memory.
Instead, a program gets a hold on a stream instead of the actual data. The program then starts asking the stream to send a chunk of the data. BizTalk implements a forward-only streaming design. Forward-only means that the stream can only be read, and cannot be sought back. Out of the box pipelines are stream-based; they utilize streaming when fetching data from the adapter and as data passes from one stage to another. For example, out-of-the-box components such as the Flat-File Disassembler and the XML Disassembler, are built with streaming in mind.
We changed in the BizTalk360 source code to support BizTalk Server 2016 and refer to Microsoft.BizTalk.StreamProcessing.
If you have any suggestions or feedback, you can write to us at [email protected]. Have a try at our latest version by downloading a 14-day free trial of BizTalk360.