SecurID® Governance & Lifecycle Blog

Subscribe to the official SecurID Governance & Lifecycle community blog for information about new product features, industry insights, best practices, and more.

Data Processors : Basics

Moderator Moderator
1 2 714

Data processors have always existed in G&L to allow manipulation of data during various phases of collections or SoD processing. In the past, it required sys access on the AVDB database and a tool like SQL developer to add custom logic to these extension points.

With G&L Cloud (or 7.5.2 on premise), SecurID has made available all these extension points from the UI, making it very simple to add and maintain these custom extensions.

The table below lists some of the common extension points

Pre_ID_Unification_Handler Any action needed post identity data collection but before unification. Mostly used to manipulate the T_DC_SOURCEDATA_USER table
Post_ID_Unification_Handler Any action that needs to be performed after the identities have been collected, unified and persisted in the system
Pre_Supervisor_Resolution Any action that needs to be performed after the identities have been collected, but before supervisor references are resolved
Pre_ADC_Handler Any action to be performed post account data collection but before processing.
Post_Account_Data_Load_Handler Action to be taken once account data has been collected and persisted in the system
Post_MAEDC_Load_Handler Any action needed post multi-app EDC run
Post_Process_SoD_Violations Actions to be taken post SoD rules have been evaluated and violations generated



💬 Comment below if you want any specific data processors to be covered with basic examples.


Trusted Contributor
Trusted Contributor

@PradeepKadambar Good to read this (except we're not on 7.5 yet) but I have a few questions ...

Presumably the same principles apply to the pre 7.5 SQL packages, i.e. we simply add our code/SQL after the /*Add Custom Code here */ comment? And we then just compile the package?

Are there variables for things like the run_id of the task invoking the package? I notice one of your examples uses a SELECT MAX(RUN_ID) from a table - it would surely be cleaner to have the run_id available?

Is there no post processor for "normal" EDCs? We already use an MAADC/MAEDC to collect data for multiple applications from an interim staging database, but if we wanted to configure an EDC to go directly to a target application datasource (for example) AND use a post processor on the collected data - is that currently possible? 


Moderator Moderator

Yes, these extension points are available in older versions, but not through UI. You can add customizations to these as indicated, validate and compile them using standard SQL tools.

MAX(run_id) ensures that we look at latest run in my example.

In 7.5.2, we do have post and pre for EDC but not in older versions (I am unaware if it exists)