topic Re: Commit Work Delay in Background Job submission in Application Development and Automation Discussions

Commit Work Delay in Background Job submission

Former Member — Mon, 19 Apr 2010 17:59:51 GMT

Hello there, I have a function module which gets called by a Service interface proxy. Inside the function module, I have a Job_open, submit to standard sap report (VI04 transaction equivalent) and Job_close. The standard SAP report creates SCD header and saves it. But when the job finishes and Job_close gets called, the data is still not commited to database (I poll to check if there is a record by reference number). I have wait up to 4 seconds and it works most of the time but misses sometimes. Is adding more delay only the solution or is there anything else I can do to quickly force the commit to database so my polling results in success. Thanks in advance.

Kiran

Re: Commit Work Delay in Background Job submission

Former Member — Tue, 20 Apr 2010 05:53:43 GMT

Hi Kiran,

Try using the statement : COMMIT WORK AND WAIT.

This should take care of the commit to the database.

Hope this helps.

Thanks,

Anusha

Re: Commit Work Delay in Background Job submission

Former Member — Tue, 20 Apr 2010 14:11:32 GMT

Thanks for the reply. My submit job runs in background with a scheduler ID. So it's a different LUW than my calling program. I will try AND WAIT addition and I'll double check.

Re: Commit Work Delay in Background Job submission

HermannGahm — Tue, 20 Apr 2010 14:36:21 GMT

Hi,

> submit to standard sap report (VI04 transaction equivalent)

it might be related to asynchronous update.

check if the standard report offers the possibility for a synchronous update... (documentatin, selection screen fields, ...)

Kind regards,

Hermann

Re: Commit Work Delay in Background Job submission

Former Member — Thu, 22 Apr 2010 16:23:40 GMT

Commit work and wait. will definitely work.

Re: Commit Work Delay in Background Job submission

Former Member — Thu, 22 Apr 2010 16:51:46 GMT

Hi Kiran,

When you call a program in background using job_open, submit and job_close. They will start to run only after JOB_CLOSE, and at this time even if you choose run IMMEDIATELY, there's no guarantee that you job will in fact run in X seconds, because they will only run when there's a background slot WP free.

Why are you calling a job if you need the result into your program ? Why not just call SUBMIT AND RETURN w/o job ?

If you really need run something after the job, you probably need a second step on your job with the rest of code or do not use jobs for this.

Kind regards, Fernando Da Ró

Re: Commit Work Delay in Background Job submission

Former Member — Mon, 26 Apr 2010 14:16:57 GMT

It's a good question as why I want to trigger it in background mode! The reason is cause the program behaves differently when run online or submit mode versus background mode. In online mode it requires a user interaction for certain thing to happen but in background it executes the whole step without any user interaction. This is vital for my functionality. I will give Commit work and wait a try but since it's going to be 2 different LUWs I'm not too sure that it would work. I can only add more wait and hope the polling works, at this time. Thanks for suggestions.

Re: Commit Work Delay in Background Job submission

Former Member — Mon, 26 Apr 2010 14:24:27 GMT

Hi Kiran,

I think it's better you put a second report (many a new one with coding for second part of your logic).

Put this report as second step of your job (you can just do another SUBMIT before the close_job).

So, when the background program finish the next step is automatic your logic (at same LUW).

Another advantage is that your first program should ends, releasing the LUW.

It's a good pratice to do not wait for another LUW that you can't guarantee their execution in time.

Think about it.

Regards, Fernando Da Ró

Re: Commit Work Delay in Background Job submission

Former Member — Mon, 26 Apr 2010 15:39:57 GMT

I agree, I'll have to do something jazzy here. I was actually thinking of encapsulating the whole thing as a background task function module and wait till all the locks are released (I think locks are causing the issue because it happens only in first iteration). I do have a fallback system where I'll let the process handle it rather than putting too much programming (if 200 documents are created in one day I don't want to have 400 job completion steps as for any reason something fails, it's a hassle)

Also for who suggested Commit work and wait, I tried it and as suspected, it didn't work.

Thanks all.

Re: Commit Work Delay in Background Job submission

Former Member — Mon, 26 Apr 2010 16:34:21 GMT

Solved this on my own. I called the routine which creates the document I need in using Perform in Program technique. I have a couple of hardcoded parameter right now but they are mostly system sort of commands.

Re: Commit Work Delay in Background Job submission

Former Member — Mon, 26 Apr 2010 16:51:09 GMT

Solved this on my own. I called the routine which creates the document I need in using Perform in Program technique. I have a couple of hardcoded parameter right now but they are mostly system sort of commands.

Hi Kiran,

It was exactly what I asked for you:

Why not just call SUBMIT AND RETURN w/o job ?

To put that to work you just needed to comment JOBOPEN, JOB CLOSE and the VIA JOB instruction on SUBMIT.

Kind regards, Fernando Da Ró

Re: Commit Work Delay in Background Job submission

Former Member — Mon, 26 Apr 2010 19:25:08 GMT

I didn't use SUBMIT and RETURN. As soon as the report behind the transaction gets SUBMITted it calls it one foreground, which requires user interaction as I explained. What I've done though is to dissect the functionality of the standard transaction and put the required subroutines in order I need and called Perform in Program. Now the logic is standalone and has no resemblance to standard program. SUBMIT and RETURN doesn't produce the same output. Thanks

Re: Commit Work Delay in Background Job submission

Former Member — Mon, 26 Apr 2010 19:27:03 GMT

Hi Kiran,

Thank you your feedback.

Understood your points and totally agree.

Regards, Fernando Da Ró