Update erlaststatuschangedate in ISIM with a TDI HR Feed

IBM has a support article on this topic here:

https://www.ibm.com/support/pages/how-update-erlaststatuschangedate-through-tdi-hr-feed#:~:text=If%20the%20%22erpersonstatus%22%20attribute%20value%20is%20being%20modified,Work%20attribute%20called%20%22erlaststatuschange%22%20to%20the%20Input%20Map 

Unfortunately, the code provided is incorrect and will throw an exception if you try to use it.

Here's the corrected code:

// set up variables to set the erlaststatuschangedate attribute

// get milliseconds since epoch in local time zone.

var mydate = new Date().valueOf();

// get milliseconds of offset from Zulu/UTC

var localOffset = new Date().getTimezoneOffset() * 60000;

// add/subtract milliseconds based on local timezone to get Zulu time.

var myTZ = mydate + localOffset;

// create a new Date() object representing "now" in Zulu time.

var utcDate = new Date(myTZ);

// Format the date into a string in the correct format

var myTZStr = new java.text.SimpleDateFormat("yyyyMMddHHmm").format(utcDate);

// Add "Z" to the end of the string to complete the correct format.

var myTZStrZ = myTZStr + "Z";

// set the value of erlaststatuschangedate

work.setAttribute("erlaststatuschangedate",myTZStrZ);

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

 TDI 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: