Allow Within an LUW (Transaction_Manager) COMMIT WORK AND WAIT

[Former Member]

During data processing i use persistent classes. Therefore I start a LUW using IF_OS_TRANSACTION_MANAGER and IF_OS_TRANSACTION

At the end of the complete process I do either a ...->end() of a ...->undo() to store or cancel the changes made on the persistent objects.

Well, it just so happens, that in between a different logic is called that stores other data in the database and calls COMMIT WORK AND WAIT.

This now results into a Dump in class CL_OS_TRANSACTION Reason: "OS_COMMIT_TOP_FAILED".

Is there a way to capsulate the other logic within my LUW, allowing them to do mutiple COMMIT WORK AND WAIT without having an influence on my LUW and my persitent objects?

[nabheetscn]

Hello

If the processing of the new code is independent of current code then you can wrap the new code in a Function module and call it as starting new task. So this will not impact the current flow.

Thanks

Nabheet

[Former Member]

Hello Nabheet,

It works pretty nice with the FM and starting new task. No Issue with OS_COMMIT_TOP_FAILED any longer.

I encapsulated the method call in such a FM. But the "Starting new task" does not allow importing values back into my method. And the new task is "so far away" that even using static attributes or singleton classes "as a messenger" won't work to shift data back out of the FM into my routine.

Any Idea on that little remaining problem?

Many thanks and KR

Markus

[Former Member]

Taking over the values is pretty easy. If I would have read the Help correctly. Using the "Calling my_method ON END OF TASK" ;-).

So everything works fine now.

[Ankit_Maskara]

Another approach you can follow is to implement an implicit enhancement in the other logic and have a flag imported from memory from your custom logic. Based on this this flag control the Commit Work and Wait statement of other logic. For example if the call comes from your methods then bypass the commit work and wait since in your own logic at the end of processing you would have written a commit work statement. In other cases from where the control comes directly to the other logic let it work as is i.e. with existing commit work and wait statement.

[balaji_nandikolla]

Hi

Have you tried transactional RFC (tRC), to achieve your requirement?

Regards,
Balaji

[Former Member]

Hello Balaji,

I checked Google to get an idea of what you mean with tRC. In other words call the FM with "IN BACKGROUND TASK" instead of "STARTING NEW TASK" . No I did not try that by now. Today I coded a FM as RFC and tried the "New Task"-way. It worked, but I can not import parameters from the FM back into my routine.

Monday is a new day I will check it.

The custom logic contains a customer own specific package and coding for managing web-service calls. For our new tool, that communicates via web-service it is mandatory to use that logic.

So we will see how to manage this last remaining issue.

Regards

Markus

[Sandra_Rossi]

typo : tRFC

[Former Member]

Taking over the values is pretty easy. If I would have read the Help correctly. Using the "Calling my_method ON END OF TASK" ;-).

So everything works fine now.