Reference error: 'java' not found

Just to let you know, if you get the above error then it means you've probably spelled the Java class name wrong.

now = new java.util.Calender()

I was getting ready to start pulling out hair when I saw the light: 'Calendar'.

And I've also gotten other error messages that turned out to be caused by spelling. Just wanted to share that :)

To Google, or not to Google? That is the wrong question.

If you've ever hit an error or connection problem or logical challenge using TDI and cursed the lack of helpful content to be found online, you may not be looking in the right places.

Firstly, use the term 'tdi' in your search arguments only if you're interest is motors or diving. Searches that include 'tivoli directory integrator' will be less exciting but more relevant.

Secondly, remember that TDI is pure Java and also that the core of an issue might be some system that you are integrating. So the trick is to examine available clues, and then make a informed search.

For example, let's look at this error returned while trying to update a Domino server:

10:03:21,410 ERROR - [UpdateDomino] CTGDIS810E handleException - cannot handle exception , update
java.lang.Exception: CTGDKC002E Failed to execute the command. NotesException occurred: Invalid object type for method argument
at com.ibm.di.connector.dominoUsers.DominoUsersConnector.executeCommand(DominoUsersConnector.java:647)
at com.ibm.di.connector.dominoUsers.DominoUsersConnector.putEntry(DominoUsersConnector.java:732)
at com.ibm.di.server.AssemblyLineComponent.executeOperation(AssemblyLineComponent.java:3139)
at com.ibm.di.server.AssemblyLineComponent.add1(AssemblyLineComponent.java:1930)
at com.ibm.di.server.AssemblyLineComponent.update(AssemblyLineComponent.java:1681)
at com.ibm.di.server.AssemblyLine.msExecuteNextConnector(AssemblyLine.java:3669)
at com.ibm.di.server.AssemblyLine.executeMainStep(AssemblyLine.java:3294)
at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2930)
at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2913)
at com.ibm.di.server.AssemblyLine.executeAL(AssemblyLine.java:2882)
at com.ibm.di.server.AssemblyLine.run(AssemblyLine.java:1296)
10:03:21,410 ERROR - CTGDIS266E Error in NextConnectorOperation. Exception occurred: java.lang.Exception: CTGDKC002E Failed to execute the command. NotesException occurred: Invalid object type for method argument
java.lang.Exception: CTGDKC002E Failed to execute the command. NotesException occurred: Invalid object type for method argument
at com.ibm.di.connector.dominoUsers.DominoUsersConnector.executeCommand(DominoUsersConnector.java:647)
at com.ibm.di.connector.dominoUsers.DominoUsersConnector.putEntry(DominoUsersConnector.java:732)
at com.ibm.di.server.AssemblyLineComponent.executeOperation(AssemblyLineComponent.java:3139)
at com.ibm.di.server.AssemblyLineComponent.add1(AssemblyLineComponent.java:1930)
at com.ibm.di.server.AssemblyLineComponent.update(AssemblyLineComponent.java:1681)
at com.ibm.di.server.AssemblyLine.msExecuteNextConnector(AssemblyLine.java:3669)
at com.ibm.di.server.AssemblyLine.executeMainStep(AssemblyLine.java:3294)
at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2930)
at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2913)
at com.ibm.di.server.AssemblyLine.executeAL(AssemblyLine.java:2882)
at com.ibm.di.server.AssemblyLine.run(AssemblyLine.java:1296)

Step one is to find the topmost (first) stackdump, and then trace it to the top two or three lines:

10:03:21,410 ERROR - [UpdateDomino] CTGDIS810E handleException - cannot handle exception , update
java.lang.Exception: CTGDKC002E Failed to execute the command. NotesException occurred: Invalid object type for method argument
at com.ibm.di.connector.dominoUsers.DominoUsersConnector.executeCommand(DominoUsersConnector.java:647)
at ...

The first line is timestamped and filled with info coming from the AssemblyLine itself. In the above snippet there is the component name in brackets, UpdateDomino, followed by a codified error message - in this case, a very general one that tells us that the AL was unprepared to handle an exception thrown by one of its components. At the very end of the first line is the operation which failed: update. Although this information gives us context, it brings us no closer to solving the problem.

The second line of the snippet is more interesting here. It also has a numbered error message that translates to 'the desired operation failed because Notes flagged an exception'. After the colon is this error: Invalid object type for method argument. Now we have bait for our hook and can go fishing for answers.

In Google I look for: 'Invalid object type for method argument' update notes
Ok, so this wasn't the best example :) Plenty of TDI content here. The third link in the result page takes me to a redpaper entitled 'Domino Integration using TDI', and here on page 26 is the same Notes error message and the cause: the type of an attribute is not recognized by Notes. A typical situation is that a date value is being written, but was not converted to a Domino Date type. Or that a set of values was being written, and one of them was null. On a side note: This can happen if you are using the template example for AD - Domino synchronization and the AD instance you're working against has a different schema for Users than the standard, out-of-the-box one. In this case the 'Location' attribute in the Output Map or the Domino Connector may be in error.

Getting back to my rant, sometimes the search results aren't this promising. That's when you add 'java' to the list of terms, hoping that some Java developer, deployer or application user has seen this before, and an answer lies beckoning in some forum thread, blog post, presentation or page of documentation somewhere.

And finally, if you learn how to read a JavaDoc then you may find answers in TDI's JavaDocs, or those of the libraries that your solution uses. This includes stuff like database drivers and client APIs, as well as standard Java classes.

So the answer is to Google, but it's the question that's key.

CSV Parsing with a twist

So the question I got was this: how can I get the line being parsed by the CSV Parser?

Unfortunately, the CSVParser class does not have any public method for this, so the following is not possible:

lineRead = thisConnector.getParser().getCurrentLine()

Instead, with the help of Jens Thomassen, TDI surgeon, and the indispensible AL Debugger, I created this example TDI 7.1 AL to do just that. You can download the linked Example AssemblyLine and just drop the file onto a TDI Project. It's self-contained thanks to the ever-handy Form Entry Connector.

This AL contains first a Form Entry Iterator in the Feed section that reads a CSV bytestream line-by-line using the LineReader Parser. This returns each line from the CSV loaded into the Connection parameter of the Connector. Then in the Flow section there is another Form Entry Connector that has the CSV Parser, which gets us the actual CSV attributes.

To make this magic work, I did a couple of things:

1. First I set the Flow Section Iterator to initialize 'only when used'. You do this by pressing the More... button out to the right of the Inherit From setting and changing the Initialize drop-down accordingly. This is to prevent the Connector and Parser from initializing until we have data for it.
2. Then I added this code to the After Initialize Hook of this second Iterator:
   

   outStream = new java.io.PipedOutputStream()
   inpStream = new java.io.PipedInputStream(outStream)
   newline = new java.lang.String("\n\r")
   
   formEntry = thisConnector.getConnector()
   formEntry.initParser(inpStream, null)
   
   csvColumns = formEntry.getParser().getParam("csvColumns")
   firstRow = true

   
   The Piped stream allows me to write into one end of the pipe and have my CSV Parser read from the other end.
3. Now in the Before GetNext Hook I need to write the current line into my pipe.
   

   outStream.write(work.getString("line").getBytes())
   outStream.write(newline.getBytes())
   
   if (firstRow && (csvColumns == "")) {
     outStream.write(work.getString("line").getBytes())
     outStream.write(newline.getBytes())
     firstRow = false;
   }

   
   If this is the first row of the file and no Field Names have been specified for the Parser, I am assuming this must be the column title line of the file, so I have to write it twice to the pipe.

And presto! I am getting both the 'line' Attribute and those parsed out of the CSV. Note that this is a slightly simplistic approach, and as a result the first Entry returned by the CSV Parser contains the column names as Attribute values.

So I made a Second Attempt using just a single Iterator in the Feed section, and scripting the setup and calls to the CSV Parser. You can also just drop this .assemblyline file onto a Project and then play with it. I am using the code that I built for the first example in a slightly different way:

1. The After Initialize Hook script is a bit shorter:
   

   outStream = new java.io.PipedOutputStream()
   inpStream = new java.io.PipedInputStream(outStream)
   newline = new java.lang.String("\n\r")
   
   firstRow = true;
   initParser = true;

2. All the work is done in After GetNext, once I have read in the line:
   

   if (initParser) {
     // In this next line you could instead get a pre-configured
     // Parser from your Project Resource library:
     //    csvParser = system.getParser("Parsers/MyCSV")
     //
     // AND to find out what the 'true name' of a Parser is
     // just add it to a Connector and then use the More...
     // Select Inheritance button to see the inheritance link
     // for the Parser (yeah, it's not that elegant ;)
     //
     csvParser = system.getParser("ibmdi.CSV")
     csvParser.setInputStream(inpStream)
     csvParser.initParser()
     csvColumns = csvParser.getParam("csvColumns")
   
     initParser = false;
   }
   
   if (firstRow && (csvColumns == "")) {
     outStream.write(conn.getString("line").getBytes())
     outStream.write(newline.getBytes())
   }
   
   outStream.write(conn.getString("line").getBytes())
   outStream.write(newline.getBytes())
   
   csvEntry = csvParser.readEntry()
   if (firstRow && (csvColumns == "")) {
     firstRow = false
     system.skipEntry() // skip the column names
   }
   
   if (csvEntry != null)
     conn.merge(csvEntry)

This time only the actual data values are returned.

And now for more coffee :)