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
No comments:
Post a Comment