04-19-2010 6:59 PM
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
04-20-2010 6:53 AM
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
04-20-2010 3:11 PM
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.
04-20-2010 3:36 PM
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
04-22-2010 5:23 PM
04-22-2010 5:51 PM
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ó
04-26-2010 3:16 PM
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.
04-26-2010 3:24 PM
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ó
04-26-2010 4:39 PM
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.
04-26-2010 5:34 PM
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.
04-26-2010 5:51 PM
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ó
04-26-2010 8:25 PM
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
04-26-2010 8:27 PM
Hi Kiran,
Thank you your feedback.
Understood your points and totally agree.
Regards, Fernando Da Ró