Technical Enhancements within Dealer Business Management (DBM) - the Flowerpot and Actions
Introduction
A quick search on SDN for the word "flowerpot" and "DBM" revealed little information of initial relevance. I have not gone mad and we are not talking botany or database management but are talking about aspects of the dealer business management component of the ECC Automotive industry solution. Like many industry solutions, this is fertile ground for developers with many enhancements often being required. This is an attempt to provide a starting point and a cross technical-functional perspective of how you can enhance the order engine (OE), core component of the DBM 6.0 solution.
The basics
DBM is part of IS-AUTO however in practical terms it is the SAP ERP industry solution for all things related to the retailing of vehicles. All aspects of a vehicle - the manufacturer, model are created as master data in the system and vehicles can be traded accordingly using solution specific aspects of the standard logistics solution (sales order, purchase requisition, purchase order, goods receipt and billing). The two transactions which form the mainstay to functionality can be enhanced using the action concept.
Order actions are delivered as standard business functionality but new actions and modification to existing actions can be achieved - some examples of which an implementation developers might be involved in:
- Additional business functionality such as dirty core processing, credit check or authorisation processing
- Enhanced existing functionality such as additional checks before billing or order save
It should be noted that whilst the order and the vehicle both use a concept of actions, the two are each quite different from one another. This document will just discuss order actions and the information is only relevant to order engine actions.
The order
Within the DBM order an action is defined as a self-contained business transaction. Unlike the VMS action concept, DBM order actions are linked to one or more events. Events form part of a core framework called the order engine which drives processing of the DBM order. This is defined in the customising:
Transaction /DBM/SPRO and select Order / Order Control / Enhancements
The event, akin to a "process controller" to execute one or more business transactions (actions):
The action should represent a self contained business transaction:
- There are several methods of executing an event which is essentially a process step
- o From within an order when you do something implicitly e.g. ITEM_CHANGE
- o Explicitly from within an order by selecting an event from a popup list (dialog)
- o Externally from outside an order e.g. standalone program, interface, CRM etc
- In all cases an access sequence must be fulfilled. The access sequence can consist of one or more criteria tables which can include many different combinations of data. This offers considerable customising flexibility and control over how a process is executed - much more than in the vehicle master
- In addition to an access sequence, the processing and availability of individual actions is status dependent i.e. actions can be made relevant only under certain conditions e.g. goods movement (GDSMVT_CREATE) is only performed if all items are not marked as rejected or an order is released
Unlike in the case of the vehicle master, an iOBJECT is not used to store data. Data is stored in transparent tables that are akin to the traditional SD DDIC design. The tables are within the /DBM/ namespace and include /DBM/VBAK_DB (order header) and /DBM/VBAP (order item).
Order Action Enhancements - BAdIs
SAP produce a very useful cookbook which can help guide enhancements to the order engine. The latest version can be found under note 1105899:
https://service.sap.com/sap/support/notes/1105899
There are a number of enhancement spots available throughout the DBM order transaction - search from transaction SE18 using the prefix /DBM/ORDER* for a full list and the corresponding BAdI's.
From an order action perspective three of the main BAdI's can be found within the action customising:
Level and Definition | Enhancement Spot | Description |
Preperation /DBM/BADI_OE_ACTION_PREPARE | /DBM/ORDER_ENGINE_IMPL | Determination of Actions - use for checks ahead of the action being called |
Execution /DBM/BADI_OE_ACTION_EXECUTE | Action execution - the core business process | |
Post processing (finalize) /DBM/BADI_OE_ACTION_FINALIZE | Post processing of action - executed after the action has been executed sucessfully |
TIP: Do not fall into the mistake of thinking that every implementation needs to be created in the same enhancement implementation. When you create an implementation the system proposes an implementation - it is not mandatory to use that implementation. Structure your implementations logically as you would other developments. Putting everything into one enhancement implementation can result in serious grief when it comes to transporting enhancements!
The 3 levels of implementation form the core of the DBM order engine. The order engine is a central framework around which the DBM order transaction UI has been built. See function module /DBM/OE_MAIN_CONTROL or crucially static method /DBM/CL_ORDER_ENGINE=>RUN(). The event is executed from within this method (see method PROCESS_EVENT) and thereafter the action(s) (method PROCESS_ACTIONS). You can use checkpoint group /DBM/OE_ACTION to debug the order engine ahead of actions being processed.
Although BAdI's can be placed in any action you are advised to steer clear of any actions where the "system action" flag is checked in the configuration. These actions are core to the standard working and processing of the DBM order and although can be enhanced should be treated with further respect.
TIP: standard implementations e.g. see enhancement implementation /DBM/ORDER_ACTIONS_IMP are not shown by default in the order action customising however these can be shown by typing =SAP in the transaction code box when viewing action configuration detail.
The Order Class
Within the order data is held within a central object - super class /DBM/CL_ORD_OBJECT and sub class /DBM/CL_ORDER. Internally amongst DBM developers this class is affectionately known as the ‘flowerpot' due to its size and spherical like aspect of the data it holds. It is important to note that /DBM/CL_ORDER is only one of a number of classes that inherit from /DBM/CL_ORD_OBJECT:
There are many attributes to the /DBM/CL_ORDER class however data is split in three principal areas with following prefixes:
Area | Description |
DETAIL | The DETAIL area is just to build an interface to the main program which is calling the order engine. Changes and creation of new elements (items, jobs, ...) are transferred via this area to the action. |
COM | The COM area contains always the status quo of the order |
DB | The DB area contains always the last saved version of the order i.e. DB version. |
TIP: Note the read-only status of many attributes à adhere to the DETAIL to COM data transfer described later; don't think of modifying COM or DB attributes directly!
Everything to do with the order is stored within this class including:
- o Order header
- o Order Item
- o Jobs
- o Tasks
- o Splits
- o Partners
Order action enhancements - a practical example
A new item level Z event and action called ZSTORAGE_LOC_CHA have been created in the configuration and linked together:
The standard criteria table /DBM/OE_EVAC_DEF is used to define a new custom event and action. Within the action ZSTORAGE_LOC_CHA, click on the execution button to see the BadI that will be executed when the event and action are executed:
Within the respective method you may see the "raw" code or a public/static method call to pass a function module name. The interfaces for preparation, execution and finalize BadI's are each slightly different - I have created class ZCL_ASG_DBM_ORDER_UTILITY which has static methods to cover all 3 scenarios:
TIP: create a generic bespoke class, in this case ZCL_ASG_DBM_ORDER_UTILITY with 3 static methods to handle your new action functionality whether it is preparation, execution or finalize implementations. Copy the standard code from the respective standard class/methods into your static methods e.g. class /DBM/CL_ORD_AX_ACFMOD / method CALL_ACTION_FM for the execution implementation. The advantage of using this approach is:
- One standard interface (cut n paste for all your z actions)
- Reusability - no need to create multiple methods to do the same thing
- "Standard" exception class handling and control
In our example the code in the BAdI is:
The function module ZVSG_001_STORAGE_LOC_CHANGE_01 gets the value of a parameter id that is set elsewhere and if a value exists replaces the existing storage location value. The message log is then updated to show the execution of the action and the change in storage location values.
The code to do this in the function module:
DATA: LV_DUMMY TYPE STRING,
LV_LGORT TYPE LGORT_D,
LV_LGORT_OLD TYPE LGORT_D,
LS_ITEM_DETAIL TYPE /DBM/S_POS.
* ---Ensure a storage location exists
GET PARAMETER ID 'ZDBM_NEW_STORAGE_LOC'
FIELD LV_LGORT.
CHECK LV_LGORT IS NOT INITIAL.
* ---Get the item struc & update the location
LOOP AT IO_ORDER->MT_VBAP_COM
INTO LS_ITEM_DETAIL
WHERE SLCTD = ABAP_TRUE.
LV_LGORT_OLD = LS_ITEM_DETAIL-LGORT.
LS_ITEM_DETAIL-LGORT = LV_LGORT.
APPEND LS_ITEM_DETAIL TO IO_ORDER->MT_ITEM_DETAIL.
ENDLOOP.
*.................. Call Event ITEM_CHANGE ........................... *
IO_ORDER->ITEM_CHANGE( ).
MESSAGE I194(ZASG) WITH IV_ACTION LV_LGORT_OLD LV_LGORT
INTO LV_DUMMY.
IO_ORDER->BAL_ADD_SYMESSAGE( ).
General Notes:
- In the above example we get the selected item record from attribute MT_VBAP_COM (field SLCTD is set for all selected items - something which is dependent upon the action customising)
- Standard method ITEM_CHANGE can be called to update the new storage location details
- This action is a simple example - it does not do anything with statuses or document flow nor is it status dependent
- (A) Golden rule - by all means update data via actions however don't add in COMMIT's, the standard framework will look after this. As a good practice you should not set a bespoke action to commit in the configuration unless it is explicitly required. Note the "automatic-save" feature on events - not enough time to go into detail here however the order can be saved automatically without request
- Recursive calls à it is very easy to get into a situation where an action is called repeatedly by triggering itself again as a result of inappropriate method calls which can result in poor performance at best and un-explainable error messages at worst!
- Method BAL_ADD_SYMESSAGE appends a message to the DBM order action log. Usage of the action log cannot be underestimated - do not use it at your peril!!
Other Sources of Information
Although DBM is very much a niche solution there does exist some sources of other information. In addition to the vehicle and order cookbooks you should consult:
The standard DBM 6.0 solution online help
http://help.sap.com/saphelp_dbm600/helpdata/en/6F/9FC1FA5E8F44B2858B845A3AD1249E/frameset.htm
Standard best practices
http://help.sap.com/bp_dbmv1600/DBM_DE/html/index.htm
The Automotive forum on SDN
Conclusions
We have barely scratched the surface from an enhancement perspective and what can be achieved - whilst the vehicle master offers significant opportunities, the DBM order engine offers a developer even further opportunities and challenges for development. The order engine framework is an ideal mechanism for developing enhancements and you can re-use many of the standard methods within the flowerpot - class /DBM/CL_ORDER.
...a word of caution however - whilst the scope of this should excite you it can also be the cause of its own downfall. It is possible to trigger actions which result in the abrupt termination of the order engine in certain circumstances which can be extremely hard to scrutinize. I have heard examples of the order transaction being "down for days" in extreme cases where a rogue action has done something but nobody can work out where the actual rogue code is. In the order engine you have immense power and control to enhance, however just be respectful of that!
It should also be pointed out that although you can use any of the standard methods and concepts described in this document you should understand that you do so at your own risk. Methods such as ITEM_CHANGE are not released APIs and as with all standard code subsequent changes to them can occur in later versions without notice or warning. From a technical perspective this can mean something working one day and not the next - even with this in mind however many meaningful and significant enhancements can still be achieved.
3 Comments