Breaking The Declaration

The snippet of powershell below is useful for trading partners who declare an xml document with

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

Then go ahead and use invalid characters that are not part of UTF-8.

foreach($i in get-childitem testfolder/test*.xml) {
$dest = $i.Fullname.Replace("testfolder","productionfolder/in")
get-content $i | out-file -encoding utf8 -filepath $dest
rm $i
}

What this does is setup a destination path variable and outputs a file to that destination. In the process it parses the file to ensure it's all UTF-8.

Using ESB Add Namspace

When working with systems that utilize the older no-namespace style of XML documents, the ESB add namespace is handy for strong typing documents.

Why go to the effort of using it? You could create a schema and set the target namespace to blank and continue on your way. The problem lies when many documents utilize this same blank namespace and their root name is <Root> which is very common. I consider using a blank namespace as anti best practice, though each to their own.

The ESB Add Namespace component seems to not be useable without first adding a ESB Remove Namespace before it regardless of whether you're creating a receive or send pipeline. I think the problem is encoding related. Without adding ESB Remove Namespace you will get errors along the lines of 'Root element cannot be found'. Make sure to include these components before a disassembler so that the document can be resolved.

Example receive pipeline using ESB Add Namespace

Biztalk Edifact Parties & Deployment

One thing to keep in mind especially when using BTDF (Biztalk Deployment Framework) is that using it to deploy parties and agreements can cause the UNB Interface Control Reference to reset. If you're working with trading partners that don't pay too much attention to this, then deployment can be as easy as using BTDF to delete the parties and agreements and redeploy them. If it's essential that you persist the Control Reference sequence, then your options are:

1. Unbind the send ports from the Edifact agreements and redeploy your solution without redeploying parties and agreements.

2. Promote properties to set the Edifact agreement and pass the message along to a dynamic send port. Doing this does not require you to bind the dynamic send port to an agreement.

ESB Itinerary Broker Filters

Biztalk's Itinerary Broker Filters are a great example of what Biztalk development is about. Start off with a business process and throw out any ideas of how you'd implement it in the normal world and massage, squeeze it into the Biztalk way of doing things.

Let's start off with how to get started with this component.
Drag the Itinerary Broker Service onto your design surface and configure it with these properties:

• Container - your onramp
• Itinerary Service Extender - Messaging Broker|Messaging Broker Extender
• Service Name - Microsoft.Practices.ESB.Itinerary.Services.Broker.MessagingBroker

In my usage I'll be creating filters to route a file to different offramps based on what type of file output I need.

For each resolver, set the resolver implementation to CONTEXT. You may see other options but don't get fancy and try to use anything else because it won't work.

Add a filter and choose XPATH for the filter implementation. In the expression set your xpath expression.

Drag an Itinerary Broker Outport and drop it onto the Itinerary Broker Service. Configure the Outport to match up a filter and a resolver.

This is a review of the basic steps to configure the Itinerary Broker Service and you could have worked this out from Microsoft's documentation. The tricky part is setting a filter expression that works.

To solve this for the use case I just mentioned, I created a schema property called OutputDoctype and promoted it during the Onramp. I start up Debugview and drop an instance of my message and Debugview will spit out a bunch of properties like so:

Grab the schema property you're interested in and put it into your favourite xml editor and craft an xpath expression against it. In my case it is:

count(//Property[@name='OutputDocType' and @namespace='https://?????.Outbound.Internal.???'][contains(., 'EDI')]) > 0

Put this into your Itinerary Broker Service filter and you should be good to go. Your XPath expression must use Xpath 1.0 and it must return a True to fire. This is why the above expression uses xsl:count()>0 rather than xsl:exists().

You may think that another way of getting the correct xml to craft an xpath expression could be to suspend a message and save the context to filesystem. The xml looks similar but it's not the same and you won't be able to craft an xpath against this.

Another thing to note is that you only need to write the properties to context and it's not needed to promote them. Itinerary Broker Service does not work with any other data sources/types such as message content. They must be context properties.

FTP via BRE and Dynamic Ports

Here's an example of how to set up the properties on a message that is required for the FTP adapter.

If you find that you're outputting 0kb files, ensure that the passive mode property is included.

For a hint of what other properties are available, you can export the bindings from an application that contains an ftp port and examine the <TransportTypeData> for that send port.