ObjectSynchronizationType (Complex Type)

Items

• name

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Free-form name. Used for diagnostics purposes.

• description

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Free-form textual description of the object. It is supposed to describe the object or a construct that it is attached to.

  This information may be presented to midPoint users, even to ordinary end users. For example role description may be presented to users when they are selecting roles to request. Therefore the description should be written in a language that the users can understand.

  Description is assumed to be a plan, non-formatted text. Amount of white space is considered insignificant. E.g. leading and trailing white space may be skipped, multiple spaces can be collapsed to one and so on.

• documentation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Technical documentation for a particular object or construct.

  The purpose of this element is to document system configuration and behavior. The documentation will not be presented to end users. In fact, it will probably not be presented at all in midPoint user interface. This documentation element is supposed to be a part of the technical documentation of midPoint deployment. The tools than generate deployment configuration will look for these elements and combine them to compiled documentation document.

  AsciiDoc formatting is assumed for this element. Any leading or trailing whitespace is skipped. Indentation equivalent to he indentation of the first non-blank line of text is also skipped.

• objectClass

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Object classes that will be processed by this definition. This property should NOT be multi-value. Multiple object classes here do not make sense any more. That might make sense in early midPoint versions. But we cannot have several object classes that map to the same kind/intent. This is still formally multi-valued property in the schema, so we won't break upgrades. But multiple values in this property won't work.

• kind

  Flags: RAM,runtime,AVals:4

  Multiplicity: [0,1]

  Shadow kind assumed by this definition. If not specified then the kind defined by schemaHandling part will be used. However this element can define a more specific kind in case that the schemaHandling part is ambiguous (e.g. the same objectclass is used for two kinds).

• intent

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Shadow intent assumed by this definition. If not specified then the intent defined by schemaHandling part will be used. However this element can define a more specific intent in case that the schemaHandling part is ambiguous (e.g. the same objectclass is used for two intents).

• focusType

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Type of the focus that would be applied to this type. If not specified the User (c:UserType) is assumed.

• enabled

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Flag indicating if this synchronization specification is enabled. If it is not, then the system will ignore this definition. If enabled, the synchronization should start with most recent change after enabling synchronization. It will NOT pull in even the changes that were done during disabled synchronization.

  If this flag is not present the synchronization is assumed to be enabled. This flag is meant to act as a tool to temporarily disable synchronization without losing the configuration and state or for forcing the synchronization engine to "skip" some changes.

  Note that this is different from disabling/deleting the synchronization task. If the task is stopped, midPoint will not poll for changes at all. This means that the changes will still be "pending" on the resource and once the task is enabled it will pull such changes. On the other hand, disabling synchronization using this flag and leaving the task running will "acknowledge" all changes without doing anything.

  Also note that disabling synchronization using this flag will disable all the flavors, e.g. it will also disable import from resource.

• condition

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Expression that is evaluated to check whether this definition is applicable to a particular shadow. It is assumed to return a boolean value. If it returns 'true' then the shadow will be processed by this definition. If it returns 'false' it will not be processed.

  If no condition is present then all applicable shadows will be processed.

• correlation

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Correlation filter expression. Running the query should return a list of candidate focus entries that may be owners of a particular shadow.

  Correlation is an rough but an efficient way how to relate the shadow (e.g. an account) to a focus (e.g. an user). The correlation expression is in fact just a search filter that can contain expressions inside it. If correlation search returns more that one entry, confirmation expression will be executed for each of them.

  The filter in this case is conditional, i.e. there can be specified an expression that denotes a necessary condition for the filter to be applied.

• confirmation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Confirmation expression. The arguments are an account and a candidate owner (user). The confirmation expressions should return true if the user should be owner of the account. It should return false if the user cannot be owner of the account. The evaluation of the confirmation expression may be relatively inefficient, as it will only be run for candidate entries returned by correlation expression. The expression variables should be set as follows: $user - the candidate user object (one of the results of correlation expression) $account - the changed account object

• correlationDefinition

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Definition of the correlation process. Normally, this would be called "correlation", but that name has been historically used to specify correlation filters. Hence this one.

• objectTemplateRef

  Flags: RAM

  Multiplicity: [0,1]

  Object template used in case the midPoint (focus) objects are created or modified. This overrides the system global object templates. This option is usually used set per-resource user template.

• reconcile

  Flags: RAM,runtime

  Multiplicity: [0,1]

  If set to true, applicable synchronization reactions will attempt to reconcile the real attributes from the resource with the state of the midPoint repository. This may require additional read and recompute, therefore may be slightly less efficient. If set to false, attribute values will not be reconciled. If not present the attribute values will only be reconciled if they are available ("automatic" mode). No additional read will be executed.

• limitPropagation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  If set to true, applicable synchronization reactions will propagate changes only form/to source resource. In the case focus contains links to another resource this will be not recomputed and after reaction execution there may be small inconsistencies. It can improve performance for example for initial import. Default value is false.

• opportunistic

  Flags: RAM,runtime

  Multiplicity: [0,1]

  If set to true midPoint will try to link and synchronize objects whenever possible. E.g. it will link accounts in a case if an account with a conflicting account is found and correlation expression matches. MidPoint can be quite aggressive in this mode therefore this switch is used to turn it off. It is on by default.

• reaction

  Flags: RAM,runtime

  Multiplicity: [0,-1]