Example: Modification Scenario
The best way how to describe synchronization is to illustrate it using an example.
The change to the first account is detected by the live synchronization or reconciliation logic of midPoint. The method of change detection does not really matter. As the change is detected, the provisioning component make makes sure that the corresponding AccountShadow object is updated in midPoint repository (see Common Data Model). Account Shadow usually contains only identifiers and therefore it should be already up-to-date in this case.
The synchronization logic in the provisioning subsystem will then issue a change notification that will is picked up by the IDM model. IDM model will try to figure out what's going on (so called situation, it is described in the second example below). In this case it simply means that the IDM model will check if the account has an owner, that means whether it is already linked to a user. This example assumes that it has an owner, so locating appropriate user object is straightforward.
Following XML snippet shows a user object. It can be seen that there is appropriate
linkRef (in 2.1.x versions
accountRef is used instead) that points to the account shadow object provided above. Please also note that the full name of the user is
<user oid="c0c010c0-d34d-b33f-f00d-111111111111"> <name>jack</name> <fullName>Jack Sparrow</fullName> <givenName>Jack</givenName> <familyName>Sparrow</familyName> ... <linkRef oid="c0c010c0-d34d-b33f-f00d-222111111111"/> <linkRef oid="c0c010c0-d34d-b33f-f00d-222111111112"/> </user>
The IDM model logic will need needs to map changes in an account to the changes to a user. The
schemaHandling part of the resource definition is used for that. The schema handling contains supplementary definition how to handle each of the account attributes. That definition may also contain inbound mapping that define how to handle change of the attribute and propagate it inside within midPoint.
The following XML snippet describes the
schemaHandling part of the Resource where the change originated. It describes a default account type for the resource. The account type is referring refers to the resource schema (the
schema part), where appropriate XSD type is defined. This part defines capabilities of the Resource and connector. MidPoint can influence that only slightly. The way how midPoint handles the attributes is described in the
schemaHandling part. Some of the attributes are described here in more details, including
Please note the
schemaHandling definition of attribute
ri:cn. It defines an inbound mapping that tells telling midPoint to copy the value of this attribute to the
fullName property of User object.
As the model is processing the change notification it encounters the change of
ri:cn attribute. It looks into the
schemaHandling definition for that attribute and finds out that the value of that attribute should be copied to the
fullName property of user. So model transforms the modification of account attribute
cn to the modification of user attribute
fullName. Model will apply applies the modification to the user object resulting in the following state of the user:
<user oid="c0c010c0-d34d-b33f-f00d-111111111111"> <name>jack</name> <fullName>cpt. Jack Sparrow</fullName> <givenName>Jack</givenName> <familyName>Sparrow</familyName> ... <linkRef oid="c0c010c0-d34d-b33f-f00d-222111111111"/> <linkRef oid="c0c010c0-d34d-b33f-f00d-222111111112"/> </user>
After applying that the change to the user midPoint behaves exactly as if the user was modified from any other source. It This means that midPoint will try to apply (provision) user changes to all user's accounts. Therefore midPoint will take takes user's other account (which is an AD account in this case), fetch definition of AD resource and look looks into the
schemaHandling section. But this time it will look looks for outbound expressions. The resource definition for the AD resource looks like this:
The model looks through all the outbound expressions, looking where the change of the
fullName can be applied. In that way it figures out that the
cn attribute of the AD resource account should be set to a copy of the
fullName property of the user. Therefore model invokes provisioning service to change the account attribute.