Portable Solutions

There are two simple tricks that will make your TDI solutions more portable:

1. Use forward slash in pathnames
2. Use relative pathnames
   

A forward slash will work on Unix and Windows, whereas backslash is Windows-only. The reason I use relative pathnames is that my ultimate goal is a single zip file distributable.

The Solution Directory is the root for all relative paths. If you look in the ibmdisrv and ibmditk batch-files/scripts used to start TDI, you can see that before the TDI Java executable is launched the current directory is changed to the solution directory (bin/defaultSolDir.bat or .sh).

The CE workspace on the other hand is an Eclipse construct. Since TDI follows the Eclipse Project paradigm, you get a workspace with folders for the various projects, and with sub-directories below these that reflect the onscreen Navigator hierarchy.

All the TDI Server itself really needs is a single XML file that is 'compiled' based on Project assets, and this file is written to the sub-directory of the Project that starts with 'Runtime-'. This is subsequently where the Default test Server loads it from when you Run or Debug your AssemblyLines. You can change this preference in the Project properties by using the Linked File option.

The Runtime folder is also where TDI puts your default Property store (also named after the Project). If you look at the Connector tab for the Property store and click on the label of the Collection/Path parameter, you'll see that this value is tied to a substitution Expression:

{config.$directory}/ProjectName.properties

The substitution token {config.$directory} translates at run-time to 'wherever the TDI Server loaded the Config from'. Filepaths set this way ensure that supporting files need only reside in the same folder as the Config file, wherever that happens to be. As you'll see below, I like to be a bit more explicit.

Armed with this knowledge, let me share how I start new projects. For the sake of illustration I'm going to call this project TDI4SyncService.

1. Make a sub-folder of my Solution Directory named 'TDI4SyncService'.
2. Create the project called TDI4SyncService and set the properties to write the Config file to the folder created in the step above: TDI4SyncService/TDI4SyncService.xml.
   
3. Edit the TDI4SyncService Property store so that the collection/filepath is 'TDI4SyncService/TDI4SyncService.properties"

Now I have a single folder that I can zip down and share. It contains both the Config xml and properties files, plus anything else my solution accumulates during development. I will even store .jar files here if they are project specific, editing the com.ibm.di.userjars property as needed. Plus I can drop in batchfiles/scripts for launching the solution so that TDI skills won't be required to use it.