Chat now with support
Chat with Support

Identity Manager 8.1 - Configuration Guide

About this guide One Identity Manager software architecture Customizing the One Identity Manager default configuration Adjusting the One Identity Manager base configuration One Identity Manager schema basics Editing the user interface
Object definitions for the user interface User interface navigation Forms for the user interface Statistics in One Identity Manager Extending the Launchpad Task definitions for the user interface Applications for configuring the user interface Icons and images for configuring the user interface Using predefined database queries
Localization in One Identity Manager Process orchestration in One Identity Manager
Setting up Job servers in Designer Configuring the One Identity Manager Service Handling processes in One Identity Manager
Tracking changes with process monitoring Conditional compilation using preprocessor conditions Scripts in One Identity Manager Reports in One Identity Manager Adding custom tables or columns to the One Identity Manager schema Web service integration SOAP Web Service One Identity Manager as SPML provisioning service provider Processing DBQueue tasks Appendix: Configuration files of the One Identity Manager Service

Process tracking for DBQueue Processor operations

In order to track inherited calculations as a result of changes to the system, the GenProcID is always passed to the DBQueue Processor operation. There may only be one entry in the DBQueue for each operation and object in case of follow-on operations. To map such processes, a new GenProcID is issued and used in subsequent processes. The conflicting processes and their GenProcID’s are saved in the table DialogProcessSubstitute.

When a new GenProcID is created for conflicting processes, the following rules apply:

  • Several of the same DBQueue Processor operations on one object are merged into one process (one GenProcID). This uses existing substitute processes if the number is identical to the predecessor (with respect to the root processes).
  • If further conflicts occur in the sequence, the GenProcIDs that have already been replaced are reset to the original and a new substitute is created.
  • A substitute is only valid for one set of original processes.
Related Topics

Example of replacing the GenProcID

A hierarchical role structure exists which consists of 4 roles O1, O2, O3 and O4. Employee X is assigned to roles O1, O4 and O3. The assignment of applications to roles is depicted in the following:

Figure 33: Role structure as in the example above

Three processes run between two DBQueue Processor executions, each with its own GenProcID:

  • P1: Application A1 is assigned to the role O1
  • P2: Application A2 is assigned to the role O1
  • P3: Application A3 is assigned to the role O2

The following operations are in the DBQueue (table DialogDBQueue) and in the process information:

Operation Object GenProcID
OrgHasApp O1 P1
OrgHasApp O1 P2
OrgHasApp O2 P3

The operation OrgHasApp cannot be subdivided with respect to O1 because the union quantity of the applications is not yet computed. At this point, no more information is available as to which GenProcID has been entered by the assignment for which application.

In order to achieve uniqueness for the combination of operation and object, a new GenProcID P4 is introduced and the two O1 operations are compacted into this GenProcID. P1 and P2 are noted in the table DialogProcessSubstitute as possible predecessors of P4 (but not clearly in the individual actions).

Operation Object GenProcID
OrgHasApp O1 P4
OrgHasApp O2 P3

The following constellations can occur depending on whether the operation OrgHasApp is processed as a single step or in bulk:

Case 1) O1 is calculated and then O2.

Case 2) O2 is calculated and then O1.

Case 3) O1 and O2 are calculated together simultaneously in a bulk operation.

After these operations have been executed and assuming that they all cause changes to the total sets affected, the following situation arises:

Case 1) O1 is calculated and then O2.

Operation Object GenProcID
OrgHasApp O2 P3
OrgHasApp O4 P4
OrgHasApp O2 P4
OrgHasApp O3 P4
PersonHasApp X P4

Before the next DBQueue Processor run, the GenProcID’s must be compressed again, because the OrgHasApp operation did not produce a unique result for the object O2. P5 is introduced with possible predecessors P4 and P3.

Operation Object GenProcID
OrgHasApp O2 P5
OrgHasApp O4 P4
OrgHasApp O3 P4
PersonHasApp X P4

Now the calculation is done for O2:

Operation Object GenProcID
OrgHasApp O3 P5
PersonHasApp X P5
OrgHasApp O4 P4
OrgHasApp O3 P4
PersonHasApp X P4

Because O3 is not unique, P6 is introduced with possible predecessors P4 and P5.

Operation Object GenProcID
OrgHasApp O3 P6
PersonHasApp X P5
OrgHasApp O4 P4
PersonHasApp X P4

After O3 and O4 have been calculated, the following situation exists:

Operation Object GenProcID
PersonHasApp X P6
PersonHasApp X P5
PersonHasApp X P4

There is no uniqueness for object X such that P7 is introduced with possible predecessors P4, P5 and P6.

Case 2) O2 is calculated and then O1.

Operation Object GenProcID
OrgHasApp O1 P4
OrgHasApp O2 P3

After execution the following entries are in the DBQueue:

Operation Object GenProcID
OrgHasApp O1 P4
OrgHasApp O3 P3

The following situation is the result after the next step:

Operation Object GenProcID
OrgHasApp O3 P3
OrgHasApp O4 P4
OrgHasApp O2 P4
OrgHasApp O3 P4
PersonHasApp X P4

To achieve uniqueness for O3 a process P5 with possible predecessors P3 and P4 is created:

Operation Object GenProcID
OrgHasApp O3 P5
OrgHasApp O4 P4
OrgHasApp O2 P4
PersonHasApp X P4

After the calculations, the following situation exists:

Operation Object GenProcID
PersonHasApp X P5
PersonHasApp X P4

There is no uniqueness for object X such that P6 is introduced with possible predecessors P4 and P5.

Case 3) O1 and O2 are calculated together simultaneously in a bulk operation.

Operation Object GenProcID
OrgHasApp O1 P4
OrgHasApp O2 P3

After the first step in the calculation the following entries are in the DBQueue:

Operation Object GenProcID
OrgHasApp O4 P4
OrgHasApp O2 P4
OrgHasApp O3 P4
OrgHasApp O3 P3
PersonHasApp X P4

Uniqueness is achieved for O3 by introducing P5 with possible predecessors P3 and P4:

Operation Object GenProcID
OrgHasApp O4 P4
OrgHasApp O2 P4
OrgHasApp O3 P5
PersonHasApp X P4

After the next step in the calculation, the following content is found

Operation Object GenProcID
OrgHasApp O3 P4
PersonHasApp X P4
PersonHasApp X P5

After O3 has been calculated in the next run and has not created a new PersonHasApp entry, only X exists with P4 and P5 because X already exists with P4.

Operation Object GenProcID
PersonHasApp X P4
PersonHasApp X P5

There is no uniqueness for object X such that P6 is introduced with possible predecessors P4 and P5.

Archiving and deleting records

All records logged in One Identity Manager are initially saved in the One Identity Manager database. The proportion of historical data to total volume of a One Identity Manager database should not exceed 25 percent. Otherwise performance problems may arise. Records should be regularly removed from the One Identity Manager database and archived.

The following methods are provided for regularly removing recorded data from the One Identity Manager database:

  • The data can be transferred directly from the One Identity Manager database into a One Identity Manager History Database. This is the default procedure for data archiving. Select this method if the servers on which the One Identity Manager database and the One Identity Manager History Database are located have network connectivity.
  • The data is deleted from the One Identity Manager database after a certain amount of time without being archived.

For detailed information about setting up archiving of data in a History Database, see One Identity Manager Data Archiving Administration Guide.

Detailed information about this topic

Direct deletion of records in the One Identity Manager database

If records from a subsection should be kept in the One Identity Manager database for a certain amount of time but are not archived later, you then have the following options:

  • To exclude subsection from archiving do not configure it for export, but only specify a retention period.
  • To delete all subsections with archiving, specify the retention period. Enable the Common | ProcessState | ExportPolicy configuration parameter in Designer and enter the value NONE.

The records are deleted from the One Identity Manager database by the DBQueue Processor when the retention period has ended. In addition, all entries for triggered actions that have no corresponding records in the subsections are deleted.

NOTE: If you do not specify a retention period, the records from the subsection are deleted from the One Identity Manager database during DBQueue Processor daily maintenance tasks.

If there is a large amount of data, you can specify the number of objects to delete per DBQueue Processor operation and run in order to improve performance. You use configuration parameters to make the choice for each subsection.

Table 140: Configuration Parameters for Deleting logged Data Changes
Configuration parameter Meaning

Common | ProcessState | PropertyLog | Delete

This configuration parameter allows configuration of deletion behavior for logged data changes.

Common | ProcessState | PropertyLog | Delete | BulkCount

This configuration parameter contains the number of entries to be deleted in an operation.

Common | ProcessState | PropertyLog | Delete | TotalCount

This configuration parameter contains the total number of entries to be deleted in any processing run.

Table 141: Configuration parameters for deleting process information
Configuration parameter Meaning

Common | ProcessState | ProgressView | Delete

This configuration parameter allows configuration of deletion behavior for process information.

Common | ProcessState | ProgressView | Delete | BulkCount

This configuration parameter contains the number of entries to be deleted in an operation.

Common | ProcessState | ProgressView | Delete | TotalCount

This configuration parameter contains the total number of entries to be deleted in any processing run.

Table 142: Configuration Parameters for Deleting Process History

Configuration parameter

Meaning

Common | ProcessState | JobHistory | Delete

This configuration parameter allows configuration of deletion behavior for the process history.

Common | ProcessState | JobHistory | Delete | BulkCount

This configuration parameter contains the number of entries to be deleted in an operation.

Common | ProcessState | JobHistory | Delete | TotalCount

This configuration parameter contains the total number of entries to be deleted in any processing run.

Table 143: Configuration Parameters for Deleting Process Status Entries
Configuration parameter Meaning

Common | ProcessState | Delete

This configuration parameter allows configuration of deletion behavior for process status entries.

Common | ProcessState | Delete | BulkCount

This configuration parameter contains the number of entries to be deleted in an operation.

Common | ProcessState | Delete | TotalCount

This configuration parameter contains the total number of entries to be deleted in any processing run.

Related Topics
Related Documents