There are a couple of new questions on the MDM Workbench FAQ which I think it's worth drawing attention to. Making sure you use short and simple install and workbench directory names from the start can save a few headaches later in the set-up process.

On the subject of the FAQ, don't forget that anyone in the MDM Developers group can edit it, so if you have any other tips to share, please do.

What directory names should I use to avoid problems?

There are a number of issues that you may encounter related to the
directories used to install software, as well as your workspace
location. For example:

Long path names

Directory names which contain special characters, such as the $ symbol
This can be a particular issue on Windows 7 where the default install location may include '(86)'

To avoid these problems, you should use short, simple, directory names. For example:

C:\IBM\SDP

C:\IBM\MDMWorkspace

Why does testing the database connection cause an error?

You may see the following error when using the "Test Connection" button:

Input Error

... db2ValidateDBName.log (The system cannot find the file specified).

This problem can occur for a couple of reasons: either the RSA
install directory contains special characters (see details above) or the system path environment variable has exceeded the Windows limit.
If the directory name is not the problem, check whether 'db2' can be
found on the path using the Windows Command Prompt. You will see the
following message if the DB2 path entries are not being picked up
correctly:

'db2' is not recognized as an internal or external command,operable program or batch file.

You can work round the Windows environment variable limit by moving
the DB2 path entries to the front of the system path before re-starting
RSA and trying the setup again.

In some situations you might want to use a remote server for testing while developing an MDM application, instead of configuring a local MDM database and server environment. To get started you only need to run the Prepare > Import Application Projects into Workbench step of the development and test environment wizard. Once you have the MDM projects in your workspace you can begin developing as normal, however there will be more manual steps required when you need to test your application. You'll need to have installed MDM Server to use as a remote test environment, for example I installed on AIX with DB2 and a WebSphere server. Once you have successfully installed your server, the following tips should help make it slightly easier to work with
the remote database and application server from within the MDM
Workbench.

To start with, you can create a new entry in the Servers view to connect to the remote application server. Open the Servers view, right click in the view and choose New > Server. Enter the address of your remote server and select the correct server type and runtime, for example:

You'll need to configure the connection settings with the right port numbers on the next page. I was using the default ports but use the Test Connection link to confirm everything is configured correctly:

Click finish to add the new connection to the Servers view.

In a normal workbench development environment, the local server is configured to use the contents of the CustomerResources project directly, so changes get picked up without any manual intervention. With a remote server however, you'll need to handle the process of updating DWLSchemas.jar and properties.jar before deploying the application. Also, because you didn't run the Prepare > Customize Configuration Files step of the set up wizard, there will be place holders in the .properties files. Instead of manually updating all the place holders for the target server, I used the administration console to export the deployed ear and extract the properties.jar file. You can get to the administration console by right clicking on the server that was configured above, and selecting Administration > Run administration console. Find the MDM application and export it as shown:

You can then extract the properties.jar which will contain all the right settings for the remote server. I used the following command:

jar -xvf MDM-App.ear properties.jar

Finally, it's useful to have a database connection to run any SQL that's generated for your module projects. There should be a Data Source Explorer view in the Data perspective. Right click on Database Connections, click New... and enter the connection parameters for the remote MDM database. For example, these were my settings:

Once everything is set up, the development process is not that different to using a local test server. Just don't forget to package up the contents of CustomerResources before deploying the application!

This article, which was previously available in a preview draft on the MDM Developers group as MDM Workbench Project Best Practices & Performance Tuning Guide, captures real world experiences taken from successful
projects that have been executed using the MDM Workbench. By utilizing
the experiences taken from using the MDM Workbench on a number of
different projects this article aims to recommend best practices and to
identify common pitfalls when using the tools and how to avoid them.

Take a look to find out about all the components available in the workbench, how structure and run your projects, along with tips to get the most out of the workbench in a team environment.

Testing the database connection in the Development and Test Environment wizard can cause Rational Software Architect to stop responding. This is occurs when one of the scripts running under the covers picks up the wrong find command. The problem is typically because something like MKS Toolkit is installed, which includes its own version of the find command. You may not have installed MKS Toolkit manually, for example DataStage Designer installs MKS Toolkit automatically. The simplest way to check if this is the case, is to run the find command directly and check the output. You can use the start > Run... menu option to open a Command Prompt; type cmd in the Open box and press OK. You should see the following output when you run the find command:

If you see a different response, the Development and Test Environment wizard will fail when you try to test the database connection. To get round this problem you should modify the PATH environment variable so that the folder containing the default Windows find command is before any others. The article, "How To Manage Environment Variables in Windows XP" describes how to modify environment variables on Windows XP. The correct find command is in the same folder as cmd.exe, which you used above. This folder will already be in the PATH, but you need to move it to the beginning so that is checked before any of the other folders. This change will cause problems for any software relying on the the PATH to locate the alternative find command, so I recommend taking a copy of the PATH setting before you change it, then restoring the original settings after you have successfully set up your development environment.