Using a Connector Loop to replace Connectors in Lookup Mode - and Why

Although our motto has been 'make no assumptions', TDI makes an assumption about Connectors in Lookup mode: One and only entry will be matched successfully. Period. If none are found, you have to script (or at least enable) the On No Match Hook. If multiple are found, then the On Multiple Found Hook must be dealt with. And if you want to perform some operation repeatedly for all entries in the result set, you have to script your way through connector functions like getNextDuplicateEntry(). And you have to make sure the Lookup Limit is set high enough, since TDI will buffer this many entries in memory.

This gets simpler if you turn your Connector into a Connector Loop. In other words, Add a Connector Loop and attach your Lookup Connector to it.

A Connector Loop will not cycle at all if the search returns no entries. Otherwise it cycles once for each entry found. You control what is found each time through the Link Criteria tab of the Loop. The Loop also gives you the option to Initialize each time it starts up each AL cycle, also performing the Lookup. Or you can set the Loop to just perform the Lookup. This latter option can save time by avoiding having to set up time-consuming connections each cycle.

You can still code the On No Match and On Multiple Found Hooks if you want, but these are not mandatory for a Lookup Loop.

The Loop supports both Lookup and Iterator modes if the attached Connector supports them. In order to perform specific actions on each entry returned (like deleting them) you need to add another Connector under the Loop and set the Link Criteria to search for a unique attribute - which should be one of those returned by the Loop Input Map.

The observant reader will have noted that the Lookup Limit setting is still an issue. You solve this by changing the Mode of the Loop from Lookup mode to Iterator, since Iterator mode does not buffer entries. Then you control the search by setting the relevant search filter parameter of the Connector via the Loop's Connector Parameters tab. So for LDAP you would map the ldapSearchFilter parameter like you would any attribute, for example using Javascript.

Or you could do this using a literal Text with Substitution tokens: uid={work.EmpId}.

For for JDBC it could look like this:

Note that the names that show up in the Schema area of the Connector Parameters map are the internal names of the parameters. You see this if you click on the label for a parameter, or the pencil button out to the right of it.

Normally, a Connector gets the values from its Connection Form only when it initializes. After that point, changing a parameter value (which just changes the configuration) will have no affect. However, some Connectors refresh the value for their search criteria parameter, for example the LDAP and JDBC Connectors. As a result, you do not need to tell the Connector to re-initialize, but merely to perform the Select each time.

For those parameters that do require a re-initialization to pick up changes, just tell the Loop to Initialize each time.

It's as easy as spittin'.

Printing the stacktrace of an exception to the log

When you code your error Hooks then you generally don't get the exception stacktrace printed, as you do when the error halts your AL. Here is some handy code to do this yourself:

// Error Hook code - the error Entry will be available
var sw = java.io.StringWriter();
var pw = java.io.PrintWriter(sw);
error.exception.printStackTrace(pw);
pw.close();
task.logmsg("Stacktrace: \n" + sw)

As usual, the secret is in the Java.

JSON and XML Tutorial - Part 1

If you're working with cloud services, or probably any kind of services, you're most likely working with JSON, XML (e.g. SOAP web services) or both. Although TDI provides specific components for handling web services, there is an easier approach to deal with both formats quickly and flexibly - and in the exact same way - if you're ready to do a little scripting. This is a quick tutorial to get you started with TDI's hierarchical Entry features - or hEntry for short.

As an experienced TDIer, you know that data in the system is carried around in Entry objects. Each Entry holds zero or more named Attributes. Each Attribute contains zero or more values.  Each value is a specific Java object used to represent the actual data content of that Attribute. We'll call this a 'flat Entry', since it represents a one dimensional list of Attributes - like a directory entry or a database table.

As of version 7, the Entry now has an hierarchical mode to represent a tree of data. hEntry mode is enabled automatically when you create an Entry based on hierarchical data, for example parsing XML or JSON. You can also explicitly call the enableDOM() method of an Entry, which then makes the DOM Interface functionality active and available. Or you can just add hierarchical attributes to it.

hentry = system.newEntry() // hentry is still flat
hentry.root = null // now it has a single attribute
hentry.root.branch = null // it's become hierarchical now
hentry.root.branch.leaf = "Green" // add a node with a text value

The above script creates a tree of data in the form of an hEntry. You can get the XML representation like this:

task.logmsg(hentry.toXML())

Here is the output:

<root>
  <branch>
  <leaf>Green</leaf>
  </branch>
</root>

And produce the JSON version like this:

task.logmsg(hentry.toJSON())

Which gives you the following:

{"root":{"branch":{"leaf":"Green"}}}

At this point it might help to know a little about how DOM (the XML Document Object Model) works. Here is where I learned about it: http://www.w3schools.com/dom/

In short, the DOM Model describes how an XML document is organized into a tree structure, and the DOM Interface provides methods for reading, searching and manipulating the leaves and branches of this tree. JSON is another way of describing hierarchical data. Once you have converted hierarchical data (either XML or JSON) into an hEntry then you use the DOM Interface methods to work with the data.

The Entry object provides a couple of static methods for turning hierarchical data into an hEntry: fromJSON() and fromXML(). Since they are static methods, this means you can call them using either an existing Entry object - e.g. work.fromJSON() - or by using the Class itself: com.ibm.di.entry.Entry.fromJSON(). Since you have methods for turning an hEntry into an XML or JSON representation, this makes JSON to XML conversion as simple as:

xmlString = work.fromJSON(jsonString).toXML()

And note that the above snippet will not change the contents of work. We're just making use of the static methods.

So much for the theory. You can easily play with this using the Javascript View at the bottom of your TDI Workbench, or by firing up the Debugger. Stay tuned for the next part of this discussion.