Should you cluster the BizTalk 2006 Master Secret Server?

In short, YES you should cluster the service if possible.

I have seen lots of posts on this and I think that some recent problems with SSO clustering (see my post here for fixes) may have caused people to shy away from it.  If you are running SQL on a cluster, then you may as well tack on another clustered service and have that much more protection. If you are not running SQL in a cluster then clustering the Master Secret Server will probably not make much of a difference for you!

If you have a reliable cluster available and it seems to be managed well, use it and cluster the Master Secret Server. This is still the recommendation that you will get from Microsoft and still the easiest way to ensure that a hardware failure will not bring your BizTalk server to its knees.  I realize that the manual process involved in bringing up another master secret server in case of a failure is simple and short, but it is still a manual process. This means that somebody has to notice the problem, diagnose the problem, and fix the problem. All of which turns into downtime in your production environment.

I have seen people take a lot of time to notice and diagnose the problem in the past, so even if the fix is a quick one, you may still have a few hours of "head scratching" time before the production support team realizes what's happening.  Whereas if you have the master secret clustered, you will have a breif pause during the failover, then smooth sailing.  Chances are that your apps will not be affected at all (unless you happen to be restarting your host instance at the precise instant the failover takes place, in which case you will be unable to start them properly the first time and will have to issue the restart again)

I absolutely, definitely, 100% recommend that you take the time to cluster your Master Secret Server. (Just don't enable the registry replication if you happen to get an old version of the MSS clustering docs)

SSO Master Secret Server does not start after cluster failover

This post contains instructions about modifying the registry. This is inherently risky and this post is provided AS-IS without warranty of any kind.

I recently resolved this issue for a client but I suspect that many people have it due to some incorrect documentation regarding the installation of a clustered Master Secret Server.

The Problem

  1. SSO Master Secret server fails to start after failing over to second cluster node.

Event Logs

———————————————————————————
Source: ENTSSO
EventID: 10565
Description: The secret could not be loaded from the registry. The service account for the SSO service may have been changed or the secret may be corrupted. Restore the secret from a backup file.
———————————————————————————
Source: ENTSSO
EventID: 10521
Description: Could not load secrets from the registry of the master secret server.
———————————————————————————

Theory 1

  1. Perhaps the master secret was not installed on this second node.  So I dig out the Master Secret from the secure file share, and run the following command in command prompt from the Enterprise Single Sign-On directory:

    ssoconfig -restoresecret <keyname>

  2. The command completes, I go to cluster administrator, take the ENTSSO service offline, bring it back online and voila! It starts fine. End of problem right? WRONG?
  3. Just to be thorough, I fail it back over to node1 of the cluster (WHERE IT FAILS!). Now node1 exhibits the same behaviour as node2 did originally.
  4. Then I restore they key to node1 and node2 has the same problem it had in the first place.
  5. I scratch my head
  6. I call MS PSS (always a good idea when you're not sure)

Pause for Thoughts

  1. Couldn't be the key, because the node that has it restored begins to work and both nodes have it
  2. Couldn't be the database because one node always works
  3. Couldn't be the service account because one node always works
  4. Each node can operate correctly so there is no defect specific to the node
  5. Why does restoring the key on one node break the other, after all it's just a REGISTRY KEY (AHA!)

Theory 2

  1. The registry replication configured on the ENTSSO service in the cluster definition has a domino affect and somehow messes up the registry on whatever node did not just have the key restored. If I disable that, and cleanup the registies, maybe SSO will failover properly.

Solution

  1. Backup keys HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ENTSSO\SSOSS from both nodes (just in case)
  2. In cluster administrator, remove registry replication for that same key on the ENTSSO "Generic Service"
  3. Delete keys HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ENTSSO\SSOSS from both nodes (carefully)
  4. Restart both nodes (perhaps not necessary)
  5. Restore master secret to active node, then failover to other node
  6. Restore master secret to this node as well.
  7. Problem solved (test with multiple failovers to be sure)

Special thanks to Somu J. from MS PSS for the assistance on this problem.

BizTalk 2006 SOAP Adapter (Web Service call) in Messaging Only Scenario.

Web Services support in BizTalk is not a new topic, it’s already mentioned heavily in few of the famous blogs like Darren Jefford , Aaron Skonnard, Biztalk Server Team Blog etc

In this entry I’ll explain how you can use the out of the box SOAP adapter to call a web service in a messaging only scenario (aka Content based routing),  BizTalk 2004 SOAP adapter didn’t have this functionality, we need to use orchestrations along with SOAP adapters to call a Web Service. There is a MSDN sample called “Consuming Web Services (BizTalk Server Sample)” found under Samples, which show cases SOAP adapters messaging only capability, but it fails to explain in detail how its archived.

The below figure shows the biztalk solution we are going to implement in this blog post.

1. Web Service Definition:

For this sample we’ll define a simple web service with 2 web methods (sample download contains full implementation)

  1. ProductInfo GetProductInfo (CustomerInfo customer)
  2. ProductInfo GetProductInfoByAccountNumber (CustomerInfo customer, int accountNumber)

The below class diagram explains the custom in and out parameter (CustomerInfo and ProductInfo) data structure.

2. Create .NET Web Service Proxy Class:

Create a new Class Library project within Visual Studio, and Add Web Reference to the web service we created in Step 1. If you are using the sample application the url will be

http://localhost:11258/SOAPMessagingOnly.WebService/CustomerProcessing.asmx

We don’t need to add any custom coding to the proxy class, build the solution and deploy the assembly in GAC (you need to add strong name key to solution to do it).

3. Create Ports in Biztalk:

For this demonstration we are going to create 3 ports in BizTalk.

  1. MSG_File_Receive- File Receive
    1. Name : MSG_File_Receive
    2. Adapter: FILE
    3. Direction: One-Way
    4. Receive Pipeline: PassThru
    5. URI: <<Folder location where you are going to drop the file>>
  2. MSG_File_Send – File Send
    1. Name : MSG_File_Send 
    2. Adapter: FILE
    3. Direction: One-Way
    4. Send Pipeline: PassThru
    5. Filter: BTS.SPName = WS_SOAP_Send
    6. URI: <<Folder location where you want the web service response messages>>
  3. WS_SOAP_Send – SOAP Send
    1. Name : WS_SOAP_Send
    2. Adapter: SOAP
    3. Direction: Solicit-Response
    4. Receive Pipeline: PassThru
    5. Send Pipeline: PassThru
    6. Filter: BTS.ReceivePortName=MSG_File_Receive
    7. On the SOAP Adapter Config Screen Set:

Web Service URL:

http://localhost:11258/SOAPMessagingOnly.WebService/CustomerProcessing.asmx

Assembly Name: Pick the .dll of the web service proxy we created in step 2.

Type Name: Fully Qualified name of CustomerProcessing

Method Name: GetProductInfo

(Once after creating all the ports, enlist and start the send ports and enable Receive Location.)

Key things to Note:

  • We didn’t deploy any schemas into Biztalk
  • All the pipeline are “PassThru” in our settings.
  • Messages are routed (Filter Conditions) purely based on promoted properties, in our case just port names.

4. Drop the Sample Message in the Receive Location Folder:
This is one of the confusing bit, if you browse to the asmx page in Internet explorer and see the request message for GetProductInfo Web method, the SOAP:Body element will have the XML content as shown below.

<GetProductInfo xmlns=”http://www.digitaldeposit.net/biztalk/samples”>
<CustomerInfo xmlns=”http://www.digitaldeposit.net/biztalk/samples/Customer”>
<CustomerID>string</CustomerID>
</CustomerInfo>
</GetProductInfo>

People often try to post the whole message to the SOAP adapter, thinking it will be transmitted as it’s. But the reality is Biztalk will submit the IBaseMessage (Multipart message) to the SOAP Adapter, then the SOAP adapter will pick up the part inside the IBaseMessage and assign it to the web service argument based on the content-id of the part. If we try to pass the whole message, then there will be a type mismatch. So all we need to pass is

<CustomerInfo xmlns=”http://www.digitaldeposit.net/biztalk/samples/Customer”>
<CustomerID>string</CustomerID>
</CustomerInfo>

Interesting Exception message:

Ok, just a quick quiz, can you suggest me some solution based on the following exception.

The messaging engine was unable to resubmit a message for send port “WS_SOAP_Send” with URL

http://localhost:11258/SOAPMessagingOnly.WebService/CustomerProcessing.asmx.

Details:”Cannot access a disposed object. Object name: ‘CEventingReadStream’.”.

I tried googling it, couldn’t find any search results. After a bit of experiment found out, its the problem with the namespace I specified in the sample message. Its one of the bizarre error messages I came across.

You can replicate this exception by pasting the sample file “Namespace Error Customer.xml” found under MSG_SAMLES (from the download) folder in the receive location folder.

 So what happened to the second Web Method with 2 arguments?

As explained in step 4. I need to construct a Multipart message with two parts, first part will contain “customer” argument and the second part will have “accountNumber” argument. It’s still achievable by the traditional orchestration approach. In part 2 of the article I’ll explain in detail one of the approaches I took to solve this problem in a messaging only scenario without Orchestration.

Download the sample here and follow the steps below.

  1. Create a folder called BTSSample under C: and extract all the files.
  2. Open the solution in Visual Studio, build it, copy the proxy client dll to GAC, and view CustomerProcessing.asmx in the browser, this will kick off ASP .NET web server with port 11258.
  3. Create a Biztalk 2006 Application called SOAPMessagingOnly and import the binding file binding.xml.
  4. Drop the sample file (placed inside MSG_SAMPLES folder) into the folder MSG_IN.

Nandri!

Saravana

A Custom Functoid – EBCDIC to ASCII

Here is an example of a custom functoid method that converts an EBCDIC signed value to ASCII format:
Add a new C# class library project to your BizTalk solution and call it MyCompany.BizTalk.Functoids. Create a C# class in the project and use the same project name for the namespace.
 Example:

using System;
using System.Collections.Generic;
using System.Text;
 
namespace MyCompany.BizTalk.Functoids
{
    /// <summary>
    /// Summary […]

Custom Pipeline Components – part 3: Completing the Archive Component

This post continues the series on creating custom pipeline components. The previous posts in the series can be found here:  post 1,  post 2.
In order to complete the exercise of creating the archive component, we need to add the code to actually perform the archival of the message. For this example, the requirements of the archive component is to persist […]

UnzipDisassembler

I came across an article on CodeProject about creating a custom pipeline component for dissassembling incoming messages in zip formats. Even though it is implemented in 2004 version, it is still valid for 2006. It articulates well on how the custom pipeline is constructed in C# and how it can be deployed to a BizTalk […]