XLang – Debugging BizTalk from within VS.Net

When developing Orchestrations, you are using a visual designer, which will in effect generate XLang which is handled by the BizTalk Xlang engine.

Although the Xlang engine has its own language XLang, it does support some shapes (Expression shapes, Delay) which are compatible with C#. It’s also possible to call .Net assemblies from an Atomic scope, and debug these following the steps; described in this post: Debugging .Net):

• Build the external C# library project
• Add it to the GAC
• Restart the Host Instance
• Attach the debugger to the Host instance

All great stuff, additionally, you can use the Orchestration debugger (Orchestration debugger) which connects to the XLang scheduler, all fine and dandy.

When you however, have an orchestration that directly fails, with an error you cannot comprehend, or tracking is disabled, you’re not so happy. Tracking is performed at the persistence points (Persistence points).

An Expression shape (which does not lead to a persistence point), which leads to a failure…

 

Does not result in an Error that helps a lot…

InstanceId: de8b3be2-48a3-493d-8dcb-c0b3c1a848fc

Shape name: Construct Routing and Resolutoin Fault Message

ShapeId: a42fb879-c074-455b-9c4c-a4e98b5632a5

Exception thrown from: segment 5, progress 3

Inner exception: Object reference not set to an instance of an object.

 

I want to show, that you can also look deeper than this, however it does requires you to understand, work with the XLang that is generated based on your designer…which might not be that easy to understand.

The Xlang is not C#, there a good post on this Xlang vs C#, it is generated. Below a short sample of XLAng;

               if (IsDebugged)

                    return Microsoft.XLANGs.Core.StopConditions.InBreakpoint;

                goto case 4;

            case 4:

                System.Diagnostics.Debug.WriteLine("test");

                if ( !PostProgressInc( __seg__, __ctx__, 5 ) )

                    return Microsoft.XLANGs.Core.StopConditions.Paused;

                goto case 5;

            case 5:

                if ( !PreProgressInc( __seg__, __ctx__, 6 ) )

                    return Microsoft.XLANGs.Core.StopConditions.Paused;

                Tracker.FireEvent(__eventLocations[7],__eventData[4],_stateMgrs[2].TrackDataStream );

                if (IsDebugged)

                    return Microsoft.XLANGs.Core.StopConditions.InBreakpoint;

                goto case 6;

            case 6:

 

When building a file, the XLang that is generated is located on the following location;

<ProjectName>.Orchestrations\obj\Debug\BizTalk\XLang\File0.cs

If you open this file….it looks you like can set breakpoints, off course, it’s C#, but then a little different. We can now go to our shape;

Consider Xpath which might be incorrect;

 

And look at the generated source;

Doesn’t that look simple….? let’s debug this…

As we have the C# file, and can look at the generated code, we would like to do more, we can attach to this (so directly from Visual Studio) using the following steps;

·         Build the Orchestration project

·         Add it to the GAC

·         Open the File0.cs

·         Set a breakpoint

·         Restart the Host instances

·         Attach the debugger (with the File0.CS) open to the Host Instance process

 

Sending a message leads to an exception which we have seen;

 

However, we can perform debugging by inspecting the message using the QuickWatch, change the XPath;

 

We can also look at the result of the XPath;

 

So that was the problem? The Xpath query I used was wrong;

QUERY:  /*[local-name()='Order']/*[local-name()='OrderHeader']/*[local-name()='Id']

RESULT:

The Xpath query needs to be wrapping in a string to return the Value (something you might know, but sometimes forget L);

CHANGE:QUERY:  string(/*[local-name()='Order']/*[local-name()='OrderHeader']/*[local-name()='Id'])

 

RESULT:

 

So yet, another way to figure out stuff, with the minimal of effort required such as deploying the solution, using the Orchestration debugger, attaching. This could be helpful when trying to understand the exception and cause of the exception. For instance when using:

·         XPath assignments (http://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2004/10/25/using-xpath-inside-biztalk-orchestrations.aspx#sthash.npqIcFHH.dpbs)

·         Inline C# code

·         Initializing of variables

 

It’s in any case….really cool to look at the generated code, understand the XLang engine. This was done on a BizTalk 2013 engine, I’m sure it works in all previous versions.

 

 

HTH,

Sander

Tags van Technorati: XLang debugging,BizTalk,Visual Studio