Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

CALL transaction using generic user.

Former Member
0 Likes
485

Hi experts,

I have a CALL TRANSACTION, which code is: 'ME54' USING BDC_TAB MODE 'E' UPDATE 'S'.

I have previosly defines the BDC_TAB. Is is a backgroud process executes with an event. The sy-uname there is the same as the user that has lauched the event. I want this to be executed with a generic user, example GENUSER instead of the one that really launches the event.

¿Is this possible?

Thank-you very much,

Artur.

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
427

Hi,

The only way I can think of at the moment is to extract your CALL TRANSACTION into a separate self-contained program (which it may already be looking at your post). Then use FM JOB_OPEN, JOB_SUBMIT (changing the parameter AUTHCKNAM to you generic user) and JOB_CLOSE (with STRTIMMED = abap_true).

This obviously gives rise to other problems such as knowing when the job finished etc but this depends on your overall design and if this is important or not.

Looking at your overall process this does not sound like a problem. Simply change the background job step for the event - have it call a new program to perform the JOB* FM steps instead which calls your original program that was registered against the event.

Thanks,

Pete

2 REPLIES 2
Read only

Former Member
0 Likes
428

Hi,

The only way I can think of at the moment is to extract your CALL TRANSACTION into a separate self-contained program (which it may already be looking at your post). Then use FM JOB_OPEN, JOB_SUBMIT (changing the parameter AUTHCKNAM to you generic user) and JOB_CLOSE (with STRTIMMED = abap_true).

This obviously gives rise to other problems such as knowing when the job finished etc but this depends on your overall design and if this is important or not.

Looking at your overall process this does not sound like a problem. Simply change the background job step for the event - have it call a new program to perform the JOB* FM steps instead which calls your original program that was registered against the event.

Thanks,

Pete

Read only

0 Likes
427

Ok, thanks!