IBM Support

Change Polling in Maximo with VMMSYNC

Technical Blog Post


Change Polling in Maximo with VMMSYNC


I've been working an issue with a colleague recently regarding Change Polling with the VMMSYNC cron task. When using Tivoli Directory Server there is a key step that is missing in current documentation that isn't needed with Active Directory, missing this step will prevent Change Polling from working. Before I go into the the missing piece regarding Tivoli Directory Server, I will explain a bit more what Change Polling does.

In Maximo change polling functionality was implemented. When enabled change polling allows the VMMSYNC to perform incremental synchronization of required changes, instead of a full synchronization of the database and it's users on each run. This works similar to LDAPSYNC which uses the LDAPSYNCPARAMS table to compare the HighestCommitedUSN attribute in the database to the usnChanged value in Active Directory to determine what needs to be synchronized into Maximo.

With Tivoli Directory Server there is no usnChanged value to compare what's currently be synchronized, so we need to enable the Change Polling database in order for this to happen. To enable the database open up the IBM Tivoli Directory Server Instance Administration Tool, select your current instance for TDS and click on 'manage' as seen below.




The configuration tool will now open a panel of options, choose 'Manage changelog' and check  'Enable change log database'. Once you click update, you will be required to stop and restart the instance in order for the changes to take affect as you see below.





The above two options are the only difference in configuration between using Change Polling with VMMSYNC and Tivoli Directory Server over the Active Directory Configuration. Going forward the steps can be used for both directory types, the next step is to enable change polling in WebSphere for your repository. To do this open a bash or cmd window and change directory to \IBM\WebSphere\AppServer\bin and run the following commands

1. wsadmin.bat -lang jython

2. AdminTask.updateIdMgrRepository('[-id ldaprep -supportChangeLog native]')


In step #2 you will want to change the -id ldaprep to the name of the repository you want to enable change polling on, for example.




Once the changes are done, restart your WAS services and synchronize the node. The rest of the configuration is done in Maximo with the Cron Task Setup application. For VMMSYNC In the user and group mapping xml files the attribute <attribute>changeType</attribute> will need to be added to the attributes section as seen below.

Group Mapping


User Mapping


Once the XML is changed the only step left is to update the 'Change Polling' flag from 0 to 1 and reload the cron task.





You will now be to perform incremental synchronization instead of full synchronization using the VMMSYNC crontask. If there are no changes to be processed your log will print the following entry, to confirm it's working.


 [DEBUG] Search response for current checkpoint:
<?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:xsi=";
    xmlns:sdo="commonj.sdo" xmlns:wim=""&gt;
    <wim:controls xsi:type="wim:ChangeResponseControl">

 [INFO] BMXAA6789I - VMM Synchronizer determined that no synchronization is needed.

* Note to force a full synchronization you can run the cleanldapsyncparams.bat file located in ibm\smp\maximo\tools\maximo\internal



[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSLKT6","label":"IBM Maximo Asset Management"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]