Yossi Dahan [BizTalk]

Google
 

Sunday, August 17, 2008

Unexpected EOF error

If you wanted another example where good error handling in code could save some time, here's one -

Last week I was making some changes to a small process I've had for ages; the process was all working when I wanted to extract a small bit of information from the message and decided to use the XLANG/s xpath method to do so.

I planned to get the actual xpath string from a helper class (I always do, to help with maintenance), so I've create a variable for it, but as a temporary step I've put the xpath as the initialising value for the variable.

When trying to build the project I've received an error in the error list  - "Unexpected EOF".  not very useful.

This could have taken me ages to figure out, but luckily I knew the only thing I changed was adding that variable, so I changed the initialising value to TEST and tried to build; this time the error was much more meaningful -

"identifier 'TEST' does not exist in '<process name>'; are you missing an assembly reference?"

as well as -          

"cannot find symbol 'TEST'

Just out of curiosity I tried again with the value of TEST THREE WORDS, this time it looked like

"identifier 'TEST' does not exist in '<process name>'; are you missing an assembly reference?"

and

"cannot find symbol 'TEST'

as well as

unexpected identifier: 'THREE'

and

expected ';'          

So what do I make out of it -

To start with I should stop forgetting that the values for string variables should be provided in quotes

That having a single quote in a variable value results in the rather cryptic "Unexpected EOF" error

That BizTalk could have done slightly more to validate values of variables at design/compile time and save us developers precious time :-)

Labels: , ,

Monday, August 11, 2008

Visual Studio 2008 SP1 and .net framework 3.5 SP1 released!

Both have been officially released today and can be downloaded here.

It is worth mentioning though that this time (although not the first time, and certainly not the last time) this "service pack" contains significantly more than just fixes and improvements - there's quite a few significant enhancements and new features in it.

Amongst others that includes the long awaited entity framework and the ADO.net Data Service. see more details here

Labels:

Zombies

A lot has been written about Zombies in BizTalk, but somehow they never really caused me too much problem. until today.

In one of our processes we are calling a web service to perform a certain lookup.

That web service’s implementation (whether correct or not) is to return the instance of the class if found or null otherwise.

When the service returns a null BizTalk receives an empty message, which triggers an exception in the process -

Microsoft.XLANGs.Core.MissingPartException: The XLANG/s message has no part at index '0'. The total number of parts found in the message is '0'. If you expect a multipart message, check that the pipeline supports multipart messages such as MIME.

I’m quite all right with that, BizTalk is definitely correct – we have returned an empty stream as a message which means nothing.

And so - we've added an exception handler around the call to the service and our orchestration’s flow carries on correctly all the way to the end shape. as expected.

However, contrary to the expected at this point the orchestration instance gets suspended by BizTalk with the error - “The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended.”

I believe this behaviour has been introduced in BizTalk 2006 - 2004 was quite “happy” to have the so called "zombies" in the process, and it was up to the developer to handle those (or not, as the case often was); since 2006 this had become an error and if a process ends with unconsumed messages the process gets suspended and the unconsumed messages are available for inspection.

Generally, I think that making a zombie an explicit error is a good idea, although it would have been nice to be able to set whether this behaviour is required on a per-process basis, however - in our case we found this very problematic - we were in a position where we couldn't consume the message properly (due to the exception handler) but although we have handled the exception we ended up with a suspended in stance as it appeared as a zombie. we could not win.

I have opened a support call on this one, waiting to hear if the product group agrees that this is incorrect behaviour or not (I seem to be getting conflicting thoughts). I'll try to keep this post updated when I get an answer.

Update: I've been exchanging quite a few emails with the product group on this one, but have not (yet) managed to convince them that this cannot possibly be the expected behaviour - I should be able to handle the exception and carry on without having a suspended instance; they think otherwise.

(You can read more details about this here - http://technet.microsoft.com/en-us/library/bb203853.aspx and http://blogs.msdn.com/biztalk_core_engine/archive/2004/06/30/169430.aspx

An interesting point is that this case is not listed in the list of causes for zombies in these articles, which makes me wonder – should an exception raised through a receive shape, which was properly handled by an exception handling result in a zombie?)

Labels: , , , ,

Thursday, August 07, 2008

Admin console wish list feature

I’ve been fortunate enough to have to go through a bunch of suspended items on our production server from the last week and do some impact analysis – understand what failed, why it failed, what is the impact on the business, and how we can mitigate (technically or non-technically)

I have to admit this is very interesting work, but I suspect only until it gets somewhat repetitive...

Anyway, this has made me come up with a new wish list item for BizTalk, this time for the admin console –

I was going through all the items in the list, for each one I had done some investigation, and possibly raise some queries with others to understand the process/impact/etc.

Getting answers takes a while, so I end up having a bunch of suspended/dehydrated items waiting there until I can get around to resume/terminate them.

To make matters worse - often in BizTalk server you would get more than one instance in the admin console that relates to a failure. the send port might be suspended, the orchestration sending the message might be suspended as a result and another orchestration that called that (or that is waiting for a correlated response) might simply be dehydrated)

All of this made it harder to know, at a glance, where I stand - what have I looked at, what haven't I checked yet, what is this one waiting for and which other process it relates to.

I think there are a bunch of feature that can be added to the admin console to make this work much better.

Things like being able to relate several suspended items together, tagging/colour coding items to categorise them, adding notes to items to indicate where in the investigation process I am etc.

I'm aware that there are several tools out there to help track support tickets etc. but they lack the relation to the tools admin use to monitor the application - in our world this would be primarily the BTS Admin Console!

Labels: ,