I’m happy to announce that the next Auckland Connected Systems User Group meeting is set for the 19^th of November 6:00pm at Datacom, 210 Federal Street downtown Auckland, New Zealand . Free entry, pizza and drinks provided as usual. Register here.

Jeff will take us through a practical exploration of the powerful Business Rules Engine in BizTalk Server, including guidance on creating vocabulary and policies, versioning pitfalls, and exposing the BRE as a WCF service.

Jeffrey Chilberto is a Software Consultant specialising in designing and developing business solutions using the Microsoft technology stack.  His focus is integration solutions using BizTalk, WCF and SQL Server technologies.

More information and registration form.

See you there!

Thiago Almeida

Emil Velinov from the Customer Experience Team in the Business Process Division (CSD + SQL) came to the New Zealand Tech Ed in September to present on BizTalk Server 2009 and Dublin.

During the visit the manager for BizTalk Server in New Zealand, Darryl Burling, spent some time with Emil to discuss BizTalk and Dublin as part of an awesome podcast series that Darryl is running. I highly recommend following the podcast, and this entry in particular for anyone interested in BizTalk and/or Dublin:

http://www.burling.co.nz/post/MSNZ-Podcast-5-e28093-BizTalk-Server-2009-and-Dublin.aspx

Regards,

Thiago Almeida

Every time when creating a Visio diagram for a solution architecture involving BizTalk I can’t really find a good server icon for BizTalk Server. Then I twittered my frustration.

What ensued is one of the best things about Twitter in my opinion.  Two twitter messages away I got the icons! Thanks to Todd Sussman and Rick Garibay for hooking me up. If I had looked around I would have found two of them, but this has a few extra stencils in the file.

Get them while they’re hot:

http://cid-df930ee6f91132fd.skydrive.live.com/self.aspx/Public/Share/BiztalkServer2006.vss

Other useful stencils for BizTalk are:

The icons from Enterprise Integration Patterns available here: http://enterpriseintegrationpatterns.com/downloads.html

Some stencils by André Dammeyer: http://www.acsug.co.nz/files/Downloads/BizTalk-2006-Messaging-Shapes.aspx

Do you have any others?

We’ve recently had some development and test BizTalk environments move data centres, and after the BizTalk Server machines were restarted the BizTalk host instance services stayed disabled.

By default the BizTalk host instance service (the windows services named ‘BizTalk Service BizTalk Group: <host name>’) have a start up type of Automatic. There is a known issue with Windows Server 2008 and Windows Vista where the Enterprise Single Sign-On service doesn’t start quickly enough and the BizTalk host services end up failing to start.

The resolution is simple: change the start up types for the BizTalk services on all the BizTalk machines in the group to Automatic (Delayed Start). This gives the Enterprise Single Sign-On enough time to start before the BizTalk services try starting.

This behaviour has been acknowledged by Microsoft in the support article 942284 and in the BizTalk forums.

So if your company are running BizTalk 2009 on Windows Server 2008, or BizTalk 2009/2006R2 on Windows Vista you should update your installation, release, or deployment notes to include updating the services start up type.

Regards,

Thiago

Just got a note from Ewan Fairweather from the BizTalk Customer Advisory Team. He is presenting a TechNet webcast on the BizTalk performance tests him and his team have performed this year and their results.

The webcast is happening in a couple of days (Tuesday, September 01, 2009 1:00 PM Pacific Time). For those in New Zealand that is Wednesday, 2 September 2009 at 8:00:00 a.m.

To read more about it and register for the webcast follow this link:

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032416252&EventCategory=4&culture=en-US&CountryCode=US

Regards,

Thiago

Code Camp Auckland is coming fast – 13 of September 2009, the Sunday before Tech Ed. With many international and local speakers, this is the biggest Code Camp ever.

If you want to catch some free  sessions on the state-of-the-art in .NET development, SQL Server and developer security  then sign up for Code Camp Auckland 2009 now.

To cover the costs of the event, we have the help of our generous sponsors: Microsoft, Datacom, Intergen, INETA and Xero.

So make sure you visit the website for more details, and sign up now!

See you there,

Thiago

Now that POP3 is not a part of Windows Server 2008 it is probably timely to post on a hidden POP3 adapter context property that you can use to decode emails picked up from the file system without actually using the POP3 adapter. I’ve been meaning to blog this for a while since I investigated it when reviewing a question on the MSDN forums. This trick is also useful for when you are using the POP3 Adapter but need to store the original email before any MIME decoding and then need to apply the decoding to it (in this case set the ‘Apply MIME decoding’ property on the POP3 adapter to false then use the method below later).

The POP3 adapter handles the POP3 protocol negotiation over TCP/IP to retrieve MIME encoded email messages. Once it has the email content, it puts it internally through an instance of the MIME/SMIME pipeline component (which in turn uses the COM dll BTSMIMEComps.dll) to decode it, and from there the message is given to the receive location pipeline.

The adapter writes (not promotes) an undocumented context property called CopyMailHeadersToContext to the message context before passing it to the MIME/SMIME pipeline component – this tells the component to add some POP3 properties to the message context as well.

So if you have MIME encoded emails being forwarded to BizTalk via file, FTP or otherwise (usually files with a .eml extension), you can reproduce the adapter’s behaviour by creating a very simple pipeline component to write the CopyMailHeadersToContext property with the POP3 adapter namespace and a value of 3 (don’t ask me why 3, still not sure about this value), then place it just before the MIME/SMIME pipeline component in the decode stage of a receive pipeline:

This is the execute method of the pipeline component, almost as simple as it gets:

public IBaseMessage Execute(IPipelineContext pContext, IBaseMessage pInMsg)

{

   //By writing this to the context we tell the MIME/SMIME decoder to

   //populate the POP3 context properties while going through the email message

   pInMsg.Context.Write("CopyMailHeadersToContext",

   "http://schemas.microsoft.com/BizTalk/2003/pop3-properties", 3);

   return pInMsg;

}

Once the message goes through this pipeline you will then get some valuable properties in the context that you wouldn’t see with just the MIME/SMIME component. The properties are Date, From, Headers, Subject, and To:

And that’s it, pretty simple really .

Download the sample here (Visual Studio 2008, BizTalk 2009)

Regards,

Thiago Almeida

A common misconception is that SharePoint is needed for the BizTalk BAM Portal.  I just wanted to write this quick blog post to say that SharePoint is not needed for BAM or the BAM Portal. The BAM Portal is a normal ASP.NET website, and does not require SharePoint at all.

As a BizTalk Server 2009 prerequisite you only need SharePoint if you are using the Windows SharePoint Services Adapter.  The supported versions for the adapter are WSS 2.0 with Service Pack 3 (SP3), WSS 3.0 with Service Pack 1 (SP1), and Microsoft Office SharePoint Server 2007 (MOSS).  So you do no need to install WSS or MOSS if you do not plan to use this adapter (but are welcome to ).

In previous versions of BizTalk prior to 2009 SharePoint was also required by Business Activity Services (BAS), which has been removed and is not a part of the 2009 release.

Of course you can use a SharePoint webpart to present the data collected by the BAM activities and views, but it has nothing to do with the BAM Portal.

It is quite a common requirement to have a generic receive location in BizTalk to accept any XML file. Richard Seroter has listed a few options already on how to do this.

I looked into how BizTalk exposes its WCF receive locations and how they could be consumed by using the WCF channel model, without having to use WSDLs or proxy classes.

Creating the BizTalk Receive Location

In my scenario I created a one way BizTalk receive port, and a receive location with the WCF.NetTcp adapter and the XMLReceive pipeline (but you could choose other WCF adapters here):

I then configured the WCF-NetTcp adapter properties by entering a URI and changing the security mode to None (for simplicity sake):

The WCF Adapter Interfaces

The main part of the BizTalk WCF receive locations is in Microsoft.BizTalk.Adapter.Wcf.Runtime.dll found on the installation folder  of BizTalk 2006 R2 and 2009.

As already noted by Paolo Salvatori “the WCF Receive Adapter instantiates a singleton instance of the BizTalkServiceInstance class for each WCF Receive Location”. The BizTalkServiceInstance class declaration implements the following service contract interfaces:

·         ITwoWayAsync

·         ITwoWayAsyncVoid

·         IOneWayAsync

·         IOneWayAsyncTxn

·         ITwoWayAsyncVoidTxn

Each of these cover the different scenarios of the WCF receive locations. They all have a BizTalkSubmit method, but if you inspect the BizTalkServiceInstance class’ implementation of this method (for all of the interfaces) you’ll notice that it’ll throw a NotSupportedException exception, so you can’t use this method to submit messages to the BizTalkServiceInstance instance. Read up Paolo’s post for some more information. Here’s the BizTalkSubmit implementation for the ITwoWayAsynchVoid for example:

[OperationBehavior]

void ITwoWayAsyncVoid.BizTalkSubmit(Message message)

{

   throw new NotSupportedException();

}

What is made available to us though is the server side IAsyncResult model. This model is well explained in this blog post by Dan Rigsby . The methods to use to send messages to BizTalk WCF receive locations are the other two method of BizTalkServiceInstance that implement the IAsyncResult mode class: BeginTwoWayMethod (or BeginOneWayMethod for the IOneWay… interfaces) and EndTwoWayMethod (or EndOneWayMethod).

Sending Messages to the Receive Location

Now that we have a BizTalk receive location and a basic understanding of the WCF receive adapters we can move on to sending a message to it from our .NET code. First add a reference to System.ServiceModel.dll and System.Runtime.Serialization.dll. Our one way receive location uses the ITwoWayAsyncVoid interface (the IOneWay… interfaces are only for the WCF-NetMsmq adapter, and the ones ending in Tx are for when transactions are enabled on the receive location. Interfaces without Void are for receive response):

namespace Microsoft.BizTalk.Adapter.Wcf.Runtime

{

[ServiceContract(Namespace = "http://www.microsoft.com/biztalk/2006/r2/wcf-adapter")]

public interface ITwoWayAsyncVoid

{

    // Methods

    [OperationContract(AsyncPattern = true, IsOneWay = false, Action = "*", ReplyAction = "*")]

    IAsyncResult BeginTwoWayMethod(Message message, AsyncCallback callback, object state);

    [OperationContract(IsOneWay = false, Action = "BizTalkSubmit")]

    void BizTalkSubmit(Message message);

    void EndTwoWayMethod(IAsyncResult result);

}

}

You can get the other service contracts from Paolo’s post or from Microsoft.BizTalk.Adapter.Wcf.Runtime.dll.

Once you have the appropriate service contract interface in your code you can now configure the end point. I added mine to my app’s App.Config file with the address configured on the BizTalk WCF receive location and a binding that follows the one configured there:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <bindings>

      <netTcpBinding>

        <binding name="NetTcpBinding_ITwoWayAsyncVoid">

          <security mode ="None" />

        </binding>

      </netTcpBinding>

    </bindings>

    <client>

      <endpoint

        address="net.tcp://bt09standalone.thiago.com/WCFNetTcpGenericReceive"

        binding="netTcpBinding"

        bindingConfiguration="NetTcpBinding_ITwoWayAsyncVoid"

        contract="Microsoft.BizTalk.Adapter.Wcf.Runtime.ITwoWayAsyncVoid"

        name="BlogWCFGenericReceiver" />

    </client>

  </system.serviceModel>

</configuration>

Here is the BeginTwoWayMethod method declaration for the ITwoWayAsyncVoid interface:

[OperationBehavior]

IAsyncResult ITwoWayAsyncVoid.BeginTwoWayMethod(Message message, AsyncCallback callback, object state);

You pass it a WCF message, and can also pass an async callback method so that the main thread isn’t blocked. You can also pass in an object in the state parameter and you will get the same object back once the callback method is called.

Alternatively from passing in a callback method you can just tell the wait handle to block the current thread until a signal is received – once it is received this is when BizTalk is ready for you to call the EndTwoWayMethod.

Here is the method in my windows forms app that sends a message to BizTalk and uses the wait handle to wait for a signal:

private void btnSubmitWaitHandle_Click(object sender, EventArgs e)

{


    txtResults.Text += DateTime.Now.TimeOfDay.ToString()

                         + " Sending message to BizTalk\r\n";

    DisableForm();


    try

    {

        cf = new ChannelFactory<ITwoWayAsyncVoid>("BlogWCFGenericReceiver");

        cf.Open();

        ITwoWayAsyncVoid waitHandleProxy = cf.CreateChannel();


        btnSubmitWaitHandle.Enabled = false;


        Channels.Message msg =

            Channels.Message.CreateMessage(Channels.MessageVersion.Default,

            "BeginTwoWayMethod", new XmlTextReader(new StringReader(txtMessage.Text)));


        //Start the call to BizTalk and get the async result back

        IAsyncResult res = waitHandleProxy.BeginTwoWayMethod(msg, null, null);


        //Blocks current thread until until AsyncWaitHandle receives a signal

        res.AsyncWaitHandle.WaitOne();


        //End the call once the wait handle signal is received from BizTalk

        waitHandleProxy.EndTwoWayMethod(res);


        txtResults.Text += DateTime.Now.TimeOfDay.ToString() +

            " Message sent successfully\r\n";

        cf.Close();

    }

    catch (Exception ex)

    {

        txtResults.Text += DateTime.Now.TimeOfDay.ToString()

          + " Exception: " + ex.Message + "\r\n";

        if (cf != null) { cf.Abort(); }


    }

    finally

    {

        EnableForm();

        if (cf.State == CommunicationState.Opened)

        { cf.Close(); }

    }

}

And here are the two methods that send a message to BizTalk using the callback approach:

private void btnSubmitAsyncCallback_Click(object sender, EventArgs e)

{

    cf = new ChannelFactory<ITwoWayAsyncVoid>("BlogWCFGenericReceiver");

    cf.Open();

    asyncCallbackProxy = cf.CreateChannel();

    string state = Guid.NewGuid().ToString();

    txtResults.Text += DateTime.Now.TimeOfDay.ToString()

                         + " Message " + state + " sent to BizTalk\r\n";


    //Create message

    Channels.Message msg =

        Channels.Message.CreateMessage(Channels.MessageVersion.Default,

        "BeginTwoWayMethod", new XmlTextReader(new StringReader(txtMessage.Text)));


    //Start the call to BizTalk and pass in the async callback method

    DisableForm();

    IAsyncResult res = asyncCallbackProxy.BeginTwoWayMethod(

       msg, new System.AsyncCallback(OnEndTwoWayMethod), state);

}


public void OnEndTwoWayMethod(IAsyncResult asyncResult)

{

    //Get the guid back, this will be what we passed as 'state' on BeginTwoWayMethod

    string msgid = asyncResult.AsyncState.ToString();

    try

    {

        //End the call to BizTalk. Make sure it's the same asyncCallbackProxy

        //object instance used to send the message otherwise it will fail

        asyncCallbackProxy.EndTwoWayMethod(asyncResult);


        this.Invoke(new MethodInvoker(delegate()

            { txtResults.Text += DateTime.Now.TimeOfDay.ToString() +

                " Message " + msgid + " sent successfully\r\n"; }));

    }

    catch (Exception ex)

    {

        this.Invoke(new MethodInvoker(delegate()

            { txtResults.Text += DateTime.Now.TimeOfDay.ToString()

                + "Message: "

                + msgid + ". Exception: " + ex.Message + "\r\n"; }));

        if (cf != null) { cf.Abort(); }

    }

    finally

    {

        this.Invoke(new MethodInvoker(delegate()

        { EnableForm(); }));

        if (cf.State == CommunicationState.Opened)

        { cf.Close(); }

    }

}

That’s it! We can now send any XML message to BizTalk this way. Here’s what my tester application looks like after two messages were sent with the WaitHandle and once with the callback approach:

If the BizTalk receive location is disabled or the BizTalk host is stopped, you get a System.ServiceModel.EndpointNotFoundException exception when calling the EndTwoWayMethod method (I removed my machine’s ip address from the exception):

“Could not connect to net.tcp://bt09standalone.thiago.com/WCFNetTcpGenericReceive. The connection attempt lasted for a time span of 00:00:02.0141069. TCP error code 10061: No connection could be made because the target machine actively refused it ip address:808.”

What if, for example, we change the Inbound BizTalk message body from Body to Path and enter an invalid path?

If you have ‘Include exception detail in faults’ enabled you get an exception of type  System.ServiceModel.FaultException<System.ServiceModel.ExceptionDetail> with the right details:

“Unable to find match for inbound body path expression "/nothing" in message.”

If the tickbox is not enabled you get a System.ServiceModel.FaultException:

“The server was unable to process the request due to an internal error.  For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.”

If you untick the ‘Suspend request message on failure’ and there is an exception in the pipeline, the message doesn’t get suspended and the client gets the error back when ‘Include exception detail in faults’ is ticked:

“There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Receive Port: "Blog.GenericReceive" URI: "net.tcp://localhost/WCFNetTcpGenericReceive" Reason: Finding the document specification by message type "http://Blog.GenericReceiver.BT/Schemas#aGenericReceiverSample" failed. Verify the schema deployed properly. ”

So there you have it, another way of submitting any XML messages to BizTalk by using the WCF channel model.

Download the sample code

Regards,

Thiago Almeida

Just saw on Rahul’s blog that the latest edition of the BIzTalk HotRod magazine is out, with some great articles on:

• Azure
• Testing maps and schemas
• Richard Seroter’s "SOA Patterns With BizTalk Server 2009" book review
• Throwing typed faults from orchestrations exposed as a WCF service
• Integrating BizTalk with Dynamics AX
• Managing BizTalk with WMI and C#
• BizTalk resources list

Download it here!