Triggering background jobs

[Former Member]

What is the best solution to trigger background jobs within user exits?

Currently the method I am using is quite cumbersome.

1. Create user event in SM62

2. Create background job attached to this user event.

3. Within user exit call function module BP_EVENT_RAISE using user event.

The problem I have with this approach is that in the program I have to add a 15 - 20 sec delay to handle record locking. Lets say I am in a user exit in MM02, triggering this event without the delay can lead to no records been processed.

What are other ways of implementing this solution?

Can I do a SUBMIT report VIA JOB

or CALL FUNCTION IN UPDATE TASK.

[former_member194669]

Try this way also.

In the userexit update a custom table with document number + flag (pending for process)

Create standalone program that to be scheduled like every 5 minutes (as you like ) search for this table and get all open documents (with flag eq space ) and process one by one.( Calling jobs)

This will reduced number of repetative background jobs

Say User A edit document 100 at 10.00 am and saves at 10.01 am and user B edit document 100 at 10.02 am and save it

10.03 am ( so every save if you trigger a backgound job, unncessary create jobs for same document number 10 )

a®

[Former Member]

But if User A changes material master and then User B changes material master again for the same material, then background job should run twice.

But I do like the custom table idea. I want the standalone program to be triggered on event though - when material master is changed. What are some ways of accomplishing that. I feel like the one I am using is unnecessarily too complicated

[Jelena]

What's the purpose of the background job? What is it supposed to do?

It might be better to utilize the change pointers, like the IDocs do. Or maybe you should use the IDocs to begin with...

[Former Member]

Hi,

Try the set of function modules:

JOB_OPEN, JOB_SUBMIT and JOB_CLOSE.

Please check in SE37 with JOB_*.

Before calling these function modules, we need to create Variant for that program. We have one FM to create Variant for the report which is going to be scheduled in background. Please check with createvariant*. I did not remember this one.

Ex: I have 2 programs.

Rep1 and Rep2.

I want to schedule Rep2 from Rep1.

Rep2 has few fields in Selection-screen.

In Rep1:

Step:1 create Variant by using FM

Step2: call above FM in sequence.

Thank you,

Balaji Peethani.

[Jelena]

>

>   Before calling these function modules, we need to create Variant for that program. 

No, we don't need to create a variant to use these function modules.

Also the issue here is, as far as I understand, not really how to start a background job. Since the author wants to do something (we still don't know what) in a user exit during the creation or change of material, I would actually question the whole idea of starting a separate program in background. If the program does any updates, the author has to make sure that the data integrity is preserved.

[Former Member]

I want to trigger a background job to make mass changes to material master.

Lets say the country of origin is changed in MM02, then the program should extract all batches associated with the material and change the country of origin. How to do this? I am doing it by triggering a background job. But are there any better ways of doing it?

[Jelena]

Unfortunately I haven't worked with batches and am not sure what this entails. You might want to check with your SD consultant if there is a better way to do this. How often does the country of origin change, anyway? It seems to me that this should really be handled by a business process rather than a program.

Otherwise it seems to me that a better option would be to use the change tracking tables CDHDR/CDPOS and run a separate program in a scheduled background job. The program would check which materials were changed and do the updates. This will resolve any possible locking and update termination issues and also prevent from changing the batches back and forth if a user made a mistake, for example, and corrected it immediately. Or if, like you said, one user made a change and then another one made a change.