The mechanism that is available for required operation data caching is the <operation-data> element. Because you might need to provision the SecureLogin account from either an <add> or <modify-password> command, a logical place to implement the non-static data caching policy is in the Subscriber Command Transformation policy. The following example shows a typical SecureLogin Provisioning <operation-data> element:
<operation-data> <nsl-sync-data> <nsl-target-user-dn> cn=GLCANYON,ou=finance,dc=prod,dc=testco,dc=com </nsl-target-user-dn> <nsl-app-username>GCANYON</nsl-app-username> <password><!-- content suppressed --></password> <nsl-passphrase-answer>50024222</nsl-passphrase-answer> </nsl-sync-data> </operation-data>
In the sample Finance department scenario from Figure 2-1, the following values are needed to populate the operation data payload:
The <nsl-target-user-dn> element is populated with the value of the DirXML-ADContext attribute from the Identity Vault, which was set by the Active Directory driver. To ensure that the SAP User driver is notified when the value is set by the AD driver, make sure you add DirXML-ADContext to the Subscriber filter as a notify attribute.
The <nsl-app-username> element is populated by the value of the sapUsername attribute which, for an <add> command, is generated by the Create policy of the SAP User driver and is therefore available as an operation attribute. With the SAP User driver, the SAP User name value is part of the association value. This means that for password modification events the names are parsed from the association.
The password element is populated with the value of the <password> element in the <add> or <modify-password> command.
The <nsl-passphrase-answer> element is populated with the value of the workforceID attribute from the Identity Vault, which was set by the SAP HR driver. Although this value should be set during initial provisioning to the Identity Vault, it is still a good practice to add workforceID to the Subscriber filter as a notify attribute.