Yossi Dahan [BizTalk]


Tuesday, April 25, 2006

Setting send port filter based on properties from a schema of another application

I don't usually hurry to raise the "bug" flag, but after playing with this for an hour or so this is the only explanation I can find (and if someone thinks otherwise please correct me)

I have a very simple messaging scenario I use for demo purposes in which a receive port takes an xml message from a file drop, parses it, promotes some fields into the message's context and publishes it to the message box.

A send port then subscribes to this message and delivers it to…you guessed it right - a file drop.

I've been playing around with the promoted properties and subscriptions the other day when I stumbled into this -

A very standard scenario - create a subscription based on the existence of a promoted property.

So I went to add a filter to the send port by selecting the property I wanted ("Sabra.BizTalk.Demos.PO.Schemas.Status" in my case) and the operator "Exists", nothing special here.

Only that the property did not appear on the list.

Do the usual checks - promoted properties are defined correctly, property schema deployed…everything seems ok. The only suspect I had is that the promoted property (and the message schema) were deployed to another application (since it really belongs to another demo I'm doing).

But surely this shouldn't matter. After all - if I drop a message it gets parsed ok, no matter which application the schema was deployed to. the application is only a logical container and not a physical container.

But it did.

I've moved the schemas to the same application and I could now succesfully select the property from the list.

To me this does not make any sense. It is quite reasonable to have an application subscribe to messages published by another application. Not to mention generic services that may want to subscribe to messages with certain properties - for error handling, archiving or SLA tracking implementations for instance

This limitation simply does not make any sense. Also - it did not fit with my understanding of BizTalk application as a logical grouping of artefacts only, with no real impact on the runtime.

So - I decided to play around - I configured the send port with the subscription and then moved the schemas back to their real application.

Checked the port configuration - it still shows the subscription ok -

Restarted the host - no errors.

Ran the scenario - runs ok, the subscription caused the send port to pick up the message with no issues.

For curiosity I tried to open the property combo box in the filter and see if my property is now there - as soon as I do so the value selected disappears and again - my property does not appear in the list

After confirming that indeed the runtime did not care which application held the schemas, and that once deployed and configured propertly everything works fine, plus the fact that this behaviour does not make sense from a design perspective I had to conclyde is that this is indeed a bug in the Administration Console and not a real restriction.

While there are workarounds for this issue - either temporarily moving the schemas to the relevant application as I did (not very useful in real world as the schemas are at the base of the dependency tree and doing so may require removing the entire contents of the first application) or by editing the port configuration through a bindings file or code - they surely complicate things and makes the administration console and the applications concept unusable.

As such I'm sure (hope?) MS will fix this rather soon.

Update -

After raising this with Microsoft I was very happy to hear back from them (you have to appreciate the effort)

In the email it is confirmed that the runtime does not enforce the restriction described above but they do recommend following this rule as the design time behaviour suggests in order to avoid cross-app dependencies that are difficult to track.

Apparently the way to do this the proper way (and it is all my fault I never even realised this option exists) is to create a reference between the two applications (by right clicking on the application and selecting Add->Reference from the context menu ).

This links the two applications together, and when you will export your application to an MSI you will get a nice screen informing you which other applications should be imported on the target group as well in order to get the solution to work. pretty nice.

It will also, of course, let you select the properties in the send port filter property combo box...


Post a Comment

<< Home