Yossi Dahan [BizTalk]


Thursday, July 12, 2007

Downcasting and orchestration parameters

Here's a tricky one that, for some odd reason, made us all smile.

We have a lightweight .net class (I'll call it X) we often use in our orchestrations (to do some tracing work for us, if you must know); we will quite often pass this class as a parameter to any called (or started) orchestrations.

Recently we've created another flavour of this class through inheritence; the new class (Y from now on) inherits the original class and extends it.

Having the new class defined we went to one of our processes and simply replaced the variable type from X to Y; thanks to the inheritence we did not really have to change any code other than adding the new logic we needed.

However, this orchestration was calling another one, in which the parameter type was still X while the paramter we were passing in has now changed to be Y.

In .net this is perfectly legal and the object would be down-casted to the base type with no issues.

I'm happy to report that BizTalk is no different (which shouldn't really be a surprise) and indeed our orchestrations still executed just fine. Y was being used by the first process, and then was passed in to the called process which used it as X. nice.

There is one major problem though - the orchestration desginer does not seem to support this scenario - if, like we did, the change of type is an aftermath thing (i.e. type change is done after configuring the call orchestration shape) everything is working just fine.

If, however, we need to introduce a new call orchestration when we have Y and the orchestration parameter is configured as X, or we try to modify an existing call orchestration shape the designer will not let us select a variabel of type Y for a parameter of type X.

We see the parameter type of X in the deisgned and quite simply are not given the change to select any variable of type Y.

This is unnecesary and quite limiting as it means we cannot call the orchestration from different processes passing either X or Y depending on what we have in the calling processes, we have to either restrict ourselves to one type (i.e. migrate all of the system to Y, which is not ideal) or do the downcasting ourselves before passing the parameter.

We were almost tempted to fool the designed by always changing the type after configuring the call orchestration shape, but this is unmaintainable, so we're resulting to changing the paramter type where possible or downcasting ourselves before the call orchestration shape where not.

Labels: ,


Post a Comment

<< Home