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.