Do we need to really maintain ABAP profiles in SAP IDM?

[Former Member]

Hello All,

In our target systems (ABAP), no profile is directly assigned to a user.

In that case, do we really need to pull the profiles to IDM during the initial load ? I know we can disable the corresponding pass from the initial load job if we don't want to load. But what is the best practice ?

And also, the filter option in the ReadABAPProfiles don't work for me. In the below screenshot the filter is * which means read all profile. But I have tried with my custom filters like Z* (to import proles that start with Z*). But still all the profiles in the system loads into IDM.

Does it work that way ? or Am I doing something wrong ? Please suggest.

Regards,

Krishna.

[Steffi_Warnecke · Accepted solution]

Hello Krishna,

I'd say that if you don't want to add profiles to users directly via IDM, you don't need to load them into IDM. We, for example, have only imported the "ALL" and another one into IDM.

For your second question: you look at the loading of the temp-table now (where it reads the profiles from the backend and saved them into a temp-table on the database). Check the second pass for the profiles, where they are written to the identity store. There you can alter the source SQL statement to just write those profiles into the ID store, that you really want to use.

Regards,

Steffi.

[Former Member · Accepted solution]

Thanks Steffi,

Yes, we also do only the "ALL" profile to be assigned from IDM.

For the second one, yes I have used the same work around you have mentioned.

But wanted to check with the community regarding the filters for profiles, whether the filter in the ReadABAPProfiles pass works or not?

Regards,

Krishna.

[Steffi_Warnecke · Accepted solution]

Hello Krishna,

we haven't changed the filter in the read-pass for any of our inital loads (or delta loads, for that matter). So maybe that's not the workaround, but the best practise. ^^

I have no experience in changing up the filter options for the profiles as it wasn't really necessary for us.

Regards,

Steffi.

[former_member2987]

Hi Krishna,

To follow up on Steffi's answer, and in general:

If you don't need the data, don't bring it in!

More data means a bigger database size, more to search through, more for the database to do, and greater complexity.

Anytime you can limit the data in the system is a good thing to pursue! Just don't get too enthusiastic! (And of course, make sure the database team is making backups before major changes are made)

Regards,

Matt