Error processing Broker OperationResolved

Topics: Technical Questions
Nov 6, 2009 at 10:37 AM

Any quick thoughts on why I am getting this error?  I am using the BAM component included (but comes undocumented) with the newest MSE release.  I have no problems at all until I start trying to use the XSL transform behavior...that is when I see the error below.   I have a XLS request and response transform in my operation policy.

mseTraceSrc Error: 0 : [BAM Interceptor] Error processing Broker OperationResolved event: Object reference not set to an instance of an object.
mseTraceSrc Information: 0 : XslRequestTransformationBehavior-IEndpointBehavior.ApplyDispatchBehavior Called...
mseTraceSrc Information: 0 : XslResponseTransformationBehavior-IEndpointBehavior.ApplyDispatchBehavior Called...
mseTraceSrc Information: 0 : XslRequestTransformationBehavior-BeforeSendRequest is called....
mseTraceSrc Information: 0 : XslResponseTransformationBehavior-AfterReceiveReply is called....

Nov 7, 2009 at 9:04 PM

The BAM Behavior has a couple issues with the data it tracks related to policies and policy assertions.  In your case, you've uncovered a bug that occurs when you use the BAM policy assertion on an endpoint and there is also a policy assigned to an operation version accessible at that endpoint.  The BAM behavior should still record usage information, you just won't have any recorded information about the policies in effect at the time of the incomming message.  So for the most part you can ignore this error. 

We'll be putting a fix in the next release so this exception isn't thrown (should be before end of year).  However, the policy information recorded by the BAM behavior will still not be useful for reporting purposes.

Nov 10, 2009 at 11:00 AM

Ah ok. Thanks for the reply.  It is good to know that it isn't just me!  One more thing about the BAM Behavior...I can never get the username data to be stored...Do I need to flow credentials to do that?



Nov 10, 2009 at 3:26 PM

That looks to be another bug, a side effect in the last release where we record the BAM data asyncronously.  Once on the threadpool thread the ServiceSecurityContext.Current property becomes null so we can't retreive the PrimaryIdentity.Name value.  It really should have been captured before transitioning to the threadpool thread.

The BAM Behavior is not quite ready for prime time as you are discovering (partly why it's largely undocumented), but if you look at the behavior through reflection you should be able to address these issues with an improved implementation.


Nov 12, 2009 at 4:27 PM

Thanks.  With your guidance I was able to use Refleftor to decompile and resolve the two issues you mention.  I'm now able to track user name using the BAM behavior.  Thanks again for your help.   Looking forward to the next release!