Tuesday, August 16, 2011

Import pictures from Domino database into Lotus Connections

Many organizations who buy IBM Connections already have a employee pictures database in Domino of some sort.

I do believe this would work for all kinds of domino databases, either if you are using the names.nsf or some other picture DB. You just have to find the correct fields in the domino db you are using.

In this scenario, the Iterator is a standalone pictures DB, called pictures.nsf. The field "bc_mapping" contains an email-address of the user. This is used as the link-criteria when doing a lookup to the employee table. The Employee table then gives us the "PROF_KEY" value for that profile/employee, which I then use in the link criteria in the Photo table.

The screenshots will show you some other IF statements and stuff. This is just some logic I used to get the date of when the picture in the domino database had changed, and later on compare it to the date stored in the Photo table in Connections. When the dominodate is newer than the one stored in the Photo table, then I overwrite the picture.

Give me a wink, and I'll blog about this aswell.

So here goes:

The Iterator looks like this:

As you can see, I'm fetching the $FILE field from the domino database.
The screenshot is a bit unclear, but the assignment is: "conn["$FILE"]"
This is the connector for looking up the employee table:


This is the link criteria for the lookup towards the Employee table in Connections:
Here are the fields I select to take with me furter into the assemblyline:
In the lookup error hook, I just type something out, and then do a skip:
This is the connector for the Write to the Photo table: It's in update mode remember. So that it will update the existing records in the db2 table, or create new ones if they don't exist.
And of course, the link criteria is the PROF_KEY field:



This is the fields I'm writing. "image/jpeg" is the value for the "PROF_FILE_TYPE".
And now, this is the important one. the "PROF_IMAGE" has to convert the picture that's saved in Domino into a DB2 BLOB data type:
Here's the entire script used:

try
{
    var item = work.getAttribute("jpegPhoto").getValue(0);
    var filename = work.getAttribute("jpegPhoto").getValue(0).getValueString();

    var maxread = 253600;
    var fis = item.parent.getAttachment(filename).getInputStream();
    var byteStream = new java.io.ByteArrayOutputStream;
    var bytes = new byte[maxread];
    var readCount = 0;
    var readCount = fis.read(bytes, 0, maxread);
    var result = readCount;
    task.logmsg("readcount " + readCount);
    fis.close();
  
    if(readCount >= maxread || readCount<1){
        bytes = null;
        print("Exceeded byte count");
        system.skipEntry();
    } else {
        byteStream.write(bytes, 0, readCount);
        print("got byte array");
        ret.value = new javax.sql.rowset.serial.SerialBlob(byteStream.toByteArray());
    }
}

catch(e)
{
    e.printStackTrace();
}


Feel free to comment if anything is unclear. And also comment if you find this useful.

DO REMEMBER that the picture should not be bigger than 45kb filesize. If it's bigger, then the import will fail!

Friday, August 12, 2011

Issues with new SSL certificate. 2047 bits instead of 2048 bits.

A customer of mine had their Verisign SSL certificate expire in a few days, so they asked me to renew it.

They are using IBM HTTP server(IHS) where iKeyman is beeing used to manage the certificates.

So I went in, opened up iKeyman from the startmenu (windows), found the CMS key database used by the IHS and examined the certificate.
They were using a 1024 bit encrypted SSL certificate. This would not work, so I had to generate a new CSR request with 2048 bit encryption. Why?
As Verisign themself say:
To meet industry standards and security best practices, 2048-bit private keys are required for all SSL and code signing certificates after 1 October, 2013.
Therefore, any certificate whose validity period will extend past 1 October, 2013 must have a 2048-bit key or stronger


So I did, generated a CSR request and tried to select 2048 bits. THIS WAS NOT AN OPTION in iKeyman. Highest encryption I could select was 1024....

So I googled a bit, and found this page:
http://www-01.ibm.com/support/docview.wss?uid=swg21421447

Ok, so I followed the instructions, removed the gskim.jar file and started up iKeyman once again. Voila, I could select 2048 bits encryption.

I then pasted in the CSR info into the "renew certificate" input box on the Verisign renewal website.
This did not work. Verisign said that the CSR was not a 2048 bits request!

Google once more, found this page:
http://www.sslshopper.com/csr-decoder.html
Where I could analyze my CSR.
And the result said that the CSR was at a 2047 bits encryption level!!

Googled again and found this page:
http://publib.boulder.ibm.com/httpserv/ihsdiag/gather_certificate_doc.html#1023

So either upgrade the IHS and the JAVA to solve this. (IHS version at this customer was 6.0.2, so pretty old).

Or do as I did:
I had WebSphere Portal installed on this server, which the customer in fact had upgraded, so the java version here was newer than the one used by the IHS/iKeyman.

I found ikeyman.bat under the $IHS_INSTALLDIR\bin folder, copied it and called it ikeyman2.bat.
Edited it in Notepad, and changed the $JAVA_HOME variable to point to the java dir for the WAS server. (the directory below the \bin directory where java.exe exists).

I then started up ikeyman2.bat, generated a new CSR and voila, the CSR i then got was finally 2048 bits.

And of course I recommended the customer to upgrade to a newer version as well :-)