BizTalk 2010 and Clustered Enterprise Single Sign-On Support for Multiple BizTalk Groups

My current company follows the traditional code promotion environments: Development, Test, and Production. These environments are fully integrated with other systems so we can test messaging of our Enterprise Service Bus (ESB).  Where things really start to get atypical is in the fact that we support three different development and test environments.  Wait, what???

Yeah, and since we have three different test environments, we have three different BizTalk groups which all mimic our production set up.  Which in turn means three clustered databases.  Here is one thing that is super nice, we leverage the same Master Secret Server database and Enterprise Single Sign-On Service (SSO) for all three BizTalk groups.  Wait, what???

That's right, when installing and configuring different BizTalk groups, you can configure these BizTalk groups to leverage the same Enterprise Single Sign-On Service (SSO), and in my case, that resides on the cluster.  So how did I set this up?  In my particular scenario, all of our test BizTalk databases reside on the same cluster server. When I start the Failover Cluster Manager application, I'm presented with all the database clusters (In my case, 1, BIZTALK2, and SQL Server):

The clustered  Enterprise Single Sign-On (SSO) Service resides on the cluster with the name of  "1", which houses the original BizTalk database I created.  If I click this cluster in the left hand pane, it shows me a summary of my resources, which includes the Enterprise Single Sign-On Service:

So knowing that the Enterprise SSO resides on the first cluster application, I can leverage this set up when configuring my second BizTalk group.  To do this, during the configuration of the second BizTalk group, I selected the Enterprise Single Sign-On feature.  Instead of creating a new SSO System, I selected the "Join an existing SSO system".  I then entered the server name and database of where the Master Secret server was originally created (on the first cluster named "1").  I also used the same domain account that the service runs under:

Configuration of the remaining BizTalk features can be set up to leverage the second cluster application labeled BIZTALK2.  This cluster has a SQL Server database that can be used when configuring the BizTalk group, BizTalk Runtime, Business Rules Engine, and Business Activity Monitoring (BAM).

I used the same process when configuring the third BizTalk group.  The only changes are during the configuration of BizTalk.  Instead of using the BIZTALK2 clustered application, I used the clustered application labeled "SQL Server".

So what do I gain in having three different BizTalk groups leveraging one Enterprise SSO?

• For starters, this minimizes the number of clustered servers.  Instead of having three different clustered servers, I have one, which means fewer servers to maintain and support.
• Reduce Total Cost of Ownership (TCO) which directly relates to the first point.
• Maintain only one Enterprise Single Sign-On Service.  If I had multiple clustered servers, each one would require it's own Master Secret Server and Enterprise SSO (which need to be clustered).
• Avoid multiple Master Secrets to backup and store for a non production environment.

As a side note, some may argue that I've altered my test environment in a way so that it no longer mirrors production.  In theory, I can agree with this, however in practice I'm willing to take the risk.  I don't think multiple BizTalk groups sharing the same Enterprise SSO creates a test environment that deviates in a meaningful way from the production environment.

BizTalk 2013 and configuring the Oracle Adapter in a 64 bit environment

At my current company, I was on a recent project that needed to query master data housed in our PeopleSoft  Enterprise Resource Planning (ERP) System.  Generally, we have leveraged the Request/Reponse message pattern via web services when querying ERP master data.  However, on this project, we needed multiple succinct request messages to get the required data.

These smaller high volume messages were a definite limitation for PeopleSoft.  PeopleSoft uses Integration Broker (IB) for messaging, and we discovered early on that it's ability to respond in a timely manner to a high volume of requests was sub par.  Luckily we have BizTalk, which is interoperable, and provides an Oracle adapter that could be used to access the PeopleSoft Oracle database.  Having never used the Oracle Adapter before, I started Googling around for help.

I found two blog posts that got me rolling.   The first is installing the BizTalk LOB Adapter by Sandro Pereira which can be found here:

• BizTalk 2013 Installation and Configuration – Installing BizTalk Adapter Pack

This is a step-by-step guide with screen shots for installing the BizTalk Line of Business Adapter Pack. Although I was more interested in the Oracle adapter, I went ahead and installed the other adapters as well (SAP, Siebel, Oracle E-Business Suite, etc.).  In addition, this blog post also guides the user on how to add the adapter to the BizTalk Administration Console.

The second article, written by Jason Agostini, was around configuring the BizTalk Oracle adapter which can be found here:

• Getting off the ground with the WCF-Oracle Adapter

The only problem I had with the second article was that it was geared to a 32 bit development environment and an earlier version of the Oracle Database.  So using the above article as a guideline, here are the steps I took to get the Oracle adapter configured in a 64-bit environment:

• First I contacted our PeopleSoft Admin to get the current version of the PeopleSoft Oracle Database (11.2.0.2).  I then went to the Oracle website and downloaded the appropriate 32-bit and 64-bit ODAC zip files (ODAC112021XCopy).  Why not just the 64-bit?  For design time development, you will need the 32-bit version to create a connection to the database.
• From the readme.txt included in the ODAC zip files, I installed the assemblies by running the "install.bat" file from the command prompt.  Again, I had to do this twice, once for the 32-bit version and once for the 64-bit version.
• I then navigated to the directory where the BizTalk Adapter Pack was installed (In my case, C:\Program Files (x86)\Microsoft BizTalk Adapter Pack\bin) and opened the file "Microsoft.Adapters.OracleDB.config".  I then added an entry to reference the new version of the Oracle DataAccess assembly:

• Having completed the installation, I opened Visual Studio 2012 and brought up my BizTalk solution. In my schemas project, I right clicked the project and selected "Add Generated Items" selection:

• From the "Add Generated Schema" window, I selected the "ConsumeAdapterService" option:

• The next step is to select your binding, in my case "OracleDBBinding", and click the "Configure" button.  This is where I entered database information like ServerName and ServerAddress in the "URI Properties" tab.  Enter any credentials needed for access in the "Security" tab:

• Once the database information is entered, click the "OK" button.  From the "Configure a URI" text box, copy the text and paste into an application like notepad for later (you will need this information when setting up your send port in BizTalk Administrator).  
• Click the "Connect" button.  Once connected to the database, I selected the "Client (Outbound operations)" from the "Select Contract type" pull down list (which will allow me to pull data from the database).  Select the appropriate database object and operation from the menu panes.  Click the "Add" button so that your operation is added to the "Added categories and operations" menu pane.  Click the "OK" button :

• From this, a schema of the database object is created in the BizTalk project that can be used to retrieve data.  In my case, this was a table. Included in the schema's "Select" record is a filter element which acts as a "WHERE" clause to narrow your return set.  Below is a screenshot of a sample table schema with the "Select" and the "SelectResponse" records:

• After completing development (in my case an orchestration), building, and deploying my project, it was time to configure the send port in BizTalk Administrator.  The first step is to create a new Send Port for the application.  Right click the "Send Ports" and add new "Static Solicit-Response Send Port"
• When selecting the type of adapter to use, I have two choices.  I  can either select the "WCF-Custom" or the "Oracle" adapter:

• Since I selected the "WCF-Custom", under the "Binding" tab of the adapter I needed to select "oracleDBBinding":

• When configuring the adapter, under the "General" tab, there are two important steps.  First, I entered the Address (URI) by copying and pasting the text saved in notepad from my previous step of connecting to the Oracle database.  Second, the Soap Action should come from the "Target Namespace" of the database object schema created with the Adapter service.

• To ensure I was using the 64-bit version of the adapter, I made sure the BizTalk Host associated with the adapter was configured with the check box for "32-bit only" not selected:

• Running a test message, I was able to confirm that the send port was sending and receiving messages with the Oracle database successfully.  One thing to note, directly accessing an ERP database table is not a recommended approach, and I only used a table to get a working example up and running.  

BizTalk 2010 Moving the Master Secret to a Windows Server Cluster

My company recently went through a Microsoft audit of our production BizTalk 2010 environment. The main area of improvement Microsoft recommended was where the Master Secret Server should reside. Instead of having the Master Secret Server on one of the BizTalk Servers, it was recommended to move this to the clustered SQL Server.  Having not done this in my past, there were two main articles I followed to move the Master Secret Server:

1. How to Move the Master Secret Server
2. How to Cluster the Master Secret Server

Following the guidelines set within the above two articles, here are the steps I followed:

• I started with the first link above and navigated to the section of the article titled "To move the master secret from one server to a Windows Server Cluster".  This guided me to the second posted article above under the section "To install and configure Enterprise SSO on the cluster nodes (Windows Server 2008)".  As instructed, I ran the BizTalk install bits on both SQL Server boxes in the cluster and installed the required components for Enterprise SSO:

• When configuring BizTalk in custom configuration, instead of creating a new SSO system, I selected "Join an existing SSO system":

• After the installation and configuration of SSO, I followed the section entitled "To update the master secret server name in the SSO database".  Following the instructions  I created the xml file and ran the command "ssomanage -updatedb" from a command prompt with elevated permissions.  After updating the master secret server name, I ran the command "ssoconfig.exe -status" to ensure the name had been changed

• I then followed the section entitled "To create the clustered Enterprise SSO resource (Windows Server 2008)".  The directions are pretty self explanatory, but here are a couple of screenshots of adding the new resource and setting it's properties:

• After accomplishing this, I switched back to the article ""To move the master secret from one server to a Windows Server Cluster".  I copied the Master Secret backup file to each server in the cluster.  I brought the new "Enterprise Single Sign-On Service" (ESSO) on-line:

• After bringing ESSO online for the cluster, I restarted the Enterprise Single Sign-On Service on each of the BizTalk Servers.  
• Last step is to restore the Master Secret on the active node of the cluster.  Those directions can be found here: How to Restore the Master Secret Server.  Essentially, running the command "ssoconfig -restoreSecret [filename]" will restore the master secret on that server.  One thing to note is that you will need the password originally set-up when backing up the Master Secret to restore successfully.
• One last talking point to this whole process.  I'm fortunate to work in a company with the foresight to invest in multiple environments.   Before implementing this in our production environment, I was able to test this process in our quality assurance environment.  I would highly recommend going that route to identify potential problematic areas.
• One other talking point, if your looking to cluster your BizTalk hosts, check out this article by Kent Weare Clustering BizTalk Hosts.  A great article on not only the "how to" but why you would want to.

BizTalk360 Proactive Monitoring beyond just BizTalk

We currently leverage BizTalk360 to help maintain our Enterprise Service Bus (ESB) implemented with BizTalk Server.  One of the things I especially like about BizTalk360 is it's proactive monitoring.  With the flexibility of BizTalk360, our production environment has been set-up with monitoring of:

• BizTalk Applications - Receive Ports, Send Ports, Orchestrations, and Suspended Messages are all areas we are alerted to when there is a problem.
• BizTalk WCF Services -  WCF Services for BizTalk Receive Locations hosted in Internet Information Services (IIS).
• BizTalk Host Instances - Our BizTalk host instances are monitored to ensure they are in a started state.
• SQL Server jobs related to BizTalk - monitoring the success of jobs like DTA Purge and Archive that help maintain the health of BizTalk.
• Message Box Viewer (MBV) - a tool that can help identify problematic areas in your BizTalk environment, it is verified that the tool runs successfully every night.

Recently we came into an issue where the proactive monitoring alerted us to a number of applications with a high number of suspended messages.  After troubleshooting this for a while, it was determined that one of the subscribing systems (we use the publish/subscribe message pattern a lot) web services server had become overloaded and couldn't process any more incoming messages.  After the issue was resolved, we had a follow up meeting to discuss what we could do better in the future.  BizTalk360 came to the rescue!

BizTalk360 can be configured for not only BizTalk but other systems as well, especially if they have implemented web services.  How do you do this?  First open BizTalk360 and navigate to the "Monitor and Notify" tab and select the "BizTalk Environment" from the left menu pane:

Select the alarm that you want to set-up the alert for from the right hand pane "Choose Alarm" pull down option (You need to have already created an alarm in order to configure it).  Click the "Add new Web Endpoint" button:

The next step is to fill out the "Add new Web Endpoint for monitoring" form with the appropriate information like the "URL" field and the "Expected Return Code" field:

Once created, the alarm will trigger every time the expected return code isn't received.  In our case, the alarm is set-up to email not only the BizTalk team but the team responsible for the subscribing web service server.  This has also been enabled for all subscribing applications where web services are the main mode of transportation.  Kudos to the BizTalk360 team for their forward thinking on monitoring beyond the BizTalk environment!

BizTalk 2010 invoking PeopleSoft Web Service throws System.ServiceModel.CommunicationException

As I've mentioned before, I try and leverage content based routing whenever possible in BizTalk.  There are a number of reasons for doing this, the main one being to not overcomplicate your messaging scenarios when you don't need to.  As I try and practice what I preach, content based routing is widely used within the current environment I support.

Our main Enterprise Resource Planning (ERP) system, PeopleSoft, has many messaging scenarios set up with content based routing.  When originally setting up messaging for PeopleSoft subscriptions using the WCF Custom Transport Type, I kept on running into an error when sending the message.  The message looked like the below:

I immediately googled this problem and found the following Microsoft Question/Answer.  Basically it explains that BizTalk is expecting a NON NULL response from the PeopleSoft Service.   When inspecting the message through Fiddler,sure enough, this was the issue:

So the solution from the link above was to just have PeopleSoft include a non NULL response, but what if that isn't possible?  There is a way for BizTalk to handle a NULL response.  By using the WCF Custom Transport Type with a CustomBinding binding type, I can include a Binding Element Extension.  Within the WCF-Custom Transport Properties, select the "Binding" tab:

Right click the root "CustomBindingElement" in the left hand pane.  It will give you the option to "Add Extension".  In the Select Binding Element Extension, there should be an extension for "oneWay":

 Select the "oneWay" extension and click "OK".  This will take you back to the Binding tab where the new extension will now be visible in the left pane labeled "Binding".  The last piece of the puzzle is to move this extension up by right clicking the "oneWay" extension and selecting the "Move Extension Up" option.  This extension must be the first one:

After setting up the binding and re-testing the send port, the error no longer appears.  By setting the "oneWay" extension on the binding, BizTalk is no longer expecting the NON NULL response.  

BizTalk 2010 Tools of the Trade

Having worked with BizTalk for several versions now, I've collected a number of "Tools of the Trade" that I thought I would share.  These tools cover a wide variety of aspects within BizTalk 2010 but have all contributed to increased productivity and stability in the environments I've worked in.

Administration

• BizTalk360 - The most recently added tool to my repertoire, it must be said that this is much more than just a tool.  Saravana Kumar has developed a formidable application that covers a number of topics the most important being monitoring.  No more logging into production environments for discovering problems, the pro active monitoring that can be configured within BizTalk360 can notify interested parties of problems, and it's all configurable via a web interface.  There might be other monitoring solutions out there, but I think Saravana's team has one of the best solutions.

• BizTalk Deployment Framework - I can't recollect how I deployed my BizTalk applications before this utility, but one thing I know is that before this tool, the process was time consuming and stressful.  Thomas F. Abraham and Scott Colestock have put together a tool that allows a developer or admin to build an .msi file which contains all artifacts associated with a BizTalk application.  Huge kudos to these guys for this tool is a huge time saver in many areas, the most important being deployment.

Development

• Pipeline Component Wizard - Need to create a custom pipeline component?  Trying to remember all the different methods required of a custom pipeline component class can be difficult.  Let this wizard do the heavy lifting.  Not the best documentation and a little buggy, but a big time saver in this area.

Testing

• Pipeline Testing - Need to unit test that new pipeline component you just created with the Pipeline Component Wizard?  Tomas Restrpo has a testing library that can help.  Before I even think of leveraging a custom pipeline component, I'll test it with this library.  This library can save you an enormous amount of time when troubleshooting pipeline components.

• WCF Storm - Working with Web Service or WCF Services?  This app can test your endpoints whether they are associated with BizTalk or not.  Since my current work environment uses the Pub/Sub Message pattern extensively, this tool has worked for unit testing our endpoints.

Debugging

• Fiddler - The go to standard for web debugging in general, I use Fiddler for all web service troubleshooting.  I love the tools ability to inspect the raw XML.  Especially useful when failures on BizTalk send ports.

This is just a start to the list, and I plan on including more tools as I discover them.  If you have any suggestions for tools in any area within BizTalk, please let me know.

WCF Send Port SOAP Action header property in Content-Based routing vs. Orchestration

In my current work environment, BizTalk is leveraged for a lot of content-based routing scenarios.  As a rule, I've tried to use WCF Custom receive and send ports wherever possible. Recently while working with the business, there was a need to change from pure content-based message routing to incorporating an orchestration.  This orchestration was set up to use the current send ports that had already been created with  content-based routing. When testing the orchestration, everything was working as expected, except when the message hit the send port.

 The Send Port was originally set up to use the WCF-Custom Adapter (the message is actually being sent to a web service). It was configured with the following SOAP Action:

When testing the message, the message would always suspend.  Here is the error:

So why is it suspending with an incorrect SOAP Action when the message is sent from an orchestration and not when it is sent via content-based routing?  I had to pull out Fiddler to find the answer (If you have never used Fiddler, get to know it, I use it for all my troubleshooting of Web Service issues).  

When inspecting the Raw Message in Fiddler, notice the SoapAction included the whole action mapping setting that was set up in the Action property of the SOAP Action header in the WCF-Custom Transport. After reading this from Microsoft, there are two solutions and both included updating the WCF-Custom Transport configuration SOAP Action header:

1.) Change the name of the Operation in the SOAP Action header bts action mapping to match what was used in the orchestration. See below screenshots:

2.) Instead of using the BtsActionMapping in the SOAP Action header, just use the name of the SoapAction that the receiving system is expecting.

This will surely come up again when the business requires more than just content-based routing out of BizTalk.  Hopefully this will help someone else who might have missed this small but important configuration change.