Saturday, September 18, 2004
I've been working for a large defence client in Portsmouth in the UK and recently come across another limitation in the filter expressions that can be applied to an activatable receive shape of an orchestration.
First some background though. When you drag an operation from a port to an activatable receive, you are effectively creating a subscription for that orchestration in the message box. When you deploy the orchestration, bind it and then enlist, the subscription will be created for that orchestration based on the message type that was defined on the operation that was bound to the receive shape.
This is important: the subscription is based on the message type of the operation defined on the port type. If you look at the subscription viewer and find your orchestration subscription (look for ServiceType of XLANG and the name will be prefixed with Activate), then you'll notice that the subscription has been automatically created with a MessageType filter.
Therein lies the problem. You see, because the subscription has been based on the message type being received, you can't set a filter in the receive shape that points to, say an envelope's promoted properties. This in my opinion is a serious flaw. If I have an envelope that contains meta data about my message, then I want to subscribe to properties on the envelope, but actually receive the message contained in the body of the envelope.
If I want to do this, then I have to define the envelope schema as a normal schema, that is, not a BizTalk Envelope schema. I then ensure that the body element is extensible, in other words, appending an <Any> element with ProcessContents set to Skip and the Namespace to ##any.
Once this has been done, receive the envelope in the orchestration (defined on the receive shape and port type) and then extract, plus optionally validate, the body inside orchestration.
This has an advantage:
The body document can be validated at a 'business' level - effectively allowing any errors from the validation to be handled within the orchestration, rather than being automatically suspended. I'll post some neat code that achieves this in a later post.
However, and this brings me all the way back to the point of my post, if I try and modularise my envelope schema by separating my header schema and then importing it into the main envelope schema, I have a major problem.
The envelope schema exists in one namespace and the header schema in another. The header schema has been imported into the envelope schema. In so far as XSD is concerned, I have a valid schema. In so far as BizTalk is concerned, it can see the header schema and can thus validate the contents (as opposed to using the Any element trick).
However, if I go to set a filter expression on the receive shape, then all of the promoted properties that are defined in the header schema do not display. Only promoted properties of the envelope schema will be displayed!
I've been bitten by filter subscriptions with BizTalk Envelopes and now with imported schemas. I so wish this will be sorted out as it limits the flexibility of the schema design that could be possible, but due to restrictions imposed by BizTalk, isn't.
I would be interested to hear some other view points on this.