BAPI_USER_CHANGE does not update changes

[Former Member]

Hi ABAPERS!

I’m calling bapi BAPI_USER_CHANGE remotely in order to change expired date & user group.

Although the BAPI returns message: “User XXXXX has changed” no changes are made when I check SU01 transaction in the target system.

If I test the bapi via SE37 transaction, changes are made.

In more detail, my requirement is to set up some actions automatically when a user leaves a company. For this purpose  created a FM  which include BAPI calls. All of them are working fine except BAPI_CHANGE_USER.  Here the list of actions and the bapi I use.

- Lock the user -> BAPI_USER_LOCK

- Remove all roles -> BAPI_USER_ACTGROUPS_DELETE

- Remove profiles -> BAPI_USER_PROFILES_DELETE

- Expire the user / Change the user group to a specific user group --> BAPI_USER_CHANGE

My code:

  CLEAR ls_logondata.
ls_logondata-class = 'LEAVERS'.
ls_logondata-gltgb = sy-datum.
ls_logondatax-class = 'X'.
ls_logondatax-gltgb = 'X'.

CALL FUNCTION 'BAPI_USER_CHANGE' DESTINATION lv_dest
EXPORTING
username   = lv_username
logondata  = ls_logondata
logondatax = ls_logondatax
TABLES
return     = lt_return.

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' DESTINATION lv_dest

If I check the system log, it seems that a rollback is executed by the system setting expired date/ user group to original values.

Any idea about this problem? Or do you know another BAPI to use for the same purpose?

Thank you!

[Former Member]

Is your system managed by CUA? This might be the reason the change is rolled back by the system.

Best regards,

Anders

[Former Member]

No, the system is not managed by CUA

[Szczerbowski]

BAPI TRANSACTION COMMIT also has a return parameter, maybe you will find some info there?

[ziolkowskib]

It can only return errors in case of being executed with WAIT parameter set to 'X' hence this will not help here.

[ziolkowskib]

The BAPI you use is perfectly fine.

Could you elaborate on the following one:

Sira Agulló Salvia wrote:

If I test the bapi via SE37 transaction, changes are made.

Does it work when you execute BAPI_USER_CHANGE in target system using your own user or does it work when you execute BAPI_USER_CHANGE in source system with destination set?

I would suggest to turn on system trace (ST01) for user DRC_DE3_180 in target system for Authorization Check and RFC Calls and then execute your logic once again and check if you find any clues in the trace file.

[Former Member]

It works:

     - running trx. se37 in source system DRC to target DE3

     - it also works running se37 in target DE3 system

When I run my FM which contains all bapi calls

I run ST05 traces both in source / target systems. Target system has more info about the UPDATE than the source:

All seems fine, until I check it in su01.

I put only BAPI_USER_CHECK call removing the other bapis. Same occurs.

The system is not managed by CUA.

The user which performs the RFC call, has SAP_ALL. So no authorizations problems.

The only suspicious issue is the system log (attached in my 1st message), which appears a rollback after change values.

[Former Member]

Did you try to set an external breakpoint in the target system after BAPI_USER_CHANGE and after BAPI_COMMIT to see the return codes? Can you see the correct values in the USRxx tables after the BAPI_TRANSACTION_COMMIT, but before your fm ends?

[ziolkowskib]

According to the first screenshot values are reverted right after you change them but I can't see it from your ST05 log. Can the data reversal be seen in ST05? If so which program triggers it?

Anything available in ST22?

[Former Member]

hi,

the 1st screen shot is from SUIM transaction.

In ST05 I can't see any data reversal... I don't know who triggers this reversal.

I have no dumps in ST22.

Probably is the BAPI_USER_CHANGE who is triggering this rollback. If I search for the term 'rollback' inside the bapi  there are many occurrences...

[Former Member]

Did you try to set external breakpoints in BAPI_USER_CHANGE at the rollback statements? Just to see if the rollback occurs inside BAPI_USER_CHANGE or later.

[Former Member]

Hi Sira,

Did you check if the destination is correct? Try removing it.

[Former Member]

Yes destination is correct. The other 3 BAPIs run perfectly 

[sachin_yadav3]

We are calling BAPI_USER_LOCK and then BAPI_USER_CHANGE. I am suspecting it has something to do with the sequence of BAPI. As you said, when you run it from SE37 it run as expected. Can you just comment the BAPI_USER_LOCK and then test your custom FM to see the behavior or call only BAPI_USER_CHANGE from your custom FM and check the behavior.

Regards

Sachin

[Former Member]

Sounds quite probable... How about locking the user as the last step in the custom FM?

[Former Member]

I commented out the other 3 BAPIs I use and I only left BAPI_USER_CHANGE but the problem persists. 

I suspected exactly the same as you.

[sachin_yadav3]

May I know know how you called the wrapper function module after commenting other 3 BAPI.

Did you called it wrapper FM from SE37 or through program?

If you called from SE37 then it should work because, it contains only single BAPI i.e. BAPI_USER_CHANGE and this BAPI is working as expected when called from SE37.

In Wrapper FM did you used commit BAPI ?

[former_member259807]

Hi Sira,

Is it possible for you to create a custom wrapper function module in the target system, where you call the bapi_user_change and bapi_transaction_commit, and use import and export parms from the bapi_user_change?

If that is possible, you can try to call that user module remote from the source system.

reg. Bob

[Former Member]

Hi all,

I would like to share with all of you that I've found the problem debugging and I confirm that it is not in the BAPI_CHANGE_USER. It is in the configuration of GRC Access Request BRF+ rules and the Request Type.

The Request type contains two Actions: User Defaults and Change User.

So the BAPI is called 2 times. The first of them into the User Defaults (here the Z function module is executed with all BAPI calls) and the second one in the Change User action (which is an standard execution)

In more details:

When I start the flow, the breakpoint stops for the 1st time in target BAPI_CHANGE_USER system with the desired values (user group: 'LEAVERS' and expired date: sy-datum) and a commit work is executed.

Then I press F8 to finish the flow and STOPS AGAIN in the bapi BAPI_CHANGE_USER with OLD values. Here there is the second commit work and values are overlaped.

So the 1st time the update is due to my RFC call but the 2nd time is the standard procedure linked to CHANGE USER rule!

Thanks for your help!

[Former Member]

Very interesting. Thanks for sharing and have a nice day.