The Power of the FormEntry Connector

I alluded to this in a previous post and would like to expand on it here. If you have ever been in the situation where you wanted to iterate over the xml nodes in the string value of an Attribute, or csv, or some other format, then you can solve this with JavaScript. I used to as well. Now I use the FormEntry Connector.

It's an Iterator that uses an attached Parser to read the text value you write/paste in its Config parameter (labeled 'Raw Text Data'). If you furthermore drop this Iterator into a Connector Loop, then you can map in the Connector Parameters you want, and then instruct the Loop to re-initialize and issue the search query, or just re-issue another query (no re-init).

So you map the Attribute value you want to parse as the assignment of the entryRawData parameter, attach your Parser, set up the Input Map and you're in business.

This Connector is standard issue with TDI 7.

The FormEntry.jar for TDI 6 is available for download here:

http://www.tdi-users.org/twiki/bin/view/Integrator/FormEntry

Scheduling when AssemblyLines run

When possible, use the scheduling mechanisms already in place: cronjobs, Windows scheduler, etc. Your TDI ALs can be started from the command line:

ibmdisrv -c MyConfig.xml -r MyAssemblyLine

That way if something goes wrong, your flow is restarted.

You can also do this in TDI using the Timer Connector (Iterator only). Here you can set up a scheduling mask. In the Flow section of your scheduling AL, you drop in AssemblyLine Function components (AL FCs) to launch other ALs.

One simple 'availability trick' for keeping an AL running is to start it (AL FC) inside a Loop that never ends. The AL FC is set to "Wait for completion" and will suspend until the called AssemblyLine stops. If it stops due to an error, you can catch this in the Error Hooks of the FC (& log it, send alerts, order pizza...). Regardless, the Loop -- which is Conditional and based on a script like this: ret.value = true; -- just executes the AL FC again, re-starting the stopped AssemblyLine.

So even in what is typically a long-running AL (like one listening to a changelog, or changes in Notes) you could set the Change Detection Iterator to timeout once in a while. Then you could do how keeping in the Scheduler AL, and restart the AssemblyLine again.

Here is an excellent developerWorks article on using TDI to Web 2.0-enable practically any type of data store or system, focusing on practical examples using TIM and TAM; and with Connections as the dashboard.

Thanks to Chris and Neil for sharing an impressive piece of work! Including their TDI Config and new ATOM Feed Connector.

ISM: Creating a Discovery Library Adapter to write IdML docs

If you are interested in creating IdML import files for systems like TADDM then there is a video that shows you how to assemble a DLA using TDI here.

There is also a shorter version on YouTube.

Please let me know if you have any comments, suggestions, corrections or just a bone to pick!

Happy 2009!

Troubleshoot the SyncDBfromSource AL in the Lotus Connections TDI Config: profiles_tdi.xml

Now that I have your attention, let me point you to this forum post where I describe the steps it takes to bring the SyncDBfromSource AssemblyLine -- the AL that forms the entire API into Connections' Profiles registry -- into the TDI Debugger in order to step through it for purposes of troubleshooting and adventure:

Google Group post about how to debug the Connections TDI ALs (near the bottom of the thread)

My wordy response is at the bottom of this thread. If you have an AssemblyLine that you wish to debug, but are still unable to (even after video #6 here) then let me know!

...now I remember

Remember to check out the FormEntry Connector. This is the perfect companion to the AL Debugger, letting you set up an infinite feed while you interactively set up Attribute values in order to exercise every corner of your AssemblyLine logic.

Plus, you can map out to the entryRawData parameter when this component is used in a Connector Loop, letting you use multiple Parsers on the same bytestream.

Very handy indeed!

New Component and Library .jar Files

Generally, adding a new component to TDI's library amounts to either 1) copying the relevant jar files to the [TDI Installation Folder]/jars sub-directory; or 2) leaving these files where they are and instead telling TDI where to find them.

This latter is done by setting the com.ibm.di.loader.userjars property found near the top of the solution.properties file which is located in your Solution Directory.

According to the instructional comments found in the property file, you can set this property to a list of directory paths, or a list of files, or any combination of the two. For example,

com.ibm.di.loader.userjars=C:\Notes;CustomJars;C:\Drivers\jdbcDrv.jar

Using this property lets you keep custom jar  files either in place, or in a common area like the CustomJars folder I use. This can be preferrable to copying them into the TDI product installation folder.

Due to the mystical dance of Java loaders, sometimes these library files may need to be available to other loaders, in which case you end up having to do one or both of the following:

a). Modifying the PATH in the ibmditk and ibmdisrv files to include additional folders*.

b). Modifying the CLASSPATH line in these files for this same purpose.

I have several sub-folders to my own CustomJars directory, each containing the library files associated with a particular data source, like "Maximo", "Lotus" and so forth. TDI's loader checks all sub-folders under root directory specified, making it simple to keep these organized and backed up.

Note: libraries can be in zip files as well.

*Note: For Domino integration you will want to put the Notes path first: SET PATH=c:\Notes;%PATH% - since a little bird told me that only the first 128 chars are used by the Notes loader. At least for older versions.

...and I know there was something else I wanted to mention...