BOPF: Using Non-UUIDs (DB_KEY) keys DB tables

1. Definition

The Business Object Processing framework is an ABAP Object oriented framework that provides a set of generic functionalities for modularized and standardized development. It controls business logic as well as data retrieval of buffer and persistency layer. The Business Object Processing Framework mainly processes data that are uniquely identified by UUIDs. This means, database tables should contain DB_KEY of Type RAW16. In case, there is a requirement to use existing legacy tables (Non RAW16 keys) in BOPF then it requires different steps in configuration of BOPF. Many blogs/documents are available that can provide more details about default configuration process and implementation of BOPF. However, not much information is available on the configuration required for using non-UUID key fields as table keys.

2. Objectives

The objective of this document is to explain how to create BOPF nodes using legacy tables or existing database tables without DB_KEY (RAW16) keys.

3. Requirement

A master data maintenance application has to be created using existing database tables which do not have RAW16 type key. Since the development has to be done on S4HANA, it mandates the use of BOPF. Hence, the developer would have to configure the legacy tables with non RAW16 key fields to be used in BOPF.

Let’s assume the below tables are the database tables that the developer would like to use in BOPF modeling.

Header table: ZQUOTA_HD

Fields	Type	Key
COMPANYCODE	CHAR4	Key
QUOTANUMBER	CHAR10	Key
QUOTATYPE	CHAR1
QUOTASTATUS	CHAR1

Item Table: ZQUOTA_IT

Fields	Type	Key
COMPANYCODE	CHAR4	Key
QUOTANUMBER	CHAR10	Key
QUOTAITEM	CHAR4	Key
QUOTAMATERIAL	CHAR18
QUOTAQUANT	CHAR10

4. Understanding keys in ROOT & Sub Nodes

Let’s first understand default BOPF database relationship. How UUIDs (RAW16 type) keys are used in the Database tables of parent child relationship. In BOPF each node instance will be as per UUIDs primary key stored in the database table.

Node	Key Fields
ROOT	MANDT DB_KEY (as KEY)
Sub node of ROOT	MANDT DB_KEY (as KEY) PARENT_KEY
Sub Node of Sub node (third level)	MANDT DB_KEY (as KEY) PARENT_KEY ROOT_KEY

DB_KEY, PARENT_KEY, ROOT_KEY all are type RAW16.

1. Legacy DAC (Data Access Class)

In order to have a node representing instance stored in a database table that doesn’t have a RAW16 type key as primary key, the Legacy DAC (Data Access Class) is used. This special class creates RAW16 type transient key values for each instance when you read data from the database. This key is temporary stored during a session only. Below example explains mapping of legacy DAC created transient keys with legacy table key:

Legacy table key:

Company Code (Key)	Order Number(key)	Order Status
ZAB1	BK0001	Open
ZAB1	BK0002	Open

Field Company code and Order number are primary key of legacy table which uniquely identify each table entry.

Legacy DAC:

Transient key and Legacy table key mapping:

KEY (RAW16)	Company Code (Key)	Order Number(key)
0	ZAB1	BK0001
1	ZAB1	BK0002

Transient key and legacy table data mapping:

KEY (RAW16)	Company Code (Key)	Order Number(key)	Order Status
0	ZAB1	BK0001	Open
1	ZAB1	BK0002	Open

BOPF:

Transient key and legacy table data mapping

KEY (RAW16)	Company Code (Key)	Order Number(key)	Order Status
0	ZAB1	BK0001	Open
1	ZAB1	BK0002	Open

5. Configuration

The following steps explain step by step configuration:

1. Run t-code BOBX

There are other transactions code. I prefer to use BOBX. Create a new BO. Change setting to ‘Extended’ view:

2. Maintain Data Access Class

Maintain DAC class /BOBF/CL_DAC_TABLE in Data Access Class field.

3. Create ROOT Node

Create ROOT node. You can change text of ROOT node as well. Maintain Data Access Class as /BOBF/CL_DAC_TABLE. Give Database table name for example ZQUOTA_HD and Data structure ZSQUOTA.

Below screenshot provides database table structure details:

structure ZSQUOTA:

4. Create a Child Node:

Create a child node by right click on ROOT node and create sub node: Give Data Access Class /BOBF/CL_DAC_TABLE

Subnode:

Use item table ZQUOTA_IT in subnode:

Structure ZSQUOTAIT

5. Create Alternative keys

Create Alternative keys of node elements ROOT and sub node QUOTAITEM.

Name of Alternative key for ROOT should be DB_KEY and Sub node should have keys DB_KEY and PARENT_KEY just like default BOPF database key.

Alternative key of ROOT node:

Create a structure of keys:

Alternative Key of Sub Node Quota Item:

For the sub node you must create DB_KEY with structure of item keys fields and PARENT_KEY with parent i.e. ROOT key.

Structure of sub-node key:

Add PARENT_KEY:

6. Generate BO

Generate BO, constant interface and Dictionary elements.

6. Test

Now test BO, click on execute button. It should open window with BO for testing.

Click on add ROOT button:

Now click on association button for quota item:

Click on Add button and add items:

Finally, click on save button and save record in the database:

7. Coding

Coding part is same as default BOPF. Only additional call required for instantiation using CONVERT_ALTERN_KEY method of service manager. It is required when you try to read a record from DB using key fields.

8. Limitation

There are some limitations:

1. You must use CONVERT_ALTERN_KEY using actual key fields for creating node instances.

2. Instance of transient nodes are only for one session. No need to store it for multiple session it won’t work.

3. The legacy DAC is only available with NetWeaver 7.50 and above

4. A node managed by DAC can have DAC managed node only