Feeds:
Posts
Comments

Archive for the ‘BizTalk Development’ Category

One of the great parts about my job is that I get to mix things up a couple of times a year and switch gears from SharePoint to BizTalk development. (It can be somewhat frustrating to keep everything straight at times, but it’s never boring!) Recently, I’ve been working on upgrading some BizTalk applications from 2006 R2 to 2010. It’s been great to see that not a whole lot has changed over the years. The integration with WCF was quite a change, but the principles aren’t a whole lot different from what was already there.

I was testing one of my orchestrations yesterday and ran into a rather unexpected problem: it was suspending with the message, “Suspend due to persistence failure during dehydration.” That’s not good: a DehydrationFailedException. Hmmm. I’ve seen this happen before–and it is most common to happen–when an object being used in the orchestration is not serializable. So, I checked all of my variables: they were all primitives or marked with the SerializableAttribute in the class definition. Hmmm. Okay, I’ve run into this before. For example, even though generics may be marked serializable, BizTalk doesn’t always handle the serialization very well.

Well, I was using a System.Collections.Specialized.StringCollection object. Though, it’s not a generic. To be on the safe side, I replaced it with a simpler System.Collections.ArrayList object. Still no go: “Suspend due to persistence failure during dehydration.” Grrr.

Review the variables once again. Everything is as primitive as I can get except for a System.Exception variable. So, I replaced it with some duplicated shapes. (This is getting absurd.) Still no go: “Suspend due to persistence failure during dehydration.” Grrr!

By this time, I knew what was causing the orchestration to hit a persistence point. I have a helper class which calls to a WCF service and uses the results to create a message used by the orchestration. (I know, it would be better to use the WCF service directly in the orchestration so I can get all of the failover, retry, et. al. offered by BizTalk itself. I went back and forth no less than half a dozen times before finally settling on calling the service in a helper class because it was just simpler.) The service call was failing because the data being passed to it wasn’t valid. No problem; good test! This could happen in production.

Problem was what the WCF service returned: a System.ServiceModel.FaultException. This in and of itself was not a problem (it’s marked SerializableAttribute), but it has a property on it called Code which holds a System.ServiceModel.FaultCode. System.ServiceModel.FaultCode is not marked with SerializableAttribute! AH HAH!

So, when the WCF service incurred a fault exception, it threw it, which got thrown from my helper class to the BizTalk orchestration. The orchestration has an exception handler that catches the exception. Within the exception handling is a Decide shape in which the orchestration either suspends or delays (for automatic retry). Suspending or delaying causes a persistence point and BizTalk tries to serialize and dehydrate. Only, it couldn’t serialize the exception because the Code property on the exception existed and is not serializable. (WOW! That was buried.)

Moral of the story: If you run into orchestrations suspending with the message, “Suspend due to persistence failure during dehydration,” (the DehydrationFailedException) first check the objects being used in the orchestration (variables, messages, etc.). If that doesn’t reveal the unserializable object, you may have to dig into those objects’ properties. An unserializable object must be around somewhere.

BTW, this problem will typically be accompanied by an event log entry of source “XLANG/s” with Event ID 10041 and the message, “xlang/s engine event log entry: Suspending due to exception occurring during dehydration of instance…”

Advertisements

Read Full Post »