XO Cookbook PDF

Extensible Objects  Cookbook
Table of Contents
Table of Contents ................................................................................................................................................................................................... 2
Version History ....................................................................................................................................................................................................... 4
Introduction to Extensible Objects......................................................................................................................................................................... 5
A Simple Example ................................................................................................................................................................................. 6
A Simple Plan ...................................................................................................................................................................................... 10
Your First Extensible Object Application ............................................................................................................................................ 13
Individual Implementations in Your Extensible Object Application ................................................................................................... 23
Summary of XO Objects and Assignments ......................................................................................................................................... 24
Facts and Principles .............................................................................................................................................................................................. 25
Object Instantiation ............................................................................................................................................................................ 26
Read and Write Data .......................................................................................................................................................................... 27
Mass Data Access ............................................................................................................................................................................... 28
Transactional Events........................................................................................................................................................................... 29
Validation in Your Extensible Object Application ............................................................................................................................... 30
Integration of Change Documents in Your Extensible Object Application ......................................................................................... 31
The Listener in Your Extensible Object Application ........................................................................................................................... 32
2 XO – Extensible Objects | Cookbook

Tool Integration .................................................................................................................................................................................................... 33
BDT Adapter ....................................................................................................................................................................................... 34
API Adapter......................................................................................................................................................................................... 35
CNS Adapter ....................................................................................................................................................................................... 36
Reference ............................................................................................................................................................................................................. 38
XO Objects Class Diagram................................................................................................................................................................... 39
XO Sequence Diagram ........................................................................................................................................................................ 40
Appendix............................................................................................................................................................................................................... 44

Version History
Version No. Date Author Changes
0.7 30.09.2010 Mathias Beck Introduction to extensible objects, graphics added
0.8 08.06.2011 Jörg Mauelshagen Enhancements to XO details
0.9 23.08.2011 Henning Masuch Facts and principles, tool integration
1.0 02.09.2011 Jaqueline Steptoe Language Editing

Introduction to Extensible Objects
Extensible Objects (XO) is a framework designed to support the development and

enhancement of business applications. XO is best used for application-managing data
that needs to be persisted on a permanent data source (usually a database). The main
examples of this are master data objects.
These applications are expected to represent the specified functions in a robust and
high-performing manner. However, the pace of change and the demand on flexibility is
continuously increasing.
Expectations have risen to a level where the sophistication of a solution is measured by

its ability to support easy enhancement of the application as well as easy integration
into existing software environments.
These high expectations often complicate the application’s code base and subsequently
lead to increased maintenance efforts. XO counters this effect by providing a clearly
structured and easy-to-understand object model together with a very open and flexible
framework. This framework consists of generic components that can be reused and
refined at all levels.
The following sections of this cookbook will help you understand …
 the principle idea and framework architecture behind XO
 the building blocks of the framework
 how to develop and individualize an XO-based application
 how to integrate XO-based applications into other environments

A Simple Example
SAPLANE SPPLANE
Let’s use a simple example to familiarize ourselves with the framework.
MANDT MANDT
The following data model is based on the simple idea of airplanes. The database PLANETYPE PLANETYPE
SEATSMAX ANZ_NOTAUS
table SAPLANE is the root table of the data model. Each table entry represents a CONSUM ANZ_PERS
single airplane. CON_UNIT ANZ_SBER
TANKCAP
The additional tables SPPLANE and SCPLANE have a 1:1 relationship with the CAP_UNIT
root table. They contain details that are specific to the potential role of the WEIGHT
WEI_UNIT SCPLANE
airplane (“cargo plane” or “passenger plane”). SPAN
MANDT
SPAN_UNIT
PLANETYPE
LENG
CARGOMAX
LENG_UNIT
From an object-oriented point of view, the first idea would be an inheritance CAR_UNIT
OP_SPEED
between three types of airplane: the generic airplane, the passenger plane, and SPEED_UNIT
the cargo plane. PRODUCER
SEATSMAX_B
SEATSMAX_F
Airplane
Passenger Plane Cargo Plane
However, it is also possible to have a third type of airplane, a multipurpose plane that can transport passengers and cargo. To add more details to our
model, we define three individual objects that represent the different types of details. The four airplane types then comprise the specific aspects that
define them.

A Simple Example
Whereas each plane represents an holistic view of

an object, the “details” objects are subnodes of the
object that describe it in more detail. Some of Airplane
these subnodes are mandatory and some are 1
optional. Various compositions represent further
specialized entities of a general object type.
Passenger Plane Multipurpose Plane Cargo Plane
To ensure flexible and normalized database
persistency, the best choice would be to attach the 1 1 1 1
relevant database tables to the subnodes. This
means that we do not need to define tables with
overlapping field design for each and every new 1
1 1 1 1
object type.
General Details Passenger Capacity Details Cargo Capacity Details
Table:SAPLANE Table:SPPLANE Table:SCPLANE

A Simple Example
In this simple example, each “details” object refers

to a single database table. We will see later that Airplane
more elaborate object models can be 1
constellations in which one subnode connects to
more than one database table or one database
table is attached to more than one subnode. Passenger Plane Multipurpose Plane Cargo Plane
To ensure flexibility and to avoid redundant 1 1 1 1

buffering and database access, it is important to
separate these technical levels from the business
view of our object. 1
1 1 1 1
1 1 1
SAPLANE SPPLANE SCPLANE

A Simple Example Business view
Airplane
If we take a closer look at this model, we see that it 1
is structured in layers.
The top layer comprises all objects that have an

holistic view of a real-life (business) object. The
“details” objects are all subnodes and represent a
1 1 1 1
semantic building block for business objects.
The remaining layers are a technical representation

of the related database tables underlying these 1 1
1 1 1
business objects. General Details Passenger Capacity Details Cargo Capacity Details
1 1 1Technical view
We are only one step away from our first XO
application. First let’s take a look at the building
blocks provided by XO:

A Simple Plan
XO correspond to a plain model for implementing a business application, which expects a clear and well-defined interface between application provider
and application consumer. The providing application separates transactional behavior from the business object-specific logic, which in itself separates
from the connection to a persisting entity.

A Simple Plan
XO comprises nine elementary building blocks. These blocks are provided with a generic implementation and enable an XO user to individualize them
further. The blocks are bound together by a customizable model.
Business Object Type The business object type groups together all components that
are relevant for a software solution developed in XO. It acts like
a unique identifier for Customizing and the runtime instances.
Customizing Customizing contains the component-specific configuration and

relationship settings between the component levels. It is
interpreted at runtime in order to instantiate the correct XO
model of the application.
Controller The controller manages the transactional behavior in accordance

with the requesting overlying transaction model. It propagates a
transactional event to all related objects so that one
transactional step can be completed.
Business Objects Business objects (BO) are the unique representation of a

business object. The runtime instances represent the object in its
entirety. Business objects subdivide their behavior and data
model with the help of segments.
Segment Objects Segment objects (SO) represent logical and semantic subnodes of
a business object. They either connect to a data memory (via
memory objects) or simply represent a specific feature or
behavior.

A Simple Plan
Memory Objects Memory objects (MO) represent the data in memory. They usually
refer to a database table and ensure that data is buffered, changes
collected, and that the persisting level is connected.
Persistence Objects Persistence objects (PO) retrieve or store data from the database.
They support mass data retrieval and optimized mass update
processes.
Validation Objects Validation objects (VO) carry out additional plausibility checks on a
business object or a specific segment object. These objects do not
overrule the standard object validations but also do not represent
a technical modification.
Listener Objects Listener objects (LO) enable outside applications to subscribe to

XO-specific events or notifications.

Your First Extensible Object Application

Business view
Airplane
Let’s see how the XO object model
1
matches our airplane design:
 The holistic objects Business

“passenger plane”, “cargo Passenger Plane Multipurpose Plane Cargo Plane
Object
plane”, and “multipurpose Level
1 1 1 1
plane” match the definition
of a business object.
 The subnodes of the planes Segment 1

1 1 1 1
with their semantic view Object
are best represented by Level
segment objects.
 The technical
representation of the Memory 1 1 1Technical view
underlying data model at Object SAPLANE SPPLANE SCPLANE
runtime can be done with Level
the help of memory
objects.1
 Finally, the persistence Persistence

objects access the database Object
table for read and write Level
operations.2
1
The name of the memory objects must match existing ABAP Dictionary structures. Furthermore, we recommend you use the name of the database table.
2
The XO-generic persistence object is already sufficient in this example since the memory objects are named according to their database tables.

XO comes with its own modeling shapes. Before we configure the new application in the system, let’s take a look at the corresponding XO model:
Business Object Type

Airplane
Business Objects
General Details Passenger Capacity Cargo Capacity

Segment Objects
Root Link
Memory Objects
generic
Generic Persistence Object
The model represents exactly what was illustrated earlier. The “root link” comes as an additional element. This will be explained later.
Now we are ready to implement our model. Let’s move to the XO Cockpit.

Start the SAP GUI transaction XO_COCKPIT (or

XO80). When you call the transaction for the first
time, an initial dialog box appears.
Usually you select an existing business object type

from the dropdown list and move on to the main
screen. However, in this case you want to create a
new business object type. To do this, choose or
press F5.
Fill the Name of Business Object Type

and Description fields as shown in the
example.
Choose or Enter to continue to the main

screen.

You are now on the main screen.
Let’s have a closer look at the screen

elements. 1
2 3
A set of general functions are represented
by the main button bar (1).
The navigation tree (2) contains three

main tree nodes:
 Components – this is where you

enter the XO model with all its
elements (BOs, SOs, and so on)
 Class library – this is where you

find all classes listed by XO
component type. The class library
is generated by the cockpit and
helps you to access your individual
implementations quickly via
forward navigation (double-click).
 Further settings – this is where

you can make additional settings
for the tools integrated with XO.
This will be described in more
detail in the section Tool
Integration.

Let’s continue with our airplane model.
You can create all other XO components from the main screen.
You have two choices:
a) Select the relevant tree node in the left-hand navigation tree

and select New in the context menu (by right-clicking).
b) Choose the Create New Extensible Object button

on the main button bar or choose F5 and then select the
desired object type in the following dialog box.

An input screen is provided for each XO element. You also find

these fields on the corresponding maintenance subscreens on the
main screen.
Let’s take a look at the business object (BO) screens:
In addition to the input fields on the creation screen, the

maintenance subscreen of the BO allows you to define:
 The SOs assigned to the BO
 The VOs assigned to the BO

Let’s take a look at the segment object (SO) screens:
In addition to the input fields on the creation screen, the

maintenance subscreen of the SO allows you to define:
 The MOs assigned to the SO
 The VOs assigned to the SO

Finally, for our first application, let’s have a look at the memory
object (MO) screens.
Most settings can be defined when you create the

memory object. However, the persistence object can
only be assigned on the maintenance screen.

Now, provided you followed the XO model

and didn’t find the screen introduction too
complicated, you should have been able to
create the new business object type and all
of the business objects, segment objects,
and memory objects. Next we need to
make the required assignments and define
the root link.
The easiest way to create assignments is to

drag and drop the designated object from
the navigation tree into the corresponding
tree control. This works for the following
assignments: SO to BO, VO to BO, MO to
SO, and VO to SO.
You define the root link on the

maintenance screen of the business object
type. Input help is available for the input
fields.

Congratulations!
You have just completed your first
XO application!
(Don’t forget to save your settings.)
Before we move on to the next

level, coding with XO, we should
take a break. Your head is probably
full with questions. Let’s try to
answer some of these.

Individual Implementations in Your Extensible Object Application

When you add a new business, segment or memory object to your XO
application, you can decide to use an individual implementation for
the object behavior, instead of the generic one.
To activate your individual implementation, simply enter the class

name of this individual implementation. The class will not be
generated automatically but if you double-click the class name you will
be asked to create the class.
Individual implementations
of XO elements should
inherit from their XO
superclass. Redefinitions of
inherited methods enable
you to create your individual
implementation and change
the standard behavior of the
XO element.
XO element Superclass
Business Object XO_BUSINESS_OBJECT
Segment Object XO_SEGMENT_OBJECT
Memory Object XO_MEMORY_OBJECT
Persistence Object XO_PERSISTENCE_OBJECT
Instead of individual implementations of XO elements, if you define the business object type you
can use your own classes for the several XO elements. These classes will be the standard classes
for the generic implementation of the XO elements after you have assigned them to your business
object type.

Summary of XO Objects and Assignments

The following different assignments exist in XO. The “generic assignments” are made without any additional customizing effort. The concrete
assignments can be defined in the Cockpit configuration.
Business Object
Type
Business Object 0:n

Business Object
1:n 0:n
Validation Object
Segment Object 1:n 0:n
0:n
Segment Object
Memory Object 1:n
0:1
[1]
0:n
Persistence Object generic

Memory Object
1:n 0:1
Validation Object 0:1 0:1 0:1
Persistence Object Assigned BO Type

Listener Object Assigned BO
Generic Assignments Concrete Assignments

Facts and Principles
After you have modeled your business object using XO_COCKPIT and included your business logic with specific implementations, you can start building
your application. In this section you’ll find code examples of how to work with your business object.

Object Instantiation
All XO objects are instantiated using factory methods. Objects must not be created using the ABAP statement CREATE OBJECT.
The main factory class is XO_FACTORY. This class provides methods to retrieve single objects (business objects, segment objects, memory objects, and
so on) as well as more specific factory methods (business factory, segment factory, and so on).
The factory methods apply to:
- object instantiation
- the maintenance of a reference list for existing objects
- event linkages between objects

(for example, the segment objects register to the event
data_modified of their memory objects)
- mass operations for a set of objects

(mass read, for example)
- instance reuse (performance improvement)
With the exception of XO_FACTORY, the factory classes can be

specialized for a business object type. The specialized factory class
must inherit from the XO factories and can redefine their methods.

Read and Write Data

In general, data should be read and set using the business objects methods. The business object delegates the method call to the memory objects via its
segment objects. The memory objects contain the old data (as it is exists at database level) as well as the new data.
Note that when you add new data to the business object it doesn’t necessarily mean that these changes are saved to the database. To save the changes
to the database, you have to call the business objects method SAVE and raise the transactional events.
data: if sy-subrc <> 0.

lv_object_key type xo_object_key, write / 'This is not a cargo plane!'.
lr_bo_airplane type ref to if_xo_business_object, return.
lr_controller type ref to xo_controller, endif.
lt_data_new type tty_xo_table_data,
lt_messages type tty_xo_message. assign <data_new>-table_data->* to <table>.
read table <table> index 1 assigning <scplane>.
field-symbols:
<data_new> like line of lt_data_new, if sy-subrc <> 0.
<table> type standard table, append initial line to <table> assigning <scplane>.
<scplane> type scplane. endif.
lv_object_key = i_planetype. <scplane>-cargomax = i_cargomax.

<scplane>-car_unit = i_cargo_unit.
lr_bo_airplane = xo_factory=>get_business_object(
i_bo_type = 'AIRPLANE' i_bo_airplane->set_data_new( lt_data_new ).
i_bo_name = 'CARGO_PLANE'
i_object_key = lv_object_key lt_messages = lr_bo_airplane->validate( ).
). if lt_messages is initial.
lr_bo_airplane->get_data_new( lr_bo_airplane->save_data( ).
exporting endif.
i_table_name = 'SCPLANE'
importing lr_controller = xo_factory=>get_controller( 'AIRPLANE' ).
e_data = lt_data_new lr_controller->raise_finalize( ).
). lr_controller->raise_commit_start( ).
lr_controller->raise_commit_end( ).
read table lt_data_new lr_controller->raise_cleanup( ).
with table key table_name = 'SCPLANE'
assigning <data_new>. commit work and wait.

Mass Data Access

In general, XO reads data from the database as late as needed. In our airplane example, if XO reads only SAPLANE data it does not access the database
tables SCPLANE and SPPLANE. However, due to the deferred read access, XO accesses the persistence layer with n single requests when working with n
objects. If you are working with mass data these single requests should be combined into a mass request.
You can use GET_TABLE_DATA of the XO_MEMORY_FACTORY to trigger this kind of mass data read. The memory factory then buffers the data and uses
it later when it instantiates the XO business, segment or memory objects.
data:
lr_mem_factory type ref to xo_memory_factory,
lv_object_key type xo_object_key,
lr_bo_airplane type ref to if_xo_business_object,
lt_data_new type tty_xo_table_data.
lr_mem_factory = xo_factory=>get_memory_factory( 'AIRPLANE' ).

lr_mem_factory->set_buffer_limit( lines( i_object_keys ) + 100 ).
lr_mem_factory->get_table_data(
exporting
i_table_name = 'SAPLANE' In this example we’re not interested in the data,
i_object_key_list = i_object_keys so the importing parameter is not used. The
* importing
method will still fill the internal buffer of the
* e_data = lt_saplane
). memory factory for later use.
loop at i_object_keys into lv_object_key.
lr_bo_airplane = lr_bo_factory->get_instance(
i_object_name = 'PASSENGER_PLANE'
i_object_key = lv_object_key
).
lr_bo_airplane->get_data_new(
exporting
i_table_name = 'SAPLANE'
importing
e_data = lt_data_new
).
* process lt_data_new ...
endloop.

Transactional Events
The XO framework uses internal events for its transactional logic. By default these events are not coupled to any external events, neither the ABAP
events raised by COMMIT or ROLLBACK WORK or to any other frameworks events. This may seem a disadvantage since you have to link your external
events to the XO events or trigger the XO events explicitly. For example, the end of a logical unit of work (LUW) means nothing to the XO frameworks.
No data is saved and no memories are cleared.
But in fact the lack of a hard-coded dependency to other transactional events is one of the strengths of the XO framework. It allows you to integrate
your XO business objects into any framework with its own transactional behavior. All you have to do is map and link the events of both frameworks. For
some scenarios, such as the BDT framework or regular (B)APIs, XO provides adapters that map and trigger the XO transactional events.
The transactional events are raised using the XO Controller.
- FINALIZE. - ROLLBACK.
At this event, all XO objects complete their data. The XO This event should be used when the ABAP event ROLLBACK
default implementation calls the key generator and replaces WORK is raised. The XO business objects save a flag and the
temporary object keys (if used) with the final ones. object is locked. Since the ROLLBACK WORK releases all locks,
Furthermore, this event should be used to generate default this event should also be called to clear this flag.
values for your data and add any required administrative data
- CLEANUP.
(change user and timestamp).
This event clears all memory and buffers. It resets all XO
- COMMIT_START. object instances so that these instances can be reused
For technical reasons the event COMMIT is split into two (instance reuse). This event should be raised at the end of
steps. For the default behavior this allows you to first collect each LUW.
the changes of the single BOs and save them with a mass data method end_transaction.
access to the database. At COMMIT_START the XO memory data: lr_controller type ref to xo_controller.
objects submit their changes to their persistence objects. lr_controller = xo_factory=>get_controller( 'AIRPLANE' ).
lr_controller->raise_finalize( ).
- COMMIT_END. lr_controller->raise_commit_start( ).
lr_controller->raise_commit_end( ).
At COMMIT_END the XO persistence objects submit the lr_controller->raise_cleanup( ).
changes from all memory objects to the update function commit work and wait.
endmethod.
modules.

Validation in Your Extensible Object Application

To validate your XO elements in the individual implementation,
you can redefine the method VALIDATE. Without an individual
implementation you can define validation objects and assign them
to segment objects or business objects.
The class, in our example CL_VO_SO_CARGO_CAPACITY, has to

include the interface IF_XO_VALIDATION_OBJECT and can
implement the methods:
ON_VALIDATE_ME( ) Transfers the results of the validation to your

XO element, calls the XO element
methods ADD_VALIDATION_RESULTS( )
or GET_VALIDATION_RESULTS( ) from the
interface IF_XO_VALIDATION_TARGET
REGISTER_HANDLER( ) Code example:

set handler if_xo_validation_object~on_validate_me
for i_sender activation i_activation.
The new validation object must be assigned to the segment object using drag and
drop.

Integration of Change Documents in Your Extensible Object Application
You can write change documents for XO memory objects.

Set the Update Change Documents checkbox and define the change
document object.
Note that the change document objects have to be created up front

(using transaction SCDO). However, the generated function modules
for the change documents are not used since generic XO function
modules are used instead.
XO creates memory object-based change documents, even if

several tables ( memory objects) are assigned to one change
document object. This doesn’t comply with the principle of one
change document entry per business object change. Hence, if
business object-based change documents are needed the
generic XO integration can’t be used.
At business object type level you can activate or deactivate the use of
change documents for the whole business object regardless of the settings
for change documents for the XO memory objects.

The Listener in Your Extensible Object Application

To enable outside applications to subscribe to XO specific events
or notifications, you can implement your own listener object.
The class for the listener object must implement the interface
IF_XO_LISTENER_OBJECT.
In the interface method LISTEN( ) you can activate the handler for
all events implemented in the XO element classes.
Example of the XO element “business object”:
data lr_controller type ref to xo_controller.

lr_controller = xo_controller=>get_instance( bo_type_airplane ).
set handler:
on_commit_start for lr_controller activation true,
on_data_submitted_for_save for all instances activation true,
on_data_object_is_locked for all instances activation true.

Tool Integration
The concept of the transactional events of the XO framework allows you to integrate your XO business objects into existing frameworks as well as to
build new applications from scratch.
In addition, the XO framework provides adapters to easily integrate your XO business objects into existing frameworks and with existing tools.
 Business Data Toolset (BDT) adapter
The BDT is a central control tool for maintaining master data and simple transaction data. In addition to dialog maintenance, it also supports
maintenance with direct input and function modules. The BDT also provides generic services for consistently recurring requirements that occur
in change document lists, field groupings, and the deletion program. It takes control over these objects as well as generic parts and calls the
applications using predefined interfaces (control tables and events). The applications themselves introduce application-specific enhancements,
such as writing and reading application tables.
 (B) API adapter
SAP business objects are accessed through Business Application Programming Interfaces (BAPIs),
which are stable, standardized methods. SAP provided the first BAPIs for customers and external
providers in R/3 Release 3.1, enabling them to integrate their software components in an SAP system.
The number of BAPIs increases with each R/3 release and this also increases the possibility of object-
oriented access to an SAP system.
 Change notification service (CNS) adapter
The change notification service enables you to create, store, and read change pointers. A change pointer is an object that records a change
made to a business object by an application. The service stores some information about the business object and its changes (such as date,
change type, images). A report deletes the used change pointers after a specified period. The change notification service also supports different
read mechanisms for the stored change pointers. You can choose whether to display the entire history of the changes, or only one change
pointer containing the most important information.

Tool Integration
BDT Adapter
BDT applications have to provide several function modules for various BDT events, for example read data (ISDAT), complete and save data (DSAVC,
DSAVE), and initialize the memory (DLVE1, DLVE2). Since the implementation for these events is often similar, the XO framework provides a generic
implementation.
The generic function modules call

the methods of class
XO_BDT_ADAPTER. To enhance the
generic implementation for your
business object, provide an
individual implementation of the
BDT adapter, which inherits from
the XO_BDT_ADAPTER and
redefine the methods in question.
The BDT settings contain the name

of the application object according
to BDT Customizing and the name
of the ABAP Dictionary structure
for the direct input header data.
An overview of events for each BDT

application is shown in the bottom
part of the configuration screen.

Tool Integration
function ZZXO_API_CREATE_PASSENGERPLANE.
API Adapter *"------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING
Using the XO API adapter, you’re able to create (B)APIs for your business *" REFERENCE(I_SAPLANE) TYPE SAPLANE
*" REFERENCE(I_SPPLANE) TYPE SPPLANE OPTIONAL
object very quickly. The API adapter provides methods to read and write single *" EXPORTING
data sets as well as to create and change entire objects. *" REFERENCE(E_MESSAGES) TYPE BAPIRET2_T
*"------------------------------------------------------------
data:
function ZZXO_API_READ_PASSENGERPLANE.
Depending on the method, the lv_object_key type xo_object_key,
*"----------------------------------------------- API adapter checks whether lr_api_adapter type ref to xo_api_adapter,
*"*"Lokale Schnittstelle: lt_table_data type tty_xo_table_data,
*" IMPORTING
the object doesn’t exist yet ls_table_data like line of lt_table_data,
*" REFERENCE(I_PLANETYPE) TYPE S_PLANETYE (bo_create) or whether it lt_xo_messages type tty_xo_message,
*" EXPORTING lt_saplane type standard table of saplane,
already exists (bo_change),
*" REFERENCE(E_SAPLANE) TYPE SAPLANE lt_spplane type standard table of spplane.
*" REFERENCE(E_MESSAGES) TYPE BAPIRET2_T calls the validations, generates
*"----------------------------------------------- " prepare input data structure for API adapter (BO create)
error messages, and so on.
data: append i_saplane to lt_saplane.
lv_object_key type xo_object_key, ls_table_data-table_name = 'SAPLANE'.
lr_api_adapter type ref to xo_api_adapter, get reference of lt_saplane into ls_table_data-table_data.
lt_xo_messages type tty_xo_message. append ls_table_data to lt_table_data.
The API adapter doesn’t
lv_object_key = i_planetype. if i_spplane is supplied.
lr_api_adapter = xo_api_adapter=>get_instance( submit changes to a business append i_spplane to lt_spplane.
i_bo_type = 'AIRPLANE' object to the database ls_table_data-table_name = 'SPPLANE'.
i_bo_name = 'PASSENGER_PLANE' get reference of lt_spplane into ls_table_data-table_data.
). immediately. Instead they are append ls_table_data to lt_table_data.
lr_api_adapter->mo_get_line( collected and mass-enabled endif.
exporting
i_object_key = lv_object_key saved when function module lv_object_key = i_saplane-planetype.
i_table_name = 'SAPLANE' BAPI_TRANSACTION_COMMIT lr_api_adapter = xo_api_adapter=>get_instance(
importing i_bo_type = 'AIRPLANE'
e_data = e_saplane or the ABAP statement i_bo_name = 'PASSENGER_PLANE'
e_messages = lt_xo_messages COMMIT WORK is called. So ).
). lr_api_adapter->bo_create(
e_messages = lt_xo_messages. the API adapter also takes care exporting
of the XO transactional events. i_data_new = lt_table_data
endfunction. i_new_object_key = lv_object_key
importing
e_messages = lt_xo_messages
).
e_messages = lt_xo_messages.
endfunction.

Tool Integration
CNS Adapter
SAP Note 1298389 has redesigned the CNS connectivity of the XO framework (for NW
711 SP6 and later). In this document we’ll focus on the current design of the XO/CNS
integration. Note that you cannot use transaction XO_COCKPIT to maintain the
Customizing settings of the previous CNS integration. Instead you’ll find the button
Switch to Current Version.
The legacy CNS integration can still be used but you have to maintain the
configuration directly via Customizing tables (CEXO_CHANNEL_CNS and
CSXO_CNS_TYPE) using transaction SE16, for example.
Before you maintain your XO/ CNS configuration, you have to create the regular CNS configuration for your business object. You find the CNS
configuration in the SAP Customizing Implementation Guide under Cross-Application Components  General Application Functions  Change Pointer
Service. Here you define your CNS application ID, export object types and receivers. Note that XO supports only one CNS application ID per business
object type.
At runtime the XO CNS adapter checks which CNS export object types actually have active receivers. For performance reasons, the adapter tries to
create change pointers only if there are active users.
XO provides two simple handlers to create change pointers:
- EX001 – creates simple change pointers with the object key as CNS export object key and sets the change category to “I” (insert) or “U” (update)
depending on whether the object is new or not
- EX002 – creates change pointers such as EX001 but also fills the CNS info table with the list of changed segments

For our airplane example, we are using CNS Customizing with the application ID “DEMO” and its two export object types. For changes to “cargo planes”
and “passenger planes” we want to create simple change pointers of type GEO, containing only the business object key (plane type) as the export
object key in the change pointer. We can use the predefined XO CNS handler EX001 for this purpose.
For “passenger planes” we want to save

more information, for example we want to
save a snapshot of the business object in a
separate database table and link it to the
change pointer. Therefore, we create a user-
specific handler class
ZZXO_CNS_HANDLER_EXAMPLE that
implements the interface
IF_XO_CNS_HANDLER. This class will be
called for each business object in order to
create the change pointer and save the
snapshot data. Then we define a logical name
for our user-specific handler, here SAMPL.
Finally, we can use this handler for our
second export object type and “passenger
planes” only.
method if_xo_cns_handler~new_change_pointer.
data: lt_bo_data type tty_xo_memory_data.
i_bo->get_data( importing e_data = lt_bo_data ).
" Decide based on actual data whether or not to create a Change Pointer
if [irrelevant change].
return. " don’t write a change pointer
else.
save_bo_snapshot( lt_bo_data ). " save snapshot of current BO state
super->if_xo_cns_handler~new_change_pointer(
i_bo = i_bo
i_appl_id = i_appl_id
i_expobjtype = i_expobjtype
).
endif.
endmethod.
Reference
XO is located in software layer SAP_ABA and available in NetWeaver 7.01 SP 8, 7.02 SP5, 7.10 and newer releases.
The package hierarchy is defined as follows:
XO_FRAMEWORK Main package

XO_MAIN Framework core components
XO_INTEGRATION Integration of XO into other solutions
XO_INCORPORATION Incorporation of other components into XO
XO_COCKPIT Maintenance application for XO

Reference
XO Objects Class Diagram

xo_factory
0..1 0..1 0..1 0..1 0..1
0..* 0..*
0..* 0..* 0..*
xo_business_factory xo_segment_factory xo_memory_factory xo_persistence_factory xo_validation_factory
if_xo_listener_object
xo_key_generator 1 cl_aunit_assert
(from SAP_BASIS)
if_xo_key_generator
1
1 xo_controller 1 xo_services xo_enumerator xo_unit_test
1 xo_object
0..* +assigned_controller 1
xo_customizing 1
xo_business_object xo_segment_object xo_memory_object xo_persistence_object

1..* * 1..* * 1..* 1
if_xo_busine 1..* if_xo_segme 1..* 0..* if_xo_memor 0..* if_xo_persist
ss_object nt_object y_object ence_object
0..* 1
1
0..*
if_xo_validation_object if_xo_so_assigne if_xo_mo_assign
d_bo_behavior ed_bo_behavior
xo_so_assigned_bo_behavior xo_mo_assigned_bo_behavior

Reference
XO Sequence Diagram
Get a business object instance
: xo_factory : :
: Actor
xo_business_factory xo_customizing
get_business_object( )
get_business_factory( )
get_instance( )
IF not yet instanciated

get_bo_data( )
bo_data
:
if_xo_business_object
ENDIF
Alternative
call sequence
get_instance( )

Reference
XO Sequence Diagram
Get existing business object instances
: xo_factory
: Actor
:
xo_business_factory
get_buffered_instances( )
read from buffer

Reference
: : : :
: Actor
XO Sequence Diagram if_xo_business_object if_xo_segment_object if_xo_memory_object xo_customizing
=>SEQ: get Business Object instance

Get business object data
get_data( )
IF table name(s) provided
LOOP AT table names
get_so_mo_data( )
get_segment_object( )
get_data( table_name )
is_bo_connector( ) = FALSE
get_data( )
data
data
ENDLOOP
ELSE
get_data( )
get_used_tables( )
LOOP AT table names
get_data( )
data
data ENDLOOP
ENDIF
data

Reference
XO Sequence Diagram
Set business object data
: : :
: Actor
if_xo_business_object if_xo_segment_object if_xo_memory_object
=>SEQ: get Business Object instance
set_data_new( i_data_catalogue )
LOOP AT i_data_catalogue
LOOP AT segments
get_segment_object( )
is_table_used( )
TRUE
set_data_new( )
LOOP AT tables
get_table_object( )
set_data_new( )
ENDLOOP
ENDLOOP
ENDLOOP

Appendix
XO Interfaces

Appendix
XO Interfaces

Appendix
XO Exceptions
cx_xo_root_dynamic
cx_xo_illegal_operation cx_xo_invalid_parameter cx_xo_object_not_found cx_xo_processing_error cx_xo_dump_with_messages

Appendix
XO Interfaces (Constants)
Interfaces with constants for the XO framework start with the prefix IF_XO_CONST_.
For example, the following interfaces are provided in package XO_MAIN:
- IF_XO_CONST_ACTIVITY
- IF_XO_CONST_BOOLE
- IF_XO_CONST_CHANGE_INDICATORS
- IF_XO_CONST_COMPARE
- IF_XO_CONST_COMPONENTS
- IF_XO_CONST_DATE_PERIODICITY
- IF_XO_CONST_DEFAULT_OBJECTS
- IF_XO_CONST_DIRECTIONS
- IF_XO_CONST_MESSAGE
- IF_XO_CONST_TABLE_TYPES
- IF_XO_CONST_VALIDATION_TARGET
- IF_XO_CONST_WEEKDAYS

XO Cookbook PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

XO Cookbook PDF

Загружено:

Авторское право:

Доступные форматы

Extensible Objects  Cookbook

Table of Contents ................................................................................................................................................................................................... 2

Version History ....................................................................................................................................................................................................... 4

Introduction to Extensible Objects......................................................................................................................................................................... 5

A Simple Example ................................................................................................................................................................................. 6

A Simple Plan ...................................................................................................................................................................................... 10

Your First Extensible Object Application ............................................................................................................................................ 13

Individual Implementations in Your Extensible Object Application ................................................................................................... 23

Summary of XO Objects and Assignments ......................................................................................................................................... 24

Facts and Principles .............................................................................................................................................................................................. 25

Object Instantiation ............................................................................................................................................................................ 26

Read and Write Data .......................................................................................................................................................................... 27

Mass Data Access ............................................................................................................................................................................... 28

Validation in Your Extensible Object Application ............................................................................................................................... 30

Integration of Change Documents in Your Extensible Object Application ......................................................................................... 31

The Listener in Your Extensible Object Application ........................................................................................................................... 32

2 XO – Extensible Objects | Cookbook

BDT Adapter ....................................................................................................................................................................................... 34

CNS Adapter ....................................................................................................................................................................................... 36

XO Objects Class Diagram................................................................................................................................................................... 39

XO Sequence Diagram ........................................................................................................................................................................ 40

XO Sequence Diagram ........................................................................................................................................................................ 41

XO Sequence Diagram ........................................................................................................................................................................ 42

XO Sequence Diagram ........................................................................................................................................................................ 43

3 XO – Extensible Objects | Cookbook

Version No. Date Author Changes

0.7 30.09.2010 Mathias Beck Introduction to extensible objects, graphics added

0.8 08.06.2011 Jörg Mauelshagen Enhancements to XO details

0.9 23.08.2011 Henning Masuch Facts and principles, tool integration

1.0 02.09.2011 Jaqueline Steptoe Language Editing

4 XO – Extensible Objects | Cookbook

Extensible Objects (XO) is a framework designed to support the development and

Expectations have risen to a level where the sophistication of a solution is measured by

The following sections of this cookbook will help you understand …

 the principle idea and framework architecture behind XO

 the building blocks of the framework

 how to develop and individualize an XO-based application

 how to integrate XO-based applications into other environments

5 XO – Extensible Objects | Cookbook

Passenger Plane Cargo Plane

6 XO – Extensible Objects | Cookbook

Whereas each plane represents an holistic view of

Table:SAPLANE Table:SPPLANE Table:SCPLANE

7 XO – Extensible Objects | Cookbook

In this simple example, each “details” object refers

To ensure flexibility and to avoid redundant 1 1 1 1

Table:SAPLANE Table:SPPLANE Table:SCPLANE

8 XO – Extensible Objects | Cookbook

The top layer comprises all objects that have an

The remaining layers are a technical representation

Table:SAPLANE Table:SPPLANE Table:SCPLANE

9 XO – Extensible Objects | Cookbook

10 XO – Extensible Objects | Cookbook

Customizing Customizing contains the component-specific configuration and

Controller The controller manages the transactional behavior in accordance

Business Objects Business objects (BO) are the unique representation of a

11 XO – Extensible Objects | Cookbook

Listener Objects Listener objects (LO) enable outside applications to subscribe to

12 XO – Extensible Objects | Cookbook

Your First Extensible Object Application

 The holistic objects Business

 The subnodes of the planes Segment 1

 Finally, the persistence Persistence