AJAX made easy and interactive

Stolen from Jon Elwoods internal IBM blog:

---------------------------------------------------------

I was writing some simple AJAX functions for a web page for the migration project. They are generic enough to be used anywhere...

I created an assembly line that iterates on an HTTPServer FC. I found it hard to code all my client-side JavaScript functions directly into TDI (caused problems in expression attribute mapping) so I included them all in a funcs.js. This was included at in the header of the page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<link rel="stylesheet" type="text/css" href="dashboard.css"/>
<script src="funcs.js"></script>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></meta>
<title>title</title>
</head>

Contents of funcs.js:

var component

function request(attribute, value, comp) {
try {
xmlhttp = window.XMLHttpRequest?new XMLHttpRequest(): new ActiveXObject("Microsoft.XMLHTTP");
}
catch(e){
document.getElementById("main").innerHTML = "BROWSER DOES NOT SUPPORT AJAX";
}
component = comp;
xmlhttp.onreadystatechange = loadResult;
url=attribute + "=" + value;
url=url+"&sid="+Math.random();
xmlhttp.open("GET", url);
xmlhttp.send(null);
}

function loadResult() {
// if the readyState = 4 = Completed
// & http status is 200, get responseText
if ((xmlhttp.readyState == 4) && (xmlhttp.status == 200)) {
document.getElementById(component).innerHTML = xmlhttp.responseText;
}

else {
document.getElementById(component).innerHTML = "Loading...";
}
}

request() takes three parameters. Attribute and value will be used as part of the GET url. e.g. myurl.com?attribute=value. The third parameter is the component where the response xml/xhtml from TDI will be inserted.

The callBack function loadResult() will display a "Loading" message in the choosen element ID until the response is returned from TDI. I used simple <span> tags as place holders to insert my httpResponse text. e.g.:

<span id="result"> response goes here! </span>

So I would call the function:

request("myAtt","myvalue","result");

TDI simply looks at http.base for the attribute and value and returns an http.body according to my specifications. This is a very simple over view of the code. (There may be bugs and other nasties in the code so if your project comes tumbling to the ground....you have been warned!!) I will hopefully be posting a detailed tutorial on TDI and AJAX some time in the future.

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!