Skip to Content
Author's profile photo Tero Virta

Small tip: Setting the System Privilege Modify Trigger Attributes programatically

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



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



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



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.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Steffi Warnecke
      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! 😥

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



      Author's profile photo Tero Virta
      Tero Virta
      Blog Post Author

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

      regards, Tero

      Author's profile photo Former Member
      Former Member

      Very usefull. Thx Tero,


      Author's profile photo Rene Feister
      Rene Feister

      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.



      Author's profile photo Tero Virta
      Tero Virta
      Blog Post Author

      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

      Author's profile photo Former Member
      Former Member

      Nice one Tero

      Author's profile photo Ganesh S
      Ganesh S

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

      Author's profile photo D P
      D P

      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


      Can you please let me know how to proceed further.