Yossi Dahan [BizTalk]

Google
 

Monday, July 16, 2007

Orchestrations and the Obsolete attribute

I've recently posted this message; which meant we had to go back and change quite a few methods shared between quite a few orchestration.

considering the size of our project finding all the places that needs changing was not a simple taks, nor could we break the interface and assume we'll find and fix all the places before our next build is due; a more planned and carefull appraoch was required and so we've decided to add the Obsolete attribute to the offending methods and overload them with ones that take in XlangMessage to be used everywhere.

We were hoping that adding the attribute would result in nice warnings appearing in every build that uses the obsolete overloads which would help us identify, and eventually change them all.

However, to our surprise, BizTalk (in the most general term one could use 'BizTalk') is being a bit inconsistent in it's handling of the Obsolete attribute -

If we use a method called MyMethod in an expression shape in an orchestration, and we add the Obsolete attribute to the method -

[Obsolete("Some Message Here")]
MyMethod(XlangPart part)

When we build the orchestration we don't get any warnings as we'd expect which makes the Obsolete attribute quite useless (and is very inconsistent with .net in which, obviously, the use of the attribute is supported)

Whats strange is that if we change the attribute to raise an error -

[Obsolete("Some Message Here",true)]
MyMethod(XlangPart part)

Not only we see this error when trying to build the orchestration we would also see any other WARNINGS caused by the use of the attribute elsewhere in the project. suddently they are all visible.

Labels: ,

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: ,

Tuesday, July 10, 2007

Are you passing XlangPart to a helper class?

Then dont!

(note: there's an important update relevant to this post, you should read it here)

Generally I'm not a big fan of manipulating messages in code (as many people will testify after having long discussions with me on the subject); however - reality often comes into play and I find myself being able to clearly justify it.

This is uaully the case when the complexity of the operations required is such that it would be very difficult (and so less maintainable) or much slower to do so in a map (using custom xsl or not).

Then, of course, there are all the other cases where you simply need to pass in a message part to a helper method for other reasons as well, not necessariliy to modify them.

In any case - I've recently stumbled accross this article that suggests passing around message parts may cause a reference leak.

Bottom line is that one should always pass in the xlang message and resolve the part in code rather than pass in the xlang part itself.

Just though it's worth sharing...

Labels: ,