Tuesday, October 28, 2008

Biztalk and WCF - When two big beasts collide

I spent the entirety of last week trying to create a ridiculously simple Biztalk orchestration and trying to get it to talk to a simple WCF service and I thought I should describe what I "learned".

Biztalk

If you follow me on Twitter you'll know how unbelievably annoyed the results made me and although I didn't learn much from the experience I thought I should put down some tips:

  1. If Biztalk gives you an error DO NOT read it, the message itself is bound to be utter jibberish and the correct response is to put it straight into Google.
  2. If Biztalk behaves like a problem is with step N don't assume that step N-1 passed especially if step N-1 is a transformation. You can test the transformation in isolation within the IDE using a sample document so do it,
  3. If you are having real problems working out why Biztalk and WCF aren't playing ball then it might well be XML namespaces that are the issue.
  4. If you're thinking of renaming the orchestration or anything in it be careful and take a backup first.

WCF

Whilst Biztalk left me cold the WCF side of it was a joy, mainly because Johnny Hall pointed me at the Castle WCF Facility and his own usages of it. Using the WCF Facility configuring your services is an utter joy, definitely when compared to the XML based approach that you get with bog-standard WCF. The documentation isn't great but the tests that you get with the Castle source code are the real way to see how to use its fluent interface.

Johnny also suggested we use a console application to host the service when testing and a Windows Service when deploying for a real. The console application makes testing locally a lot easier, just CTRL+F5 and your host is loaded and ready for you to fire requests at it.

If only Biztalk was as enjoyable to use...

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

5 comments:

  1. I totally agree on the Biztalk/WCF issues... Been there done that :(

    As for testing windows services you dont need a separate exe for testing them, just add:

    static void Main(string[] args)
    {
    if (args.Length > 0 && args[0] == "-d")
    {
    //start in non service mode
    Console.WriteLine("Push any key to stop");
    Console.ReadKey();

    }
    else
    {
    ServiceBase[] ServicesToRun;
    ServicesToRun = new ServiceBase[] { new ScheduledTasks() };

    ServiceBase.Run(ServicesToRun);
    }
    }

    And start your windows service project with CTRL+F5 with -d as commandline arguments

    And yes the castle WCF-facility rocks!!

    ReplyDelete
  2. Didn't know you could do that, will definitely give it a shot! :)

    ReplyDelete
  3. Just to clarify, you should replace the
    //start in non service mode - comment

    with code to start whatever your service is supposed to be doing. In my case something like

    var sr = ScheduledTasks();

    sr.Start();

    You can look at a working program.cs for one of my pet-projects here:
    http://code.google.com/p/andreasohlund/source/browse/trunk/NServiceBus.Management/src/NServiceBus.Management.ManagementService/Program.cs

    ReplyDelete
  4. Anonymous8:30 pm

    Dear BizTalk Team - please give us support for true one-way service operations. KKThxBye.

    ReplyDelete
  5. Anonymous9:13 pm

    hmmmmmm. Can't say I agree.

    ReplyDelete