IBM Directory Integrator error "unknown format type at"

So here's a strange one that I didn't find anywhere in my numerous searches, so I figured I would post it here. When running a TDI AssemblyLine, I got the following exception / error:

12:14:43,274 ERROR - [My-JDBC-Connector] CTGDIS810E handleException - cannot handle exception , addonly

java.lang.IllegalArgumentException: unknown format type at

        at com.ibm.icu.text.MessageFormat.makeFormat(MessageFormat.java:2086)

        at com.ibm.icu.text.MessageFormat.applyPattern(MessageFormat.java:589)

        at com.ibm.icu.text.MessageFormat.<init>(MessageFormat.java:437)

        at com.ibm.icu.text.MessageFormat.format(MessageFormat.java:1137)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:229)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:173)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:245)

        at com.ibm.di.connector.JDBCConnector.putEntry(JDBCConnector.java:1202)

        at com.ibm.di.server.AssemblyLineComponent.executeOperation(AssemblyLineComponent.java:3351)

        at com.ibm.di.server.AssemblyLineComponent.add1(AssemblyLineComponent.java:2012)

        at com.ibm.di.server.AssemblyLineComponent.add(AssemblyLineComponent.java:1965)

        at com.ibm.di.server.AssemblyLine.msExecuteNextConnector(AssemblyLine.java:3780)

        at com.ibm.di.server.AssemblyLine.executeMainStep(AssemblyLine.java:3391)

        at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2989)

        at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2972)

        at com.ibm.di.server.AssemblyLine.executeAL(AssemblyLine.java:2939)

        at com.ibm.di.server.AssemblyLine.run(AssemblyLine.java:1317)

12:14:43,276 ERROR - CTGDIS266E Error in NextConnectorOperation. Exception occurred: java.lang.IllegalArgumentException: unknown format type at

java.lang.IllegalArgumentException: unknown format type at

        at com.ibm.icu.text.MessageFormat.makeFormat(MessageFormat.java:2086)

        at com.ibm.icu.text.MessageFormat.applyPattern(MessageFormat.java:589)

        at com.ibm.icu.text.MessageFormat.<init>(MessageFormat.java:437)

        at com.ibm.icu.text.MessageFormat.format(MessageFormat.java:1137)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:229)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:173)

        at com.ibm.di.util.ParameterSubstitution.substitute(ParameterSubstitution.java:245)

        at com.ibm.di.connector.JDBCConnector.putEntry(JDBCConnector.java:1202)

        at com.ibm.di.server.AssemblyLineComponent.executeOperation(AssemblyLineComponent.java:3351)

        at com.ibm.di.server.AssemblyLineComponent.add1(AssemblyLineComponent.java:2012)

        at com.ibm.di.server.AssemblyLineComponent.add(AssemblyLineComponent.java:1965)

        at com.ibm.di.server.AssemblyLine.msExecuteNextConnector(AssemblyLine.java:3780)

        at com.ibm.di.server.AssemblyLine.executeMainStep(AssemblyLine.java:3391)

        at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2989)

        at com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:2972)

        at com.ibm.di.server.AssemblyLine.executeAL(AssemblyLine.java:2939)

        at com.ibm.di.server.AssemblyLine.run(AssemblyLine.java:1317)

The problem was that I had a scriptable field in a connector that was set as "Text w/substitution", but needed to be set to "Advanced (JavaScript)". Sometimes (with only a tiny bit of JavaScript, for example), you can get away with this. But in my case, I had a LOT of JavaScript and this error was the result.

To figure that out, I put lots of debugging code in the JavaScript itself and in the Component Hooks around when this field should have been evaluated.

Tivoli Directory Integrator Entry.toJSON() function produces bad JSON for single-element arrays

 DI lets you create a JSON string from an Entry type object using that class's toJSON() method. It works like a champ UNLESS you happen to have a property that is an array with a single element, like this:

entry = system.newEntry()

entry.foobar = [ "0" ];

task.logmsg(entry.toJSON());

That will produce the following string:

{ "foo":"0" }

Whereas it should produce:

{ "foo" : [ "0" ] }

If you have two or more elements in the array, it works perfectly. 

To fix the issue, I used the following code:

goodString = entry.toJSON().replace('"foobar":"0"','"foobar":["0"]');

And now everything is good. Whew!

Setting DISPLAY in .bashrc on AIX doesn't work in at least one strange situation

 Here's what I tried in  my .bashrc:

DISPLAY=$(who am i | perl -pe 's/.*\((.*)\)/$1:0.0/')
export DISPLAY

Here's the result:

$ xterm

Warning: This program is an suid-root program or is being run by the root user.

The full text of the error or warning message cannot be safely formatted

in this environment. You may get a more descriptive message by running the

program as a non-root user or by removing the suid bit on the executable.

xterm Xt error: Can't open display: %s

xterm:  DISPLAY is not set

$ echo $DISPLAY

10.110.2.214:0.0
$ export DISPLAY=10.110.2.214:0.0

$ xterm

(xterm displays as expected)

This drove me crazy for longer than it should have. I even ran:

echo $DISPLAY | od -c

and that showed no extra characters at all. I was at my wit's end until I simply tried a different set of commands to set DISPLAY. The one that works is:

REMOTE_HOST_IP=$(who am i | awk '{print $NF}' | tr -d ')''(' )

DISPLAY=$REMOTE_HOST_IP:0.0

export DISPLAY

This is on AIX 7.3, with what I'm certain are strange and old versions of perl and bash (they behave oddly in other situations, too), but wanted to share my silly solution.

Tivoli Directory Integrator Certificate Chain Exception

 Saw this error today in an HTTP Client Connector in TDI 7.1.1:

 java.security.cert.CertPathValidatorException: Certificate chaining error

I had the remote host's entire certificate chain imported into serverapi/testadmin.jks . I also made certain that my solution.properties file was pointing to the correct JKS file, restarted the TDI CE multiple times, and it simply kept failing. I thought I was going crazy, so I:

• stopped TDI CE
• moved testadmin.jks
• zeroed out testadmin.jks
• started TDI CE
• Went to the connector and clicked "Get Certificate" and it complained, whereas before it said "Certificate is already trusted", so I knew I was dealing with the correct JKS file.
• FINALLY, out of desperation, I deleted the server certificate, but left the other two certs in the chain (the signer and the signer of THAT certificate), and THEN IT WORKED.

So I'm not certain what the moral of the story is, but that's how I solved this problem, which is slightly different than I've seen anywhere else and I wanted to record it to hopefully help anyone who runs into this in the future.

Launch a page in JazzSM DASH without login page

The following is from an IBM Communities post on this topic by Detlef Kleinfelder . The link is also included, but those see to go dead on IBM's site, which is why I'm including the text:

https://community.ibm.com/community/user/aiops/discussion/is-there-a-way-to-run-public-event-viewer-of-omnibus-webgui-for-big-wall-dashboards#bmd85f7aed-8757-47a5-99c0-ceae09aec075

you can launch a page directly with URL provinding the page id and an user-based token.

The user-based token has the encoded username and password that is used to authenticate and launch a page.

 

The URL convention is https://<FQDN>:16311/ibm/action/launch/<PageID>/<xlaunchCred>

where:

FQDN = Fully Qualified Domain Name or IP address
PageID = The Page ID of the DASH page
xlaunchCred = The user-based token generated by xlaunchapi.jar

The following STEPS will walk you through to obtain the required parameters:

 

1. Get the Page ID of the DASH page. For example, to get the Page ID of DASH About Page, open the About page and click on the "Page" icon at the top right corner and click "About". The Page ID is under "General"

2. Generate the  user-based token using xlaunchapi.jar, ensure all text in the command are all in one line as shown:
    
   ./java -cp /<JazzSM_HOME>/profile/installedApps/JazzSMNode01Cell/isc.ear/xlaunchapi.jar com.ibm.isc.api.xlaunch.LaunchPropertiesHelper\$Encode com.ibm.isc.xlaunch.username <username> com.ibm.isc.xlaunch.password <password>

• Replace <username> and <password> with the user you want to Single Sign On.

 

• The command will return a string like:

• L2NvbS5pYm0uaXNjLnhsYXVuY2gudXNlcm5hbWUvc21hZG1pbi9jb20uaWJtLmlzYy54bGF1bmNoLnBhc3N3b3JkL29iamVjdDAw

3. Following the URL convention, https://<FQDN>:16311/ibm/action/launch/<PageID>/<xlaunchCred>, launch the DASH About Page. The page will launch without manually entering login and password.

 

• Example:

• https://dash151.poc.ibm.com:16311/ibm/action/launch/com.ibm.isclite.ISCAdminPortlet_banner.isc.about/L2NvbS5pYm0uaXNjLnhsYXVuY2gudXNlcm5hbWUvc21hZG1pbi9jb20uaWJtLmlzYy54bGF1bmNoLnBhc3N3b3JkL29iamVjdDAw

Configuring DASH/JazzSM and WebGUI HA using an ObjectServer database

 There is a great support article on this exact topic here:

https://www.ibm.com/support/pages/omnibus-webgui-configuring-high-availabilityload-balancing-using-omnibus-81-objectserver-ha-database

There are just a few caveats that need I need to point out:

1. Use the webha.sql file from the above link to create the ObjectServer database. There are two similar files on your DASH/JazzSM server after the install, but both are incorrect.

2. The instructions in the link for configuring WebSphere are all manual, through the WebSphere Admin Console. To make things more easily repeatable, I created a file with all of the Jython WebSphere administrative commands required. Here are the contents of that file:

Modifying the Netcool Remedy 8 gateway for use with Java JDK 8

𝐁𝐚𝐜𝐤𝐠𝐫𝐨𝐮𝐧𝐝

The Netcool Gateway for Remedy 8 version 1.3 was originally written for Java 6, which used the Rhino JavaScript engine. The Nashorn JavaScript engine in Java 8 (which is automatically installed with an OMNIbus fixpack) is slightly different. Nashorn is so different that the some modifications are required to get the probe to work correctly.

The error you'll see in the gateway log file if you try to run the gateway without these changes is:

Error: [Main Gateway] java.lang.RuntimeException: javax.script.ScriptException: ReferenceError: "importPackage" is not defined in <eval> at line number 1

The issue is basically that Nashorn gives you a new way to create Java objects within JavaScript.

𝐒𝐨𝐥𝐮𝐭𝐢𝐨𝐧
You will need to modify three files to get the Remedy 8 gateway working correctly. Those files are listed here:

$𝗢𝗠𝗡𝗜𝗛𝗢𝗠𝗘/𝗷𝗮𝘃𝗮𝘀𝗰𝗿𝗶𝗽𝘁/𝗺𝗼𝗱𝘂𝗹𝗲𝘀/𝘀𝗼𝗴.𝗷𝘀
$𝗢𝗠𝗡𝗜𝗛𝗢𝗠𝗘/𝗷𝗮𝘃𝗮𝘀𝗰𝗿𝗶𝗽𝘁/𝗺𝗼𝗱𝘂𝗹𝗲𝘀/𝗱𝗮𝘁𝗲𝗳𝗼𝗿𝗺𝗮𝘁.𝗷𝘀

In the above two files, you simply need to add this one line at the beginning of each file:

𝚕𝚘𝚊𝚍("𝚗𝚊𝚜𝚑𝚘𝚛𝚗:𝚖𝚘𝚣𝚒𝚕𝚕𝚊_𝚌𝚘𝚖𝚙𝚊𝚝.𝚓𝚜");

$𝗢𝗠𝗡𝗜𝗛𝗢𝗠𝗘/𝗴𝗮𝘁𝗲𝘀/𝗯𝗺𝗰_𝗿𝗲𝗺𝗲𝗱𝘆/𝗯𝗺𝗰_𝗿𝗲𝗺𝗲𝗱𝘆.𝗻𝗼𝘁𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻.𝗷𝘀 
This file requires a bit more customization. Specifically, you replce this line in the update() function definition:

    𝚟𝚊𝚕𝚞𝚎𝚜 = 𝚜𝚘𝚐.𝚗𝚎𝚠𝚛𝚘𝚠();

With these 3 lines:

    //𝚟𝚊𝚕𝚞𝚎𝚜 = 𝚜𝚘𝚐.𝚗𝚎𝚠𝚛𝚘𝚠(); // 𝚓𝚞𝚜𝚝 𝚌𝚘𝚖𝚖𝚎𝚗𝚝𝚒𝚗𝚐 𝚒𝚝 𝚘𝚞𝚝.
𝚟𝚊𝚛 𝚂𝙾𝙶𝚁𝚘𝚠 = 𝙹𝚊𝚟𝚊.𝚝𝚢𝚙𝚎("𝚌𝚘𝚖.𝚒𝚋𝚖.𝚝𝚒𝚟𝚘𝚕𝚒.𝚗𝚎𝚝𝚌𝚘𝚘𝚕.𝚒𝚗𝚝𝚎𝚐𝚛𝚊𝚝𝚒𝚘𝚗𝚜.𝚜𝚘𝚐.𝚂𝙾𝙶𝚁𝚘𝚠");
𝚟𝚊𝚛 𝚟𝚊𝚕𝚞𝚎𝚜 = 𝚗𝚎𝚠 𝚂𝙾𝙶𝚁𝚘𝚠();

Once you make all of the above changes, you need to restart the gateway for the changes to take effect, and it has a better chance of working. I say better chance because you still have to provide all of the correct values for the various properties. But if you're just upgrading your working gateway to OMNIbus 8.1 FixPack 30, then the above changes are what you need.