‎2014 Nov 06 5:53 PM
Hello Gurus,
I have a custom output type in which I've created and put my custom program/form into configuration. Everything works fine except there is some processing in my form that I need to do a COMMIT WORK. When I do this with a dispatch time of 4 - Immediately it short dumps because of the this COMMIT WORK. When I remove it I get no short dump but also my work doesn't actually commit and do what it needs to do. However, if I leave the COMMIT WORK in and just process the output with a dispatch time of 1 - send with periodic job and then process it via transaction VL71 everything works fine and my work does what it's supposed to do. Does anyone know any way to get my work to commit while still using the dispatch time of 4? The two function modules I'm using that require the COMMIT WORK are RV_MESSAGES_INSERT and RV_MESSAGES_UPDATE.
Thanks,
Tamara
‎2014 Nov 10 5:26 PM
I think what I'm going to do is to just have the output transmitted at 1 send periodically with scheduled job and just schedule a job to do what I need.
Kartik - I liked the RFC call but it didn't work for some reason and it seems to be too much effort.
Noel - The reason why I'm not using a user exit is because it's for the purpose of an output condition. The scenario is that when a delivery get's PGI'd I have an output that gets created. Based on certain criteria at the same time I'm creating a new output type.
I'm using the function modules RV_MESSAGES_INSERT and RV_MESSAGES_UPDATE but it will only work if a commit work is put after the update. Therefore I cannot do it in the immediate dispatch time.
Thanks everyone for all their input I greatly appreciate it.
‎2014 Nov 07 2:38 AM
Hi Tamara,
What`s error message from 'commit work'?
regards,
Archer
‎2014 Nov 08 5:22 AM
‎2014 Nov 08 7:30 AM
Actually no commit is required with dispatch time 4, are you calling any bapi or updating tables?
one workaround is to have the code in a RFC FM and call it with 'starting new task' addition asynchronously.
‎2014 Nov 09 9:56 PM
Hi Tamara,
The problem is that the output is usually processed in the update task and you are not permitted to execute a "COMMIT WORK" in the update task (this is documented in the ABAP keyword documentation of "COMMIT"). A Commit triggers the update task, so if you have a commit within the update task, what should it do - trigger the update task again? No, it dumps.
It works in VL71 because here the output is not being processed in the update task in VL71.
I think you should probably look at the possibility of employing a user exit to populate whatever data you need to. User exits would be called before the COMMIT. Check include MV50AFZ1 for a suitable exit (I guess this output is a delivery output due to you using VL71).
It might be a possibility to use "INSERT" instead of COMMIT in the output program to get the data into the database, but obviously this requires a lot of testing and some knowledge of what you are trying to do.
‎2014 Nov 10 5:39 AM
Use this FM to check if the code is being called in update task or not,
TH_IN_UPDATE_TASK
Then call commit accordingly.
‎2014 Nov 10 5:26 PM
I think what I'm going to do is to just have the output transmitted at 1 send periodically with scheduled job and just schedule a job to do what I need.
Kartik - I liked the RFC call but it didn't work for some reason and it seems to be too much effort.
Noel - The reason why I'm not using a user exit is because it's for the purpose of an output condition. The scenario is that when a delivery get's PGI'd I have an output that gets created. Based on certain criteria at the same time I'm creating a new output type.
I'm using the function modules RV_MESSAGES_INSERT and RV_MESSAGES_UPDATE but it will only work if a commit work is put after the update. Therefore I cannot do it in the immediate dispatch time.
Thanks everyone for all their input I greatly appreciate it.