New BOPF implementation on existing custom tables, implementation options

[former_member488575]

We are on SAP ERP EHP7, NW 7.4 SP18.

I wanted to ask opinions from the community on how to best implement a complete refactoring of an existing ABAP solution.

To keep it simple, we have 3 custom tables that have many existing various custom ABAP objects that perform CRUD against them. I'm wanting to convert all of these calls to use a central BOPF architecture. Then we'll be wanting to implement some of the BOPF handled features like locking, change documents. Following that, we'll then be exposing them as odata entities and creating UI5 applications.

The question I have is would you:

• implement BOPF on top of the existing table and implement a custom data access class

or

• update the existing table key with a GUID and then implement BOPF on it?

I'm leaning towards updating the table keys to be BOPF compliant. This then would enable us to implement BOPF with out a custom DAC, right? I'm obviously greatly over simplifying, but want to simply weigh this option on its own.

[cyclingfisch_]

Hi,

I would definitely go for the second option. Because implementing an own DAC is not that easy and SAP did already do it for you. So why not using it?

My suggestion would be to create new tables using the BOPF tools and migrate the data from your existing tables. This would ensure that the old CRUD logic is not used anymore to access the "BOPF enabled" tables and you don't get inconsistencies (e.g. missing GUIDs.)

Cheers Martin

[former_member488575]

Thanks Martin,

I was also concerned about correctly converting existing CRUD operations and your strategy seems to eliminate inconsistent interactions.