Hold the phone!. Didn't I just pull that folder up in Explorer

Ah…good old File System Redirector. Turns out that on x64 machine’s this folder is located here

C:\Windows\SysNative\AppFabric

We can browse to this location when adding references to the Windows Server AppFabric assemblies to our VS 2010 projects.

All is well again in the universe

Of course the official site can be found here > http://australia.msteched.com/

I have been avoiding this for sometime now. That is, adding new activity items to the current BAM deployment in production. Production has been running for months now and in this high volume system we partition the BAM activities every week and archive each month (giving the client a rolling month worth of activity data). I was concerned that during the update of the BAM definition this data was going to be blown away (an experience that has caused much embarrassment in the past).

So the procedure I used this time did the trick…well almost

• Took a “backup” of the current BAM definition using BM.exe
  
  

  bm.exe get-config -FileName:MyConfig.xml

  
  
• Added the new activity items using Excel and edited the views
• Exported the new BAM definition to xml
• Removed the existing views using BM.exe
  
  

  bm.exe remove-view -Name:MyView

  
  
• Deployed the new definition using BM.exe and the update-all command – FAILED
  
  

  bm.exe update-all -DefinitionFile:MyNewDef.xml

   
  The error message in the command window was:

              All queries
combined using a UNION, INTERSECTorEXCEPT operator
must have an 


equal number of expressions in their
target lists.

 
Upon investigation, I found that the partition tables did not get updated with the new activity items. As the view spans both the current activity tables and all the partition tables the view creation failed. Interestingly, the BAM Archive tables did get updated.


• “Upgraded” the partition tables using the script from this blog post
  
  I did need to make a slight change to avoid some errors that cropped up with partition tables already archived and as such no longer present in the BAMPrimaryImport database (although the original script works).
  
  I changed the CURSOR definition to filter out those tables already archived:
  
  

  DECLARE partition_cursor CURSORLOCALFOR
  SELECT InstancesTable
  FROM [dbo].[bam_Metadata_Partitions]
  WHERE ActivityName = @activityName 
  
  AND ArchivedTime IsNull--
  Added additional filter
  ORDERBY CreationTime ASC
  

• Deployed the new definition again using BM.exe and the update-all command – SUCCEEDED
• Re-applied security to the Views using BM.exe
  
  

  bm.exe add-account -AccountName:TheStig -View:MyView

  
  

Unfortunately all my BAM Alerts got blown away . Makes sense as the alerts reference the view that was removed. Luckily taking the backup in step one allowed me to pull out the original alert definition and paste them into my new definition file. I re-deployed that using the update-all command and alerts are back to normal.

I did come across this KB 969558 article for BTS 2006 R2 that appeared to address the partition tables issue. It looks as though this did not make it into BTS 2009.

Just lost a couple of hours I will never get back…

I am in the process of upgrading one of our RFID applications to 2010 beta. The upgrade went through without a hitch and I found myself the proud owner (or at least caretaker) of a brand-spanking new BizTalk RFID Server 2010.

(No visible differences to BizTalk RFID Server 2009 – except for the icon)

I then proceeded to upgrade my Visual Studio 2008 projects to VS 2010. WOW!!! Build succeeded first time…I am on a roll baby!

So I imported my Process into RFID Manager and fired her up…

The WCF service was not responding. So I open up IIS Manager (my VM is Windows Server 2008 so I’m running IIS 7) and try to browse to the hosting.svc under my RFID process VD and I get a http 401.3 error. Where do I start to hunt this down. I have installed .NET Framework 4.0, VS 2010, BizTalk RFID Server 2010 (plus Silverlight 4, Windows Azure platform AppFabric 1.0, … ).

So I check:

• Application pool identities are correct – Tick
• Application pool framework version – v4.0 Classic mode
• Authentication set to Anonymous – Tick
• Anonymous user set to application pool identity - Tick
• NTFS permissions on the VD - Tick
• Test Pass-through authentication – Green Lights
• IISRESET (last desperate attempts of a beaten Sco)

Still no go. I get on the “bat-phone” to Ninja Mick and explain what's happening. He just laughs…”What! Another 401 error. That’s about the sixth this week”. He points me off to a KB article about disabling the loopback check (I am using host headers on my RFID Services site). Still no go but it hinted at the problem…host headers.

Back into RFID Manager and look at the Advanced Server Properties

Even though these settings are technically correct and BizTalk RFID Server creates the provider and process services without error, I needed to set the Host IP address to the host header name I am using. This appears to have changed between either BizTalk RFID Server 2009 > 2010 or a change to IIS, Windows Update, .NET 4.0 … your guess is as good as mine?

After setting this to the host header name all worked fine and I’m back to sending my tag read events into BizTalk RFID Server 2010

During the CTP(s) one way we could provide client credentials to authenticate with the Service Bus was to use username and password. We were writing code that looked something like this:

          // create the credentials object for
the endpoint 
          TransportClientEndpointBehavior userNamePasswordServiceBusCredential
= new TransportClientEndpointBehavior();
userNamePasswordServiceBusCredential.CredentialType = TransportClientCredentialType.UserNamePassword;
userNamePasswordServiceBusCredential.Credentials.UserName.UserName = this.solution;
userNamePasswordServiceBusCredential.Credentials.UserName.Password = this.password;

The UserNamePassword credential type is no longer supported in the v1.0 release. The types of supported client credential types are now:

• Saml: this option specifies that the client credential is provided in the Security Assertion Markup Language (SAML) format, over the Secure Sockets Layer protocol. This option requires that you write your own SSL credential server.
• SharedSecret: This option specifies that the client credential is provided as a self-issued shared secret that is registered with AppFabric Access Control through the AppFabric portal. This option requires no additional settings on the Credentials property.
• SimpleWebToken: This option specifies that the client credential is provided as a self-issued shared secret that is registered with AppFabric Access Control through the AppFabric portal, and presented in the emerging industry-standard format called simple Web token (SWT). Similar to the shared secret option, this option requires no additional settings on the Credentials property.
• Unauthenticated: This option specifies that there is no client credential provided. This option avoids acquiring and sending a token. It is used by clients that are not required to authenticate, based on the policy of their service binding. Note that this setting might leave data nonsecure if not used together with another security measure.

[See Choosing Authentication for an AppFabric Service Bus Application for more details]

So where we used to use UserNamePassword, the corresponding credential type is now SharedSecret (although you should check out the other authentication options as well). Here is what your code now looks like:

          // create the credentials object for
the endpoint 
          TransportClientEndpointBehavior sharedSecretServiceBusCredential
= new TransportClientEndpointBehavior();
sharedSecretServiceBusCredential.CredentialType = TransportClientCredentialType.SharedSecret;
sharedSecretServiceBusCredential.Credentials.SharedSecret.IssuerName = this.issuer;
sharedSecretServiceBusCredential.Credentials.SharedSecret.IssuerSecret = this.secret;

Default issuer name and secret are generated for you when you activate your AppFabric account. Create additional ones using the Windows Azure platform AppFabric Access Control Management Tool (Acm.exe) that is installed as part of the SDK.

I am getting a few reports that after a recent windows update (or installing .NET Framework 4.0) the ESSO service fails to restart. Microsoft have released a hotfix to address this (http://support.microsoft.com/kb/2252691)

Microsoft Reports:

This issue occurs after installing .NET Framework 4.0. The registration of the assembly used by ENTSSO to access SQL Server does not specify the correct version of the .NET Framework. When .NET Framework 4.0 is installed, the assembly will try to use the newer framework and then fail to load

To resolve this manually:

32-bit Server

1.       Open a command window
2.       Go to C:\Windows\Microsoft.NET\Framework\v2.0.50727
3.       Type: regasm “C:\Program Files\Common Files\Enterprise Single Sign-On\ssosql.dll”

64-bit Server

1.       Open a command window
2.       Go to C:\Windows\Microsoft.NET\Framework64\v2.0.50727
3.       Type each of the following and hit ENTER:

32bit:  regasm “C:\Program Files\Common Files\Enterprise Single Sign-On\win32\ssosql.dll”
64bit:  regasm “C:\Program Files\Common Files\Enterprise Single Sign-On\ssosql.dll”

Note On a 64-bit server, regasm will need to be run for both the 32-bit and 64-bit versions of ssosql.dll.

Hope this helps

Setting up a new VM and hit this hurdle. Lucky for me Microsoft just released 1.2 of the SDK that supports VS 2010 and .NET 4.0

Windows Azure SDK 1.2

Also, if you are using Windows Azure AppFabric and .NET 4.0 make sure the relay bindings are installed into the .NET 4.0 machine.config (not done by installer). Check out Wade’s post on how to go about it easily.

Keep those heads in the cloud

In my last post, I was exploring a different approach to implementing a simple windows service. In that solution, I used Windows Workflow to implement a folder monitor service. Part of the solution required me to gather target folder details from configuration. I needed more than the out-of-the-box appSettings collection of key-value pairs. Normally I would use a second xml configuration file and basically deserialise that into my custom collection class. However, I was in exploration mode so I decided to give the System.Configuration classes another go.

I wanted the client to easily manage the target folders to monitor and customise the alert that gets logged in BAM (see the last post). I wanted something like this:

            <
            folderMonitors
            >
            

            <
            folderMonitor
            targetFolder
            ="E:\Data\BizTalk\Monitor1"
            fileMask
            ="*.xml"
            timerInterval
            ="1"
            processingInterval
            ="2"
            >
            

            <
            alert
            alertInterval
            ="5"
            sender
            ="BIZTALK"
            destination
            ="LOB1"
            messageType
            ="Order"
            errorType
            ="Folder
Monitor"
            errorCode
            ="OFFLINE"
            />
            

            </
            folderMonitor
            >
            

            <
            folderMonitor
            targetFolder
            ="E:\Data\BizTalk\Monitor2"
            fileMask
            ="*.xml"
            timerInterval
            ="1"
            processingInterval
            ="2"
            >
            

            <
            alert
            alertInterval
            ="5"
            sender
            ="BIZTALK"
            destination
            ="LOB2"
            messageType
            ="Invoice"
            errorType
            ="Folder
Monitor"
            errorCode
            ="OFFLINE"
            />
            

            </
            folderMonitor
            >
            

            </
            folderMonitors
            >
          

I was surprised by the amount of code I needed to write. Basically you have to:

1. Define a ConfigurationSection
2. Define the ConfigurationElementCollection and implement the indexers and ARC methods
3. Define the actual ConfigurationElement (the folder monitor structure you see above)
4. Declare the configuration section in the app.config

Here is the source code   

              using System;

              using System.Collections.Generic;

              using System.Linq;

              using System.Text;

              using System.Configuration;

              namespace Breeze.BizTalk.WorkflowLibrary

{

              public
              class FolderMonitorSection
: ConfigurationSection

    {

              #region Static
Accessors

              ///
<summary>
            

              ///
Gets the configuration section using the default element name.
            

              ///
</summary>
            

              public
              static FolderMonitorSection
GetSection()

        {

              return GetSection("folderMonitorConfig");

        }

              ///
<summary>
            

              ///
Gets the configuration section using the specified element name.
            

              ///
</summary>
            

              public
              static FolderMonitorSection
GetSection(string sectionName)

        {

            FolderMonitorSection section = ConfigurationManager.GetSection(sectionName) as FolderMonitorSection;

              if (section
== null)

            {

              string message
= string.Format("The
specified configuration section (<{0}>) was not found.", sectionName);

              throw
              new ConfigurationErrorsException(message);

            }

              return section;

        }

              #endregion
            

              #region Configuration
Properties

        [ConfigurationProperty("folderMonitors",
IsDefaultCollection = true)]

              public FolderMonitorConfigElementCollection
FolderMonitors

        {

            get { return (FolderMonitorConfigElementCollection)this["folderMonitors"];
}

            set { this["folderMonitors"]
= value; }

        }

              public
              override
              bool IsReadOnly()

        {

              return
              false;

        }

              #endregion
            

    }

    [ConfigurationCollection(typeof(FolderMonitorConfigElement),
CollectionType = ConfigurationElementCollectionType.BasicMap)]

              public
              class FolderMonitorConfigElementCollection
: ConfigurationElementCollection

    {

              protected
              override ConfigurationElement
CreateNewElement()

        {

              return
              new FolderMonitorConfigElement();

        }

              protected
              override
              string ElementName

        {

            get { return"folderMonitor";
}

        }

              public
              override ConfigurationElementCollectionType
CollectionType

        {

            get { return ConfigurationElementCollectionType.BasicMap;
}

        }

              public
              override
              bool IsReadOnly()

        {

              return
              false;

        }

              #region Indexers

              public FolderMonitorConfigElement this[int index]

        {

            get { return BaseGet(index) as FolderMonitorConfigElement;
}

            set

            {

              if (BaseGet(index)
!= null)

                {

                    BaseRemoveAt(index);

                }

                BaseAdd(index, value);

            }

        }

              public
              new FolderMonitorConfigElement this[string name]

        {

            get { return BaseGet(name) as FolderMonitorConfigElement;
}

        }

              #endregion
            

              #region Lookup
Methods

              protected
              override
              object GetElementKey(ConfigurationElement
element)

        {

            FolderMonitorConfigElement cfg = element as FolderMonitorConfigElement;

              return cfg.TargetFolder;

        }

              public
              string GetKey(int index)

        {

              return (string)BaseGetKey(index);

        }

              #endregion
            

              #region Add/Remove/Clear
Methods

              public
              void Add(FolderMonitorConfigElement
item)

        {

            BaseAdd(item);

        }

              public
              void Remove(string name)

        {

            BaseRemove(name);

        }

              public
              void Remove(FolderMonitorConfigElement
item)

        {

            BaseRemove(GetElementKey(item));

        }

              public
              void RemoveAt(int index)

        {

            BaseRemoveAt(index);

        }

              public
              void Clear()

        {

            BaseClear();

        }

              #endregion
            

    }

              public
              class FolderMonitorConfigElement
: ConfigurationElement

    {

              #region Constructors

              public FolderMonitorConfigElement()

        {

        }

              #endregion
            

              #region Configuration
Properties

        [ConfigurationProperty("targetFolder",
IsRequired = true)]

              public
              string TargetFolder

        {

            get { return (string)this["targetFolder"];
}

            set { this["targetFolder"]
= value; }

        }

        [ConfigurationProperty("fileMask",
IsRequired = true, DefaultValue = "*.*")]

              public
              string FileMask

        {

            get { return (string)this["fileMask"];
}

            set { this["fileMask"]
= value; }

        }

        [ConfigurationProperty("timerInterval",
IsRequired = true, DefaultValue = "3")]

        [IntegerValidator(ExcludeRange = false,
MaxValue = 1440, MinValue = 1)]

              public
              int TimerInterval

        {

            get { return (int)this["timerInterval"];
}

            set { this["timerInterval"]
= value; }

        }

        [ConfigurationProperty("processingInterval",
IsRequired = true, DefaultValue = "5")]

        [IntegerValidator(ExcludeRange = false,
MaxValue = 1440, MinValue = 1)]

              public
              int ProcessingInterval

        {

            get { return (int)this["processingInterval"];
}

            set { this["processingInterval"]
= value; }

        }

        [ConfigurationProperty("alert")]

              public AlertConfigElement
AlertConfig

        {

            get { return (AlertConfigElement)this["alert"];
}

            set { this["alert"]
= value; }

        }

              public
              class AlertConfigElement
: ConfigurationElement

        {

              public AlertConfigElement()

            {

            }

            [ConfigurationProperty("alertInterval",
IsRequired = true, DefaultValue = "20")]

            [IntegerValidator(ExcludeRange = false,
MaxValue = 1440, MinValue = 1)]

              public
              int AlertInterval

            {

                get { return (int)this["alertInterval"];
}

                set { this["alertInterval"]
= value; }

            }

            [ConfigurationProperty("sender")]

              public
              string Sender

            {

                get { return (string)this["sender"];
}

                set { this["sender"]
= value; }

            }

            [ConfigurationProperty("destination")]

              public
              string Destination

            {

                get { return (string)this["destination"];
}

                set { this["destination"]
= value; }

            }

            [ConfigurationProperty("messageType")]

              public
              string MessageType

            {

                get { return (string)this["messageType"];
}

                set { this["messageType"]
= value; }

            }

            [ConfigurationProperty("errorType")]

              public
              string ErrorType

            {

                get { return (string)this["errorType"];
}

                set { this["errorType"]
= value; }

            }

            [ConfigurationProperty("errorCode")]

              public
              string ErrorCode

            {

                get { return (string)this["errorCode"];
}

                set { this["errorCode"]
= value; }

            }

        }

              #endregion
            

    }

}

And my app.config file looks like this

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

  <configSections>
    <!--Custom config section declaration for Folder Monitor-->
    <section
     name="folderMonitorConfig"
      type="Breeze.BizTalk.WorkflowLibrary.FolderMonitorSection, Breeze.BizTalk.WorkflowLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
    />
  </configSections>

  <!--Custom config section for Folder Monitor-->
  <folderMonitorConfig>
    <folderMonitors>
      <folderMonitor targetFolder="E:\Data\BizTalk\Monitor1" fileMask="*.xml" timerInterval="1" processingInterval="2">
        <alertalertInterval="5" sender="BIZTALK" destination="LOB1" messageType="Order" errorType="Folder Monitor" errorCode="OFFLINE"/>
      </folderMonitor>
      <folderMonitor targetFolder="E:\Data\BizTalk\Monitor2" fileMask="*.xml" timerInterval="1" processingInterval="2">
        <alertalertInterval="5" sender="BIZTALK" destination="LOB2" messageType="Invoice" errorType="Folder Monitor" errorCode="OFFLINE"/>
      </folderMonitor>
    </folderMonitors>
  </folderMonitorConfig>
  
</configuration>

Tip: If you do end up GAC’ing the assembly your configuration classes are under, don’t forget to update the type in the <configSections> to use the new PublicKeyToken value.

Once all that was setup (Birthdays and Christmas sorted out along the way) I was happy with the end result. In my WF I simply used the static accessor to get my configuration collection and bound that to the Repeater Activity in my workflow. Because of the amount of work involved, I think it would of been much better to stick with my usual approach. That is, using a second custom configuration file and deserialise it into my custom collection class. The real test will be what I choose next time I am asked to implement this type of thing…custom config file or custom config section?

Being in the integration business we are often are asked to interface with older, legacy systems via the file system. In BizTalk Server this is stock standard stuff. One feature that clients really love is the real-time monitoring and notification capabilities that BAM provides (often a compelling reason to adopt a product like BizTalk Server over the traditional roll-your-own interface approach). During a recent project the client loved the monitoring feature so much they asked if we could use this to monitor other legacy file based interfaces outside of BizTalk. That is, although BizTalk would not be involved in the processing or delivery of these files, could they use BAM to monitor and notify them when the legacy interface application goes down and stops processing them. Essentially they wanted a service that monitors folders and alerts them when files have not been processed (in-activity).

Outside of BizTalk, one tool I love using is Windows Workflow. WF is not new, but I don’t see much adoption out there in the real-world. Why is that? When I speak with other developers they often reply:

• When should I use WF?
• What benefits does WF give me over what I’m doing now?
• What does WF project look like?

To explore these questions I decided to implement the folder monitor service as a workflow hosted by a Windows service. Along the way I found some interesting features and techniques that I thought I might share here (some WF related some not). If you are like me, something like 80% of the code I am writing is the same. Reading from configuration, exception handling, calling services and database operations. Most of the time the business logic is simple and procedural in nature. Do this > If that > Do this > For each of these > perform this …. These applications seem to be well suited to the WF Sequential Workflow approach. A nice feature is of course the visual aspect. Its just too easy to validate your logic when its mapped out for you (or perhaps your client). I can also imagine revisiting this code 6 months down the track and not have to spend time recalling what the developer was trying to do (regardless of how well the code is commented).

To show you what I mean, here is the logic for the folder monitor.

Its easy to visualise the what I’m trying to do here. An interesting feature is the Monitor_Each_Folder activity. In WF you implement for-each loops using the Repeater Activity. Essentially you bind the activity to a collection class (like List) and it will iterate over each item in the list and execute the sequential activity(s) grouped under it using the current item as its data context. The collection I am using is a List of custom configuration elements with details of the target folder to monitor (more on that in another post). Expanding the sequential activity (the one that gets executed by the Repeater activity) we can see clearly the logic implemented by the folder monitor. I simply added code to the three activities I defined and left all the repetitive flow operations (If Then Else) to the designer.

Although not shown here, exception handling was also provided by the WF designer and all that was left for me to do was the specific exception messages and flow control (terminate or continue). So compared with the traditional approach I have actually reduced the amount of code I needed to write, just concentrating on the specific implementation bits. This also pays dividends when it comes to testing and debugging your application as instrumentation (tracking) comes out of the box. When debugging, the designer is re-hosted and stepping through the code highlights the activities executed and workflow path taken (very nice). We also have a nice integration story with BizTalk using the BAM WF interceptor as well.

With my workflow done and tested I moved on to hosting. I see this as another very nice feature of WF. My application is agnostic to the environment it is running under. I can choose to host this in a console app (for testing this is what I did) or in a Win Forms app, ASP.NET web app, Windows Service, WCF service, even BizTalk Server (in fact any .NET 3.5 application). To get this running under a Windows Service host took all of about 5 mins using the VS Windows Service project template. So when developing WF applications we manage the workflows separately from the host. Workflows in one project and the host in another referencing it. We may even decide to share out the WF across many hosts.

So while not terribly exciting in functionality, I found that choosing to implement the folder monitor service in WF actually took less code to write, made the code more readable, and provided all of the instrumentation I needed to quickly test and debug my code. I also now have more flexibility to reuse my code in other environments and applications. And we have only scratched the surface of Windows Workflow…

This week the Breeze RFID Team will be show casing an innovative RFID Document Management solution at CeBit. We have teamed up with Magellan Technologies to develop a hardcopy (paper) document workflow solution built on the Microsoft SharePoint platform. The solution allows printed documents to participate in document management workflow in the same way as traditional electronic documents.

Our partners, Magellan, have some very cool RFID gear on show including their RFID Document Tray Reader and their RFID Bookshelf Reader that we use in the demo.

So if you're at the show, pop in and say hi to the team.

In a (not so recent) post, I walked through the steps to get your BizTalk Server 2006 R2+ Orchestrations exposed to the Cloud. See Exposing BizTalk Orchestrations to the Cloud. With the release of the Microsoft .NET Services SDK (March 2009 CTP) this week, you will find your existing .NET Services endpoints no longer valid.

Here's how to resolve the issue.

At the moment your existing .NET Services endpoints are in the form:

sb://servicebus.windows.net/services/[solution name]/[service name]/

This has now been changed to:

sb://[solution name].servicebus.windows.net/[service name]/

Note: you can still register your service hierarchy as before (e.g. sb://.../[service group]/[service name]) but for simplicity I have just used [service name] in the URI's above.

So, even if you followed Microsoft's advise and coded your service endpoints URI's this way:

Uri address = new Uri(String.Format("sb://{0}/services/{1}/{2}", ServiceBusEnvironment.DefaultRelayHostName, solutionName, serviceName));

that didn't get you out of trouble when the URI change was released. We are now encouraged to use the following when generating endpoint addresses in code:

Uri address = ServiceBusEnvironment.CreateServiceUri("sb", solutionName, serviceName);

This will give us an address in the new structure and protect us from any future changes (but we heard that somewhere before didn't we). Also, be aware that (as of time of posting) the published services feed is not listing your services correctly (but they are still accessible). Your new published services feed will also be:

http://[solution name].servicebus.windows.net/

In the coming days, the team at Breeze will be walking through the new goodies the March CTP brings so look out for future posts (of particular interest is the queuing and routing features we have now!).

This week I gave a presentation to the Sydney BizTalk User Group on (Biz)Talking to the Cloud. I showed how we can quickly and easily configure a BizTalk Receive Port to consume services hosted in the cloud. In the demo, we configured BizTalk to participate in a multicast events scenario.

I have been playing further with BizTalk and Cloud services and in this post I will demonstrate how to expose BizTalk Orchestrations to the Cloud. To make it easy for you to build this on your own environment, I have used the now famous (or infamous) EchoService as the basis of this demo. This allows you to use the existing Microsoft .NET Services SDK sample to call the BizTalk Orchestration through the cloud.

Before You Begin

1. Sign-up to Microsoft .NET Services and create your Solution.
2. Download the Microsoft .NET Services SDK and install on your BizTalk Server 2006 R2 development environment.
   Note: Nothing more is needed as far as BTS is concerned. I am pleased Microsoft is making good on ensuring developers can use existing skills and technologies to get started with cloud services. Furthermore, we can be fairly comfortable that playing around with this stuff is not going to break or render our existing dev environment useless. Credit where credit is due.

BizTalk Development

In this step we will create a simple orchestration that receives a generic message, pulls the "echo" text out, creates the response message, and sends it back out the two-way port. I have used System.Xml.XmlDocument types avoiding the need to create schemas and simplifying the demo.

1. In Visual Studio 2005, create a new Empty BizTalk project.
2. Go ahead and set your Assembly Key File and BizTalk Application project settings. (I called my BizTalk App BizTalk Services as we will see later on)
3. Add a new Orchestration to the project.
4. Create the following messages:
   

Add the following shapes to the design surface

            // Retrieve the text sent in
the request strText = xpath(msgRequest, "string(//*[local-name()='text'])"); //
Construct the response strResponse = System.String.Format("<EchoResponse
xmlns=\"http://samples.microsoft.com/ServiceModel/Relay/\">

<EchoResult>{0}</EchoResult></EchoResponse>", "BizTalk:
" + strText); // Create the response document xmlDoc.LoadXml(strResponse); //
Assign the response message variable msgResponse = xmlDoc;

Wire up the port operations and don't forget to set the Activate property of the Receive shape

BizTalk Application Configuration

In this step we will configure a WCF-Custom receive port to expose our newly created orchestration to the cloud.

1. In BizTalk Server Administration Console, navigate to the BizTalk Application you just deployed to (mine was called BizTalk Services).
2. Create a new Request-Response receive port.
3. Add a new receive location and set the Transport type to WCF-Custom.
   
   
   
4. Configure the WCF-Custom adapter.
5. Set the EndPoint Address to:
   
           sb://servicebus.windows.net/services/[your solution name]/EchoService/
   
6. Set the Binding Type to NetTcpRelayBinding
   Note: This is one of the new bindings added when you installed the Microsoft .NET Services SDK
   
   
   
7. On the Behaviors tab, add a new behavior extension called transportClientEndpointBehavior to the EndPointBehavior node.
8. Set the credentialType to UserNamePassword and enter your solution credentials on the UserNamePassword element of the ClientCredentials node.
   Note: If you are using Windows CardSpace instead, set the transportClientEndpointBehavior to use it here instead.
   
   
   
9. Click Apply and verify no errors occurred with your WCF-Custom adapter configuration.
10. Click OK to close the Adapter configuration dialog.
11. Set the Receive Handler to your BizTalk Server Application host.
12. Leave the Receive and Send piplines as PassThru (as we are not requiring xml parsing of the messages we are sending and receiving).
13. Click OK to save the new receive location.
14. Do likewise for the receive port.
15. Now, configure your orchestration bindings and start the BizTalk application.

Verify the Service is Exposed to the Cloud

In this step we will browse to your Microsoft .NET Services service registry feed and verify your service is exposed to the cloud.

1. Launch Internet Explorer and browse to the following URL:
   
        http://servicebus.windows.net/services/[your solution name]/
   
2. You should now see your service endpoint listed in the Atom feed.

Test Your Solution

1. In Windows Explorer, navigate to the samples folder under the install folder for Microsoft .NET Services SDK
   Note: If you installed to the default folder it should be C:\Program Files\Microsoft .NET Services (Nov 2008 CTP) SDK\Samples
2. Locate the ServiceBus\GettingStarted\Echo sample and open your flavour of choice (C#/VB)
3. Build the Solution using VS 2008
4. Run the Client.exe
5. Enter your Solution name and password.
6. Enter some text to send to your service.
7. Verify the service response includes BizTalk: <your echo text>
   
   

What did we just do?

Using only the new WCF features that were installed in the Microsoft .NET Services SDK we were able to configure a request-response receive port in BizTalk that exposed our orchestration to the cloud. This is very cool .

At the very least, we could do away with the orchestration binding and just configure the receive port to drop messages into the BizTalk MsgBox. We then use content based routing to route the messages off to our existing orchestrations.

Think of the times you wanted to expose your BizTalk services to customers and clients outside your organisation, but had to jump all those hurdles the IT infrastructure team seams to magically come up with.

This is just the beginning...