Fix for BAM error "Views or Activites may be missing because one or more database(s) could not be contacted"

I had to migrate a BAM implementation into production from a development environment where everything in localized to a clustered database back end.

The deployment went fine, including the BAM part, but I couldn't access the views in the BAM portal. I verified that data was being written into the BAM database, but when I went to the portal to view the data I saw the following message:

Views or Activites may be missing because one or more database(s) could not be contacted. No view to display

There was also an error in the event log which read:

Referenced database 'BAMPrimaryImport' on server 'xxxx' is not accessible. The error is:
System.Data.SqlTypes.SqlNullValueException: Data is Null. This method or property cannot be called on Null values.

After some investigation I learned that the owner of the BAMPrimaryImport database needed to be a domain account. I tried to change the account role:

sp_addrolemember 'dbowner' 'domain\user'

This failed with an error.

So I ran instead (which does not remove the user, just ‘resets’ the users access rights):

sp_revokedbaccess 'domain\user'

Which threw an error, but the account was holding the db owner schema, so I changed that to dbo and it worked.

Then, I could run the original call (which now worked):

sp_changedbowner 'domain\user'

The views are now visible in the portal, so if you see this error above, this may be the cause.

BizTalkCop For Naming Convention Enforcement in BizTalk 2006 and R2

Elton Stoneman has put together an extension to FxCop to assist with the enforcement of naming conventions around BizTalk applications.

The 1.0 release contains a set of FxCop rules for analysis against BizTalk assemblies and BizTalk applications. The rules in the package are configurable, by default they are based on the naming conventions Scott Colestock put out a few years ago.

A detailed usage guide is published here:

http://geekswithblogs.net/EltonStoneman/archive/2008/11/14/introducing-biztalkcop.aspx

An extensive demo of the tool is published here:

http://geekswithblogs.net/benny/archive/2009/03/01/biztalkcop.aspx

You can download the package from CodePlex here:

http://www.codeplex.com/BizTalkCop

Empty Node Gotcha with the Business Rules Engine

I've been on a BizTalk 2006 R2 project where we are using the business rules engine to enrich some data coming from a call center.

The data comes in using the vendor's format and is mapped on the inbound port into a cannonical format to be used internally for processing. Because of the complexity of the vendor's schema, we used some inline XPATH statements in the map to transform the data.

When testing against the endpoint DB2 database, we discovered the database was failing to process the messages, even though everything appeared fine on the surface. After some investigation we discovered some hexidecimal characters in what were supposed to be empty nodes. The characters we saw were representative of a line break and a tab: #xD; and #xA;.

Tracing the steps back, we discovered this was appearing after the Business Rules Engine processed the document.

In a normal map, empty nodes are created as <empty>, but using XPATH we were deriving empty nodes that looked like <empty></empty>, and when this type of node went to the rules engine, it created line breaks.

We needed the empty nodes because the endpoint demanded all the nodes be present, so we had to make an adjustment to the XPATH statements to use something similar to:

<xsl:choose>
<xsl:when test="@@XPATH HERE@@">
<xsl:element name="Empty">
<xsl:value-of select="@@XPATH HERE@@"/>
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:element name="Empty"></xsl:element>
</xsl:otherwise>
</xsl:choose>

Where the choose/otherwise allowed us to create the type of empty node we were looking for.

So, if you find yourself extracting data from the rules engine and these unwanted characters appear, this is one way to solve it.

Using MSBuild Extension Pack with BizTalk 2006

As many of you already know MSBuild is not compatible with BizTalk projects out-of-the-box. This fact can be a hurdle to overcome if Team Foundation Server (TFS) is being used to automate builds. The problem is TFS uses MSBuild exclusively in its build process. The workaround was to use an MSBuild task that called a NANT build to execute the BizTalk implementation. This was clumsy and not intuitive.

To solve this issue a group of developers got together and created the MSBuild Extension Pack Project. The Extension Pack provides MSBuild Tasks for BizTalk 2006, SQL 2005, SQL 2008, among others. Tasks for BizTalk include tasks for checking the existence of an Application, adding/removing References, starting/stopping Applications, and creating/deleting Applications. The Extension Pack includes a help file and samples for all this functionality.

Consuming a Java Web Service (JWS) Method Containing String Arrays as Parameters

Consuming a Java Web Service (JWS) Method Containing String Arrays as Parameters

Recently I was working on a POC where one of the tasks was integrating with a Quality Control application that exposed a web service built with Java. The application used a JWS to expose web service methods that were RPC encoded. BizTalk Server 2006 and Visual Studio 2005 natively recognized and imported the JWS WSDL and generated a multi-part message in the BizTalk project.

Early in the POC, consuming, connecting and executing the process were demonstrated using a JWS method called, Sample Log. There was no issues importing the JWS WSDL but the challenge was populating the message since it used string arrays for parameter names and values.

Multi-part Message Types
The multi-part message type generated by importing the SampleLog WSDL are the last invoke_request and invoke_response in the figure below. We will take a closer look at the invoke_request message because the fieldsArrayC and valuesArray C items for the invoke_request message are actually string arrays. This message structure presents a challenge for BizTalk because although this message type was successfully generated in BizTalk, it was not available for use within the Mapper.

Using and populating the message structure
In order to use and populate the mutli-part message in BizTalk, 3 three messages needed to be defined to get around the limitations of the mapper.
These are:

1. msgLIMSSampleLogRequest - Message that will be sent to the JWS.
2. msgLogSampleReferenceNameArray – An array that contains the names of the parameters passed. This message structure will be added to the msgLIMSSampleLogRequest message.
3. msgLogSampleReferenceValueArray – An array that contains the values of the parameters passed. This message structure will be added to the msgLIMSSampleLogRequest message.
   
   Create Message Variables
   

Orchestration Snippet
Because we can’t use the mapper, an orchestration must be used. In the orchestration, the msgLogSampleReferenceValueArray and msgLogSampleReferenceValueArray needed to be populated using the following code in the Expression Shape of the orchestration.

Once msgLogSampleReferenceValueArray and msgLogSampleReferenceValueArray messages were populated, they could be assigned to the msgLIMSSampleLogRequest message as described in the next section.

NOTE: This code is for demonstration purposes only. An actual implementation would use a component or other solution to populate the array depending on the requirements.

System.Diagnostics.Debug.WriteLine(System.String.Format("{0}{1}: {2}", strInterfaceName, "BuildReferenceArrays", ""));

//Format and Populate ReferenceName
strParameters = System.String.Format("{0},{1},{2},{3},{4},{5},{6},{7}", "LOT", "LOT_NAME", "PRODUCT_GRADE", "DESCRIPTION", "ROLL", "SAMPLING_POINT", "SPEC_TYPE", "GROUP_NAME");
System.Diagnostics.Debug.WriteLine(System.String.Format("{0}{1}: {2}", "strParameters", "strParameters", strParameters));

objXmlDoc1 = new System.Xml.XmlDocument();
objXmlDoc1.LoadXml
(@"

LOT
LOT_NAME
PRODUCT_GRADE
DESCRIPTION
ROLL
SAMPLING_POINT
SPEC_TYPE
GROUP_NAME

");

msgLogSampleReferenceNameArray = objXmlDoc1;


System.Diagnostics.Debug.WriteLine(System.String.Format("{0}{1}: {2}", strInterfaceName, "ReferenceNameArray", objXmlDoc1.InnerXml));

//Format and Populate ReferenceValue
strParameters = System.String.Format("{0},{1},{2},{3},{4},{5},{6},{7}", "89210", "1000222", "40786351", "S 901/ERL 1908 HM", "001", "6351ANYL", "SP_1", "WINONA");

objXmlDoc2 = new System.Xml.XmlDocument();
objXmlDoc2.LoadXml
(@"

89210
1000222
40786351
S 901/ERL 1908 HM
001
6351ANYL
SP_1
WINONA

");

msgLogSampleReferenceValueArray = objXmlDoc2;

System.Diagnostics.Debug.WriteLine(System.String.Format("{0}{1}: {2}", strInterfaceName, "ReferenceValueArray", objXmlDoc1.InnerXml));


Populate Main Message (LogRequest)
The final step is to populate the msgLIMSSampleLogRequest message in an Expression shape. Within the Expression shape the fieldsArrayC element is loaded with the msgLogSampleReferenceNameArray and the valuesArrayC element is loaded with the msgLogSampleReferenceValueArray.

The following is the code snippet that loads the message. The highlighted rows are where the string arrays from the previous step are actually loaded into the main message.

msgLIMSSampleLogRequest.authToken = msgLIMSAuthenticate1Response.authenticate1Result;
msgLIMSSampleLogRequest.templateNameC = "SPEC_IPL";
msgLIMSSampleLogRequest.fieldsArrayC = msgLogSampleReferenceNameArray;
msgLIMSSampleLogRequest.valuesArrayC = msgLogSampleReferenceValueArray;

RFID tags now work on metal

There has been a long standing rumor in the marketplace that RFID tags are not compatible with metal surfaces. While this may have been true at one time, new developments in the technology make this a problem of the past.

A number of vendors now make metal mount RFID tags, this month ODIN technologies has published a benchmark study of different products that are now available in the marketplace which make metal mounting possible.

Many companies who have wanted to utilize RFID have hedged because of this problem. The tags in the study were read in operational settings where metal surfaces such as shelves or server racks were present and potentially inhibit successful tag reads. You can see the study here. In short, the following tags were tested and deemed appropriate for adhesion to metal surfaces:

• Avery Dennison: AD-900, AD-902, AD-908
• Confidex: Halo, Ironside, Steelwave
• Emerson & Cummings: Ecopad
• Intermec: Large Rigid, Small Rigid
• Omni-ID: Flex, Micro, Mini
• Sontec: C0101, P01016BTTROI: MMT-3001, MMT-3004, PC-102

You can read the report here:

Metal Mount RFID Tags Benchmarked By ODIN Technologies