Hi,

We are experiencing a strange issue with Biztalk 2004 exception handling.
The orchestration calls .Net managed code, which throws an exception back to
biztalk.  The .Net call is encapsulated within a scope, with an exception
handler catching System.Exception, and then publishing an error message out
to another orchestration.

In 99.9% of situations, this works fine.  Occasionally, the orchestration
fails with an unhandled System.Runtime.Serialization.SerializationException.
The stack trace shows this is a Binary serialization problem sourced from
Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.SendMessage.  (presumably thi
s
is the Send shape)

I'm wondering what the shape is trying to serialize which would cause this?
Has anyone had similar experiences?   This behaviour also occurs occasionall
y
with failures in serializing SoapExceptions from webservices.

I'm wondering whether there could be something that causes the instance to
dehydrate 'within' the send shape, and if in this case, biztalk would try,
and fail, to serialize everything within the scope of the exception block
(including the caught exception)??  Anything derived from System.Exception
should be binary serializable though.  Have been unsuccessful replicating
this in development.

Thanks in advance

[ Post a follow-up to this message ]

BC,

> We are experiencing a strange issue with Biztalk 2004 exception handling.
> The orchestration calls .Net managed code, which throws an exception back
> to
> biztalk.  The .Net call is encapsulated within a scope, with an exception
> handler catching System.Exception, and then publishing an error message
> out
> to another orchestration.
>
> In 99.9% of situations, this works fine.  Occasionally, the orchestration
> fails with an unhandled
> System.Runtime.Serialization.SerializationException.
> The stack trace shows this is a Binary serialization problem sourced from
> Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.SendMessage.  (presumably
> this
> is the Send shape)
>
> I'm wondering what the shape is trying to serialize which would cause
> this?
> Has anyone had similar experiences?   This behaviour also occurs
> occasionally
> with failures in serializing SoapExceptions from webservices.
>
> I'm wondering whether there could be something that causes the instance to
> dehydrate 'within' the send shape, and if in this case, biztalk would try,
> and fail, to serialize everything within the scope of the exception block
> (including the caught exception)??  Anything derived from System.Exception
> should be binary serializable though.

Actually, this isn't true. You *need* to ensure exceptions are serializable
explicitly, by marking them with the [Serializable] attribute and
implementing ISerializable and a serialization constructor, since
System.Exception explicitly implements ISerializable as well. Otherwise,
serialization for your exception won't work correctly.


--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

[ Post a follow-up to this message ]

The orchestration is catching System.Exception, which is Serializable.
Derived classes will also be serializable.It would unworkable to implement
ISerializable on every exception thrown back to Biztalk.  How would you do
such a thing on SoapException, which is thrown by the web service call.

The exception catch block works fine in most instances, and is an approach
used in hundreds of other orchestrations, without a problem.  The fact that
the serialization exception is sourced back the the send shape within this
exception block is concerning.  What business would the send shape have with
serializing the exception anyhow?


"Tomas Restrepo (MVP)" wrote:

> BC,
> 
>
> Actually, this isn't true. You *need* to ensure exceptions are serializabl
e
> explicitly, by marking them with the [Serializable] attribute and
> implementing ISerializable and a serialization constructor, since
> System.Exception explicitly implements ISerializable as well. Otherwise,
> serialization for your exception won't work correctly.
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
>

[ Post a follow-up to this message ]

BC,


> The orchestration is catching System.Exception, which is Serializable.
> Derived classes will also be serializable.

That's just not true, sorry. Every exception class needs to be made
serializable explicitly *if* it wants to support serialization.  This is not
something especific to biztalk, btw; it happens all the time in
EnterpriseServices and remoting applications.

A pain in the neck, I know, but that's how it is. Whether you need to do it
in *this* case for biztalk is a completely different story, though.

> It would unworkable to implement
> ISerializable on every exception thrown back to Biztalk.  How would you do
> such a thing on SoapException, which is thrown by the web service call.
>
> The exception catch block works fine in most instances, and is an approach
> used in hundreds of other orchestrations, without a problem.  The fact
> that
> the serialization exception is sourced back the the send shape within this
> exception block is concerning.  What business would the send shape have
> with
> serializing the exception anyhow?

It probably doesn't by itself. Since you haven't shown us the entire
exception message and stack trace, it's hard to guess what exactly is going
on, but one could presumably think that an unserializable exception is being
thrown somewhere during the send operation or something else inside a scope.
here's something I've seen before: if you have a handler that picks up the
exception and then something causes your orchestration to be dehydrated, the
error might popup either during the dehydration or the rehydration of the
orchestration if the exception is not serializable.

If you give us the complete details on the error, perhaps we can offer a
more helpful response.


--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

[ Post a follow-up to this message ]

Tomas,

Thanks for the assistance.  It would be possible to use a custom exception
class for the .Net call, but I didnt think it was possible to make Web
services throw anything other than SoapException.  I guess the way around
this would be wrapping the webservice call and turn the soapexception into
something serializable.

It does indeed look like a dehydration is occuring within the exception
block.  However, I'm at a loss as to why, all the block does is push a error
message into the messagebox, with the  exception.message text.  Could it be
load related? With a slow SQL call causing dehydration?

Cheers
BC

The 2 stack traces ...

System.Runtime.Serialization.SerializationException: The type
Microsoft.Data.SqlXml.SqlXmlException in Assembly Microsoft.Data.SqlXml,
Version=3.0.1523.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 is not
marked as serializable.
at
System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitSerialize
(Object
obj, ISurrogateSelector surrogateSelector, StreamingContext context,
SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter)
at
System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.Serialize(Obj
ect
obj, ISurrogateSelector surrogateSelector, StreamingContext context,
SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter)
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(WriteObjec
tInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo)
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object
graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck)
at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Str
eam serializationStream, Object graph, Header[] headers, Boolean fCheck)
at Microsoft.XLANGs.Core.ObjectSerializer._serialize(Object graph,
StringLookup sl)
at
Microsoft.XLANGs.Core.ObjectSerializer.SerializeStateManager(IStateManager
stateMgr, StringLookup lookup)
at Microsoft.XLANGs.Core.Service.Persist(Boolean dehydrate, Context ctx,
Boolean idleRequired, Boolean finalPersist, Boolean bypassCommit, Boolean
terminate)
at Microsoft.XLANGs.Core.ServiceContext.PendingCommit(Boolean ignore,
XMessage msg)
at Microsoft.XLANGs.Core.ExceptionHandlingContext.PendingCommit(Boolean
ignoreCommit, XMessage msg)
at Microsoft.XLANGs.Core.ExceptionHandlingContext.PendingCommit(Boolean
ignoreCommit, XMessage msg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.SendMessage(Int32
iOperation, XLANGMessage msg, Correlation[] initCorrelations, Correlatio
n[]
followCorrelations, Context cxt, Segment seg, ActivityFlags flags)
at SST.DM.Transfer.segment3(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s,
StopConditions stopCond, Exception& exp)



System.Runtime.Serialization.SerializationException: The type
System.Web.Services.Protocols.SoapException in Assembly System.Web.Services,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a is not
marked as serializable.
at
System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitSerialize
(Object
obj, ISurrogateSelector surrogateSelector, StreamingContext context,
SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter)
at
System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.Serialize(Obj
ect
obj, ISurrogateSelector surrogateSelector, StreamingContext context,
SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter)
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(WriteObjec
tInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo)
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object
graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck)
at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Str
eam serializationStream, Object graph, Header[] headers, Boolean fCheck)
at Microsoft.XLANGs.Core.ObjectSerializer._serialize(Object graph,
StringLookup sl)
at
Microsoft.XLANGs.Core.ObjectSerializer.SerializeStateManager(IStateManager
stateMgr, StringLookup lookup)
at Microsoft.XLANGs.Core.Service.Persist(Boolean dehydrate, Context ctx,
Boolean idleRequired, Boolean finalPersist, Boolean bypassCommit, Boolean
terminate)
at Microsoft.XLANGs.Core.ServiceContext.PendingCommit(Boolean ignore,
XMessage msg)
at Microsoft.XLANGs.Core.ExceptionHandlingContext.PendingCommit(Boolean
ignoreCommit, XMessage msg)
at Microsoft.XLANGs.Core.ExceptionHandlingContext.PendingCommit(Boolean
ignoreCommit, XMessage msg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.SendMessage(Int32
iOperation, XLANGMessage msg, Correlation[] initCorrelations, Correlatio
n[]
followCorrelations, Context cxt, Segment seg, ActivityFlags flags)
at SST.DM.Updater.segment5(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s,
StopConditions stopCond, Exception& exp)

[ Post a follow-up to this message ]