XO Framework – Extensible Objects

This chapter provides detailed instructions about the integration of your application into XO. If you
need any details about XO, please see note 1623809 (contains a developer documentation as
attachment).
XO customizing
For maintaining, the XO customizing transaction SE80 is used. The relevant business object type for
all customer/vendor data is BUSINESS_PARTNER.
5.1 Scenario A – Integration of application owned tables
This chapter describes the XO-related steps that are necessary to integrate additional (new /
application-owned) tables into transaction BP.
5.1.1 Create Memory Object (MO) class
For each database table that shall be integrated into transaction BP a memory object class is needed.
The class has to inherit from class CVI_MO_CUSTOMER for customer data or CVI_MO_VENDOR for
vendor data.
Naming convention: CVI_MO_<TABLE_NAME>
Example: CVI_MO_KNAS
Validation
In the new class, it is necessary to create separate validation methods (static methods with public
visibility) for every table field that needs to be validated. You can also create methods to perform
combined validations using multiple fields. However, it is strongly recommended to have a low
granularity when creating the methods.
In addition, method VALIDATE_INTERN must be redefined. Within the redefinition first of all method
VALIDATE_INTERN of the super-class has to be called, before all new validation methods within this
redefinition are processed. You can compare for example the implementation in method
CVI_MO_KNA1->VALIDATE_INTERN. Method VALIDATE_INTERN is called in an overall check on
saving the business partner or when pressing button “check” in business partner maintenance.
In addition, the created validation methods must be called in the corresponding PAI function modules
for dialog input validation.
Please also have look at SAP note 2293713 if want to integrate foreign key checks provided by
classes CMD_EI_API_CHECK and VMD_EI_API_CHECK.
Class examples
CVI_MO_KNA1, CVI_MO_KNB1, CVI_MO_LFA1, CVI_MO_LFB1
5.1.2 Create Persistence Object (PO) Class
If your application table uses KUNNR or LIFNR as key field, no separate PO-class is needed. You only
need to assign the existing persistence object CUSTOMER or VENDOR to your memory object in the
next section.
If the key field of your table is not KUNNR or LIFNR, you have to create a separate persistence object
class. The new class has to inherit from CVI_PO_CUSTOMER or CVI_PO_VENDOR. Now execute
the following steps:
1. Redefine method IF_XO_PERSISTENCE_OBJECT~READ_DATA

Copy the coding from the inherited method (superclass method)

In the copied coding change the select statement at the end according to your table key.
2. Redefine method IF_XO_PERSISTENCE_OBJECT~SORT_DATA_BY_KEY

Copy the coding from the inherited method (superclass method)

Exchange the name of the assigned component ‘KUNNR’ / ‘LIFNR’ with the key field of your table at
the end of the method.
5.1.3 XO Customizing
Execute the following steps to maintain the XO customizing for your objects: Cookbook – Extending SAP
Business Partner with application owned customer/vendor dataset
© Copyright SAP SE 2018 Internal only Page 14 of 31
• • Start transaction XO80.
• • Select Business Object Type BUSINESS_PARTNER from the initial popup.
• • Switch to change mode.
• • Make sure that you are in “SAP standard version” (ctrl+F3, 10 th button in button line)

a) Persistence Object
This step is only needed when you have created an own persistence object in chapter 5.1.2. If you use
one of the standard persistence objects CUSTOMER or VENDOR, you can skip this step.
Open tree node “Persistence Objects” and create a new entry.
Name of Persistence Object = can be chosen arbitrarily
Description = can be chosen arbitrarily
Individual Implementation = Name of persistence object class created in step 5.1.2
b) Memory Object
Open tree node “Memory Objects”. Switch to change mode and create a new memory object entry.
Name of Memory Object = Table name in SE11
Name = can be chosen arbitrarily
Alternative Key = KUNNR or LIFNR or other key field name of your table
Individual Implementation = Name of memory object class created in step 5.1.1.
Scroll down to… Cookbook – Extending SAP Business Partner with application owned customer/vendor dataset
© Copyright SAP SE 2018 Internal only Page 15 of 31
Selected Persistence Object = CUSTOMER or VENDOR when your table uses KUNNR or LIFNR
Selected Persistence Object = Name of your own persistence object from last step
c) Segment Object assignment
After creating the memory object this has to be assigned to the correct segment object.
Open tree node “Segment Objects” and assign your memory object to the segment object by drag and
drop or button functionality.
The correct segment object depends on the customer/vendor segment to which your table belongs:
CUSTOMER_GENERAL = General customer data – e.g. KNA1, KNAT
CUSTOMER_CC = Company Code data – e.g. KNB1, KNB5
CUSTOMER_SALES = Sales Area data – e.g. KNVV, KNVI
VENDOR_GENERAL = General vendor data – e.g. LFA1, LFAT
VENDOR_CC = Company Code data – e.g. LFB1, LFB5
VENDOR_PURCHASE = Purchasing Org. data – e.g. LFM1, LFM2
5.2 Scenario B – Integration of core table appends
All appends of customer/vendor core tables like KNA1, KNB1, LFA1 or LFB1 are supported by the
customer vendor integration (CVI) enhancement project. It is necessary to integrate all further append
fields of the core tables using the standard classes like CVI_MO_KNA1_ENH or CVI_MO_LFB1_ENH.
Do not create new memory object classes inheriting from these core classes!
Background information
The standard way to create new classes inheriting from the standard classes and replacing them in
transaction XO80 will lead to technical problems. In case extensions have already used an older core
class to inherit from, the new enhancement will not be visible in the extension and an exchange of the
inherited class is technically not possible. Cookbook – Extending SAP Business Partner with application
owned customer/vendor dataset
© Copyright SAP SE 2018 Internal only Page 16 of 31

The purpose of this chapter is to describe an alternative approach how applications can enhance the
business partner by customer/vendor core fields without the need of creating new memory object
classes. The needed validations will be implemented in a validation class which is registered in XO
customizing as validation object.