Small tip: Setting the System Privilege Modify Trigger Attributes programatically

[terovirta]

I recently joined a nicely ongoing IdM 7.2 project and one of my tasks is to load contact information to all existing users from phone book type of application that is about to be killed. This bulk load will naturally trigger lot of update operations unless attention is paid to what attribute modification should actually be replicated to target system.

One of my own "rules" with SAP IdM is to avoid any un-necessary processing and running modify tasks to repositories where those particular attributes may not even be relevant (or isn't even mapped in the toSAP/toLDAP etc pass) is such action.

The standard initial load job template sets the Trigger Attributes for System Privileges via script that I've found a little awkward, so thought it is best to create my own job that would also give the customer more control and actually a way to maintain the trigger attributes. The list of attributes can be maintained in MMC / Privilege Metadata, but selecting the attributes from long list is bit tedious.

So as it looks like today that I am going to use the job again, thought about sharing it here if it helps anyone else.

What the job simply does is that it fetches all the System Privileges, gets the comma separated list of attribute names from repository constant (or from global constant if the repository constant is missing/not defined for that particular repository), gets the matching Id Store specific attribute ids and stores them to System Privilege's MX_MODIFYTASK_ATTR-attribute.

Global/repository constant

Source-tab

The source SQL is just example of getting the names of the System Privileges.

Destination-tab

The target tab handles each of the System Privileges and sets the attributes.

Scripts

The script "setAttrs" sets the trigger attributes. The name of the System Privilege the job is currently processing is passed in the Par-parameter, the script gets the repository name from the privilege name, tries to get the repository constant/global constant, gets the attribute ids from attribute names from SAP Master Id Store and returns them in pipe-separated multivalue string.

The u-function uGetRepositoryVar works with passed that are working in repository context but for a standalone job you need to write you own script that takes the repository and variable/constant names as parameter. "NULLATTR" is special hardcoded value for SAP IdM that acts as a "do nothing" value for attribute, handy to return in error case when you want to make sure nothing gets updated.

[Steffi_Warnecke]

Hello Tero,

thank you for this blog! It helped me to understand the structure of "MX_MODIFYTASK_ATTR" and the whole trigger-attributes-connection a lot better and to create a small job to de-mark all of the checkboxes for the trigger attributes.

I'm also working with different constants for trigger attributes, but they only added attributes and sadly not un-marked the attributes, that are not in my list. Really nerve-wrecking, if you want to tidy up there! :cry:

But now it's working, thanks to your blog, too! :smile:

Regards,

Steffi.

[terovirta]

I'm glad it helped. Figuring it out during the 7.2 ramp-up really paid off :oops: I've used it in 6-7 projects by now.

regards, Tero

[Former Member]

Very usefull. Thx Tero,

Ben

[renefeisterSAP]

Hi Tero,

nice idea but what I typically see is that there is no global list of attributes to be configured for each and every repository but it is rather likely that you would have such a list per repository type. For example you would like to update a license type in ABAP; but that one does not even exist in AD or Java. So in real world your example would become perfect if it is implemented per repository type.

What I typically do is modify the list of attributes in the initial load job before executing the initial load. The standard list is just too long.

Regards,

René

[terovirta]

Hi Rene,

thanks for the valid points. It's easy to change the script to use repository type as default if needed. In the project the script was invented the repositories had differences, Portal had custom UME-attributes and the other AS Java didn't.

regards, Tero

[Former Member]

Nice one Tero

[ganesh_s7]

Thanks Tero.  Now i finally understand how custom task trigger attributes work.

[devaprakash_b]

Hi tero,

Whenever i am trying to modify the attribute MX_MAIL_PRIMARY modify triggers are started starting at all. I have updated the ABAP repository system privilege

$FUNCTION.sap_core_setPrivilegeModifyTriggerAttributes(PRIV:SYSTEM:****!!2!!MX_MAIL_PRIMARY)$$

Can you please let me know how to proceed further.

Regards,

DP