Академический Документы
Профессиональный Документы
Культура Документы
Management
Object Control
Framework
Customizing and Configuration of DBM Object Control
Framework
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
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
Introduction
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.
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:
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).
FPM
WD ABAP POWL
Object
DBM Object Control
Registrations
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
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.
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.
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.
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
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 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 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 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.
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
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.
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
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 - 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.
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.
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:
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)
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:
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.
Data: lv_dummy.
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.
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:
data: lv_dummy.
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.
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.
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.
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.
For comparison with DBM 700 SP01 customizing please check note 1394077.
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
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.
/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.
Examples
To find out more about programming with the Object Control Framework please check out for examples in the
package /DBM/DEMO.