Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 Jack Sparrow.

Code Block
xml
xml
titleUser
<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 inbound and outbound mappings.

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:

Code Block
xml
xml
titleUser
<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.

...