Novell Home

Storing Multiple Attribute Changes in a Single Document, with the Notes Driver

Novell Cool Solutions: Feature
By Perry Nuffer

Digg This - Slashdot This

Posted: 27 Jun 2007
 

Problem

A Forum reader recently asked:

"Can the Notes driver be configured so that changing multiple attributes results in just one document for al the attributes instead of one document for each changing attribute?

I've been testing changing 2 attributes and most of the time the trace shows *one* document for each attribute - and sometimes (like below) one document for *both* changing attributes. (In this particulair trace does a change in FirstName also triggers a change of the InternetAddress value.)

The problem I'm facing is changing First and Lastname together. Most of the time 3 documents (also one for InternetAddress) are presented, resulting in 2 (incorrect) AdminP requests.

I just want *one* document containing all the changing attributes resulting in one *correct* AdminP request. How can that be accomplished?"

And here's the response from Perry Nuffer ...

Solution

No. And yes. No, because that is how the IDM engine has received the events, independent and separate from each other, and therefore will report them to the driver as separate XDS documents. This cannot be changed. Yes, because the driver can utilize policy to query the Identity Vault for any missing attributes that it may need.

If both of the user's 'Given Name' and 'Surname' attributes are modified at relatively the same time, yet produce separate events documents (XDS documents), then it is possible to write a driver policy that will query back to the IDM vault to get a missing attribute when one of the attributes is changing.

See the examples below for illustrations of how this can be done. Example 1 (CheckFirstAndLastNameForAdminP.xml) seems to target your specific problem. Example 2 (CheckAllNamingFieldsForAdminP.xml) is more universal in its application, but it is less efficient.

If the cause of the problem is a non-responsive AdminP process, then the only thing the Notes driver can do is attempt to 'kick' the AdminP process into action with its 'tell-adminp-process' custom parameter.

Remember that due to the delayed nature of the AdminP process, and the strict event-based nature of the IDM engine, sometimes certain AdminP commands cannot be processed (without an error). This is because at the time they were generated, the 'yet-to-be' processed data in the AdminP request queue had not been applied to the current Notes Database, and as such these latter requests in the AdminP queue were submitted with 'stale' naming information.

An example of this problem can be demonstrated by sending one rename request immediately after another rename request for the same Notes user. The second rename request will fail because the original rename request is processed and the object's name changes. When the second rename request is processed, the name for which it is destined no longer exists. Such is the case when dealing with AdminP, and this same problem also exists when using Lotus tools such as Domino Administrator. The referenced policy above will also exhibit this same type of AdminP rename anomaly when more than one change happens to any of the common naming fields (FirstName/MiddleInitial/LastName) prior to processing all the previous 'Initiate Rename in Domino Directory' AdminP requests for that same object.

Lothar Haegar adds:

IDM may sync too fast attempting to query the (new) missing attribute, if you are changing both Surname and Initials at the 'same' moment. In that case, an xpath call to java.lang.Thread.sleep() could help. You can put in a 10-second delay before querying for the second value to see if that helps.

Example 1

<?xml version="1.0" encoding="UTF-8" ?> 
- <policy>
- <rule>
  <description>Check for 'Given Name' change to update AdminP naming fields</description> 
- <conditions>
- <and>
  <if-op-attr name="Given Name" op="changing" /> 
  <if-op-attr name="Surname" op="not-changing" /> 
  <if-class-name op="equal">User</if-class-name> 
  </and>
  </conditions>
- <actions>
- <do-set-dest-attr-value class-name="User" name="Surname">
- <arg-value type="string">
  <token-attr name="Surname" /> 
  </arg-value>
  </do-set-dest-attr-value>
- <do-set-dest-attr-value class-name="User" name="Internet EMail Address">
- <arg-value type="string">
  <token-attr name="Internet EMail Address" /> 
  </arg-value>
  </do-set-dest-attr-value>
  </actions>
  </rule>
- <rule>
  <description>Check for 'Surname' change to update AdminP naming fields</description> 
- <conditions>
- <and>
  <if-op-attr name="Surname" op="changing" /> 
  <if-op-attr name="Given Name" op="not-changing" /> 
  <if-class-name op="equal">User</if-class-name> 
  </and>
  </conditions>
- <actions>
- <do-set-dest-attr-value class-name="User" name="Given Name">
- <arg-value type="string">
  <token-attr name="Given Name" /> 
  </arg-value>
  </do-set-dest-attr-value>
- <do-set-dest-attr-value class-name="User" name="Internet EMail Address">
- <arg-value type="string">
  <token-attr name="Internet EMail Address" /> 
  </arg-value>
  </do-set-dest-attr-value>
  </actions>
  </rule>
  </policy>

Example 2

  <?xml version="1.0" encoding="UTF-8" ?> 
- <policy>
- <rule>
  <description>Check for all AdminP naming fields</description> 
- <conditions>
- <or>
  <if-class-name op="equal">User</if-class-name> 
  </or>
- <or>
  <if-op-attr name="Surname" op="changing" /> 
  <if-op-attr name="Given Name" op="changing" /> 
  <if-op-attr name="Initials" op="changing" /> 
  <if-op-attr name="Internet EMail Address" op="changing" /> 
  </or>
  </conditions>
- <actions>
- <do-set-dest-attr-value class-name="User" name="Given Name">
- <arg-value type="string">
  <token-attr name="Given Name" /> 
  </arg-value>
  </do-set-dest-attr-value>
- <do-set-dest-attr-value class-name="User" name="Surname">
- <arg-value type="string">
  <token-attr name="Surname" /> 
  </arg-value>
  </do-set-dest-attr-value>
- <do-set-dest-attr-value class-name="User" name="Initials">
- <arg-value type="string">
  <token-attr name="Initials" /> 
  </arg-value>
  </do-set-dest-attr-value>
- <do-set-dest-attr-value class-name="User" name="Internet EMail Address">
- <arg-value type="string">
  <token-attr name="Internet EMail Address" /> 
  </arg-value>
  </do-set-dest-attr-value>
  </actions>
  </rule>
  </policy>


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell