The Solution Directory is the "current path" whenever you run TDI, either the CE or the Server. This setting is personal to a specific TDI Server. As a result, if you use relative filepaths then your solution is easily moved between TDI Servers. It is also easier to deploy and maintain (cost of ownership), as well as giving you an asset that is readily reused. Let me illustrate with an example.
Imagine that you are working on AD Synchronization (with Notes, or TDS, or TAM, ...). Start by creating a folder in your SolDir called "ADSync". Then make a new Project (or new Config in TDI 6) called "ADSync". Configure the Properties Store - which is named after the project, "ADSync" - so that it points to a file called "ADSync.properties" in your SolDir using a relative path:
ADSync/ADSync.properties
Add properties to this Property Store for the various settings of your Connectors: e.g. url, username, password, table/nsf name, etc.. Tie the configuration parameters of your Connectors to properties by clicking on the name of any Parameter and choosing the property to use.

Now your solution is configurable via a text file. You build your AssemblyLine, which you also call "ADSync" just to keep things consistent and easy to remember. Now making the "installation package" is a snap.

Now your solution is configurable via a text file. You build your AssemblyLine, which you also call "ADSync" just to keep things consistent and easy to remember. Now making the "installation package" is a snap.
Just zip up the ADSync folder, including the ADSync.xml Config and ADSync.properties files, plus a ReadMe.txt file with the following text:
To install this solution:
1) Unzip ADSync.zip to your Solution Directory;
2) Edit ADSync.properties to configure connections
3) Run the solution with this commandline:
ibmdisrv -c ADSync/ADSync.xml -r ADSync
Violá, you have something that you can hand to the operations team for deployment, pass on to a colleague, and even send to me for publishing on tdi-users.org (and get yourself a Metamerge pen).
So the Solution Directory is a tool for making solutions portable, and it is independent of where you put your TDI 7 workspace.
But what if you chose the program directory or "current location" when you installed, or want to move the Solution Directory for some other reason? No problem. Go to the TDI installation folder and edit the batch-file (script) bin/defaultSolDir and change the path set there. Note that for TDI 6 and older versions you need to edit both the ibmditk (launches the CE) and ibmdisrv (the Server) scripts. Regardless, the script line in question sets up the TDI_SOLDIR environment variable used further down in the launcher script. So if you want to move your Solution Directory, simply change this assignment.
Changing defaultSolDir for TDI 7 is half the job. The Server called "Default" - the test Server maintained by the CE for you - also has a setting for the Solution Directory. So you must double-click on "Default" in the Server view and make the change here too.
TDI 7 lets you define new Servers, allowing you to start multiple Servers on your PC, or connect to those running on other platforms. You can point a Project at any Server by editing its settings (right-click > Properties). This lets you test and debug the ALs there. Each Server has its own Solution Directory settings, so using relative paths means you can build your ALs on your laptop and then run them elsewhere. You will also want to use forward slashes for filepaths, since backslash only works on Windows and TDI runs a lot of other places as well.
And while I'm on the soapbox here are some additional tips: Define Logging for where your task.logmsg() messages are written; Code Error Hooks and log enough info for manual intervention; Write status messages to the command line by using main.logmsg(); And set up Connector Auto-Reconnect (Connection Errors).

7 comments:
Interesting article you got here. I'd like to read something more about that topic. Thank you for giving this information.
Anything in particular? I'm taking requests :)
I would love to have more information on passwords sync! Specially MSAD passwords.
Use the force!
What would you like to know? TDI Identity Edition includes password change interceptor plugins for (among other systems) AD. This plugin grabs password changes and securely sends them to an AssemblyLine you prepare for writing the credential updates to your targets.
The transport for sending the password change message is either a queue (MQe, MQ) that your 'SyncPassword' AL reads; Or by having the plugin write password change entries to a special container/branch you set up in an LDAP directory where you pick them up using a Changelog Connector. Easy as spittin' :)
More here:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.IBMDI.doc_7.0/pluginsguide.htm
Good brief and this enter helped me alot in my college assignement. Gratefulness you seeking your information.
Eddie,
It seems to me that many enterprises will have a need to deploy TDI using automated build scripts and may have a need to create (and populate) a solution directory from the command line rather than firing up the CE. For those people in that situation, the "ibmdisrv -s {soldir} -g" is your friend.
@Stephen Swann
Absolutely. Much of what you make in TDI will be left behind for others, with perhaps less TDI-savvy, to run/automate/manage. So you need all the friends you can get :)
Post a Comment