Making Filter Expressions Application Version Aware

Jul 27, 2009 at 10:05 AM

Hi guys,

I'm looking for some guidance on the best way to make filter expressions version aware. Here's the scenario:

I have some Receive Ports doing a fair amount of processing schemas,pipelines, custom pipeline components & maps, so much so that I need to be able to test this processing pipeline while it is being developed. The quickest and simplest way of seeing how all this stuff is working is to setup a few Send Ports and set filter expressions on them that have them subscribe to a specific Receive Port Names. Now I can FTP my documents in, have them picked up by the FTP Adapter, pushed through this Processing Pipeline and then look at the resultant files dropped by the Send Port.

So far so good. The problem is that because I'm using application versioning the Receive Port Names generated by the the Deployment Framework have the form AppName_VerNo_PortName rather just PortName. Ok, I could hardcode the Filter Expressions in the PortBindingsMaster to use the fully versioned PortName - but that feels clunky as it's something else to remember to change when the Application is versioned (which certainly won't play nicely should this project ever move to CI).

What I am looking for is to be able to get hold of the Versioned AppName Prefix as a macro which I can insert into the PortBindingsMaster file as a prefix for these port names in filter expressions. Is such a thing available and I've just missed it or is there some other slick way of achieving this?


Jul 28, 2009 at 2:51 AM

Well, as far as the prefix goes, it is established in the InitializeAppName target, which creates an MSBuild property called BizTalkAppName.  However, when the bindings file is preprocessed that property is not sent to XmlPreprocess.exe.  This partly eliminates the benefits of our side-by-side support, but are you aware of the DisableAutomaticPortNameVersioning property?  You can override it in your .btdfproj file to stop the port names from changing.

I was thinking about a way that you could overwrite the filter expression with some MSBuild tasks in one of the custom deployment steps targets, using something like <XmlFile.SetValue>, because you would have access to all of the MSBuild properties.  However, as I recall the filter expressions are encoded XML, so by the time you had a shot at it the binding file would already have the encoded vs. raw filter expression.

Does that give you any ideas to go on?  These are just my initial thoughts.


Aug 3, 2009 at 8:38 AM

Hi Tom, thanks for the feedback. Yeah, I was aware of BizTalkAppName - I've been using it in the .btdfproj file. I had seen theDisableAutomaticPortNameVersioning property but was hoping to keep the ports versioned as well since schema, map and pipeline version variations will need to be catered for. I'd also considered 'post-processing' the binding file from the build file, but discounted it for the the reasons you've outlined. I could write some specific command-line utility to process that file via string-matching - but that just feels wrong.

For now I will simply add a step to the manual instructions to edit these entries (just as you need to change the version number in the build file) before executing the process. It's not elegant but it's quick, and as we are dealing with version 1 right now we've got time to come up with something better before it becomes an issue.

Thanks for your help.

Aug 3, 2009 at 2:50 PM

Hi Tom,

Just a follow on to the above discussions.

Another side issue with the BizTalkAppName including the version number is if you set IncludeSSO to true this will then create an SSO application with the version number, this means that expression shapes using SSOSettingsFileManager.SSOSettingsFileReader will need to be updated whenever there is version number update.

I thought about updating InitializeAppName target to create a new property just for SSO but I am not that brave.

I have therefore reverted to a manual process for the time being which involves having three .cmd files which create/check and delete the SSO applications (without version numbers) and setting IncludeSSO to false, but it would be great if we could get a resovle to this within the script files.

You mentioned the property DisableAutomaticPortNameVersioning apart from setting it to true or false what else does it do, can't seem to find any other entries in the .targets file using this property.

Final note V5.0 is indeed very stable and I very impressed with its capabilties, in fact I think it is easier to use than the older NAnt versions, good work Tom.


Jim McLay

Aug 6, 2009 at 4:05 PM

Thanks for the feedback.  The DisableAutomaticPortNameVersioning doesn't do anything unusual -- all the side-by-side versioning except that it leaves the port names untouched.  Versioning the SSO app name was intentional because there is a good chance that two versions of an app are not going to have the same XML data stored in SSO.  I typically put the application name in a Constants.cs so that all expression shapes remain generic instead of having the app name w/ version number scattered everywhere.  I could add another property DisableAutomaticSSONameVersioning though.  If you'd like to have something like that, could you please add a request on the Issue Tracker?  That's the only sane way that I can keep track of all these requests.

I appreciate the positive comments.  Sorry that the documentation is so poor at the moment.


Aug 6, 2009 at 7:01 PM

Hi Tom,

My searching capabilities escaped me, when I tried searching for - DisableAutomaticPortNameVersioning I only found one entry in the .targets file (the setting of the property to false) hence my comments, searched again and found two entries SORRY.

Your sugestion about the constants.cs file is good, so will use that, RedDwarf had already pointed my in the same direction (we know each other from past assignments). About to start using ESB 2.0 Exception Mangement, so probably expect more emails from me, I will try to keep them to minimum though.



P.S. ESB 2.0 Your product is not the only one with poor documentation!!!!