How to deal with overlapping assignment validity in ABAP initial load?

[lambert-giese]

Dear IDM experts,

when performing NetWeaver AS ABAP initial loads in IDM 7.2, I have already several times come across the situation that the initial load generates numerous error messages complaining of overlapping ABAP role assignments, like the one shown below:

Exception from Modify operation:com.sap.idm.ic.ToPassException: ToIDStore.modEntry failed modifying entry '<affected_user_mskeyvalue>'. IDStore returned error message: " Overlapping assignment validity:Attribute: MXREF_MX_PRIVILEGE" when storing attribute 'MXREF_MX_PRIVILEGE={ValidFrom=2013-01-08!!ValidTo=9999-12-31}<affected_abap_role_mskeyvalue>'

As far as I understand, the root cause of this error message is that in the ABAP backend, the ABAP user which the error message relates to has several assignments to the same ABAP role, and the validity periods of these assignments overlap. The following screenshot from SU01 illustrates one example of such a situation. The "valid to" date (31.12.9999) of the first assignment to role Z_TEST_ROLE is higher than the "valid from" date (08.01.2013) of the second assignment to the same role:

The IDM error message indicates that something's wrong with this, so I had a look at what data IDM has stored for this role assignment after the ABAP initial load where the error message occurred:

select
  mcthismskeyvalue
  ,mcothermskeyvalue
  ,mcvalidfrom
  ,mcvalidto
  from idmv_link_ext
  where mcthismskeyvalue='<affected_user_mskeyvalue>'
  and mcothermskeyvalue='<affected_abap_role_mskeyvalue>'
  ;

The result of this query, at least in my specific case, is that IDM has correctly merged the two ABAP overlapping role assignments into one, whose "valid from" date is 01.01.1900 (from the first assignment in SU01), and whose "valid to" date is 31.12.9999 (from the second assignment in SU01):

Although the IDM assignment data and the corresponding ABAP assignment data are obviously different from a technical point of view (one row in the IDM database, instead of two rows in the AS ABAP database), it seems to me that the overall result should be pretty much equivalent for all practical purposes. The user will effectively have the role from 01.01.1900 to 31.12.9999, no matter which of the two technical representations is used.

So my questions are:

1. are there any real issues or restrictions with ABAP role assignments like these in IDM? If yes, what exactly are they?
2. what is the recommended approach to correct such a situation?

Cheers,

Lambert

[former_member239804 · Accepted solution]

Hi Lambert,

have a look at the config guide, chapter 2.2.2 (Limitations and Considerations for AS ABAP/SAP Business Suite System Connectors).

...you can execute the PRGN_COMPRESS_TIMES report...

Hope this helps.

Regards, Wim.

[lambert-giese · Accepted solution]

Hi Wim,

thanks so much, that's very helpful.

I carefully read through the section you pointed out, and from the wording "To improve efficiency, you can execute the report PRGN_COMPRESS_TIMES..." I conclude that compressing role assignments in this way is a mere matter of performance. This seems to imply that even if I choose not run the report before initial load, everything will still work  fine from a functional point of view.

Do you have any information as to whether that interpretation is correct?

Thanks & best regards,

Lambert

[former_member239804 · Accepted solution]

Hi Lambert,

yes and no, i guess.

I don't know exactly what the report does in detail.

But I can tell you that we had two types of issues when performing initial loads in the past:

- overlapping assignments as you're experiencing and

- validto in the past cases

both of these did not occur anymore after the report.

If I'm not mistaken some cases were not able to load into IdM before the report.

You don't want that.

Either you should run the report or fix every single occurence manually.

The drawback is that the historic ABAP user administration is not preserved.

But I guess you only want to keep it to lookup/investigate something afterwards, for which you could save/archive it.

Good luck.

R, Wim.