SlideShare a Scribd company logo

IBM Connections 4.5 User Data Propagation.

•
•
michele buccarello
michele buccarello

This document discusses troubleshooting user data propagation in IBM Connections. It describes the data flow process where user information is pulled from the LDAP into the EMPLOYEE table and then synchronized across applications. The document outlines different areas that can be troubleshot, including checking LDAP connectivity, reviewing logs for update errors, ensuring the scheduler is running properly, and verifying messages are consumed and data is updated in member tables.

Related slideshows

Unit 2.10 - Frames
Unit 2.10 - FramesUnit 2.10 - Frames
Unit 2.10 - Frames
 
Ibm tivoli access manager for e business junctions and links redp4621
Ibm tivoli access manager for e business junctions and links redp4621Ibm tivoli access manager for e business junctions and links redp4621
Ibm tivoli access manager for e business junctions and links redp4621
 
Designing for magento
Designing for magentoDesigning for magento
Designing for magento
 
1 of 7
Download to read offline
TROUBLESHOOTING USER DATA PROPAGATION Michele Buccarello 05/10/13
Table of Contents Author...................................................................................................................................................3 Abstract.................................................................................................................................................3 DATA FLOW CONCEPT.....................................................................................................................3 DATA FLOW SCHEMA......................................................................................................................4 TROUBLESHOOT THE DIFFERENT AREA....................................................................................5 Point 1..............................................................................................................................................5 Point 2..............................................................................................................................................5 Point 3..............................................................................................................................................6 Point 4 5 6 7.....................................................................................................................................6 SPECIAL THANKS TO.......................................................................................................................7
Author Michele Buccarello Mail: buccarello.michele@gmail.com Abstract The propagation of user data in IBM Connections is a complex mechanism that allows synchronization of information between different applications of IBM Connections. In this document we will try to highlight and explain its working, to enable efficient troubleshooting and an effective problem determination. DATA FLOW CONCEPT IBM Connections can pull and synchronize user informations between applications in two ways: • With Directory Extensions enabled (DSX). In this mode every application pulls the required information directly from the EMPINST.EMPLOYEE table through JMS messages. • With Directory Extensions disabled. In this mode every application pull the user information directly from the LDAP. Normally DSX feature is disabled if the profiles application is not installed in the Connections Environment. To check if DSX is enabled search LotusConnections-Config.xml and confirm the following parameter is set profiles_directory_service_extension_enabled="true".
DATA FLOW SCHEMA 1. LDAP is the source of users information. 2. To populate EMPINST.EMPLOYEE table we can use the “sync_all_dns.sh” script or the Jython command of Profiles such as ProfilesService.updateUser(String user_email_addr, updated_properties_list) , after the update is completed the event of update is stored in the USER_PLATFORM_EVENTS table in this format 1 INSERT INTO USER_PLATFORM_EVENTS (EVENT_KEY, EVENT_TYPE, PAYLOAD, CREATED, TENANT_KEY) VALUES (values, 'user.record.update', '{"_prof.old.guid":"44911B31-2492-4AF3-91B7BA099A7E6334","_prof.email":"TEST@example.com,"_prof.key":"884de397-1024-4b2f-920dd0142aca8b8a","_prof.workLocationCode":"","_prof.orgId":"","_prof.employeeTypeCode":"","_prof.countryCode":"","_prof .usrState":0,"_prof.old.uid":"TEST_UID","_prof.lastUpdate":1378203594400,"_prof.displayName":"TEST DISPLAYNAME","_prof.distinguishedName":"CN=TEST,ou=Users,dc=EXAMPLE,dc=COM","_prof.uid":"TEST_UID","_pro f.eventType":"user.record.update","_prof.guid":"44911B31-2492-4AF3-91B7-BA099A7E6334"}', TIMESTAMP '2013-09-03 1 Note: ProfilesService.updateUser() does not query LDAP. It simply considers the data provided in the Jython script.
06:19:54', '00000000-0000-0000-0000-040508202233') The real informations are in the PAYLOAD column {"_prof.old.guid":"44911B31-2492-4AF3-91B7-BA099A7E6334", "_prof.email":"TEST@example.com, "_prof.key":"884de397-1024-4b2f-920d-d0142aca8b8a", "_prof.workLocationCode":"", "_prof.orgId":"", "_prof.employeeTypeCode":"", "_prof.countryCode":"", "_prof.usrState":0, "_prof.old.uid":"TEST_UID", "_prof.lastUpdate":1378203594400, "_prof.displayName":"TEST DISPLAYNAME", "_prof.distinguishedName":"CN=TEST,ou=Users,dc=EXAMPLE,dc=COM", "_prof.uid":"TEST_UID", "_prof.eventType":"user.record.update", "_prof.guid":"44911B31-2492-4AF3-91B7-BA099A7E6334"} 3. A “profile worker” thread runs by internal scheduled task of Profiles application and reads every row in the USER_PLATFORM_EVENTS , the profiles scheduled tasks are documented here: - http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp? lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=M anaging_Profiles_scheduled_tasks_ic45&content=pdcontent The name of the scheduled task is ProcessLifeCycleEventsTask. 4. The profile worker thread every 30 second reads the records. The worker task then sends a JMS message to two topic spaces connections.events and connections.platformCommands. The scheduler gets a batch of records, processes them and deletes them from the table. When the scheduler is done reading all batches the table becomes empty. 5. Every Application subscribes to the command topic. 6. When the DSX is enabled every application pulls the information from the message payload. If the DSX is disabled every application reads directly from LDAP the users information via WALTZ. 7. Every member table is updated with the new information. TROUBLESHOOT THE DIFFERENT AREA For every point there are different ways to troubleshoot the problem. Point 1 In this area you must check: • • If port 389 is open. If “profiles_tdi.properties” file contains the right settings Point 2 In this area you must check: • • The TDI logs if there is something wrong during the update process If the logs are not clear you can enable the debug on the TDI side.
To enable logging you may edit the profiles_tdi.properties and edit these variables: • • • • • • • • debug_managers=false debug_photos=false debug_pronounce=false debug_fill_codes=false debug_draft=false debug_update_profile=false debug_collect=false debug_special=false For a deep analysis you can enable detailed traces by editing the log4j.properties in the <TDI>/etc directory. Detailed information can be found here http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp? lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=Troublesh ooting_Tivoli_Directory_Integrator_ic45&content=pdcontent&sa=true Point 3 In this area you must check if the table EMPINST. USER_PLATFORM_EVENTS is empty, if the table isn't empty you must check the profiles scheduler status via jython command and trace. Follow this link for jython command http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp? lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=Managing _Profiles_scheduled_tasks_ic45&content=pdcontent Follow this link for enable the trace http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp? lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=Verifying _that_the_Profiles_Worker_is_running_correctly_ic45&content=pdcontent Point 4 5 6 7 In this area you must check if the JMS Queue receives the message sent from the profiles worker and every application consumes the message. A simple way to check if the messages are consumed is described here: • • http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp? lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=Tr oubleshooting_the_user_lifecycle_SPI_ic45&content=pdcontent http://www-01.ibm.com/support/docview.wss?uid=swg21266769 After the messages are consumed by all applications every member table is updated with the user information. Now to check the new value we can use the following sql queries (replacing 'DISPLAY_NAME' with the display name of the user of interest): • select * from "HOMEPAGE"."PERSON" where PERSON.DISPLAYNAME_LOWER = lower('DISPLAY_NAME');
• • • • • • • select * from "SNCOMM"."MEMBERPROFILE" where MEMBERPROFILE.LOWER_DISPLAY = lower('DISPLAY_NAME'); select * from "FORUM."DF_MEMBERPROFILE" where lower(DF_MEMBERPROFILE.MEMBERDISP) = lower('DISPLAY_NAME'); SELECT * FROM "FILES"."USER" where "USER"."LOWERCASE_NAME" = lower('DISPLAY_NAME'); select * from "ACTIVITIES"."OA_MEMBERPROFILE" WHERE OA_MEMBERPROFILE.LMEMBERDISP = lower( 'DISPLAY_NAME'); select * from "DOGEAR"."PERSON" WHERE LOWER(PERSON.DISPLAYNAME) = lower('DISPLAY_NAME'); select * from "WIKIS"."USER" where lower("USER"."NAME") = lower('DISPLAY_NAME'); select * from "BLOGS"."ROLLERUSER" WHERE LOWER(ROLLERUSER.USERNAME) = lower('DISPLAY_NAME'); SPECIAL THANKS TO Michael Ahern and Francesco De Collibus from IBM for the review of this article.

More Related Content

IBM Connections 4.5 User Data Propagation.

  • 2. Table of Contents Author...................................................................................................................................................3 Abstract.................................................................................................................................................3 DATA FLOW CONCEPT.....................................................................................................................3 DATA FLOW SCHEMA......................................................................................................................4 TROUBLESHOOT THE DIFFERENT AREA....................................................................................5 Point 1..............................................................................................................................................5 Point 2..............................................................................................................................................5 Point 3..............................................................................................................................................6 Point 4 5 6 7.....................................................................................................................................6 SPECIAL THANKS TO.......................................................................................................................7
  • 3. Author Michele Buccarello Mail: buccarello.michele@gmail.com Abstract The propagation of user data in IBM Connections is a complex mechanism that allows synchronization of information between different applications of IBM Connections. In this document we will try to highlight and explain its working, to enable efficient troubleshooting and an effective problem determination. DATA FLOW CONCEPT IBM Connections can pull and synchronize user informations between applications in two ways: • With Directory Extensions enabled (DSX). In this mode every application pulls the required information directly from the EMPINST.EMPLOYEE table through JMS messages. • With Directory Extensions disabled. In this mode every application pull the user information directly from the LDAP. Normally DSX feature is disabled if the profiles application is not installed in the Connections Environment. To check if DSX is enabled search LotusConnections-Config.xml and confirm the following parameter is set profiles_directory_service_extension_enabled="true".
  • 4. DATA FLOW SCHEMA 1. LDAP is the source of users information. 2. To populate EMPINST.EMPLOYEE table we can use the “sync_all_dns.sh” script or the Jython command of Profiles such as ProfilesService.updateUser(String user_email_addr, updated_properties_list) , after the update is completed the event of update is stored in the USER_PLATFORM_EVENTS table in this format 1 INSERT INTO USER_PLATFORM_EVENTS (EVENT_KEY, EVENT_TYPE, PAYLOAD, CREATED, TENANT_KEY) VALUES (values, 'user.record.update', '{"_prof.old.guid":"44911B31-2492-4AF3-91B7BA099A7E6334","_prof.email":"TEST@example.com,"_prof.key":"884de397-1024-4b2f-920dd0142aca8b8a","_prof.workLocationCode":"","_prof.orgId":"","_prof.employeeTypeCode":"","_prof.countryCode":"","_prof .usrState":0,"_prof.old.uid":"TEST_UID","_prof.lastUpdate":1378203594400,"_prof.displayName":"TEST DISPLAYNAME","_prof.distinguishedName":"CN=TEST,ou=Users,dc=EXAMPLE,dc=COM","_prof.uid":"TEST_UID","_pro f.eventType":"user.record.update","_prof.guid":"44911B31-2492-4AF3-91B7-BA099A7E6334"}', TIMESTAMP '2013-09-03 1 Note: ProfilesService.updateUser() does not query LDAP. It simply considers the data provided in the Jython script.
  • 5. 06:19:54', '00000000-0000-0000-0000-040508202233') The real informations are in the PAYLOAD column {"_prof.old.guid":"44911B31-2492-4AF3-91B7-BA099A7E6334", "_prof.email":"TEST@example.com, "_prof.key":"884de397-1024-4b2f-920d-d0142aca8b8a", "_prof.workLocationCode":"", "_prof.orgId":"", "_prof.employeeTypeCode":"", "_prof.countryCode":"", "_prof.usrState":0, "_prof.old.uid":"TEST_UID", "_prof.lastUpdate":1378203594400, "_prof.displayName":"TEST DISPLAYNAME", "_prof.distinguishedName":"CN=TEST,ou=Users,dc=EXAMPLE,dc=COM", "_prof.uid":"TEST_UID", "_prof.eventType":"user.record.update", "_prof.guid":"44911B31-2492-4AF3-91B7-BA099A7E6334"} 3. A “profile worker” thread runs by internal scheduled task of Profiles application and reads every row in the USER_PLATFORM_EVENTS , the profiles scheduled tasks are documented here: - http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp? lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=M anaging_Profiles_scheduled_tasks_ic45&content=pdcontent The name of the scheduled task is ProcessLifeCycleEventsTask. 4. The profile worker thread every 30 second reads the records. The worker task then sends a JMS message to two topic spaces connections.events and connections.platformCommands. The scheduler gets a batch of records, processes them and deletes them from the table. When the scheduler is done reading all batches the table becomes empty. 5. Every Application subscribes to the command topic. 6. When the DSX is enabled every application pulls the information from the message payload. If the DSX is disabled every application reads directly from LDAP the users information via WALTZ. 7. Every member table is updated with the new information. TROUBLESHOOT THE DIFFERENT AREA For every point there are different ways to troubleshoot the problem. Point 1 In this area you must check: • • If port 389 is open. If “profiles_tdi.properties” file contains the right settings Point 2 In this area you must check: • • The TDI logs if there is something wrong during the update process If the logs are not clear you can enable the debug on the TDI side.
  • 6. To enable logging you may edit the profiles_tdi.properties and edit these variables: • • • • • • • • debug_managers=false debug_photos=false debug_pronounce=false debug_fill_codes=false debug_draft=false debug_update_profile=false debug_collect=false debug_special=false For a deep analysis you can enable detailed traces by editing the log4j.properties in the <TDI>/etc directory. Detailed information can be found here http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp? lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=Troublesh ooting_Tivoli_Directory_Integrator_ic45&content=pdcontent&sa=true Point 3 In this area you must check if the table EMPINST. USER_PLATFORM_EVENTS is empty, if the table isn't empty you must check the profiles scheduler status via jython command and trace. Follow this link for jython command http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp? lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=Managing _Profiles_scheduled_tasks_ic45&content=pdcontent Follow this link for enable the trace http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp? lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=Verifying _that_the_Profiles_Worker_is_running_correctly_ic45&content=pdcontent Point 4 5 6 7 In this area you must check if the JMS Queue receives the message sent from the profiles worker and every application consumes the message. A simple way to check if the messages are consumed is described here: • • http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp? lookupName=IBM+Connections+4.5+Documentation#action=openDocument&res_title=Tr oubleshooting_the_user_lifecycle_SPI_ic45&content=pdcontent http://www-01.ibm.com/support/docview.wss?uid=swg21266769 After the messages are consumed by all applications every member table is updated with the user information. Now to check the new value we can use the following sql queries (replacing 'DISPLAY_NAME' with the display name of the user of interest): • select * from "HOMEPAGE"."PERSON" where PERSON.DISPLAYNAME_LOWER = lower('DISPLAY_NAME');
  • 7. • • • • • • • select * from "SNCOMM"."MEMBERPROFILE" where MEMBERPROFILE.LOWER_DISPLAY = lower('DISPLAY_NAME'); select * from "FORUM."DF_MEMBERPROFILE" where lower(DF_MEMBERPROFILE.MEMBERDISP) = lower('DISPLAY_NAME'); SELECT * FROM "FILES"."USER" where "USER"."LOWERCASE_NAME" = lower('DISPLAY_NAME'); select * from "ACTIVITIES"."OA_MEMBERPROFILE" WHERE OA_MEMBERPROFILE.LMEMBERDISP = lower( 'DISPLAY_NAME'); select * from "DOGEAR"."PERSON" WHERE LOWER(PERSON.DISPLAYNAME) = lower('DISPLAY_NAME'); select * from "WIKIS"."USER" where lower("USER"."NAME") = lower('DISPLAY_NAME'); select * from "BLOGS"."ROLLERUSER" WHERE LOWER(ROLLERUSER.USERNAME) = lower('DISPLAY_NAME'); SPECIAL THANKS TO Michael Ahern and Francesco De Collibus from IBM for the review of this article.