Queuing

The Role and Policy Engine uses queuing to decide which identities need to be recalculated and when.

Queuing types

There are three types of queuing:

• Event-based queuing – Identities are queued automatically when data objects in Omada Identity change, for instance, when an identity, resource, or assignment is created, modified, or deleted.
• Explicit queuing – Identities are queued as a direct result of a user action, such as completing an access review or running a manual provisioning process. These actions are triggered by people rather than by the system.
• Periodic queuing – Identities are queued on a scheduled basis, for example every hour for expired assignments or at 4:00 AM in each time zone. This ensures that time-based events are captured even if no other changes occur.

Below, you will find detailed descriptions of all three types of queuing.

Event-based queuing

RoPE can queue 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, the Role and Policy Engine queues all identities that have a calculated resource assignment (CRA) for that resource.

The table shows which identities RoPE queues when different events occur on various object types.

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.
Identity	Manual queue request	The identity that was manually queued from the UI. This action is user-initiated but is internally implemented using an event.
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.
Provisioning Claim	Expired (while in Queued status)	Identities are queued on the event that a new Provisioning Claim is created.

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

note

You can configure the properties to whose changes RoPE reacts on the basis of each data object type.

• On-prem In the on-prem version of Omada Identity, you can specify such changes in the Engine configuration file.
• Cloud In Omada Identity Cloud, you can specify such changes in the Cloud Maagement Portal. Select Configure next to your environment name, and go to RoPE Configuration > XML view.

See also: RoPE extension model - Inheritable extensions.

Explicit queuing

In the situations listed below, Omada Identity can also explicitly add identities to the calculation queue. In this context, explicitly means that queuing is triggered directly by a specific user action, rather than automatically by the system.

Explicit queuing actions include:

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

Periodic queuing

RoPE performs periodic queuing 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 that are in a time zone where the local time is 4:00 AM. This only happens on selected weekdays. You can configure this in the following locations:

  • On-prem In the Engine configuration file.

  • Cloud In the Cloud Management Portal > RoPE Configuration tab > XML view, in the queuePeriodicallyAt property.

    
    info

    Additionally, if the requeueFailures property is set to True, identities whose most recent calculations have failed are requeued at the time indicated in queuePeriodicallyAt.

note

The periodic queuing of identities can be enabled or disabled altogether in the following locations:

• On-prem In the EngineConfiguration file using the queueAllPeriodically property. This property accepts Boolean values: true to enable periodic queuing, and false to disable it.

• Cloud In Omada Identity Cloud, you can specify such changes in the Cloud Maagement Portal. Select Configure next to your environment name, and go to RoPE Configuration > XML view:

  

Queuing priority

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

• Low (mapping value = 0)

• Medium (mapping value = 1)

• High (mapping value = 2)

• Very high (mapping value = 3).

RoPE takes the priority into account to decide the order in which identities are processed in a batch.

The table below explains which priority is used for particular 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
Event-based	Identity manually queued from UI	High
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	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

Queue status

The number you see next to Pending in the Operation Dashboard is a snapshot, not a live count. RoPE looks for new items only at the start of each work cycle.

This means that:

• If RoPE is paused, stopped, or busy with a long task, the queue number will not refresh until the next cycle begins.
• If you run several RoPE services at once, one service may find new items before another, so the numbers may not always match.
• Between updates, changes in the queue are not shown right away.

In summary, the queue length is most accurate while RoPE is actively working. If it looks out of date, it will update again as soon as the next cycle starts.

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"