Recently, a friend asked a very interesting question in the Lotus Connections forum. In his question, he wondered if there was any way to load photos into Lotus Connections Profiles. More specifically, he wanted to know how to load existing photos stored in the LDAP (in the jpegPhoto attribute). Out of the box, you are given scripts to load photos from the file system, but not from the LDAP. 
In my experience, about half of our customers already have photos for their employees in some kind of system. Perhaps in their LDAP... Or in their HR Badge System... Or in some other in-house application. Therefore, I often find myself helping our customers create a custom "script" that fits their needs.
In an effort to spread the "wealth", I thought this was a great opportunity to show you how powerful Tivoli Directory Integrator (TDI) really is and teach you how to use it to the max. TDI is an ETL tool, which lets you extract information from pretty much any data source, transform it (if needed), and load it into Lotus Connections. And best of all, you don't have to do any coding! Since TDI is included for free as part of your Lotus Connections, I believe this is one of the key added value features of Lotus Connections.
Anyway, now, perhaps you are thinking "I don't have any skills in TDI, how am I ever going to figure this out?" Don't worry, I'm including a video here. It shows you how to load photos from your LDAP and, best of all, this takes less than 5 minutes!
If you would like detailed instructions on how to do this, follow the steps in my answer in the forum.
Cool video, Luis! Two thoughts:
ReplyDelete1. You may need to add "jpegPhoto" to the Binary Attribute parameter of the LDAP Connector. It does not read binary attributes in by default.
2. You could have dragged the Attributes from the Connector Schema you discovered in the LDAP and straight into the Input Map. Just another approach - your way works just fine and dandy :)
Keep TDI'ing, Luis.
-Eddie
Oops. jpegPhoto is a standard binary attribute and my experts tell me that it's included automagically.
ReplyDeleteNever mind.
-Eddie :)
Hi Eddie,
ReplyDeleteI was going to say.. I tested this and it just worked.. Beautiful...! I think I'm falling in love with TDI ;)
The code in the 2.5 seems to be different I have perform_update script. That one fails. Do you have the code for the write_entry?
ReplyDeleteHi Wannes,
ReplyDeletewrite_entry is a JDBC connector which updates the EMPINST.PHOTO table. Make sure you set it to AddOnly and write to the columns: PROF_IMAGE, PROF_KEY, and PROF_UPDATED.
Hope this helps.
Hi Luis,
ReplyDeletefirst of all, thanks for this guide. For 2.0 it was really helpful.
But as Wannes already said, IBM changed the update routine from 2.0 to 2.5, now using some Java class to do the actual update.
write_entry won't run through and breaks with an SQLSTATE 23505 error, which means writing to EMPINST.PHOTO.PROF_KEY is not allowed anymore.
PROF_UPDATED and PROF_IMAGE are still writable, though. And that's exactly the point where I'm standing right now.
If anyone has suggestions how to solve this problem, It'd be nice to hear about it.
For the time being here's a (very crude) workaround:
create a .bat or .sh that
-dumps the binary from jpegPhoto in the LDAP to the filesystem
(under linux use ldaptools, dunno what it'd be under windows)
-dump the current user shortname from LDAP to a variable
-write the path and filename as well as the shortname from the variable into <$TDISOL_DIR/collect.photo.in> with the respective formatting
-execute load_photos_from_files.bat/.sh with collect_photo.in as parameter.
Upside: Works
Downside: Depending on the user count this needs a) a good amount of time and b) quite a lot of disk space to swap. After all, it's say 500kb per userpic, meaning your FS has to temporarily handle roughly 500MB per 1k users. Realistically this'll scale to roughly 1GB per 1k users, given that some are bound to have bigger files.
Regards,
Michael Gerber
SOFTWERK GmbH
Hi Mike,
ReplyDeleteI believe I tested this and it worked like a charm. What I did was disable perform_update from the load_photos_from_files assembly line and then enable both lookup_key and write_entry and make the modifications as specified in the video of this blog. This was a while ago, so not sure what else I may have done, but I'm 99% sure that if you do that it should work.
Looking at error code 23505 in the DB2 InfoCenter, it seems to imply that you have a constraint violation. This means that the data you are inserting in PROF_KEY doesn't match a PROF_KEY in the EMPLOYEE table. Once you verify that you are inserting the right value in PROF_KEY, you should be all set.