cancel
Showing results for 
Search instead for 
Did you mean: 

SAPGRC_AC_IDM_SUBMITREQUEST web service updating SU01 address information

Former Member
0 Kudos

We are using web service SAPGRC_AC_IDM_SUBMITREQUEST to initiate/submit request for role provisioning in CUP (5.3) and we're noticing that each time a requested role is provisioned, the SU01 Address tab information (Last Name, First Name, e-mail, etc) also gets upated. For new accounts this is understandable - part of creation of new accouont and assignment of role, but for existing accounts, I was expecting for just the role assignment to be updated and nothing else in SU01.

Has anyone observed the same behavior from executing this web service? Is this normal?

Thanks,

Jane

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Use the change user workflow path for changes to exsisting user. If you are using an create user path for the who already has an account then grc do not verify wthr the account is existing it just overwrites the exsisting information. You can have your own routines/ program for verifying the user accounts but there is no built in routine for this.

Rakesh

koehntopp
Product and Topic Expert
Product and Topic Expert
0 Kudos

Basically it depends on the provisioning actions that have been assigned to the request type you're using.

By default, NEW and CHANGE differ only in how they will call the backend - one uses BAPI_USER_CREATE, the other BAPI_USER_CHANGE.

Both will have the action CHANGE_USER assigned sol they will update user master data.

Both also have ASSIGN_ROLES which means you can use them to do role assignment changes.

If you want a request type that can only change roles but not change SU01 data, you will need to create one that only has ASSIGN_ROLES as a provisioning action.

Frank.

koehntopp
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Jane,

please have a look at the provisioning actions for the request type you're using.

If it has CHANGE_USER assigned, it will just do that.

Frank.