Wednesday, September 05, 2007

I was able to use the XML sample documents that come with eConnect (C:\Program Files\Microsoft Great Plains\eConnect9\XML Sample Documents\Incoming) to write some test data into my GP database using the eConnect 9.0 adapters for BizTalk Server 2006.  I setup a test environment using the TWO database for Great Plains, and through the adapter was able to insert data.  Feeling that I had made some good progress, I shutdown my machine (they are all virtualized environments) and went home for the night.

When I started everything up the next day I tried to reproduce this behavior so that I could move on with my integration.  However, every time I tried to write the document into GP through the adapter, I got the following error:

BizTalk DW Reporting

Event Type:    Error
Event Source:  BizTalk DW Reporting
Event ID:      1000
Description:   Faulting application btsntsvc.exe, version 3.5.1602.0, stamp 4410e6b9, faulting module kernel32.dll, version 5.2.3790.4062, stamp 46264680, debug? 0, fault address 0x0000bee7.

This had me stumped for a little while.  I decided to use a useful tool I received from Microsoft called the Direct Document Sender.NET (I've attached the file at the bottom of this post) to try and diagnose the problem.  This tool allows you to post an XML document directly to eConnect so that you can test out the functionality without any 3rd party application (e.g. BizTalk Server).

Using this application, I tried to post the XML file again.  This time I received a much more useful error:

System.Runtime.InteropServices.COMException (0x8000401A): The server process could not be started because the configured identity is incorrect.  Check the username and password.

Aha!  This was a much more useful error!

I opened up Component Services (Start --> Administrative Tools --> Component Services), and browsed to Computers --> My Computer --> COM+ Applications --> eConnect 9 for Great Plains.  The Microsoft Great Plains eConnect Version 9 COM Plus Package has a tab entitled Identity which allows you to define the user account under which the application runs.  Turns out that somehow my account was switched from the user I specified at installation to the interactive user system account:

Component

And this was the root cause of my problem.  eConnect requires integrated security and uses the user specified in this identity tab to access the GP database.  Consequently, the user specified must have access to the appropriate database on the GP server and also be a part of the DYNGRP role.

So, I went ahead and added my user to the DYNGRP role, made sure it had the appropriate access, and then updated account used by the COM+ package:

Component2

Having made these changes, I tested with the Document Sender.NET application - worked the first time!  Confidently I tested with BizTalk, and sure enough everything started to work!

I'm not sure why it initially worked and then stopped working after I restarted the machines.  I'm not sure if the account credentials changed or if something else was happening the first time.  All I know is that you have to use an appropriate user that has access to the database and is a member of the appropriate role, otherwise you'll get the errors I listed above.

I hope this helps!

DirectDoc9.zip (7.42 KB)

Posted on 09/05/2007 # Comments [0] Trackback
 Thursday, August 16, 2007

I got caught up yesterday with a problem I should have recognized right away, but for whatever reason I didn't put the pieces together until it was pointed out by one of my co-workers.

I was writing a BizTalk Server 2006 orchestration that, amongst other things, sends a request to a remote server.  The remote server has an application installed that accesses these requests and initiates a few local (and unimportant) processes.  Information is passed to this application via the URL which is unique with each request and constructed by the orchestration.

Rather than use a dynamic one-way send port with the HTTP adapter, I decided to create a .NET helper project (a C# class library) and create a static method that allows me to pass in the URL and wait for a response.  The contents of the response itself is unimportant; all I require is a successful response.

I created the following class in my helper project (simplified for clarity):

using System;
using System.Collections.Generic;
using System.Text;
using System.Net;
namespace Messaging.Helper
{
    [Serializable]
    public class Statics
    {
        public void CallUrl(string url)
        {
            WebRequest request = WebRequest.Create(url);
            request.Method = "GET";
            request.GetResponse();
        }
    }
}

As you can see, the static method uses the System.Net.WebRequest class to issue a request to the specified URL.  To test this method, I created a command-line application that iterated 20 or so times and issued requests against the remote server.  The code was similar to the following (simplified for clarity):

using System;
using System.Collections.Generic;
using System.Text;
using System.Net;
using Messaging.Helper;

namespace Messaging.ConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            for (int i = 0; i < 20; i++)
            {
                Statics.CallUrl("http://www.someurl.com/");
            }
        }
    }
}

I immediately noticed that this code failed after it issued two concurrent requests.  No matter how many times I ran it, it always was successful the first two times and then timed-out and threw an error message similar to the following:

System.Net.WebException was unhandled
 Message="The operation has timed out"
 Source="System"
 StackTrace:
  at System.Net.HttpWebRequest.GetResponse()
  at ConsoleApp.Program.Helper.CallUrl() in D:\Test\ConsoleApp\Program.cs:line 41
  at ConsoleApp.Program.Main(String[] args) in D:\Test\ConsoleApp\Program.cs:line 20
  at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args)
  at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
  at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
  at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
  at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
  at System.Threading.ThreadHelper.ThreadStart()

Yes, I should have immediately picked up on the fact that it succeeded the first two times but then consistently failed on each additional request.  Instead, I tried all kinds of different scenarios (non-static methods, multi-threaded calls, etc.).  Fortunately, a co-worker stopped by and reminded me that, by design, there is a limit on the number of connections you can have to any given server.  By default, this limitation is set to two!

As soon as he said that I remembered the limitation (I guess I still have a few neurons that occasionally fire).  Immediately I created an application configuration file for my command-line application and added the following (of course, I had to look-up the exact syntax):

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.net>
        <connectionManagement>
            <add address="*" maxconnection="100" />
        </connectionManagement>
    </system.net>
</configuration>

This allows for up to 100 simultaneous connections to any server.  When I ran my command-line application again it worked perfectly -- 20 requests were issued to the URL.

After poking around a little bit, I found the actual specification in the HTTP/1.1 protocol that dictates this limitation.  See Hypertext Transfer Protocol - Section 8.1.4:

"Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion."

Ah, this explains why Internet Explorer only allows me to download two files at the same time!

Now, in order to allow my BizTalk orchestration to proper issue more than two concurrent connections (remember, it too is just calling .NET code), I needed to modify the BTSNTSvc.exe.config file that services the BizTalk host instances.  This file is found in the BizTalk Server directory under Program Files:

BTSNTSvc.exe.config

Simply add the <system.net> ... </system.net> XML to the configuration file and then restart your host instances.  This will allow you to issue more than two concurrent requests to any given web server.

I hope this helps save you some time you would have otherwise lost!

Posted on 08/16/2007 # Comments [6] Trackback
 Monday, August 13, 2007

I came across a frustrating interesting problem today where the BizTalk Server 2006 Configuration wizard would fail every time I applied a new configuration.

Unlike a typical BizTalk developer environment (which usually consists of BizTalk and SQL Server on the same machine), this environment consisted of two separate machines: one BizTalk Server 2006 and one SQL Server 2005 (i.e. the BizTalk databases are stored on the SQL Server).  Additionally, this is a virtual environment and both machines were cloned from the same base Windows Server 2003 R2 template.

I was installing the following components ...

  • Enterprise Single Sign-On (SSO)
  • Group
  • BizTalk Runtime
  • MSMQT

It would successfully install ENTSSO, but would fail when installing the group.  The log file reported the following error:

Failed to configure with error message [Exception of type 'System.EnterpriseServices.TransactionProxyException' was thrown.]

The following Google search suggested to me that  the underlying problem was with MSDTC (aren't all BizTalk problems?).  I checked, and double-checked, the MSDTC properties on both servers and couldn't find anything wrong with the configuration.  So, I had to pull out the big guns.

I downloaded DTCPing (a very handy tool for debugging DTC issues) and ran it on both machines (make sure to read the instructions on how to use DTCPing as it is not straightforward).  In the generated log file I noticed the following warning:

WARNING: the CID values for both test machines are the same while this problem won't stop DTCping test, MSDTC will fail for this ...

A Google search on this warning helped me to understand that the underlying problem is that the CID values stored for MSDTC were not changed during the cloning process.  But of course!

If you're experiencing this problem, check the following registry key on both of your machines.  Are the keys identical?

HKEY_CLASSES_ROOT\CID

Mine were.  Here's the steps I took successfully reinstall MSDTC so that the CID values were unique.  Run this procedure on both machines:

  1. Use Add Windows Components, and remove Network DTC.
  2. Go to the command line and run: MSDTC -uninstall
  3. Go to the registry and delete the MSDTC keys in HKLM/Software/Microsoft/Software/MSDTC, HKLM/System/CurrentControlSet/Services/MSDTC, and HKEY_CLASSES_ROOT\CID (if they're still there).
  4. Reboot
  5. Go to the command line and run: MSDTC -install
  6. Use Add Windows Components, and add Network DTC.
  7. Go to the command line and run: net start msdtc

After running this on both servers I was able to confirm that the CID values were unique.  And, sure enough, when I next applied my configuration to BizTalk Server 2006 everything worked perfectly.

I hope this helps!

Posted on 08/13/2007 # Comments [8] Trackback
 Thursday, July 05, 2007

I've started working on a project that integrates into Great Plains 9.0 using eConnect.  Not having done this using BizTalk Server 2006, I thought I'd document some of my observations and the steps I took.

To begin, I was able to get eConnect for GP (en_econnect_for_gp.zip) through my MSDN subscription.  If you have Great Plains 9.0, then you should be able to get your hands on this package.  When you unzip the package, you'll notice two files:

  • eConnectInstallAdminGuide.pdf - This is a great document that, if you are going to interact and develop with eConnect, I highly encourage you to read.  There are three parts: eConnect Basics, Installation, and Administration.  At the very least, developers should reach the first part, which includes an overview and architecture chapter.
  • Microsoft_Business_Solutions_eConnect.msi - This is the actual installation file.  Note: it contains MUCH more than just the BizTalk Server adapters.

After reading through the eConnect guide, I ran the installation MSI file.  A few highlights / comments:

  • I chose the "Custom" setup.  I never choose Standard or Complete.
  • My sole purpose at this point is to install the BizTalk adapter with the eConnect schemas; follow the administration guide, instead of this post, if you're setting up for production.
  • There are a lot of features, including:
    • BizTalk Components - both 2004 and 2006
    • Business Objects - installs the Business Objects into SQL Server
    • COM+ Components - installs COM components and .NET assemblies
    • eConnect Incoming Service - incoming eConnect Win32 service
    • eConnect Outgoing Service - outgoing eConnect Win32 service
    • eConnect Replication Service - eConnect Win32 replication service
    • eConnect Help - help
    • eConnect Samples - .NET and VB6 examples
    • Queue Control - view documents in MSMQ queue
    • Schemas - eConnect XSD and XDR schemas
  • Not knowing any better, I decided to only include the following features:
    • BizTalk Components
    • eConnect Help
    • eConnect Samples
    • Schemas

Once you have installed eConnect 9.0, you must still install the adapters for BizTalk Server.  Browser to the following folder: C:\Program Files\Microsoft Great Plains\eConnect9\BizTalk\BizTalk 2006\ (obviously, choose \BizTalk 2004\ if  you are using 2004).  From here you can run the BTS_eConnectAdapter.msi file and install the BizTalk Server 2006 adapter.

Once the installation for the adapter is complete, make sure you update your platform settings and add the adapter.  Follow these steps:

  1. Open the BizTalk Server 2006 Administration Console.
  2. Go to BizTalk Group -> Platform Settings -> Adapters.
  3. Right-click the Adapters folder, and select New -> Adapter.
  4. Enter a name for the adapter (e.g. eConnect) and select the "Dynamics GP eConnect" adapter from the adapter list.
  5. Click OK.  Make sure you restart your host instances.

Pretty simple and straightforward.

Now, browse to the following folder: C:\Program Files\Microsoft Great Plains\eConnect9\XML Schemas\.  Here you will notice all the XDR and XSD schemas.  In particular, the "Incoming XSD Individual Schemas" and the "Incoming XSD Schemas" folders.  The first has every schema in an individual XSD, whereas the second has them all in an eConnect.xsd file.  Depending on you circumstances, you can import these schemas into your BizTalk projects, so that you can utilize them in Orchestrations, maps, or whatever else you choose.  Additionally, once you deploy your projects assemblies, the schemas will be available within your BizTalk solution.

And finally, one other folder you may want to look at is C:\Program Files\Microsoft Great Plains\eConnect9\XML Sample Documents\Incoming\.  This folder has a number of sample XML documents that you can use for testing.  VERY useful stuff here!

Just a few things I've learned and observed while getting all this configured.  I'm sure I'll post more as I continue to use the eConnect adapter.

I hope this helps!

Posted on 07/05/2007 # Comments [1] Trackback

I just recently started a new BizTalk Server 2006 project in which I created a custom pipeline component to assist in the compression and decompression of messages.  The plan is to have a receive location monitor a folder via the File adapter, and when a zip file is uploaded via FTP from a 3rrd party process, the receive location will use the custom pipeline component , via a receive pipeline, to decompress the file and publish the message to the MessageBox.  Pretty slick!

See the WingtipToys solution in the SDK folder for a great heads-start to creating a compression / decompression pipeline component.  You can find this solution in the following folder: C:\Program Files\Microsoft BizTalk Server 2006\SDK\Scenarios\PM\.

So, to get this rolling, I added a C# project to my BizTalk solution.  There are few things I configure on these C# library projects, as I need to utilize the output assembly in my Pipelines BizTalk project.

  1. Set the build output path to the following location (for the Debug configuration): C:\Program Files\Microsoft BizTalk Server 2006\Pipeline Components\.  This way, every time the project is built, the debug assembly is placed in the Pipeline Components folder.  From here, you can then reference the pipeline component appropriate through both Visual Studio 2005 (for your receive pipeline) and when you deploy it to BizTalk Server.
  2. Uncheck the "Build" checkbox, for the C# library project, in the Solution Configuration.  This way, when you rebuild or deploy the solution, the C# library project isn't also rebuilt.  The reason is that you will most likely get errors or warnings indicating that the file is in use, and cannot be rebuilt.  This is fine - you can simply do this manually.

Having made these changes, you now have a pretty flexible setup for moving forward.

When you reference the custom pipeline component assembly, you'll want to reference the assembly that has been built in the C:\Program Files\Microsoft BizTalk Server 2006\Pipeline Components\ folder.  This way, when you deploy your receive or send pipelines, BizTalk will continue to reference the same assembly.

However, having referenced this assembly, you will see these warnings the next time you build your solution:

------ Build started: Project: BizTalkApp, Configuration: Development .NET ------
Updating references...
The dependency 'Microsoft.BizTalk.Tracing' could not be found.
The dependency 'Microsoft.BizTalk.Bam.EventObservation' could not be found.
The dependency 'Microsoft.BizTalk.Streaming' could not be found.
The dependency 'Microsoft.BizTalk.XPathReader' could not be found.
Performing main compilation...

While these warnings are harmless, they are annoying.  In order to "suppress" these warnings, select the referenced custom pipeline component assembly, and set Copy Local from True to False.  Once you do this, these warnings will disappear.

I hope this helps!

Posted on 07/05/2007 # Comments [0] Trackback
 Friday, May 18, 2007

The Commerce Server team has released four white papers outlining how to use the Commerce Server adapters to export a product catalog, export an inventory catalog, export new orders, and export user profiles.  If you are attempting to use the adapters (or even thinking about it), I highly encourage you to take a look at these white papers.  If nothing else, they will give you a good overview of how you can make use of these adapter (I've been wanting to blog on them for awhile now, but haven't found the time).

In this lab, you will use the Microsoft Commerce Server 2007 Catalog adapter with Microsoft BizTalk Server 2006 to export a catalog from the Commerce Server 2007 Starter Site to the CSharp Site.

In this lab, you will use the Microsoft Commerce Server 2007 Inventory adapter with Microsoft BizTalk Server 2006 to export an inventory catalog from the Commerce Server 2007 Starter Site to the same inventory catalog within the CSharp Site.

In this lab, you will use the Microsoft Commerce Server 2007 Orders adapter with Microsoft BizTalk Server 2006 to export new orders from the Commerce Server 2007 Starter Site to a specified file directory.

In this lab, you will use the Microsoft Commerce Server 2007 Profiles adapter with Microsoft BizTalk Server 2006 to export new user profiles from the Commerce Server 2007 Starter Site to the CSharp Site.

Good luck!

Posted on 05/19/2007 # Comments [1] Trackback
 Thursday, May 10, 2007

I learned a new twist to the following error message today:

The adapter "SQL" raised an error message. Details "Unable to enlist in the transaction. (Exception from HRESULT: 0x8004D00A)".

This can occur in a scenario where your BizTalk server attempts to connect to a separate SQL Server database and execute a distributed transaction.  In order for this to work the BizTalk server must have the ability to "hand-off" the transaction to SQL Server.  Typically, when you receive this error, it's because the Distributed Transaction Coordinator (DTC) service is disabled or network DTC access is disabled.  These are the default settings in Windows Server 2003.  Take a look at the following article:

http://support.microsoft.com/?kbid=816701

There's an additional twist to this scenario.  I found myself in a situation where I was receiving this error but had DTC setup correctly on all the machines in my BizTalk group and SQL Server cluster.  Nevertheless, the distributed transactions failed.  Then I found the following article:

http://msdn2.microsoft.com/en-us/library/aa561924.aspx

Turns out that, in order for DTC to work, the SQL Server must be able to resolve the NetBios name of the client (the BizTalk servers, in this case).  If it cannot resolve the NetBios name the transaction will fail.  In my environment, a firewall prevented the ability to resolve the NetBios name to an IP address thereby preventing the distributed transaction from processing.

To resolve this, I updated the HOST files on the SQL Server cluster so that they were able to resolve the NetBios names to an IP address.  Literally, moments after saving the HOST file, all my records started getting written into the database.

As I said, a different twist to a common problem.

I hope this helps!

Posted on 05/10/2007 # Comments [1] Trackback
 Friday, May 04, 2007

As I mentioned in a previous blog, I've been setting up BizTalk 2006 in a 64-bit Windows Server 2003 environment.  This BizTalk solution communicates to AS/400 and Oracle, so I've been using the Microsoft BizTalk Adapters for Enterprise Applications (for Oracle connectivity) as well as Microsoft BizTalk Adapters for Host Systems (for AS/400 DB2 connectivity).

Setting up these adapters has not gone extremely well in the 64-bit O/S (whereas a 32-bit O/S is quite simple to configure).  I've been set back about a week because many different issues related to the 64-bit environment (and a few other issues).  In this post, I want to explain the issues I've encountered with regards to the Oracle adapter in a Windows Server 2003 64-bit environment.

This post assume that you've already installed your Oracle client.  Check out my post Using the "ODBC Adapter for Oracle Database" in BizTalk 2006 for information on how to install the client.  However, if you're installing on a 64-bit machine, stop after you install the client.  The 64-bit world is quite different ...

1. Install the .NET Framework 1.1 and SP 1.

The Oracle adapter requires the .NET Framework 1.1 and SP 1.  My 64-bit environment didn't have the .NET Framework 1.1 installed, so this was an additional step I had to take.  This was the easiest of all the steps I had to take ...

2. Create the ODBC connection.

Turns out that you cannot simply run Data Sources (ODBC) from Administrative Tools.  You have to run %WINDIR%\SysWOW64\odbcad32.exe, which invokes the 32-bit version of the Data Sources (ODBC) GUI.  See my post Adding ODBC connections in Windows Server 2003 64-bit for more information.

3. Install the Microsoft BizTalk Adapters for Enterprise Applications.

I only installed Oracle (r) Database.  Surprisingly, with the .NET Framework 1.1 and SP 1 installed, this goes very well.

4. Update registry settings for the Microsoft BizTalk Adapters for Enterprise Applications.

Turns out that some of the registry keys that are written during the installation are wrong (or rather, they're not interpreted correctly).  Browse to the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\BizTalkAdapters.  Two of the values, InstallDir and InstallPath, need to be changed.  Do the following:

1. Change InstallDir from "C:\Program Files (x86)\Microsoft BizTalk Adapters for Enterprise Applications" to "C:\Progra~2\Microsoft BizTalk Adapters for Enterprise Applications".

2. Change InstallPath from "C:\Program Files (x86)\Common Files\Microsoft BizTalk Adapters for Enterprise Applications\" to "C:\Progra~2\Common Files\Microsoft BizTalk Adapters for Enterprise Applications\".

Yes, for some reason, you have to change "Program Files (x86)" to "Progra~2", probably because the Adapter isn't written very well.  If you don't update these registry settings, you will most likely get the following error:

The description for Event ID ( 0 ) in Source ( Microsoft BizTalk Adapters for Enterprise Applications ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event:     Exception occurred:
            Error Code: 12154 (0x2f7a)
        08004 : [Oracle][ODBC][Ora]ORA-12154: TNS:could not resolve service name.

5. Update additional registry settings to fix permission errors if you are using domain groups for authentication.

Your domain groups will not have access to the Oracle adapter by default.  In order to allow the runtimeagent.exe (which is the executable that is spawned and runs the Oracle adapter) to run appropriately, it needs to be able to access a registry key.  See the following article for more information: http://support.microsoft.com/?id=923650.

Do the following to resolve this issue (from the article):

1. Locate the following registry key: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\BizTalkAdapters\Config

[** Thanks to Steef-Jan Wiggers for noting that I forgot to display the 32-bit path in the Wow6432Node key]

2. Right-click the registry key that you located in step 1, and then click Permissions.

3. On the Security tab, click Add.

4. Type the domain group or the domain user account that is configured as the BizTalk host instance, and then click OK.

5. On the Security tab, click the domain group or the domain user account that you added in step 4, click to select the Read check box, and then click OK.

If you don't update these registry settings, you will most likely get the following (unhelpful) error:

"RuntimeAgent: Error trapped in constructor: No connection could be made because the target machine actively refused it"

Error transmitting message: No connection could be made because the target machine actively refused it

6. Update the security permissions on your Oracle folder.

This is the most bizarre step of all, and it's not particular to the 64-bit environment.  Oracle software requires that you give the Authenticated User privilege to the Oracle Home.  In most cases, your Oracle agent will not be the Administrator account (or at least, I hope it's not).  However, there seems to be an issue with the permissions associated to Authenticated Users.  Consequently, the agent you specify to run the Oracle "runtimeagent.exe" is unable to gain access to the folder.  You might see the following error:

IM003 : Specified driver could not be loaded due to system error  5

To resolve this problem, you have to do the following:

1. Log on to Windows as a user with Administrator privileges.

 

2. Launch Windows Explorer from the Start Menu and and navigate to the ORACLE_HOME folder. This is typically the "Ora92" folder under the "Oracle" folder (i.e. D:\Oracle\Ora92).

 

3. Right-click on the ORACLE_HOME folder and choose the "Properties" option from the drop down list. A "Properties" window should appear.

 

4. Click on the "Security" tab of the "Properties" window.

 

5. Click on "Authenticated Users" item in the "Name" list (on Windows XP the "Name" list is called "Group or user names").

 

6. Uncheck the "Read and Execute" box in the "Permissions" list under the "Allow" column (on Windows XP the "Permissions" list is called "Permissions for Authenticated Users").

 

7. Re-check the "Read and Execute" box under the "Allow" column (this is the box you just unchecked).

 

8. Click the "Advanced" button and in the "Permission Entries" list make sure you see the "Authenticated Users" listed there with:

 

Permission = Read & Execute

Apply To = This folder, subfolders and files

 

If this is NOT the case, edit that line and make sure the "Apply onto" drop-down box is set to "This folder, subfolders and files". This should already be set properly but it is important that you verify this.

 

9. Click the "Ok" button until you close out all of the security properties windows. The cursor may present the hour glass for a few seconds as it applies the permissions you just changed to all subfolders and files.

 

10. Reboot your computer to assure that these changes have taken effect.

Yes, I was in as much shock as you are.  Uncheck a flag, and then re-check it.  I lost almost three days because of this bug.

That's about it!  A series of (mostly) undocumented steps that are required in order to get the Oracle adapter to function in a 64-bit environment.  Fortunately, I had some great support from the escalation engineer's with the Microsoft Product Support Services group.

 

I hope this post helps someone else avoid much of the pain and agony I had to go through ...

Best of luck!

Posted on 05/04/2007 # Comments [5] Trackback
 Thursday, May 03, 2007

We've been deploying a BizTalk 2006 solution to a x64 system and, while BizTalk 2006 itself has no problems, I've had a lot of problems related to the BizTalk Adapters for Host Systems and the BizTalk Adapters for Enterprise Applications.  I plan to write a number of posts in the near future discussing these problems (once we have them all resolved).  In the meantime, I wanted to share this little tidbit I've learned about ODBC on 64-bit windows.

It's important for you to know if your application is going to run as a 32-bit or 64-bit application.  There are two different repositories for ODBC connections, based on the drivers you've installed and the client that will run them.  32-bit applications will only see ODBC connections from the 32-bit side, and 64-bit applications will only see ODBC connections from the 64-bit side.

32-bit applications register ODBC connections to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI

64-bit applications register ODBC connections to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI

Adding these keys is initially tricky, but if you understand the above then it should make sense.  Typically, you go to Start --> Administrative Tools --> Data Sources (ODBC) to create your ODBC connections.  And this is fine if you want to create 64-bit ODBC connections.  Any ODBC connection created using the Data Sources (ODBC) link will get created in the HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI key.  This is because it calls the program %WINDIR%\System32\odbcad32.exe.  However, this program will not create 32-bit ODBC connections.

To create 32-bit ODBC connections, you have to run %WINDIR%\SysWOW64\odbcad32.exe.  Adding an ODBC connection through this application will create the ODBC connection in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI key, and allow your 32-bit applications to see and use the ODBC connection.

I'm still getting used to the concept of WOW and how it runs 32-bit applications on an x64 system.  This information may not be news to some of you, but it presented a challenge to me.

I hope this helps!

Posted on 05/03/2007 # Comments [4] Trackback
 Thursday, April 26, 2007

I built an XPath expression to extract the contents of an XML element.  I tested this XPath in a utility I created that executes the expression, and writes the results to the file system.  The XPath expression worked perfectly, and returned the contents of the XML element.  Here's a quick and dirty example ...

My XML file:

<ns0:Example xmlns:ns0="http://example/">
 <ns0:Contents>1169861</ns0:Contents>
</ns0:Example>

And my XPath expression:

/*[local-name()='Example' and namespace-uri()='http://example/']/*[local-name()='Contents' and namespace-uri()='http://example/']/text()

(Don't forget the "/text()" at the end, or you'll get the entire element!)

And, using my utility, I get the following (expected!) output:

1169861

However, when run in BizTalk 2006, I got that ever-so-annoyingly-generic error message:

Object reference not set to an instance of an object.

I confirmed that this error occured when I set my orchestration's local numeric variable equal to the the following expression in my BizTalk orchestration:

xPathExpression = "/*[local-name()='Example' and namespace-uri()='http://example/']/*[local-name()='Contents' and namespace-uri()='http://example/']/text()";

contents = xpath(msgExample, xPathExpression);

What gives?  The XPath expression works perfectly in my utility, but it doesn't in a BizTalk orchestration?  So, I decided see if I could find any help on Google.  No joke, I searched for "biztalk xpath gotcha" and found Aaron Saikovski's blog detailing this problem.  His note indicated that, in BizTalk 2004, you had to wrap your XPath expressing with string()!  It's that simple.  So, changing my XPath to the following ...

xPathExpression = "string(/*[local-name()='Example' and namespace-uri()='http://example/']/*[local-name()='Contents' and namespace-uri()='http://example/']/text())";

... saved the day!

What a fun quirk!  Thanks Aaron!

Posted on 04/26/2007 # Comments [0] Trackback
 Wednesday, April 18, 2007

So, I was having fun building some Orchestrations and Pipelines in BizTalk 2006, when all of a sudden I started getting some awful errors when I went to deploy from Visual Studio 2005.  Here are the errors I received:

Object reference not set to an instance of an object.
 
at Microsoft.BizTalk.Deployment.BizTalkAssembly.GetConnectedPorts(BtsCatalogExplorer explorer, String pipelineFullyQualifiedName)
   at Microsoft.BizTalk.Deployment.BizTalkAssembly.RemovePortsUsingPipelines()
   at Microsoft.BizTalk.Deployment.BizTalkAssembly.RemovePipelines()
   at Microsoft.BizTalk.Deployment.BizTalkAssembly.Remove()
   at Microsoft.BizTalk.Deployment.BizTalkAssembly.RemoveNamedModule(String server, String database, String assemblyName, String assemblyVersion, String assemblyCulture, String assemblyPublicKeyToken, ApplicationLog log)
 
Unspecified exception: "Object reference not set to an instance of an object."

Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Object reference not set to an instance of an object. 

All I did was update a pipeline that was used by an Orchestration!  I tried all kinds of things to get this to work: restarted host instances, restarted the Enterprise Single Sign-On service, performed a full stop on all my applications, and even deleted all my project assemblies from the GAC.  Nothing worked except for rebooting.

That is, nothing worked until I decided to actually delete the pipeline from BizTalk application.   Once I manually deleted the pipeline, my deployments started working again.

Very strange behavior!

If anyone can explain to me why BizTalk behaves this way, I would greatly appreciate it.

Posted on 04/18/2007 # Comments [1] Trackback
 Thursday, March 15, 2007

I recently found myself in a situation where I had to change the computer name of a machine I had configured as a BizTalk 2006 server.  The machine was actually a virtual machine that was going to be used for development, and we made numerous copies for all the developers.  Consequently, each developer needed to have a computer with a unique name.

After researching the appropriate way to do this, all I could find were very manual steps.  For instance, here are some of the intial things I tried:

Note: I do NOT recommend using this approach.

  • Rename the computer
  • Add a host entry to the old computer name; add a SQL alias for the old computer name
  • Execute the following in SQL: sp_dropserver [computerName]
  • Drop and recreate all SQL logins
  • Update the following registry keys
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0\Administration\MgmtDbServer
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BusinessRules\3.0
  • Update the following database tables
    • BizTalkHWSDb.HWS_Core
    • BizTalkMgmtDb.adm_MessageBox
    • BizTalkMgmtDb.adm_OtherDatabases
    • BizTalkMgmtDb.adm_Group
    • BizTalkMgmtDb.adm_Server
    • BizTalkMgmtDb.TDDS_Sources
    • BizTalkMgmtDb.TDDS_Destinations
  • Run the following command: ssoconfig -setdb computerName SSODB

While this worked, it was NOT an ideal solution.  I still noticed a few issues in the BizTalk configuration, etc. 

Once I had a night to think about this, I realized that there's a MUCH easier way to go about doing this.  Here's the process:

  1. Unconfigure the current BizTalk configuration via BizTalk Server Configuration.  This essentially removes all the existing BizTalk databases.
  2. Go to MSSQL, and delete all the BizTalk databases and SQL logins
  3. Change the computer name, and restart.
  4. Run the following two commands in MSSQL
    1. sp_addserver [newComputerName]
    2. sp_dropserver [oldComputerName]
  5. Configure a new BizTalk configuration via BizTalk Server Configuration
  6. Go into BizTalk Server Administration and remove the old BizTalk group, and add the new BizTalk group.

This solution has worked perfectly for our development environments.

Best of luck!

Posted on 03/15/2007 # Comments [1] Trackback
 Wednesday, March 14, 2007

I have been studying for the MS exam 70-235: Developing Business Process and Integration Solutions Using Microsoft BizTalk Server for the past couple months.  Finding resources for this exam has been difficult, but I've found a few that were helpful.  I was fortunate enough to take the following two Microsoft courses:

  • Course 2933: Developing Business Process and Integration Solutions Using Microsoft BizTalk Server 2006
  • Course 2934: Deploying and Managing Business Process and Integration Solutions Using Microsoft BizTalk Server 2006

Additionally, I purchased the book:

  • Pro BizTalk 2006, by George Dunphy and Ahmed Metwally (Apress, 2006).  Of the few BizTalk 2006 books on the market, I found this to be the best.

Also, I made use of MSDN, various BizTalk blogs and forums, and all kinds of other online material.

In the end, I decided to compile a list of the various topics I thought would be useful.  A colleague of mine (Mathew Shuster, an incredible BizTalk resource) suggested that I make sure to focus on both BAM (Business Activity Monitoring) and correlations.

So, here's the list of topics I put together:

  • Correlations
  • BAM (Business Activity Monitoring)
  • Business Rule Engine / Business Rule Composer
  • Group Hub page
  • HAT
  • Hub and Spoke model
  • EAI versus ESB
  • Persistence points
  • Atomic transactions
  • Role Links
  • BizTalk Tracking continuation
  • BizTalk Groups
  • Interchanges
  • Tracking Profile Editor
  • BizTalk Vocabularies
  • BizTalk Policies
  • Trading Partner Management

(Note: at some point, I'd like to write short articles on all the above topics.)

By no means do I mean to suggest that this list is exhaustive.  Be sure to go to the above Microsoft link to see all the various topics that the exam covers.

As this exam focuses on BizTalk 2006, it's safe to assume that the exam file highlight features new to 2006, as well as try to trip you up with questions that have answers that may have been correct in 2004 but not in 2006.  Be sure to watch out for these kind of questions.

Wish me luck!

----

[Edit: 03/16/2007]

I passed!  While the exam was difficult (took me almost two hours), I definitely found it to be passable.  My two weakest areas (according to my results) were in BAM and the Business Rule Engine.  However, a pass is a pass!! :)

I think everything I previously wrote above still applies.

Posted on 03/15/2007 # Comments [0] Trackback
 Thursday, March 08, 2007