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

background job after executing a process

Former Member
0 Kudos

Hi Experts,

I want to ask something. Is it possible to create automatic background job in some time when we execute a process? For example, when i run tcode MIGO and post the good issue of material, the system will run background job automatically to send some information to third party application and it takes time after 15/30 minutes?

And if it is possible, how to make it?


Sonia Helena


Active Participant
0 Kudos

Hello Sonia,

I assume it can be done by triggering the event. Just Find a Badi / Exit for triggering the event once PGI is done and give the event name in the start condition of the job.

Please find the below links for reference,

Reward points if it is helpful !!!


Deepan Swaminathan.

Active Contributor
0 Kudos

Use the user exit MB_CF001 or the BADI MB_DOCUMENT_BADI to create the job using the relevant function modules.

I would approach this a slightly different way in that in the user exits I would update a ZTable with the relevant information required to do whatever you are trying to do.

I would then write an update program which I would then schedule using SM36 to run every so often.  The program would:

If in background,  read the ztable (or Queue),  perform whatever process it is you wish to do,  if the process worked ok,  remove the row from the ztable.  If the process failed,  update the row with the relevant error message from your process and leave the entry in the table.

If the program is run in the foreground,  it should display an ALV grid detailing the contents of the queue and the latest status message.  Users should be allowed to delete queue entries,  add queue entries,  or select queue entries for immediate processing.

In this way you have a single background job and a well defined queue which has the ability to retry failed updates and can be manipulated by the users.  Your original idea may have multiple jobs scheduled to run as and when with no option of retrying a failed job and the user having to look in the various job logs to see if any have failed.

And having written all this,  I would ask what's wrong with using an IDOC ?