Published on Thursday, 26th April 2007 .
Today I’m releasing a message archive receive pipeline component (BTS06 only) - I’ve been meaning to release the code for this component for some time, but never got around to it.
The component is designed to be used in the decode stage of a receive pipeline to archive a message before any BizTalk processing (with the exception of the adapter) is started. An output directory and filename can be specified in the component properties, with the following macros (which will be expanded to their real-world values) available in the filename:
- %MessageID% - Expands to the unique Message Id;
- %ReceivedFileName% - Expands to the received filename, less the extension;
the remainder all expand to their context property values:
- %InboundTransportLocation%
- %InterchangeID%
- %ReceivePortID%
- %ReceivePortName%
- %AuthenticationRequiredOnReceivePort%
- %InboundTransportType%
- %MessageExchangePattern%
- %PortName%
- %ReceivePipelineID%
For example, specifying an archive filename of:
%ReceivedFileName%-%MessageID%.xml
with a file called ‘TestArchive.xml’ will produce an output filename of:
TestArchive-{2AABABE3-4D25-4A5E-A730-E4B9A71B23F7}.xml
The VS project (including full source-code) can be found in the downloads area under ‘Message Archiving Receive Pipeline Component’ (a 14Kb zip file). Details of how to make the compiled binary available in a BizTalk project can be found here.
Published on Thursday, 8th March 2007 .
This is really a post to remind myself not to be quite so stupid in future….
I’ve been developing a custom pipeline disassembling component over the last few days to take a single purchase order from a customer and split into multiple orders based on (potentially) multiple delivery addresses. The component worked well through the Pipeline.exe tool but on testing using messaging (Send Port subscribing to messages from a Receive Port configured with the new component) I kept receiving:
The "FILE" adapter is suspending a message coming from Source URL:"D:\BizTalk Messages\Inbound\Sales Orders\BAA Sales Orders\Order Splitter Test Input\*.xml". Details:"Could not find a matching subscription for the message. ".
In my wisdom, I’d managed to forget that BizTalk is based on a pub/sub model - if I don’t copy the input message properties onto the resultant output messages and promote the message type, the Send Port might struggle to subscribe…..
So, note to self - copy context properties:
// Iterate through inbound message context properties and add to the new outbound message
for (int i = 0; i < pInMsg.Context.CountProperties; i++)
{
string Name, Namespace;
object PropertyValue = pInMsg.Context.ReadAt(i, out Name, out Namespace);
// If the property has been promoted, respect the settings
if (pInMsg.Context.IsPromoted(Name, Namespace))
outMsg.Context.Promote(Name, Namespace, PropertyValue);
else
outMsg.Context.Write(Name, Namespace, PropertyValue);
}
and promote the message type:
// Promote the MessageType property to ensure subscription by orchestrations
string systemPropertiesNamespace = "http://schemas.microsoft.com/BizTalk/2003/system-properties";
string messageType = "http://www.covast.com/schemas/EDI/Accelerator2004#EDIFACT_ORDERS_D_98A_DEFAULT_UN";
outMsg.Context.Promote("MessageType", systemPropertiesNamespace, messageType);
Doh!
Published on Thursday, 28th December 2006 .
Our current infrastructure supports over 200 interfaces with external trading partners in the B2B role. Unfortunately, some of the cXML partners cannot handle Xml Namespaces and insist on receiving DOCTYPES.
Although DOCTYPE’s can be added through the BizTalk mapper, we needed a mechanism to remove the Xml Namespace from the resultant message before passing through to a client. As a result, I created the Add Doctype Declaration encoding component (send pipeline) to add DOCTYPE’s and remove Xml namespaces.
The component uses an Xml Document object to parse the message and add the DOCTYPE declarations. In addition, the Xml Namespace can be removed if required using the [boolean] ‘RemoveNamespace’ property (if this is set to false, the namespace will remain in the final message.
A project containing source-code and binaries for BizTalk 2004 can be found in the downloads area of this blog, or via this link.
This really is the first release of the component (think of it as beta) and although it is ready for production, there are a number of enhancements I want to make, including:
- Produce a version in .Net 2.0 for BizTalk 2006 (our production environment is currently 2004, hence the current code is targeted to .Net 1.1);
- For BizTalk 2006, have the component configurable at run-time rather than design-time;
- Identify the root element programmatically, rather than through a component property;
- Remove DOCTYPE addition from the component and use the mapper to add the declaration;
- Create a receive pipeline component to add an Xml Namespace based on a DOCTYPE declaration;
I hope this component will be of use, either in your projects or as a starter for enhancements. I will continue to update the code and release enhancements through this blog.
Happy BizTalking!
