Queuing

Queuing types

Event-based queuing

RoPE queues identities for calculation, based on events in Omada Identity. An event means that a data object is created, updated, or deleted.

If, for example, a resource data object is updated, Omada Identity RoPE queues all identities that have a calculated resource assignment (CRA) for the resource.

The table below specifies which identities are queued depending on a certain event:

Object type	Event	Identities queued
Identity	Create, Modify, Delete	The identity itself. Also, the identities of any added or removed explicit owners of the identity are queued.
Resource assignment	Create	The identity for which the resource assignment is targeted.
Resource assignment	Modify, Delete	The identity that has a CRA caused by the Resource assignment.
Context assignment	Create, Modify, Delete	The identity that the context assignment is for.
System	Create, Modify, Delete	Identities of any added or removed explicit owners of the system.
Resource	Create, Modify, Delete	All identities that have a CRA for the resource. The identities of any added or removed explicit owners of the resource are queued.
Resource	Create, Modify	If a resource is an enterprise role, RoPE queues all that have a CRA for one of its child resources.
Resource folder	Create, Modify, Delete	Identities of any added or removed explicit owners of the resource folder.
Assignment policy	Create, Modify	All identities that are in one or more of the contexts that the assignment policy is defined for. If the policy is only scoped with an identity view, no queuing takes place.
Assignment policy	Modify, Delete	All identities that have a CRA caused by the assignment policy.
Constraint	Modify, Delete	All identities that have a CRA that violates the constraint.
Context	Create, Modify, Delete	All identities that are in the context. Also, the identities of any added or removed explicit owners of the context.
Access delegation	Create, Modify	The identity that the access delegation is for.

In addition to the events in Omada Identity, RoPE also queues identities on the basis of changed data (accounts and resource assignments) in Data Warehouse.

note

You can configure the properties to whose changes RoPE reacts on the basis of each data object type. You can specify such changes in the EngineConfiguration file.

Periodic queuing

In addition to event-based queuing, RoPE performs periodic queuing every hour of:

• Identities with recently activated or expired assignments.

  • Activation: An assignment that was pre-valid at the time of calculation but has now entered its validity period.
  • Expiration: An assignment that was valid and enabled at the time of calculation but now has a Valid to in the past.

• Identities which are in a time zone where the local time is 4:00 AM. This is only happening on select weekdays. You can configure this in the EngineConfiguration file with the property queuePeriodicallyAt.

  • In the EngineConfiguration file, if requeueFailures is set to True, identities whose most recent calculations have failed are requeued at the time indicated in queuePeriodicallyAt.

info

The periodic queuing of identities can be enabled or disabled altogether in the EngineConfiguration file using the queueAllPeriodically property. This property accepts a Boolean value: true to enable periodic queuing, and false to disable it.

Explicit queuing

Along with event-based and periodic queuing, the Omada Identity also explicitly adds identities to the calculation queue in some situations. These include:

• When an identity is manually queued for calculation in the Identity form or the Identities view.
• When an assignment is revoked in the Identity form.
• When a Manual provisioning process is completed.
• When an Evaluate violation process is completed.
• When a result in an Access review survey is submitted.
• When the Omada Provisioning Service registers a provisioning claim.
• When an Emergency lockout process is completed.

Queuing priority

When an identity is queued, a priority is assigned to the queue item. It can be either:

• Low (mapping value = 0),

• Medium (mapping value = 1),

• High (mapping value = 2),

• Very high (mapping value = 3).

The priority is considered by RoPE when it decides which identities to include in a batch.

The table below explains which priority is used for the various types of queuing that take place in RoPE:

Category	Type of queuing	Priority
Event based	Identity created	High
Event based	Resource assignment created, modified, or deleted	High
Event based	All other data object events	Medium
Event based	Changed data in the ODW	Medium
Periodic	Identities with recently activated or expired assignments	Low
Periodic	Periodic queuing of everyone at night in their time zone	Low
Periodic	Re-queuing of calculation failures	High
Explicit	Identity manually queued from UI	High
Explicit	Assignment revoked from the UI	High
Explicit	Manual provisioning completed	Medium
Explicit	SoD violation evaluation completed	High
Explicit	Access review submitted	Medium
Explicit	Provisioning claim registered in OPS	Medium
Explicit	Emergency lockout	Very high

Distribute the workload across RoPE instances on-prem

note

This section mentions engine settings that can be changed in the EngineConfiguration.Config file, which is currently only available to on-prem customers. For more information on the settings, see Engine configuration, a page available in the documentation of the on-prem version of Omada Identity.

With the use of the engine settings queuePriorityMinimum and queuePriorityMaximum, you can let one instance only calculate queue items with higher priority. One instance should then have queuePriorityMinimum="1", and the other instance(s) should have queuePriorityMaximum="0". This way, queue items with low priority are not calculated in a batch while there are items with higher priority in the queue.

If there are three or more RoPE instances, you can also nominate one of the instances to be responsible for calculating unresolved identities. The low priority instance should have calculateUnresolved set to true, and the other ones to false. This way, a long running calculation of the unresolved identity does not halt the processing of other queue items with low priority.

example

For example, with three RoPE instances, the configuration could be:

• Instance 1: queuePriorityMinimum="0" queuePriorityMaximum="0" calculateUnresolved="true"
• Instance 2: queuePriorityMinimum="0" queuePriorityMaximum="0" calculateUnresolved="false"
• Instance 3: queuePriorityMinimum="1" queuePriorityMaximum="3" calculateUnresolved="false"