Friday, August 30, 2024

Working with dates in IBM Security Directory Integrator

Working with dates in TDI can be tricky, since you'll normally be dealing with not only ISIM's internal format, but also various formats from different databases and other sources. The easiest way I've found is to use the java.time.* classes that were introduced in Java 8. Specifically, the LocalDateTime class is great because it has methods like minusHours(), minusDays(), etc. to make it easy to get a time from "X time ago". 

Here are some examples I've come up with to use with the different formats I've run into on my latest contract:


var ldtObj = java.time.LocalDateTime.now();
var dtfObj = java.time.format.DateTimeFormatter.ofPattern("yyyyMMdd");
var today = ldtObj.format(dtfObj);  
// today is "20240830" for August 30, 2024

var dtfObjHHmm = java.time.format.DateTimeFormatter.ofPattern("yyyyMMddHHmm");
var todayHHmm = ldtObj.format(dtfObjHHmm);  
// todayHHmm is  "202408301531" for 15:31 on August 30, 2024

var dtfObjH = java.time.format.DateTimeFormatter.ofPattern("yyyy-MM-dd:HH");
var todayH = ldtObj.format(dtfObjH);  
// todayH is "2024-08-30:15" for 15:00 on August 30, 2024

var dtfObjChars = java.time.format.DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH'hrs'mm'mins'");
var todayChars = ldtObj.format(dtfObjChars);  
// todayChars is "2024-08-30T15hrs31mins" for 15:31 on August 30, 2024
// just put single quotes in the Pattern around any literal characters you want in the resulting string.

var utcZone = java.time.ZoneId.of("UTC");
var ldtObjUtc = java.time.LocalDateTime.now(utcZone);
var dtfObjZ = java.time.format.DateTimeFormatter.ofPattern("yyyyMMddHHmm'Z'");
var todayZ = ldtObjUtc.format(dtfObjZ);  
// todayZ is  "202408301531Z" for 15:31 on August 30, 2024 Zulu (UTC) time.

// get the time "3 hours ago"
var ldtObjThreeHoursAgo = ldtObj.minusHours(3);
var dtfObj = java.time.format.DateTimeFormatter.ofPattern("yyyyMMddHHmm");
var today = ldtObj.format(dtfObj);  
// today is "202408301231" for three hours before 15:31 August 30, 2024 (so 12:31)

Friday, August 9, 2024

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);

Monday, July 22, 2024

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.

Tuesday, July 16, 2024

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.

Monday, July 15, 2024

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.