Dealer Business

Management
Object Control
Framework
Customizing and Configuration of DBM Object Control
Framework

Date: November 2009

Release: DBM 7.00, SP01
Version : 1.00
SAP

Icons in Body Text

Icon Meaning
Caution

Example

Note

Recommendation

Syntax

Additional icons are used in SAP Library documentation to help you identify different types of information at a
glance. For more information, see Help on Help General Information Classes and Information Classes for
Business Information Warehouse on the first page of any version of SAP Library.

Typographic Conventions

Type Style Description

Example text Words or characters quoted from the screen. These include field names,
screen titles, pushbuttons labels, menu names, menu paths, and menu
options.
Cross-references to other documentation.
Example text Emphasized words or phrases in body text, graphic titles, and table titles.
EXAMPLE TEXT Technical names of system objects. These include report names, program
names, transaction codes, table names, and key concepts of a programming
language when they are surrounded by body text, for example, SELECT and
INCLUDE.
Example text Output on the screen. This includes file and directory names and their paths,
messages, names of variables and parameters, source text, and names of
installation, upgrade and database tools.
Example text Exact user entry. These are words or characters that you enter in the system
exactly as they appear in the documentation.
<Example text> Variable user entry. Angle brackets indicate that you replace these words and
characters with appropriate entries to make entries in the system.
EXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER.

2009 SAP AG Title: DBM Object Control Framework Page 2 of 28

Version: 1.0
Date: December 2009
SAP

Table of Contents

1 INTRODUCTION ......................................................................................................................4
1.1 PURPOSE OF THE DOCUMENT .................................................................................................. 4
1.2 OVERVIEW ......................................................................................................................... 5
2 CUSTOMIZING OF THE FRAMEWORK COMPONENTS............................................................ 10
2.1 CUSTOMIZING - OVERVIEW .................................................................................................. 10
2.2 GLOBAL EVENT DEFINITION .................................................................................................. 11
2.2.1 Event Customizing ................................................................................................. 11
2.2.1.1 Event ......................................................................................................................... 12
2.2.1.2 Description ................................................................................................................ 12
2.2.1.3 Event Text ................................................................................................................. 12
2.2.1.4 Saving before Event Execution ................................................................................... 12
2.2.1.5 System Activity Flag ................................................................................................... 13
2.2.1.6 Event Exit Flag ........................................................................................................... 13
2.2.2 Subsequent Event Customizing ............................................................................... 13
2.3 OBJECT SPECIFIC CUSTOMIZING .............................................................................................. 14
2.3.1 Define Event .......................................................................................................... 14
2.3.2 Define Action ......................................................................................................... 14
2.3.2.1 Description ................................................................................................................ 14
2.3.2.2 Update ...................................................................................................................... 14
2.3.2.3 Commit Level............................................................................................................. 15
2.3.2.4 System Action Flag..................................................................................................... 16
2.3.2.5 Action Preparation..................................................................................................... 16
2.3.2.6 Action Execution........................................................................................................ 19
2.3.2.7 Action Finalization ..................................................................................................... 21
2.3.3 Action Determination............................................................................................. 22
2.4 CUSTOMIZING VERSIONING TOOLS ......................................................................................... 23
2.4.1 Define Version Tool Usage ..................................................................................... 23
2.4.2 Version Generator.................................................................................................. 23
2.4.3 Version Analyzer .................................................................................................... 23
2.5 CONDITION TABLES?? ............................................................... ERROR! BOOKMARK NOT DEFINED.
2.6 DOS AND DONTS ............................................................................................................. 26
3 EXAMPLES ............................................................................................................................ 28

2009 SAP AG Title: DBM Object Control Framework Page 3 of 28

Version: 1.0
Date: December 2009
 SAP

Introduction

1.1 Purpose of the document

As a Dealer Management System, this component (DBM) supports the industry-specific sales and service
processes of dealers and dealer organizations, as well as vehicle importers, authorized dealers, and OEM
vendors. This includes handling of new and used vehicles sales, vehicle service, and parts management.
The component is distinguished by its multi-brand capability as well as its ability to manage different locations,
customer-specific settings with regard to language and country, such as currency and taxes, mean that it can be
deployed worldwide.
The component supports the integration of processes between the dealer and the Original Equipment
Manufacturer (OEM) within a vehicle order (vertical integration). Furthermore, it also supports horizontal
integration between dealers. For example, members of dealer organizations can obtain an overview of the parts
and vehicles in stock for the entire dealer organization.
As a dealer, you can for example manage an order from its creation, through its completion, and right down to its
billing phase. You can also manage other business objects like a vehicle or business partner through the complete
process. The Object Control Framework enables processes to be modeled flexibly. In this way, you can meet
different requirements that arise from the OEM or due to the size of a company.
This document provides you with a description of the Object Control Framework concept in Dealer Business
Management (DBM) solution. It uses screenshots as a visual aid to enable better understanding of the described
concepts and procedures. These screenshots may not necessarily reflect the customer-specific view.

The target audience of this document is implementation consultants. It describes in detail how the customers
business processes can be mapped in the DBM solution using events and actions.

For reasons of simplicity, we use the term dealer throughout this document. According to context, this
term can refer to the car dealer or dealer organizations, vehicle importers, authorized dealers, or OEM-
dedicated vendors.
We also use the term, DBM Order, to refer to orders of all types, such as, Service Order, Vehicle Order or
Parts Order.

2009 SAP AG Title: DBM Object Control Framework Page 4 of 28

Version: 1.0
Date: December 2009
SAP

1.2 Overview
The Object Control Framework (OCF) provides a harmonized approach for implementing Business Objects. The
OCF incorporates some of the advantageous concepts of the erstwhile Order Engine from DBM 600 and in
addition incorporates several additional features, refinements and technical improvements to ensure optimal
application behavior. Therefore, the OCF is the framework which is leveraged not just by the DBM Order, but by
additional objects like the business partner and vehicle.
The Object Control Framework concept uses the Events and Actions to control the business processes. The
criteria technique can be used to determine actions for an event in a highly flexible manner if the process
requirements warrant this. A simple default determination using 1-to-1 mapping can also be used for simple
object implementations. The Criteria Technique will be described in detail in subsequent sections of this
document.

EVENTS
An Event refers to a business process step or representation of multiple process steps.
An Event is triggered directly by the user, an external interface, or indirectly, for example, when creating a new
order, adding new items to an order, or performing other business steps.
An Event can determine one or more Actions.
If the user triggers an Event, the Object Control Framework is called and it executes the determined order
Actions in the sequence defined in Object Control Framework Customizing.

ACTIONS
An Action refers to a self-contained business transaction. At the end of an Action, the system can, for example,
trigger an update, set the status, include a new document to document flow, etc.
The Actions can be classified into two groups:

- Business Actions that create a dependant document and/or set a status

- Actions that control and change the processed business object itself
Each Action results in an implementation where the business logic is implemented.
The link between Events and Actions is set in the object specific customizing within the Object Control node. For
more information, see section 2.4.
Each business object implemented in the Object Control Framework (short: OCF object) has its own unique
Action determination and execution logic.
In general the determination logic can be a simple mapping of events and actions. In cases of a runtime data
based determination, criteria technique can be used where the determination is based on criteria tables.
Importantly, the execution of Actions should follow the main building blocks (preparation-, execution-,
finalization- step and update control).

2009 SAP AG Title: DBM Object Control Framework Page 5 of 28

Version: 1.0
Date: December 2009
The graphic below depicts the operational flow of the Object Control Framework.
SAP

The diagram below depicts the Object Control Framework as integrated part of the DBM architecture. (Part of
this cookbook in red rectangle)
The Object Control Framework in general is described in the following sections.
Also parts of the individual business logic layer are described as examples where it is useful for a better
understanding of the Object Control Framework.
For more detailed description how to enhance the business logic of individual objects please check the
corresponding cookbooks.
To enhance and customize the DBM UI please check the UI cookbook(s).

2009 SAP AG Title: DBM Object Control Framework Page 8 of 28

Version: 1.0
Date: December 2009
SAP

FPM

WD ABAP POWL

Object
DBM Object Control
Registrations

R IF_OE_OBJECT R IF_OE_ACTION R BAdI

Processing
Persistence Control Action Control Control &
Registration
R
R

DBM
Status and Action Execution
Persistence Recursion

R
Data Buffer

R BAdI

Backend Connectivity

R Badi
R

Backward
ERP Integration
Business
Logic

ERP
Persistence

2009 SAP AG Title: DBM Object Control Framework Page 9 of 28

Version: 1.0
Date: December 2009
SAP

Customizing of the Framework Components

1.3 Customizing - Overview

As mentioned above, Events and Actions trigger the operations flow of the Object Control Framework. To enable
the customer to exploit the full flexibility and power of the Object Control Framework, DBM provides the
possibility to customize the Events, Actions and the sequence in which they are executed.
In DBM700 you have the possibility to define Events on a global level (Logistics Execution Dealer Business
Management (DBM) Framework Components Global Event) and check which DBM business objects are
assigned to it.

For a user interface containing a DBM-Order Object and a Vehicle Object; changes to both business
objects should be saved with one Event.
This requires a global SAVE Event with an Alias Event assignment of the DBM-Order Event
ORD_SAVE and the Vehicle Event VEH_SAVE.

In addition you can combine multiple global Events within an Event Schema. These schemas are used in the new
DBM700 Web Dynpro UI to attach only the required Events to certain screens Logistics Execution Dealer
Business Management (DBM) Framework Components Object Control Framework Event Schema).
For setting an expiry date or switch off the complete Application Log for a DBM business object, you can go to
Logistics Execution Dealer Business Management (DBM) Framework Components->Application Log
Attributes.
For more information about application log deletion and expiry please check note 195157.

In addition, you can find the following configuration tools by choosing Logistics Execution Dealer Business
Management (DBM) Framework Components Customizing Versioning Tools in Customizing:
Define Version Tool Usages
Version Generator
Version Analyzer

For a detailed description of the settings, see the respective sub-section under Customizing.

The description of customizing settings in this document differs in sequence than that you will find in
the IMG.

2009 SAP AG Title: DBM Object Control Framework Page 10 of 28

Version: 1.0
Date: December 2009
SAP

1.4 Global Event Definition

In this IMG activity, the Events are defined as a first step. An Event is a business process step which is triggered
by a user or an external Interface working with DBM business objects. An example of an Event would be: Save of
an object or Creation of a New Order/Vehicle/Business Partner; adding a new Item to an Order, and so on.

To create an event for a certain business object you first have to create the event definition on the
global level.
System events play a particularly important role.

System events must not be changed in any way, as this may have unexpected consequences. For
example, if a System Event is deleted, the associated program might terminate. System Events cannot
be replaced. Enhancements are possible, such as, additional Actions or subsequent events.

To configure settings for Global Events, choose Logistics Execution Dealer Business Management (DBM)
Framework Components Global Event in Customizing.

In customizing for Events, all defined Events are displayed. To view further details, select an Event and then click
Detail or, double-click on an Event.

In the Display View Events: Details screen, you can maintain customizing in the following areas:
In the application screen area where it is possible to maintain information on the event itself, such as,
Event name, Event description and so on
In the structure under Subsequent Event where you can add, modify, or both, subsequent events and
specify their sequence of execution
In Object Registration you can check which DBM business objects react to this event.

Event Customizing
This section describes each element of the Event Details in detail and its influence upon the Object Control
Framework.

2009 SAP AG Title: DBM Object Control Framework Page 11 of 28

Version: 1.0
Date: December 2009
SAP

Event
Event the name of the event must be unique.

Description
Description free text that best describes the event. It should be maintained in all the used languages.

Event Text
Maintain this text for use on the user interface. The text entered here would appear in the User Interface.

Saving before Event Execution

Event Automatic Save Controls whether the Object Control Framework needs to automatically save the
DBM objects before the execution of the current Event.
Possible entries for the field Saving before Event Execution, are:
- Do Not Save : the objects are not saved before the execution of the current event
1 - Save Automatically: the objects are saved first before processing of the current event begins.
As a consequence, the event SAVE is executed for all the objects being processed currently.
2 - Save After Query: a pop-up window appears, prompting the user to decide if the objects
should be saved before executing the actual event. On cancellation of the pop-up the complete
processing will be stopped.

If a dependant business object is created with an event, the flag must be set, otherwise,
inconsistencies may occur. For example, labor value added -> confirm -> leave DBM-order without

2009 SAP AG Title: DBM Object Control Framework Page 12 of 28

Version: 1.0
Date: December 2009
SAP

save A confirmation was carried out for an item thereby resulting in a CO posting, but the item
linked to this posting was not saved.

System Activity Flag

System Activity Flag System Events are certain critical events which are required for ensuring consistent
changes to objects. These Events are only delivered by SAP.
The flag indicates whether or not the event is a System Event. System Events play a particularly important role.

System Events must not be changed, as this may have unexpected consequences. For example, if they
are deleted, the associated program will terminate. Modifying system events incorrectly could also
result in serious errors.
System Events cannot be replaced as these events are hard-coded in the program flow. System Events
can, however, be carefully enhanced by additional Actions.

Event Exit Flag Only relevant for SAP GUI

Event Exit Flag Setting this flag triggers exit event of the processed object after the completion of the
execution of the Event.
Example: If you set this flag for event ORD_SAVE the order maintenance transaction will be exited after
saving.

Subsequent Event Customizing

Each subsequent event is, in fact, an event as described in the previous section see Event Customizing. The
subsequent event is used if in the business process it is necessary to execute more than one event in a single
step. The subsequent events can be defined in the Subsequent Events folder.

2009 SAP AG Title: DBM Object Control Framework Page 13 of 28

Version: 1.0
Date: December 2009
SAP

Subsequent Events are called after the completion of an event to which they are assigned. This is not the
same as in the case of a recursive event call. In case of a Recursive Call, the event A is called from another
event B through an action assigned to the event B. Subsequent Events for Subsequent Events will also
be called.

1.5 Object specific customizing

The Object Control Framework provides also customizing building blocks for the implementing business objects.

In detail these are the following customizing nodes (note that they can vary in naming from object to object)
normally to be found under Object Control of the respective DBM business object:
Define Event
Define Action
Action Determination

Define Event
In this IMG activity you can make refinements of the global event settings. This means for some objects (like the
DBM-Order) there are additional settings on event level only relevant for a certain object (see also Order
enhancement cookbook Note 1105899).
Event Alias: If you have a global event assigned to multiple objects you can assign here the object specific event
alias, which is then getting executed for the object when the global event gets triggered. For example, when the
SAVE event is triggered, the ORD_SAVE is triggered for the Order and VEH_SAVE is triggered for the Vehicle.

Define Action
This chapter describes the minimum settings provided by the Object Control Framework.
Some objects which require more sophisticated customizing can provide additional settings which will be
described in the respective cookbook of the object.

Description
Description free text that best describes the action.

Update
The Update field provides information to the Object Control Framework on whether a commit should be
performed or not.
Possible entries are:
1 - Commit
2 - Commit Work and Wait
- No Commit

2009 SAP AG Title: DBM Object Control Framework Page 14 of 28

Version: 1.0
Date: December 2009
SAP

The flag is useful, for instance, if one of the BADI implementations for the action calls an ERP BAPI, as in
such cases it would be necessary to execute a Commit. The Object Control Framework checks if the flag
Update is set to Commit or Commit Work and Wait, and if no errors occurred during any of the Actions
implementations, then the Object Control Framework carries out a commit as is customized.
If the flag Update is set to No Commit the Object Control Framework does not commit the changes. These
changes would be committed only when a subsequent Action is customized to Commit.
If a subsequent Action requires the current action to have updated the Database, then you must set the
update flag of the current Action to 2 - Commit Work and Wait. . Example: Creation of material
reservation and subsequently post a material document.

Commit is always carried out by the Object Control Framework. Individual Commit statements
inside Action implementations must not be done.

Commit Level
The commit level controls the level on which the Object Control Framework commits. If the flag Update is
set to No Commit, the commit level setting is not taken into account. The commit level ensures consistency
of the object in case actions create further standard documents. All actions belonging to the same
processes step must be in the same LUW and the commit must be done together.

Possible entries are:

After every Action some objects allow the action execution for object nodes where multiple
entries are possible (e.g. DBM-Order actions can be executed for each item separately); in this case
the commit will be done after every single action execution.
1 - End of an Action the commit will be done at the end of the action. If you have multiple
hierarchy levels (object nodes) within an object and the more than one object node is selected for
an action the commit happens at the end of the complete action execution for all nodes.

2 - End of an Event the commit will be done at the end of the event. As indicated above, an
event can be associated with one or more actions. If the event is associated with more than one

2009 SAP AG Title: DBM Object Control Framework Page 15 of 28

Version: 1.0
Date: December 2009
SAP

action then the Object Control Framework will execute all the actions and then do a Commit, if all
the actions were successfully executed.
3 - After all subsequent Events the Commit will be done after the execution of all subsequent
events.

When using the setting After all subsequent Events, make sure that all actions assigned to an event
have the same commit level. The Object Control Framework will otherwise return an error message.
During external calls with NO_COMMIT all actions should have a commit level 3 if relevant for a
commit.

System Action Flag

System Actions are certain critical Actions which are required for ensuring consistent changes to objects.
These Actions are only delivered by SAP.

System Action Flag - indicates if the action is a system action or not. System actions play a particularly
important role. They are required for critical functions like object creation, changing, saving etc.

System actions should not be changed or deleted. However, you can enhance system actions with
additional execution implementations. You can also enhance system actions by adding checks in the
Actions prepare BAdI implementation.

The customizing dialog in the action detail area enables you to create enhancements via BAdI
implementations to SAP delivered functionality without modifying SAP code.

The main steps for BAdI enhancement provided for all objects in DBM for Actions are
Action Preparation
Action Execution
Action Finalization

Action Preparation
In this IMG activity, you can create a BAdI Implementation that is executed before an action is executed.
As described earlier, the Object Control Framework stipulates that Objects perform certain steps for each
action. One of these steps is to execute checks at the beginning of an action. Create your own BAdI
implementation to implement these checks for actions as enhancement of the existing business logic.
The easiest way to create a BAdI implementation is directly in Customizing click Checks.

2009 SAP AG Title: DBM Object Control Framework Page 16 of 28

Version: 1.0
Date: December 2009
SAP

The names of the new BAdI implementation and Class name must be entered, and the system will
automatically create a new BAdI implementation and the corresponding class. The BAdI filter values are
also automatically added with the Action name as a filter value.

BAdI definition /DBM/BADI_OCF_ACTION_PREPARE is part of the enhancement spot

/DBM/OBJECT_ENGINE_DEF_ACTION and is called several times (before the event, action, and from the
user interface).
Filter parameter CHECK_STEP defines at which step(s) an implementation is called. At the beginning of an
Action the CHECK_STEP filter value has value 0.

The creation of the BAdI can be done also via BAdI builder.
Always check the DBM Objects for Syntax Errors after the implementation and activation of a BAdI.
If you create your own BAdI implementations, than you must consider the following:

Only the exception classes /DBM/CX_OE_ACTION_DENIED and /DBM/CX_OE_INTERNAL_ERROR

are available at this time.

Do not run database updates in this BAdI.

2009 SAP AG Title: DBM Object Control Framework Page 17 of 28

Version: 1.0
Date: December 2009
SAP

Example of Prepare BAdI implementation out of the controlling area in the DBM Order

Filter values are automatically added and can be modified manually in the BAdI builder:
CHECK_STEP = 0 AND (ACTION = Action Name 1 OR ACTION = Action Name 2)

The class was automatically created with the name entered:

2009 SAP AG Title: DBM Object Control Framework Page 18 of 28

Version: 1.0
Date: December 2009
SAP

In other words the Object Control Framework gets the BAdI implementations based on the filter values and
for each BAdI implementation executes the method, prepare.

Action Execution
In this IMG activity, you can create a BAdI Implementation that is executed during an action.
The BAdI execution represents the action itself. Depending upon the business process, an action could have
one or more execution BAdI implementations assigned to it. The BAdI Implementation Layer determines the
sequence. Any new customer BAdI implementations are executed after standard action BAdI
implementations.
You can implement your own coding by creating a new BAdI implementation. The easiest way to create a
BAdI implementation is directly in Customizing click Execution.

The creation of the BAdI can also be done via the BAdI builder.
Always check the DBM Objects for Syntax Errors after the implementation and activation of a BAdI.
The BAdI definition /DBM/BADI_OCF_ACTION_EXECUTE is part of the enhancement spot
/DBM/OBJECT_ENGINE_DEF_ACTION and the action name is used as a filter value.
When creating your own BAdI implementations, you must consider the following:

Exception class /DBM/CX_OE_ACTION_ERROR indicates an error during action processing. You

must always add messages directly to the application log of the object:

Data: lv_dummy.
message eNNN into lv_dummy.
io_oe_object->bal_add_symessage( ).
raise exception /dbm/cx_oe_action_error.

It is highly recommended not to raise message directly via message statements, without using the
application log.

Exception class /DBM/CX_OE_INTERNAL_ERROR usually leads to an abort of the processing and

should only be used if an unexpected program situation or data inconsistencies occur.

2009 SAP AG Title: DBM Object Control Framework Page 19 of 28

Version: 1.0
Date: December 2009
SAP

Use the following statements to trigger the exception:

Data: lv_dummy.

message aNNN into lv_dummy.

io_oe_object ->bal_add_symessage( ).
raise exception /dbm/cx_oe_internal_error.

An Action BAdI implementation MUST NOT have a COMMIT WORK or COMMIT WORK AND WAIT
statement inside. The commit is done at the action level based on the Action customizing (see
subchapter 2.3.2.3 Commit Level in Action Customizing).

The events, having actions assigned that carry out a Commit, MUST NOT be called recursively, over
Object Control Framework, inside other action BAdI implementation, unless the ms_oe_control-
no_commit flag is set for io_oe_object->mo_wrapper. Not following this rule might result in
serious data inconsistencies.

Example of DBM Order Execution BAdI implementation

2009 SAP AG Title: DBM Object Control Framework Page 20 of 28

Version: 1.0
Date: December 2009
SAP

Filter values are automatically added and can be modified manually in BAdI builder:
ACTION = Action Name 1 OR ACTION = Action Name 2
The class is automatically created with the name entered.
In other words, the Object Control Framework gets the BAdI implementations based on the filter values and
for each BAdI implementation, executes the method execution.
A successful execution implementation should set the success flag.
For example cv_success = /dbm/cl_order_engine=>C_ACTION_OK.

Action Finalization
In this IMG activity, you can create a BAdI Implementation that is executed after an object action has been
successfully executed.
Again, the Object Control Framework performs certain steps for each action that is successfully executed.
One of these steps is to add additional information at the end of an action (set status, write in document
flow, and so on). If a finalize BAdI implementation was created for the executed action, then the method
FINALIZE of /DBM/IF_OCF_ACTION_FIN is executed.
An action could have one or more finalize BAdI implementations assigned to it. The BAdI Implementation
Layer determines the sequence. Any new customer BAdI implementation will be executed after standard
action BAdI implementation.
The BAdI definition /DBM/BADI_OCF_ACTION_FINALIZE is part of the enhancement spot
/DBM/OBJECT_ENGINE_DEF_ACTION and the action name is used as a filter value.
You can implement your own checks by creating a new BAdI implementation. The easiest way to create the
BAdI implementation is directly in customizing click Finalization Create.

The creation of the BAdI can also be done via the BAdI builder.
Always check the DBM Objects for Syntax Errors after the implementation and activation of a BAdI.
The Object Control Framework gets the BAdI implementations based on the filter values and, for each BAdI
implementation executes the method finalize in case the execution before was successfully.
If you create your own BAdI implementations, you must consider the following:

Only exception class /DBM/CX_OE_INTERNAL_ERROR is available at this time. It usually leads to an

abort of the processing and should only be used if an unexpected program situation or data
inconsistencies occur.
Use the following statements to trigger the exception:

data: lv_dummy.

2009 SAP AG Title: DBM Object Control Framework Page 21 of 28

Version: 1.0
Date: December 2009
SAP

message aNNN into lv_dummy.

io_oe_object->bal_add_symessage( ).
raise exception /dbm/cx_oe_internal_error.

The BAdI is only processed if the action is executed successfully.

The commit work may be performed afterwards.

Event execution in finalize implementations is not possible.

Under which circumstance should a new Action be created and when should a new Action BAdIs
implementation be added?
There is no rule for determining the best approach. Instead, we provide here in this document
examples and simple cases as a guide for mapping a business process.
An Action describes a self-contained business transaction. We therefore recommend that you create
an individual action that covers a single step in the business process.
An Action implementation performs a logical operation on the object data and is not a singular entity
describing a business process unit or a process step.
If an Action implementation can be described as a business process, then there must be a 1:1 relation
between the action and the BAdI implementations.
If several BAdI implementations, working in conjunction, describe the whole business process step,
then create and assign all necessary Action BAdI implementations in the correct sequence to an
Action.
If a system action does not cover the customers business process completely, then a new Action BAdI
implementation can be created for the System Action to enhance the existing process step.

Action Determination
In this Customizing activity, you link events to actions.
SAP delivers different tables for the DBM business objects to do so.
To find out more how to change or enhance the SAP delivered action determination tables for DBM objects
please check the respective cookbooks.

2009 SAP AG Title: DBM Object Control Framework Page 22 of 28

Version: 1.0
Date: December 2009
SAP

1.6 Customizing Versioning Tools

The DBM Versioning Tools is a set of tools designed to help consultants during implementation to take
snapshots of the customizing as a version. This helps to keep track of the customizing changes made
during the project and in addition enables easy comparison with the delivered customizing provided by
SAP. For more information, see SAP note 1398791.

Succinctly put, the DBM Versioning Tools is the Version Management for customizing tables in DBM.
The only difference being that the user needs to explicitly generate a Version as a snapshot of the
current contents of the selected customizing tables.

Define Version Tool Usage

The basis for using the Versionizer is the Usage. A usage could be defined as an application entity that groups
together all the customizing tables relevant for that application. For example, the usage OCF would refer to a
group of all the tables normally referred to as the Object Control Framework Customizing. A Version Generated
for this usage would take a snap shot of all the tables for this usage, and store this in an XML format. This data
can be re-read. For more information on other Usages, see SAP note 1398791.

In Customizing, choose Logistics Execution Dealer Business Management Framework Components

Customizing Versioning Tools Define Version Usages.

Version Generator
An Application Version (snapshot of the current customizing) is generated by executing the report
/DBM/VT_VERSION_GENERATE or via customizing node Logistics Execution Dealer Business
Management Framework Components Customizing Versioning Tools Version Generator.
You can create a version for any defined usage. Mark it as Global to provide it to all users; otherwise
the usage is restricted to your user.
For additional information you can enter e.g. a version number into the version information free text.

Version Analyzer
In Customizing, choose Logistics Execution Dealer Business Management Framework Components
Customizing Versioning Tools Version Analyzer.
The Version Analyzer, henceforth referred to as the Versionizer, provides all the features referred to
earlier, and remains the point from where all the versions are accessed and can be compared.
The Versionizer is mainly used for comparing two different Versions. These Versions are referred to as
the Reference Version and the Comparison Version. All delta information is provided in the direction
of Reference to Comparison versions. That is, an entry in the Reference Version that is missing in the
Comparison Version, is shown as a deleted entry (red) in the reference version display. Vice-Versa, an
entry in the Comparison Version that is missing in the Reference Version, is shown as a new entry (green)
in the comparison version display.

2009 SAP AG Title: DBM Object Control Framework Page 23 of 28

Version: 1.0
Date: December 2009
SAP

For comparison with DBM 700 SP01 customizing please check note 1394077.

2009 SAP AG Title: DBM Object Control Framework Page 24 of 28

Version: 1.0
Date: December 2009
Version Analyzer with an explanation of the features:
1.7 Dos and Donts
One of the first diagrams depicts the different layers (UI layer, Object Control Framework, Business logic layer,
backend connectivity layer, backend).
Please be aware that DBM provides you a lot of enhancement possibilities in the different areas.
Create your enhancements always in the correct layer e.g. do not create business logic enhancements in the
UI layer.

1.7.1 Have to know for programming

To create own enhancements or calling the Object Control Framework within your own program/report you
should now some of the control values you can set via the ms_oe_control attribute:
Field Usage Values
ACTVT Determines in which mode the framework /DBM/CL_ORDER_ENGINE=>C_ACTVT*
handles the objects (example: edit, display)
DIALOG Determines if user dialog is allowed or not. For abap_true or abap_false
example switch off user dialogs in case you call
your program via RFC
NO_COMMIT Suppress Commit Work during processing - very abap_true to suppress commit for
important if the framework is called in recursion processing
but all changes have to be done in one LUW
NO_CLONE suppress cloning of the OCF objects during abap_true or abap_false
event processing
SAP

SOFT_EXIT Enables the soft exit mechanism which allows abap_true or abap_false
you to do an Exit for any OCF object (Event Exit)
but keep the locks for update tasks and the
object itself for updating within the calling
transaction.
This is from importance if your program
explicitly triggers a commit instead of commit
handling within the framework
DISPLAY_IF_LOCKED If ACTVT is set for change mode and object is abap_true or abap_false
locked system automatically switches to display
mode

Recursive Event calls vs. Subsequent Event

Use a recursive call of the object engine, i.e. call /DBM/CL_OE_WRAPPER=>execute_event() when:
- Any parameter in control structures should be set explicitly e.g. call with no_commit
- Transaction Control with External Calls

If you call an event in recursion keep in mind to set and reset the ms_oe_control values mentioned above
according to your requirements.
E.g. You would not like to break up LUW. Therefore you set the NO_COMMIT flag before calling OCF and reset it
after the call.

Event Suspension Mode

To prevent calls to the OCF in cases correct error handling within the transaction is not ensured (remember in
the finalize step no errors should occur) the event suspension mode will prevent such calls and raise an proper
error message.
The event execution will be prohibited in case of:
- Finalization step is triggered. Which means you cannot call the OCF within a finalize BAdI
implementation
- Save method of an OCF object is executed. This method updates the DB.

Exception Handlers and their explanation:

Exception Explanation
/DBM/CX_OE_NOTHING_SELECTED No object node was selected for processing.
There is also derived exception
/DBM/CX_OE_NO_VALID_ACTION which gets triggered
if no valid action was determined for an event during
processing
/DBM/CX_OE_USER_ABORT User aborts the processing e.g. in an dialog step

/DBM/CX_OE_EVENT_DENIED The requested event is not allowed for the object. E.g.
due to missing authorization or status pre-
requirements are not fulfilled.

2009 SAP AG Title: DBM Object Control Framework Page 27 of 28

Version: 1.0
Date: December 2009
SAP

/DBM/CX_OE_ACTION_ERROR Some action could not be executed successfully.

/DBM/CX_OE_OBJECT_LOCKED is derived from action
error and raised you try to process a locked object.
/DBM/CX_OE_INTERNAL_ERROR A fatal error occurred program should be ended. E.g.
SAP-GUI will step out of the transaction

Performing Database updates

In case of data that is hold in an external buffer (other business object). The update should be triggered ideally
from the finalize method. But the finalize method again should not include any business logic as error messages
are not possible.
Only if the standard business object (B)API does not allow a split between business logic and posting, the update
function modules can be called (implicitly) inside the execution part of an action. But afterwards error messages
must not be raised. Also additional action execution implementation must not raise error messages.
Most times you also have the possibility to call the standard business object (B)API first in a simulation/test-run
mode.

Examples

To find out more about programming with the Object Control Framework please check out for examples in the
package /DBM/DEMO.

2009 SAP AG Title: DBM Object Control Framework Page 28 of 28

Version: 1.0
Date: December 2009