Skip to main content
Version: Cloud

Tracking history of data objects

The object history tracking consists of the following components implementing different aspects of the functionality:

  • The Persistence service is responsible for collecting data from the Enterprise server and the Role and Policy Engine, then merging it to the ODS. It also includes new and deleted resource hierarchies in the process.
  • The history tracking is responsible for the data transfer from ODS to ODW as a continuous background process. It allows you, for example, to monitor inconsistent objects in ODS, errors, and history of changes introduced to chosen properties of a data object type.

The following items are transferred by the history tracking feature to the ODW:

  • Identity
  • System
  • Resource
  • Context Assignment
  • Resource folders
  • Contexts
  • System categories

The data object transfer is initiated in two ways:

  • When a change to the object is introduced.
  • A timer value, set to two minutes, is reached.

All of the mentioned data object types have preconfigured properties, allowing for the export to be correct and successful with the default values of the settings. Specific fields of those data objects are mapped to the corresponding fields in ODW and values are configured in the Warehouse attribute name setting of the data object type property.

note

You can export additional data for the following data object types:

  • Identity
  • System
  • Resource
  • Context Assignment

You can achieve it by configuring the Warehouse attribute name setting in other properties. This way they will be exported as extension attributes.

Additionally, when you enable the Track history in data warehouse setting for other properties, it results in history tracking generating a new version of object history rather than just updating the current version of data object.

Omada recommends

Enable the Track history in data warehouse setting only in properties that require keeping all historical values.

Context type​

A Data Object Type can be used as a Context Type. It requires the following attributes to be configured:

  • ComposedBusinessKey - a unique value for a specific context
  • Name
  • ShortName
  • Parent_ComposedBusinessKey - a reference property pointing towards a parent context

Additionally, there are two following attributes supported:

  • Type
  • SubType

Any other configured property is considered as an extension attribute.

For the Data Object Type to serve as a Context Type, it is also required that it has the Synchronize to ODW setting enabled and the Owner Property has to point to the correct identity reference property of the data object type.

note

When the context is set as personal, the parent assignment is also generated based on the parent context.

When the Membership property is configured, the context assignment is generated when identities are referencing the context by the membership property.

Handling inconsistencies​

During data transfer, the following actions are performed:

  • Inconsistent entries are marked as failed
  • Failed entries are marked for a retry action
  • Error cleanup
  • Watermark reset
  • Extension attributes are maintained

Due to the asynchronous nature of transferring data to ODS, the order of transferred data might not be appropriate (for example, resource is loaded before the resource folder). This results in marking objects, lacking their dependencies, as inconsistent. Afterwards, the inconsistencies are reevaluated, and if the counter reaches 5 failed attempts the status is changed to permanently inconsistent.

note

The 5 attempts at reevaluating inconsistencies amount to around 25 minutes.

Inconsistencies troubleshooting​

The inconsistencies are exceptions that result from an improper configuration or malfunctions. Beneath you can find scenarios that may lead to the permanently inconsistent status and suggestions how to resolve them.

  1. Transient error in infrastructure

    Probable cause: The data has been transferred, but with a substantial delay.

    Proposed solution: Reset the inconsistency flag, resulting in reattempt of history tracking feature.

  2. Data error

    Probable cause: Data object has a wrong value in a reference property.

    Proposed solution: Update the object in the Enterprise Server. The object is then synchronized, resolving the inconsistency.

  3. Incorrect mapping

    Probable cause: The advanced configuration of mapping from ODS to ODW is incorrect.

    Proposed solution: Correct the mappings and reset the inconsistency flag.