Calling Persistence Objects in Workflows

[Former Member]

Hello All,

I have created my data model using Persistence classes and the entire process of updating is encapsulated in a method.

This method is called in a task of the workflow which tries to update the flow.

The changes are made in the persistent object correctly and no exceptions are raised.

I tried several scenarios of creating an LUW using Transaction Manager:

I am checking whether there is a TOP transaction in the transaction manager(IF_OS_TRANSACTION) and that TOP transaction has EXTERNAL_COMMIT flag set, then I am not creating a new transaction.

In this scenario, I am expecting that old LUW(classical) is created and the workflow framework takes care of the commit work.

This did not work.

I used this data model in normal module pool program and it worked correctly.

In this scenario, I created new transaction using START method of IF_OS_TRANSACTION.

Can anyone suggest what is the actual way of calling persistence database objects in workflows or I just need to call Commit work manually in this

I have seen the blog

https://blogs.sap.com/2013/04/23/using-a-persistent-object-in-a-workflow/

I did most part of it but in a different manner.

With regards,

Sandeep Akella

[pokrakam · Accepted solution]

Persistent objects are a little old and not something that SAP is developing anymore.

But... I've used them in the past, and never had an issue. To be fair, my use cases in workflow were usually simple so I never used the transaction manager. Just create/update, then COMMIT WORK, done.

In my opinion persistent classes should not be used directly in WF, but wrapped into a business class. Muddling persistency and business logic just combines too much functionality into one class. Have a look at CL_BOOK_PPF if you really must.

This is also described in chapter 16.8.2 of the WF book.

[Former Member · Accepted solution]

Hello Mike,

Thank you for your reply.

I wrapped the calling to persistence object in a class and did not use it directly in the workflow.

Yes maybe, I should add commit work manually and see if it works.

Wouldn't the workflow framework take care of commit work?

[pokrakam · Accepted solution]

It should do, but there are different ways it can handle it. Try it with and without, if it doesn't work without COMMIT then you obviously need it.

The transaction manager is only really needed if you're doing multiple updates across different persistent objects. I've never seen a case for using it for a single object or table.

[Former Member · Accepted solution]

I have multiple tables of persistence classes which I held together in an LUW using transaction manager.

All these updates I have written in a single Process method.

That method call works fine in SAP GUI screens.

The same call I have made in workflows by checking the variable EXTERNAL_COMMIT( X - is compatibility mode for classical LUW scenarios).

I can see the workflow framework implicitly creating the TOP transaction and It bundling all the changes in the same transaction.

But I am not sure, why the actual DB update is not happening.

[pokrakam · Accepted solution]

Yes on the surface of it your scenario should work. But the workflow transaction handling is fairly complex. Ideally you should leave it to the workflow commit, but I've seen some occasions where an explicit COMMIT is necessary. This partly depends on what your follow-on steps do. For performance reasons WF may bundle several steps into a single transaction.

I would leave out the external_commit and see what works. Or use external_commit and do an explicit COMMIT WORK.

I know it's not a very technical explanation but in my (lengthy) experience it doesn't always make sense, sometimes you just need to experiment and find out what works for your scenario.

[Former Member · Accepted solution]

Hello Mike,

I have written Commit work at the end of the step and it worked.

Thank you.

[egor_malov · Accepted solution]

Hello, Mike,

I noticed you called persistent objects a little old. What do you think is the way to go nowadays? Is it BOPF?

(Sorry for this offtopic comment, just couldn't help asking)

[pokrakam · Accepted solution]

Good question. Yes, BOPF is what SAP is actively promoting.

I don't have time to search for it now, but there was a not-quite-official statement somewhere on this site that Persistent Objects are in sunset mode and BOPF is the way to go.

Edit: Curiosity got the better of me and I found the info quite easily. Here are two strong hints from knowledgeable SAP people that Persistent Classes are all but deprecated:

https://archive.sap.com/discussions/thread/3893989

https://answers.sap.com/questions/439555/abap-oo-interface-for-db-access.html

[egor_malov · Accepted solution]

Mike, thank you!!