05 December 2010

Mocking BizTalk XLANGMessage Objects

I have a method that checks for a particular node in an XLANGPart message:

bool IsValidReport(XLANGMessage report){
   XLANGMessage message = report as XLANGMessage;

   if (message != null)
   {
       string status = message[0].GetXPathValue("//*[local-name()='ReportStatus']");

       if (status.Equals("COMPLETE"))
       {
           return true;
       }
   }

   return false;
}


This method is called directly from an orchestration. Note that it relies on reading the value of a node called "ReportStatus" inside the first XLANGPart object.
To unit test this method, I mocked the XLANGMessage and XLANGPart objects:


using Microsoft.XLANGs.BaseTypes;
using Moq;
...

Mock<XLANGMessage> xlangMsgMock = new Mock<XLANGMessage>();
Mock<XLANGPart> xlangPartMock = new Mock<XLANGPart>();

xlangPartMock.Setup(p => p.GetXPathValue(It.IsAny<string>())).Returns("COMPLETE");
xlangMsgMock.SetupGet<XLANGPart>(m => m[0]).Returns(xlangPartMock.Object);

bool isValid = ReportManager.IsValidReport(xlangMsgMock.Object);

xlangPartMock.VerifyAll();
xlangMsgMock.VerifyAll();


Here I've mocked the GetXPathValue method to return "COMPLETE" which will make the IsValidReport method return true. I've then attached this XLANGPart mock to the XLANGMessage mock and called the method to test.
Additional unit tests can be mocked to return other status values to simulate other conditions.

01 December 2010

Oracle Data Access in 32 and 64 bit Environments

I've spent the last couple of days struggling with getting my Oracle data access code (which works well on my 32 bit development machine) to play nice in a 64 bit Windows Server 2008 R2 environment. In the end the solution was very straightforward and the code can be compiled using the 32 bit version of the Oracle.DataAccess.dll and configured to run in a 64 bit environment without having to rebuild by editing the configuration file below:
<system.data>
<DbProviderFactories>
<!-- this is the 64 bit version of the Oracle.DataAccess.dll -->
<add name="Oracle Data Provider for .NET" invariant="Oracle.DataAccess.Client"
description="Oracle Data Provider for .NET"
type="Oracle.DataAccess.Client.OracleClientFactory, Oracle.DataAccess, Version=2.111.7.0,
Culture=neutral, PublicKeyToken=89b483f429c47342" />
</DbProviderFactories>
</system.data>

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<!-- redirect all requests for Oracle.DataAccess.dll to the 64 bit version -->
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-100.100.100.100" newVersion="2.111.7.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>

As usual, ensure that the right assemblies are in the GAC.

UPDATE: my colleague was experiencing some unusual behaviour in his development environment and after some investigation, it turns out he installed the wrong Oracle components. If the .NET Oracle component is all you require, then when you are running the Oracle installer, choose the custom option and select the Oracle Data Provider for .NET 2.0 11.x.x.x only. This will install the redirection assemblies into the GAC and the above solution will work.