Archive for July, 2007

Developing and debugging orchestrations using DebugView and SOAPTrace tools

Tuesday, July 31st, 2007

The main problem I have with developing BizTalk orchestrations is the fact that I’m so blind when it comes to follow the runtime processing. Using the debugger that is part of the HAT tool is slow and clumsy which IMHO makes the tool almost useless in everyday development. But there is hope!

DebugView

Sysinternals (Windows Sysinternal now - Microsoft bought them last year) DebugView is a wonderful little tool and is especially useful when it comes to figure out what’s actually going on inside an orchestration. Basically the tool listens to system wide debug output. From an orchestration it’s possible to write debug information using the .NET System.Diagnostics namespace and the Debug or Trace class.

Decide on how to filter

There are a couple of handy little tricks that makes DebugView a even better in BizTalk development. First one should try and have something in the debug messages that makes it possible to filter and distinct one’s own (as DebugView listens system wide debug output all running applications debug info will show up). Our team decided on “Sogeti” (our company name) for all our development and to have a method in our BaseLibrary component that outputs something like the below (the BaseLibrary is a small little .NET component with a couple of very useful classes we use company wide in our BizTalk related development).

System.Diagnostics.Debug.WrtieLine("Sogeti, your debug/trace message here")

This make is possible to have a filter in DebugView and to for example have it look something like this.

Trace full context of messages

Another little useful trick is to trace the full context of messages. This is done be storing the message in a XmlDocument typed variable and get the OuterXml property of that variable. The below code is and example of this.

tempXml = msgFindPartyRequest.parameters; System.Diagnostics.Trace.Write(System.String.Concat("Sogeti, msgFindPartyRequest: ", tempXml.OuterXml));

Example of a full message trace.

To Trace or Debug - that’s the question

As stated earlier both System.Diagnostics.Debug and System.Diagnostics.Trace has methods (Write, WriteLine and so on) for outputting debug information. However there is only one that stays in your compiled code when switching from Development to Deployment compilation mode (guess which one ;)). So make sure you choose the right class for the right information. I like to have some critical messages left using Trace and be able to trace these even on the test and production server.

DebugView on a remote desktop

When running DebugView on an other server (say a test or a production server) using Remote Desktop I’ve found that ones has to use the console user on the server. This kind of makes sense as if we’re connection “normally” we’re creating a virtual session and that’s not were the debug information is written to.

Microsoft SOAP Toolkit 3.0

This is a totally other tool than DebugView but I thought it fit here any way. It’s a handy tool when working with SOAP based messages. Without it’s very hard to actually figure out how the raw request and response message look and why your orchestration web service is acting the way it does.

The trace tool is placed as a reverse proxy between BizTalk and the Internet. It’s setup by telling the tracing tool which localhost port to listen at (for example 9091 as in the example below) then we’ll redirect to that port by changing the setting in the BizTalk send port.

Finally we’ll set up the trace tool to listen to port 9091 and redirect all traffic to our web service URL at port 80 in this case. So basically the trace tool will catch all the traffic hitting the 9091 port and forward it.

That’s it! This is probably basic stuff for most of you but hopefully it’s useful for someone! 

I’ve also noticed that the SOAP Toolkit is deprecated by Microsoft and I’d like to hear if anyone used something else (like Fiddler example) for tracing SOAP messages. I’d also love some other tips, tools and methods you use for debugging BizTalk orchestrations.

Reading text value from node using XPath function directly in BizTalk orchestrations

Tuesday, July 24th, 2007

The XPath function that’s available directly inside BizTalk orchestration is a powerful little tool. However I’ve seen a couple of project where developers just grown tired of it and started creating their own little libraries instead. I’ll be the first to admit that the XPath function isn’t perfect, and it sure doesn’t work like most of the other XPath engines (which is the biggest problem) but it’s still inside the orchestration and you can use it to both read and assign values to a message which is super useful! Basically I don’t see a valid reason for bringing more complexity into your solution by adding another library - as long as you’re just going to read or set value using XPath.

However there is one trick that you should know of when it comes to reading a text value from a node. Basically you have to use both the string() and
text() XPath functions. Both Charles Young and Yossi Dahan has good post on this subject. Also if your new to writing XPath expressions for complex schemas with loads of namespaces and stuff (like schemas in BizTalk) this post could be useful for you.

Finally a nice tool for writing and testing small XPath expression inside Visual Studio (if you don’t want to spend x minutes waiting for XmlSpy to start up …) is XPathmania. Read about it here - I use it all the time!

Lists, Arrays and collections within BizTalk orchestrations

Thursday, July 5th, 2007

This post shows how it’s possible to create your own .NET class and then use this within your orchestration (as a variable) to work with typed lists - something that unfortunately isn’t supported out of the box in BizTalk orchestrations. Below is the class used to create a typed list for System.String objects.  

using System;
using System.Collections.Generic;
using System.Text;

namespace Sample.BizTalkCollections
{
    [Serializable]
    public class StringList
    {
        private List<string> _list = new List<string>();

        public void Add(string item)
        {
            _list.Add(item);
        }

        public int Count()
        {
            return _list.Count;
        }

        public bool Remove(string item)
        {
            return _list.Remove(item);
        }

        public void RemoveAt(int index)
        {
            _list.RemoveAt(index);
        }

        public override string ToString()
        {
            StringBuilder builder = new StringBuilder();
            foreach (string item in _list)
            {
                builder.AppendLine(item);
            }

            return builder.ToString();
        }
    }
}

Notice that the class is serializable so BizTalk can serialize when dehydrating the orchestration to the database. We’ve also chosen not to extend the IList interface as we don’t want to expose all methods of that interface, but only the once we’ll really going use within our orchestrations.

This StringList class exists within the BizTalkCollections namespace where we have other classes for lists types with different datatypes (for example ObjectList, Int32List and so on). Below is a picture showing the structure of the Visual Studio project containing all the collections we current have implemented. This project and the BizTalk testproject is available for download here.

In the orchestration we then have set up a variable and type this to our StringList class within the Sample.BizTalkCollections namespace.

Also make sure the assembly with your collection class is installed in the GAC, otherwise you’ll end up with a FileNotFound exception saying

Could not load file or assembly ‘Sample.BizTalkCollections, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7109528d5dbf986b’ or one of its dependencies. The system cannot find the file specified.

Then you can use the following code within your orchestration! Download the sample project and test it.

A really generic class

I’d really like for it be possible to create my own generic classes and then initialize these using something like the below.

genericList = Sample.BizTalkCollections.GenericList<System.String>();

However this isn’t possible as BizTalk orchestrations don’t seem to understand generic classes … If someone found a solution to this please let me/us know via the comments to this post.

TechEd Barcelona here I come!

Monday, July 2nd, 2007

I’ve just found out that I get to go to TechEd in November! I haven’t been there before. I’ve been to a lot of conferences but not the Microsoft conference. Do I have to say that I’m looking forward to it?

If you’re going and feel like meeting up for a BizTalk lunch, dinner or whatever don’t hesitate to drop me an e-mail.