ROI iAM

Appearance

Initial Load (Parallel) ​

The parallel load iFlow performs a full extraction of user data from SAP IdM and writes it to ROI iAM. It divides the total user count into chunks processed across multiple concurrent threads, making it suitable for large datasets (tens of thousands of records or more).

When to use ​

Use the parallel load iFlow for:

  • First-time onboarding of master data from SAP IdM
  • Re-synchronization after data inconsistencies
  • Loading a large user population where the sequential daily flow would time out

Triggering the flow ​

The parallel iFlow can be triggered via two channels:

  • HTTPS — Send a POST request to the customer-specific endpoint (e.g., /roiam/<customer>/sap_idm/loadusers_initialload). The caller must have the ROIAM_RT_CUSTOMER role.
  • JMS — Send a message to the customer-specific JMS queue for parallel loading. (used only for scheduling)

Both channels require the roiam_customer_system_name header to be set.

How the parallel processing works ​

The flow executes the following sequence:

  1. Authorization — Resolves the source system destination and sets authentication headers
  2. Get total count — Calls the source system API (/idm-proxy-rest/api/usersFromIdM?startIndex=1&count=1) to retrieve the totalResults value without fetching actual records.
  3. Calculate parallel runs — A script divides the total count into chunks. Each chunk size is determined by the roiam_scim_bulk_parallel_page_size header, aligned to a multiple of the internal paging size (roiam_paging_size)
  4. Split into parallel threads — Split into up to 50 concurrent threads.
  5. Paged data retrieval per thread — Each thread loops internally, calling the source system in pages (controlled by roiam_api_paging_size). With a default paging size of 100, it allows for up to 15000 records to be processed in one chunk
  6. Transform to SCIM bulk — The accumulated records are transformed into a SCIM bulk operation structure via the Dynamic Mapping Engine.
  7. SCIM write — The bulk payload is sent to ROI iAM via the Bulk SCIM endpoint.
  8. Retry failed entries — If the SCIM bulk response contains failures, the failed record IDs are extracted and re-processed in a second SCIM call. This is needed due to the fact that certain links might require all records to be stored first, before being able to find them as reference (e.g. managers).
  9. Persist variables — After all threads complete, the flow writes the lastrun and lastjobid variables. The lastrun timestamp is captured on first data fetch begins, ensuring that any changes occurring during the load are picked up by the next delta run.

GZIP compression ​

The iflow uses GZIP compression to reduce memory consumption during processing.

Test mode ​

To verify connectivity and mapping without loading the entire user population, you can set the roiam_testrun_size header to a small number (e.g., 100). This overrides the total count returned by the source system and limits the load to the specified number of records. When roiam_testrun_size is active, the lastrun and lastjobid variables are not persisted.

Example request ​

text
POST /roiam/<customer>/sap_idm/loadusers_initialload
Headers:
  roiam_customer_system_name: MY_IDM_SYSTEM
  roiam_scim_bulk_parallel_page_size: 500
  roiam_api_paging_size: 100 (this is extracted automatically from the property of the repository that is loaded)

See also ​