Thoughts On Biztalk360

After a month of using Biztalk360, I thought I'd share a few of my experiences.

Standalone Installation

You have the option of installing Biztalk360 on a Biztalk server or as a standalone. A standalone installation will require that you install some Biztalk components and get your accounts and permissions right, in theory. In practice you'll find that various parts of Biztalk360 will not be functional. An example of this is if you use custom components in BRE, then BRE will fail to load. You'll then need to install the custom components on the standalone server. Another example is an inability to start/stop an application due to a bug in the Biztalk installation. Most of these problems can be avoided by installing on a Biztalk server as all the assemblies you need will already be gac'd.

Although it seems counter intuitive to put your monitoring tools on the system that will be monitored, you can let your system administrators use their monitoring tools to monitor the basic system and database availability and let Biztalk360 monitor the rest.

TL;DR avoid the grief of installing Biztalk360 as standalone. Install it on your Biztalk server instead.

BAM and ESB Portal

Both BAM and ESB in Biztalk360 are no-where near feature parity with the existing web sites in terms of functionality or usability. A pity since we use these features heavily, although I hear that there are updates coming which will close this gap. I think this is one area where Biztalk360 can really shine as the existing BAM & ESB portal are really dated, but nobody has the time to re-implement these to do a better job. I still find myself using the existing solutions because they are still better in most ways. I think this will change soon.

Monitoring

I've had a few problems with monitoring due to permissions related to the service account in use, but other than that it has been smooth sailing. The fine grain monitoring is excellent and in particular I love the process monitoring which allows you to check that a process has run and alert you if it hasn't. Massively useful for things such as daily processes.

Support

I've had to call on support a few times and they are a pleasure to deal with. No problems here.

ESB Import Failure: Microsoft.Practices.Modeling.Services

You've got your solution all tested and ready to go. You've practiced deployment on your test systems. You go to run BTDF to deploy the solution to your production system and you get an error about Microsoft.Practices.Modeling.Services being unavailable. This occurs at the step when BTDF is deploying one of your itineraries using ESBImportUtil.


The problem you'll find is that the tools folder doesn't exist at C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1 in your production system. So go into the folder C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Tools\Itinerary Designer on your test system and copy the files

• Microsoft.Practices.Modeling.Common.dll
• Microsoft.Practices.Modeling.ExtensionProvider.dll
• Microsoft.Practices.Modeling.Services.dll

to the folder C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Bin in your production system. Redeploy the solution and your itinerary should get through fine.

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.