ResourceConsistencyType (Complex Type)

Items

• avoidDuplicateValues

  Flags: RAM,runtime

  Multiplicity: [0,1]

  When set to true, midPoint will try to avoid adding attribute values that are already there and remove values that are not there. Some resources do not tolerate such operations and they respond with errors. However midPoint cannot rely on transactions. MidPoint's lock-free relativistic model provides the necessary consistency, occasional redundant additions or deletions may happen. If this option is turned on then midPoint will read the data from resource right before the operation and filter our any redundant changes. This requires additional operation and it increases the risk of inconsistencies. However it is the only practical option for some resources.

• shadowConstraintsCheck

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

  Shadow constraint uniqueness setting. It mostly applies to shadow uniqueness. Uniqueness is checked by the resource under normal circumstances. This option can be used to turn on additional checks. Those checks may be needed to diagnose configuration issues or bugs (e.g. "duplicate shadow" problems). Or it may be used in case that the resource cannot check uniqueness by itself (e.g. in case of manual or asynchronous resources).

• 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]

  If set to true then midPoint will validate the schema of objects that leave and enter midPoint by the connectors. MidPoint will checks if data types and multiplicity is correct and issue hard errors in any mismatch. EXPERIMENTAL: this feature is used mostly for internal checks during development and testing. It is not intended for production use. Those checks may slow the system down and they may also may impact robustness. MidPoint is usually able to deal data types that are slightly wrong and auto-correct them. Enabling this feature will cause that an error is thrown even if cases that may get auto-corrected.

• caseIgnoreAttributeNames

  Flags: RAM,runtime

  Multiplicity: [0,1]

  If set to true then midPoint will ignore the case of the attribute names. In that case midpoint will normalize any attribute names with regard to the resource schema.

• 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 leones.

• 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]

  WARNING: There is a this property. Use the correct form "refreshOnRead" instead.

• refreshOnRead

  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) operations 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).