Update Task and Submit Program

[kirankerudi]

Hello Experts,

There is a job scheduled to run every minute. In this program's update task I used SUBMIT custom report.

However, this led to dump. So, I called a new wrapper FM for this SUBMIT statement and called it in background task.

Will this cause any issues related to conflicts in LUWs or conflicts in update ? Or what might happen if SUBMIT takes too long to return and by that time if it calls another SUBMIT ?

Please help.

Best Regards

[Former Member]

What is the purpose of the report? - it's best IMHO not to mess with the update task.

Rich

[RaymondGiuseppi]

Consider converting the report to another object allowed in update task like a FM or method of class that won't break the update task and won't execute in another LUW (raising risk of object already locked)

As Richard wrote, what do you try to perform in the report?

Regards,

Raymond

[Former Member]

Could you please elaborate , why did you called a report from a Update Task and what is this report doing? And now that you call a function module in background task ,do you wait for this background thing to return something?

It should be registered as part of the current LUW unless you write AS SEPARATE UNIT.

Regards,

Prasenjit

[kirankerudi]

Hello All,

The purpose of the report program is to check delivery completion.

And in update task, I have written logic to update a custom Z-TABLE with delivery quantities. So after update I will call this report which will check for delivery completion and would set a flag for those which delivery has been completed in the same Z-TABLE.

So, what might be the possible conflicts ?

Regards.

[Former Member]

The update task for one.

I would not write a report in the update task.  In fact I wouldn't do anything that I would consider 'standard' business processing in the update task,  and what you are doing is basically a standard business process.

Abandon the idea of doing this in the update task.  Find an appropriate user exit and write to your ztable there - making it in the form of a queue.

Then write your report to report on what is in the queue,  removing or marking entries as printed so that they are not reported a second time (I don't know your full scenario),  and then submit that as a batch job every so often.

Rich

[kirankerudi]

Hi Richard,

There are no suitable exits for this one (J_BNFECALLRFC).. We have created an implicit enhancement just before the commit call. Here in this enhancement we have called an FM in Update Task. This FM will update Z-Table. Within this FM, I called the report update program..

Regards

[Juwin]

Try a different approach:

Create a workflow standard task, and point that to your program.

From your implicit enhancement call function SWE_EVENT_CREATE in update task, passing NO_COMMIT_FOR_QUEUE as TRUE, so that a commit doesn't happen.

This call should create a workflow event in the system and trigger your standard task, which will in turn call the program.

Thanks, Juwin.

[Former Member]

Your update program is running as a V1 update right so, why don't you write the statistical update kind of stuff that you want through your report in a V2 update and may be even update a log for better system wide visibility. Try to run the V2 steps in a collective run for optimised performance.

Regards,

Prasenjit