ResourceConsistencyType (Complex Type)

Items

• avoidDuplicateValues

  Flags: RAM,runtime

  Multiplicity: [0,1]

• shadowConstraintsCheck

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

• useProposedShadows

  Flags: RAM,runtime

  Multiplicity: [0,1]

  If set to true then midPoint will try to create shadows in "proposed" lifecycle state even before an operation is executed. The proposed shadows may be used in combination with shadowConstraintsCheck to reduce probability of identifier conflicts for resources with slow create/rename operations. See also avoidDuplicateOperations and recordPendingOperations properties. This feature is EXPERIMENTAL. Use with care.

• recordPendingOperations

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

  TODO See also avoidDuplicateOperations and useProposedShadows properties. This feature is EXPERIMENTAL. Use with care.

• avoidDuplicateOperations

  Flags: RAM,runtime

  Multiplicity: [0,1]

  When set to true, midPoint will try to avoid executing duplication operations on the resource. If an operation is already underway the duplicate operation will be ignored. See also recordPendingOperations and useProposedShadows properties. This feature is EXPERIMENTAL. Use with care.

• operationGroupingInterval

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Turns on operation grouping feature and specifies a grouping interval. Operation grouping is feature that groups several operations on a resource into a single operation. This can be used in case midPoint creates a lot of small operations. But we want to group all of them into a single big operation. This means that small operations are delayed for a specified interval. Then all the operations are grouped into a single operation and executed at once. This approach slightly delays the operations. But it may be huge advantage for resources where the operations are costly (manual resources, slow resources).

  This parameter specifies a maximum interval between the operation is requested and the operation is started. First operation will be postponed for the specified interval. When the interval is over the operation will be executed. All the operations that have accumulated during the interval will be grouped together and executed.

  Note: provisioning propagation task must be running to execute the operations.

• validateSchema

  Flags: RAM,runtime

  Multiplicity: [0,1]

• caseIgnoreAttributeNames

  Flags: RAM,runtime

  Multiplicity: [0,1]

• postpone

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Postpone the operation in case that an error is encountered. The operation will be re-tried later (consistency mechanism). DEPRECATED. Use operationRetryMaxAttempts instead.

• discovery

  Flags: RAM,runtime

  Multiplicity: [0,1]

• connectorErrorCriticality

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Specifies a method that midPoint will use to evaluate criticality of errors: which errors are considered to be critical (stops the operation) and which error are non-critical (operation continues). By default network errors are not considered critical, other errors are critical. EXPERIMENTAL: use with care. Use of this option may be DANGEROUS. Especially when used to set generic errors as non-critical. Generic errors means that midPoint has absolutely no idea what is going on. Otherwise the error would be classified to a more specific category. Continuing an operation where midPoint has no idea what is going on may have severe consequences. The results are unpredictable. If you use this setting then you are on your own. Hic sunt liones.

• pendingOperationGracePeriod

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Duration for which the completed asynchronous operations that are kept in the shadow objects are considered during computation. This may be needed to avoid repeating operations in semi-manual resources. By default there is no grace period and completed operations are not considered during computations.

• pendingOperationRetentionPeriod

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Duration for which the completed asynchronous operations will be kept in the shadow objects. This may be desirable for visibility, e.g. if the administrator wants to inspect result of an asynchronous operation.

• operationRetryPeriod

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Duration for which the system will wait before re-trying failed operation.

• operationRetryMaxAttempts

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Maximum number of attempts to re-try a failed operation. If set to 0 then operation re-tries are disabled.

• deadShadowRetentionPeriod

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Duration for which the system will keep dead shadows. After this interval has passed the dead shadows are deleted. Note: this may also be influenced by pendingOperationGracePeriod. Dead shadow may be kept for longer than the interval specified in deadShadowRetentionPeriod if that is needed to for evaluation of grace period.

• reshreshOnRead

  Flags: RAM,runtime

  Multiplicity: [0,1]

  If set to true then midPoint will always refresh shadow when it is retrieved. Refreshing a shadow means that the status of asynchronous (e.g. manual) opearions is checked, unfinished operations may be retried and so on. In this case shadow will always be as fresh as it can be. But read may be slower and there may be strange errors (e.g. reading a shadow may cause "already exists" error because pending ADD operation in the shadow was executed during that read). If set to false (which is the default) then refresh will not be executed during read operations - unless the refresh is explicitly requested by midPoint code (e.g. during reconciliation).