Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Identity Manager 8.1.5 - Configuration Guide

About this guide One Identity Manager software architecture Customizing the One Identity Manager default configuration Customizing 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 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
Using scripts Notes on message output Notes on using date values Using dollar ($) notation Using base objects Calling functions Pre-scripts for use in processes and process steps Using session services Using #LD-notation Script library Support for processing of scripts in Script Editor Creating and editing scripts in the Script Editor Copying scripts in the Script Editor Testing scripts in the Script Editor Testing script compilation in the Script Editor Overriding scripts Permissions for executing scripts Editing and testing script code with the System Debugger Extended debugging in the Object Browser
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 One Identity Manager Service configuration files

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 software to roles is depicted in the following.

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

  • P1: Software application A1 is assigned to the role O1

  • P2: Software application A2 is assigned to the role O1

  • P3: Software application A3 is assigned to the role O2

The following operations are in the DBQueue (DialogDBQueue table) 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 of software applications is being calculated for O1. At this point, no more information is available as to which GenProcID has been entered by the assignment for which software 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 DialogProcessSubstitute table 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 entries 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%. Otherwise performance problems may arise. You must ensure that log entries are 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

Deleting log entries in the One Identity Manager database without archiving

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

  • To exclude a certain section from archiving, do not configure it for export, just specify a retention period.

  • To delete all sections without archiving, specify a retention period. In the Designer, set the Common | ProcessState | ExportPolicy configuration parameter and enter the value NONE.

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

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

Related topics

Specifying data retention periods

Once the retention period has ended, the recorded data is either exported or deleted from the One Identity Manager database depending on which archiving method has been chosen. A longer retention period should be selected for sections whose records will be exported than for those that will be deleted.

NOTE: If you do not specify a retention period, the records in this section will be deleted daily from the One Identity Manager database within the daily DBQueue Processor maintenance tasks.

The recordings are not exported until the retention period for all sections has expired and no other active processes for the process group (GenProcID) exist in the DBQueue, process history, or as scheduled operation.

You use configuration parameters to define the data retention periods for the individual sections.

Table 126: Configuration parameter for handling change data
Configuration parameter Meaning

Common | ProcessState | PropertyLog | IsToExport

Exports the data changes. If this configuration parameter is not set the information is deleted once the retention period has expired.

Common | ProcessState | PropertyLog | LifeTime

This configuration parameter specifies the maximum retention period in the database for log entries from change tracking.

Table 127: Configuration parameter for handling process information
Configuration parameter Meaning

Common | ProcessState | ProgressView | IsToExport

Exports the data in the process information. If this configuration parameter is not set the information is deleted once the retention period has expired.

Common | ProcessState | ProgressView | LifeTime

This configuration parameter specifies the maximum length of time that log data from process information can be kept in the database.

Table 128: Configuration parameter for handling process history
Configuration parameter Meaning

Common | ProcessState | JobHistory | IsToExport

Exports the information in the process history. If this configuration parameter is not set the information is deleted once the retention period has expired.

Common | ProcessState | JobHistory | LifeTime

This configuration parameter specifies the maximum retention period in the database for log entries from process history.

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation