Enhancement Options for the Lean Order Interface

1 2

Introduction..................................................................................................................................2 Fictitious Example Object.............................................................................................................2 2.1 2.2 2.3 Dynpro ...................................................................................................................................2 Flow Logic..............................................................................................................................2 Event PBO .............................................................................................................................3 Data Preparation............................................................................................................3 Visibility and Ready-for-Input Status...............................................................................4

2.3.1 2.3.2 2.4 3

Event PAI ...............................................................................................................................4

Mapping in the Lean Order Framework ........................................................................................5 3.1 3.2 3.3 Communication Structures......................................................................................................5 Mapping Tables......................................................................................................................6 Events PBO and PAI ..............................................................................................................6

Enhancement Options..................................................................................................................8 4.1 4.2 4.3 4.4 4.5 New Fields in the Communication Structure............................................................................9 New Entries in the Mapping Table ........................................................................................10 Enhancement of the PBO Logic............................................................................................10 Providing Ready-for-Input Status ..........................................................................................12 Enhancement of the PAI Logic..............................................................................................12

5 6

Enhanceable Lean Order Objects...............................................................................................14 Prerequisites, Constraints, and Recommendations.....................................................................19 6.1 6.2 6.3 6.4 6.5 Decoupling ...........................................................................................................................19 Reusing Module Logic ..........................................................................................................20 Using System Fields.............................................................................................................20 Identifying the LORD Mode...................................................................................................20 Function Code Processing....................................................................................................20

Introduction

The Lean Order framework provides access to the sales document processing business logic. The procedure of reading and changing object data largely follows the logic implemented in the processing transactions VA01, VA02, VA21, and so on (VA transactions). Unlike these transactions, however, the business logic available in Lean Order (LORD) is decoupled from SAP GUI for Windows, since the interface itself does not provide any UI elements and theoretically can / should deliver the data for any UI. Reusing the business logic implemented in a VA transaction depends greatly on the extent to which the corresponding routines are decoupled. If this prerequisite is not fulfilled, modifications need to be made to integrate formatting routines and processing routines into the Lean Order framework. Using the LORD interface, the business logic fields to be read and changed can be addressed via object-specific communication structures and tables. The communication structures make up a kind of field catalog that provides a comprehensive yet restricted selection of fields for specific objects in sales document processing. However, not all of the fields that are available and visible in the classic VA transaction are automatically provided by the interface. In a standard system, this applies mostly to customer-specific fields and sometimes to industry-specific fields. It is therefore necessary to be able to access these fields using an enhancement concept. The first section of this documentation contains a fictitious example of how to map a standard object in the Lean Order environment. You then get detailed information about the enhancement options.

Fictitious Example Object

In this simple example, the subobject DATA of the business logic illustrates how the business logic in the standard VA transaction is abstracted using the Lean Order interface. Since decoupling is an essential prerequisite here, the example is presented under ideal conditions, where all the prerequisites for integration into the Lean Order framework are already fulfilled.

2.1

Dynpro

This example is a form embedded in the VA transaction as a detail screen (dynpro 1111). The UI elements on this screen are three input fields and their corresponding description texts. The fields on the dynpro are the component fields of structure GS_DATA (DDIC type TDS_DATA). Dynpro 1111

2.2

Flow Logic

The following illustrates the flow logic for dynpro 1111:

Flow Logic of Dynpro 1111 in Program SAPMV45A (fictitious example)

process before output.

module prepare_data_module. module modify_screen_module. process after input. field gs_data-field1. field gs_data-field2 module check_data_field2_module on request. field gs_data-field3 module check_data_field3_module on request. chain. field: gs_data-field2, gs_data-field3. module check_data_field23_module on chain-request. endchain. chain. field: gs_data-field1, gs_data-field2, gs_data-field3. module process_data_module on chain-request. endchain.

The flow logic of the corresponding dynpro defines how the data is read and changed in the transactional dialog. There are two different events: Process before Output (PBO) Process after Input (PAI)

2.3

Event PBO

Event PBO should contain all the process steps required to format the data so that it can be displayed. This event also defines which fields should be visible or ready for input. It is essential that these two subprocesses are clearly separated so that data preparation and determining the ready-for-input status do not interfere with each other.

2.3.1

Data Preparation

In this example, the data is formatted in the PREPARE_DATA_MODULE. In this module, the data elements that are linked to the UI elements of the dynpro are allocated (default) values. Since dynpro modules cannot be called directly within the LORD framework, only form routines that have no parameters (such as PREPARE_DATA_FORM) should be called in the module. Any number of form routines can be called. If this prerequisite is not fulfilled in the module, these types of form routine should be created and the program logic called in the module should be moved to them. We recommend differentiating between screen fields that can only be displayed and fields that can generally or potentially be changed. In accordance with this criterion, we also recommend storing the fields in different communication structures in the LORD environment. This way, the fields that can only be displayed do not need to be transferred via the LORD interface when a change is made. In this example, the PBO module PREPARE_DATA_MODULE therefore also contains an additional, separate routine for formatting the fields that are read-only. These fields are usually descriptions for related key fields or Customizing information that cannot be changed at runtime.

Module PREPARE_DATA_MODULE
module prepare_data_module output. perform prepare_data_form in program sapmv45a. perform prepare_descr_form in program sapmv45a. endmodule.

2.3.2

Visibility and Ready-for-Input Status

In the above example, the PBO module MODIFY_SCREEN_MODULE is intended to predefine the ready-forinput status of each field, for example. In this module, a loop pass runs for each screen element. The SCREEN system structure should be passed on to a form routine as a change parameter (form MODIFY_SCREEN_FORM, in this case). The business criteria and the process-oriented criteria for defining the ready-for-input status are contained in this form routine. These criteria are used to set the SCREEN-INPUT, SCREEN-ACTIVE, and SCREEN-INVISIBLE attributes, for example. It is important that the screen attributes are updated outside of the form routine using the command 'MODIFY SCREEN'.

Module MODIFY_SCREEN_ MODULE

module modify_screen_module output. loop at screen. perform modify_screen_form in program sapmv45a changing screen. modify screen. endloop. endmodule.

2.4

Event PAI

The PAI event contains not only the field transports from the corresponding FIELD commands, but also all the process steps required to validate and process the data entered. The modules are sometimes called conditionally, which means that the 'ON REQUEST' or 'ON CHAINREQUEST' commands are completed when they are called. As regards decoupling, the same applies as for the modules in PBO the modules themselves should not contain a programmed business logic. Instead, the logic should be moved to corresponding form routines that have no parameters. In this example, this results in the following module implementations:

Module CHECK_DATA_FIELD2_MODULE
module check_data_field2_module input. perform check_data_field2_form in program sapmv45a. endmodule.

Module PROCESS_DATA_MODULE
module process_data_module input. perform process_data_form in program sapmv45a. endmodule.

Mapping in the Lean Order Framework

As mentioned in the introduction, the Lean Order framework is based to a great extent on the formatting steps and processing steps being called similarly to how they are called in the dynpro flow logic in the VA transaction. This includes the mechanisms of the explicit and sequential field transport, as well as the conditional call of validation and processing logics. As a result, the LORD framework also defines events for the individual objects. PBO-specific and PAI-specific routines are called in these events. The following sections contain information about how the existing routines are integrated into the corresponding LORD class methods. As well as the subobject DATA, a fictitious LORD object (object ID = DATA) is used, which is represented by the object-specific class CL_LORD_DATA.

3.1

Communication Structures

The fields visible on the screen are mapped as communication structures and divided into two groups: potentially ready-for-input fields (COMV structure) and fields that are never ready-for-input (COMR structure).

COMV Structure:

DDIC Structure TDS_DATA_COMV Component HANDLE FIELD1 FIELD2 FIELD3 Component type Description GUID_32 FIELD1_TYPE FIELD2_TYPE FIELD3_TYPE Handle Field 1 Field 2 Field 3

COMR Structure:

DDIC Structure TDS_DATA_COMR Component HANDLE FIELD1_T FIELD2_T FIELD3_T Component type Description GUID_32 DESCR_TYPE DESCR_TYPE DESCR_TYPE Handle Description: Field 1 Description: Field 2 Description: Field 3

In parallel to the COMV structure, a COMC structure is created in the DDIC. This structure contains components that are fields with the same name as each of the fields in the COMV structure, but have component type CHAR1.

COMC Structure:

DDIC Structure TDS_DATA_COMC Component HANDLE FIELD1 FIELD2 FIELD3 Component type GUID_32 CHAR1 CHAR1 CHAR1 Description Handle Single-character indicator Single-character indicator Single-character indicator

This structure is used when the data is read (using GET methods) as an additional information carrier so that the appropriate ready-for-input status is provided for each field in the COMV structure. The relevant GET methods provide a COMI structure ('I' as in Input Mode) that is the same type as the COMC structure. When data is changed (using SET methods), the COMC structure acts as a COMX structure (checkbox). Like the BAPIs, the fields in the COMX structure whose values in the corresponding COMV structure fields are to be considered as changed require an 'X'.

3.2

Mapping Tables

A mapping table is used to define the assignment of a field in the communication structure to a field in the business logic. COMV fields and COMR fields have their own distinct mapping tables.

Mapping Tables:

LORD_MAPPING LORD_MAPPING_RO

The mapping table contains the following attributes: OBJECT: FIELD: FIELD_INTERNAL: REPID: DYNNR: Object ID of the object to which the field belongs Name of the field in the LORD interface Name of the field in the business logic Framework program in which the field in the business logic is defined or known Number of the dynpro where the business logic field can be found, presuming it is visible on a UI of the VA transaction. This is used to determine the static screen attributes such as visibility and ready-for-input status.

In this example, the fields of structures TDS_DATA_COMV and TDS_DATA_COMR are assigned as follows to the fields of structure GS_DATA:

Mapping:

Entries in LORD_MAPPING for object DATA OBJECT FIELD DATA DATA DATA FIELD_INTERNAL REPID DYNNR

FIELD1 GS_DATA-FIELD1 SAPMV45A 1111 FIELD2 GS_DATA-FIELD2 SAPMV45A 1111 FIELD3 GS_DATA-FIELD3 SAPMV45A 1111

Entries in LORD_MAPPING_RO for object DATA OBJECT FIELD DATA DATA DATA FIELD_INTERNAL REPID

FIELD1_T GS_DATA-FIELD1_T SAPMV45A FIELD2_T GS_DATA-FIELD2_T SAPMV45A FIELD3_T GS_DATA-FIELD3_T SAPMV45A

3.3

Events PBO and PAI

The PBO and PAI events are mapped using corresponding methods that are called by the framework for the requested objects. At event PBO, the DO_PBO_SINGLE and DO_PBO_SINGLE_RO methods are called, which contain the formatting routines for the changeable and non-changeable fields (separately).

In our example, the form routines called in the methods are the same as those used in the dynpro modules. This ensures that existing program logic is reusable, and reusability should always be a prime objective. Note that this is only possible if there is no dynpro-like programming in the form routines.

Method DO_PBO_SINGLE
method do_pbo_single. perform prepare_data_form in program sapmv45a. endmethod.

Method DO_PBO_SINGLE
method do_pbo_single_ro. perform prepare_descr_form in program sapmv45a. endmethod.

The ready-for-input status of the fields is determined using the GET_INPUT_MODE method, in which the MODIFY_SCREEN_FORM form routine is also called as in the module MODIFY_SCREEN_MODULE. The system gets the screen information from the allocation of the dynpro number in the mapping table LORD_MAPPING. If there is no assignment, make sure that only the IS_SCREEN-NAME attribute is filled. All of the other attributes, especially SCREEN-ACTIVE, are initial or have the value zero. With this particular data constellation, it is necessary to set the attributes explicitly in the form routine MODIFY_SCREEN_FORM.

Method GET_INPUT_MODE
method get_input_mode. data: ls_screen type screen. ls_screen = is_screen. perform modify_screen_form in program sapmv45a changing ls_screen. es_screen = ls_screen. endmethod.

At event PAI, the DO_PAI_SINGLE method is called, which maps the sequential field transports and the (conditional) calls of the check routines and processing routines using internal utility methods (methods SET_FIELD and CALL_MODULE). By using the defined mapping relationship between the interface field FIELD1 of the COMV structure and FIELD1 of the GS_DATA structure, the business logic causes the SET_FIELD( 'FIELD1' ) method to be called similarly to the command FIELD GS_DATA-FIELD1 in the flow logic of the dynpro. When the CALL_MODULE method is called, it does not call a PAI module, but the form routine that is called in a module. The IV_ON_CHECK parameter controls that the routine is only called if fields have changed that were transported using the SET_FIELD method.

Method DO_PAI_SINGLE
method do_pai_single. call_module( iv_module = 'FILL_DATA_FORM'

iv_program do_submit( ). set_field( 'FIELD1' ). do_submit( ).

= 'SAPMV45A' ).

set_field( 'FIELD2' ). call_module( iv_module = 'CHECK_DATA_FIELD2_FORM' iv_program = 'SAPMV45A' iv_on_check = R ). do_submit( ). set_field( 'FIELD3' ). call_module( iv_module = 'CHECK_DATA_FIELD3_FORM' iv_program = 'SAPMV45A' iv_on_check = 'R' ). do_submit( ). set_field( 'FIELD2' ). set_field( 'FIELD3' ). call_module( iv_module = 'CHECK_DATA_FIELD23_FORM' iv_program = 'SAPMV45A' iv_on_check = 'R' ). do_submit( ). set_field( 'FIELD1' ). set_field( 'FIELD2' ). set_field( 'FIELD3' ). call_module( iv_module = 'PROCESS_DATA_FORM' iv_program = 'SAPMV45A' iv_on_check = 'R' ). do_submit( ). endmethod.

Enhancement Options

The Lean Order interface provides the option of integrating customer-specific fields and processing logics. The relevant conditions and constraints are described below. Generally, the enhancements planned in the LORD environment should be based on the enhancements that already exist in the VA transaction. In this context, we can assume that the following enhancements will also be considered in the LORD environment: Enhancements that have been implemented in existing user exits or BAdIs Enhancements that are processed in VA transaction document processing In the following, a modified version of our example is used to illustrate the enhancement options and explain which BAdI implementations are required. The figure below shows the modified dynpro 1111, which now has an additional, customer-specific input field with a description. Modified Dynpro 1111

This additional input field is linked to the customer field ZZMYFIELD of the enhanced structure GS_DATA. The technical name of the description field is GS_DATA-ZZMYFIELD_T.

4.1

New Fields in the Communication Structure

To enable access to additional customer fields in the LORD interface, the corresponding communication structures must be enhanced. To do this, you define an append structure that contains the required fields. This applies to all three types of communication structure (COMV, COMR, and COMC structures).

COMV Structure:

DDIC Structure TDS_DATA_COMV Component Component type HANDLE FIELD1 FIELD2 FIELD3 .APPEND GUID_32 FIELD1_TYPE FIELD2_TYPE FIELD3_TYPE Description Handle Field 1 Field 2 Field 3

ZZAPP_DATA_COMV Append Structure

COMV Append:

Append structure ZZAPP_DATA_COMV Component Component type Description

ZZMYFIELD ZZMYFIELD_TYPE My Data Field

COMR Structure:

DDIC Structure TDS_DATA_COMR Component Component type HANDLE FIELD1_T FIELD2_T FIELD3_T .APPEND GUID_32 DESCR_TYPE DESCR_TYPE DESCR_TYPE Description Handle Description: Field Description: Field Description: Field

ZZAPP_DATA_COMR Append Structure

COMR Append:

Append Structure ZZAPP_DATA_COMR Component Component type Description Description: Field

ZZMYFIELD_T DESCR_TYPE

COMC Structure:

DDIC Structure TDS_DATA_COMC Component Component type HANDLE FIELD1 FIELD2 FIELD3 .APPEND GUID_32 CHAR1 CHAR1 CHAR1 Description Handle One-character indicator One-character indicator One-character indicator

ZZAPP_DATA_COMC Append Structure

COMC Append:

Append-Structure ZZAPP_DATA_COMC Component Component type Description ZZMYFIELD CHAR1 One-character indicator

4.2

New Entries in the Mapping Table

The new fields in the communication structures must be assigned to the corresponding fields in the business logic. These assignments are defined in mapping tables.

Mapping:

Entry in LORD_MAPPING for object DATA OBJECT FIELD DATA FIELD_INTERNAL REPID DYNNR

ZZMYFIELD GS_DATA-ZZMYFIELD SAPMV45A 1111

Entry in LORD_MAPPING_RO for object DATA OBJECT FIELD DATA FIELD_INTERNAL REPID

ZZMYFIELD_T GS_DATA-ZZMYFIELD_T SAPMV45A

4.3

Enhancement of the PBO Logic

If formatting for the newly added field is done in the VA transaction by calling an additional PBO module, you can have the LORD framework use a LORD-specific BAdI to call the form routines that were called in the module.

Modified Flow Logic at Event PBO (Dynpro 1111)

process before output. module prepare_data_module. * >>> start of modification <<<< module zzprepare_mydata_module * >>>> end of modification <<<<< module modify_screen_module. process after input. ...

Generally, it does not matter where the additional formatting routines are called. This can occur in modified form in an existing PBO module, as in the following example.

Modified Module PREPARE_DATA_MODULE

module prepare_data_module output. perform prepare_data_form in program sapmv45a. perform prepare_descr_form in program sapmv45a. * >>> start of modification <<<< perform zzprepare_mydescr_form in program sapmv45a. * >>>> end of modification <<<<< endmodule.

To integrate the additional formatting routines into the LORD framework, it is necessary to create a class for the LORD object DATA, which is to be enhanced (for example, class ZZCL_LORD_INTF_SUPPLY_DATA). This class implements the IF_LORD_INTF_SUPPLY interface. This interface contains the DO_PBO_SINGLE method, for example. The calls of the additional formatting routines can now be placed in the method implementation.

Implementation of IF_LORD_INTF_SUPPLY~DO_PBO_SINGLE (Example)

method if_lord_intf_supply~do_pbo_single. perform zzprepare_mydata_form in program sapmv45a if found. perform zzprepare_mydescr_form in program sapmv45a if found. endmethod.

In the FILL_SUPPLY_LIST method implementation of the IF_BADI_LORD_DO_PBO BAdI interface, the CT_SUPPLY change parameter can be used to make the reference of the IF_LORD_INTF_SUPPLY interface available to the LORD framework (dependent on the object ID). In this case, the LORD framework calls the IF_LORD_INF_SUPPLY~DO_PBO_SINGLE method as well as the additional formatting routines.

Implementation of IF_BADI_LORD_DO_PBO~FILL_SUPPLY_LIST (Example)

method if_badi_lord_do_pbo~fill_supply_list. * With the parameter IV_OBJECT_ID the actual LORD-object is identified case iv_object_id. when 'DATA'. * The object DATA does need additional preparation steps: * Return its implementing instance (created centrally within the * CLASS_CONSTRUCTOR of this class) insert gr_intf_supply_data into table ct_supply. return. endcase. endmethod.

The class constructor of the implementation class of the above BADI might look as follows:

Implementation of Class Constructor (Example)

method class_constructor. ...

... * create supply instances create object gr_intf_supply_data type ref to zzcl_lord_intf_supply_data. ... endmethod.

4.4

Providing Ready-for-Input Status

If the ready-for-input status of the new field has not already been provided by existing user exits or BAdIs of the business logic (such as USEREXIT_FIELD_MODIFICATION in include MV45AFZZ), it can be defined for each field using the BADI_LORD_GET_INPUT_MODE BAdI.

Implementation of IF_BADI_LORD_GET_INPUT_MODE~GET_INPUT_MODE (Example)

method if_badi_lord_get_input_mode~get_input_mode. data: ls_screen type screen. case iv_object_id. when 'DATA'. if iv_field eq ZZMYFIELD. ls_screen = is_screen ... perform zzmodify_myscreen_form in program sapmv45a changing ls_screen. es_screen = ls_screen. endif. endcase. endmethod.

4.5

Enhancement of the PAI Logic

At event PAI, the ZZCHECK_DATA_MYFIELD_MODULE check module is called for the new field and it in turn calls the ZZCHECK_DATA_MYFIELD_FORM form routine. In addition, the PROCESS_DATA_MODULE processing module should be called if the content of the new field has changed.

Modified Flow Logic at Event PAI (Dynpro 1111)

process before output. ... process after input. field gs_data-field1. field gs_data-field2 module check_data_field2_module on request. field gs_data-field3 module check_data_field3_module on request. chain. field: gs_data-field2, gs_data-field3. module check_data_field23_module on chain-request. endchain.

* >>> start of insertion (modification) <<< field gs_data-zzmyfield module zzcheck_data_myfield_module on request. * >>>> end of insertion (modification) <<<< chain. field: gs_data-field1, gs_data-field2, >>> start of deletion (modification) <<<< gs_data-field3. >>>> end of deletion (modification) <<<<< >>> start of insertion (modification) <<< gs_data-field3, gs_data-zzmyfield. >>>> end of insertion (modification) <<<< module process_data_module on chain-request. endchain.

* * * * *

The LORD framework provides BAdIs that enable these additional PAI commands to be considered. The DO_PAI_SINGLE method is shown below. There are additional method calls (indicated by the blue comments), which contain the relevant BAdI calls for enhancing the PAI logic.

Method DO_PAI_SINGLE (including utility methods with BAdI enhancements)

method do_pai_single. set_field( 'FIELD1' ). do_submit( ). set_field( 'FIELD2' ). call_module( iv_module = 'CHECK_DATA_FIELD2_FORM' iv_program = 'SAPMV45A' iv_on_check = R ). do_submit( ). set_field( 'FIELD3' ). call_module( iv_module = 'CHECK_DATA_FIELD3_FORM' iv_program = 'SAPMV45A' iv_on_check = 'R' ). do_submit( ). set_field( 'FIELD2' ). set_field( 'FIELD3' ). call_module( iv_module = 'CHECK_DATA_FIELD23_FORM' iv_program = 'SAPMV45A' iv_on_check = 'R' ). do_submit( ). do_pai_single_add( ). call of BADI_LORD_DO_PAI

set_field( 'FIELD1' ). set_field( 'FIELD2' ). set_field( 'FIELD3' ). set_field_add( PROCESS_DATA_FORM ). call of BADI_LORD_DO_PAI call_module( iv_module = 'PROCESS_DATA_FORM' iv_program = 'SAPMV45A' iv_on_check = 'R' ). do_submit( ).

endmethod.

It is possible implement additional PAI logic here using the BADI_LORD_DO_PAI BAdI. With this BAdI, additional entries can be created for the (internal) GT_SUPPLY table containing the commands for field transports and form routine calls. This means that customer-specific check routines can be called for new fields. The BAdI is called before the main processing routine of the corresponding object is processed.

Implementation of IF_BADI_LORD_DO_PAI ~FILL_SUPPLY_LIST (Example)

method if_badi_lord_do_pai~fill_supply_list. data: ls_supply type tds_field_supply. * * if iv_object_id eq DATA. field gs_data-zzmyfield module zzcheck_data_myfield_module on request. ls_supply-field = 'ZZMYFIELD'. append ls_supply to ct_supply. clear ls_supply. ls_supply-module = ZZCHECK_DATA_MYFIELD_FORM. ls_supply-program = SAPMV45A. ls_supply-on_check = R. append ls_supply to ct_supply. separation for next statement block by initial line append initial line to ct_supply. ... endif. endmethod.

* *

To call the main processing routine (PROCESS_DATA_FORM) because the new field has changed, the BAdI interface provides the ADD_SUPPLY_LIST method for adding more fields to the list of fields of the chainendchain command.

Implementation of IF_BADI_LORD_DO_PAI ~ADD_SUPPLY_LIST (Example)

method if_badi_lord_do_pai~add_supply_list. data: ls_supply type tds_field_supply. if iv_object_id eq DATA. if iv_module eq 'PROCESS_DATA_FORM'. ls_supply-field = 'ZZMYFIELD'. append ls_supply to ct_supply. endif. endif. endmethod.

Enhanceable Lean Order Objects

The enhancement concept of the LORD framework is based on an object-independent, generic approach. Nevertheless, the enhancement by additional fields is only supported for the objects HEAD and ITEM. An essential prerequisite is that any additionally requested field is already part of the business logic, that is, the fields are already integrated and used in the VA transaction.

The following structures in the business logic are available for referencing their components using additional fields in the enhanced communication structure of the LORD interface: Header Area (object HEAD) o o o o VBAK VBKD RV45A TVAK Header data of sales document Business data (header) Data fields for SAPMV45A Customizing order type

Item Area (object ITEM) o o o o o VBAP VBAPD VBKD RV45A TVAP Item data Item data (dynamic part) Business data (item) Data fields for SAPMV45A Customizing item category

In addition to the standard fields in the structures mentioned, customer-specific fields can also be referenced if they are part of these structures. If the LORD interface is to be enhanced by non-changeable fields (COMR structure), it is also possible to refer to fields that do not belong to the standard structures mentioned. In this case, it is probably necessary to use BAdIs to provide additional formatting routines for event PBO. In addition to the objects HEAD and ITEM, the LORD framework also provides the subobjects HDATAA and HDATAB at header level and IDATAA and IDATAB at item level (see SAP Note 1228985 if the objects are not available in your system). These LORD objects do not contain any business logic. They merely provide empty object frameworks within the LORD framework that can be supplied with business logic using the BAdIs mentioned above. This make it possible to map header-dependent or item-dependent objects such as additional data in the LORD framework, for example. These object frameworks are represented by the following classes and object IDs: Class CL_LORD_HDATAA, Class CL_LORD_HDATAB, Class CL_LORD_IDATAA, Class CL_LORD_IDATAB, Object ID = HDATAA Object ID = HDATAB Object ID = IDATAA Object ID = IDATAB

The relevant communication structures only contain the HANDLE component (type GUID_32). TDS_HDATAA_COMV, TDS_HDATAA_COMR, and TDS_HDATAA_COMC TDS_HDATAB_COMV, TDS_HDATAB_COMR, and TDS_HDATAB_COMC TDS_IDATAA_COMV, TDS_IDATAA_COMR, and TDS_IDATAA_COMC TDS_IDATAB_COMV, TDS_IDATAB_COMR, and TDS_IDATAB_COMC

The next example of a fictitious customer-specific dynpro 9111 in SAPMV45A, which is similar to the previous example, gives you a better overview of how customer-specific subobjects can be integrated into the LORD framework. The only difference is that all the fields in this example are customer-specific and that the customer defined the entire flow logic. The following program lines illustrate the flow logic of dynpro 9111:

Flow Logic of Dynpro 9111 in Program SAPMV45A (fictitious customer-specific example)

process before output.

module zzprepare_data_module. module zzmodify_screen_module. process after input. field zzgs_data-field1. field zzgs_data-field2 module zzcheck_data_field2_module on request. field zzgs_data-field3 module zzcheck_data_field3_module on request. chain. field: zzgs_data-field2, zzgs_data-field3. module zzcheck_data_field23_module on chain-request. endchain. chain. field: zzgs_data-field1, zzgs_data-field2, zzgs_data-field3. module zzprocess_data_module on chain-request. endchain.

To enable access to these customer-specific fields via the LORD interface, the LORD object HDATAA is enhanced, for example. This is done by enhancing the relevant communication structures using an append structure that contains the interface fields. It is important that the component names of the fields in the append structure begin with 'ZZ' or 'YY' since the fields must later be entered in the mapping tables, which have a corresponding customer-specific namespace.

COMV Structure:

DDIC Structure TDS_HDATAA_COMV Component Component type HANDLE .APPEND GUID_32 Description Handle

ZZAPP_HDATAA_COMV Append structure

COMV Append:

Append Structure ZZAPP_HDATAA_COMV Component Component type Description ZZFIELD1 ZZFIELD2 ZZFIELD3 FIELD1_TYPE FIELD2_TYPE FIELD3_TYPE My Field 1 My Field 2 My Field 3

COMR Structure:

DDIC Structure TDS_HDATAA_COMR Component Component type HANDLE .APPEND GUID_32 Description Handle

ZZAPP_HDATAA_COMR Append structure

COMR Append:

Append Structure ZZAPP_HDATAA_COMR

Component Component type Description ZZFIELD1_T DESCR_TYPE ZZFIELD2_T DESCR_TYPE ZZFIELD3_T DESCR_TYPE Description: Field Description: Field Description: Field

COMC Structure:

DDIC Structure TDS_HDATAA_COMC Component Component type HANDLE .APPEND GUID_32 Description Handle

ZZAPP_HDATAA_COMC Append Structure

COMC Append:

Append Structure ZZAPP_HDATAA_COMC Component Component type Description ZZFIELD1 ZZFIELD2 ZZFIELD3 CHAR1 CHAR1 CHAR1 One-character indicator One-character indicator One-character indicator

The fields of structures TDS_HDATAA_COMV and TDS_HDATAA_COMR are assigned to the fields of the ZZGS_DATA structure, which are used in this example. The customer namespace of the key fields of the mapping tables must be taken into account here.

Mapping:

New entries in LORD_MAPPING for object HDATAA OBJECT FIELD FIELD_INTERNAL REPID DYNNR

HDATAA ZZFIELD1 ZZGS_DATA-FIELD1 SAPMV45A 9111 HDATAA ZZFIELD2 ZZGS_DATA-FIELD2 SAPMV45A 9111 HDATAA ZZFIELD3 ZZGS_DATA-FIELD3 SAPMV45A 9111

New entries in LORD_MAPPING_RO for object HDATAA OBJECT FIELD FIELD_INTERNAL REPID

HDATAA ZZFIELD1_T ZZGS_DATA-FIELD1_T SAPMV45A HDATAA ZZFIELD2_T ZZGS_DATA-FIELD2_T SAPMV45A HDATAA ZZFIELD3_T ZZGS_DATA-FIELD3_T SAPMV45A

For event PBO, the formatting routines and the definition of the ready-for-input status should be implemented using BAdIs as described above.

For the standard PAI logic, the following LORD-specific implementation for the enhanced HDATAA object would be used: Method DO_PAI_SINGLE (for the enhanced object HDATA, expected)
method do_pai_single. set_field( 'ZZFIELD1' ). do_submit( ).

set_field( 'ZZFIELD2' ). call_module( iv_module = 'ZZCHECK_DATA_FIELD2_FORM' iv_program = 'SAPMV45A' iv_on_check = R ). do_submit( ). set_field( 'ZZFIELD3' ). call_module( iv_module = 'ZZCHECK_DATA_FIELD3_FORM' iv_program = 'SAPMV45A' iv_on_check = 'R' ). do_submit( ). set_field( 'ZZFIELD2' ). set_field( 'ZZFIELD3' ). call_module( iv_module = 'ZZCHECK_DATA_FIELD23_FORM' iv_program = 'SAPMV45A' iv_on_check = 'R' ). do_submit( ). do_pai_single_add( ). call of BADI_LORD_DO_PAI

set_field( 'ZZFIELD1' ). set_field( 'ZZFIELD2' ). set_field( 'ZZFIELD3' ). call_module( iv_module = 'ZZPROCESS_DATA_FORM' iv_program = 'SAPMV45A' iv_on_check = 'R' ). do_submit( ). endmethod.

However, the real implementation of method DO_PAI_SINGLE for the object HDATAA would look like this: Method DO_PAI_SINGLE (for object HDATA, given)
method do_pai_single. do_pai_single_add( ). endmethod. call of BADI_LORD_DO_PAI

Only a utility method is called here, which in turn contains a BAdI call. Since the entire flow logic is defined by the customer, it must be implemented using the BADI_LORD_DO_PAI BAdI by filling the supply table.

Implementation of IF_BADI_LORD_DO_PAI ~FILL_SUPPLY_LIST (example for enhanced object HDATAA)

method if_badi_lord_do_pai~fill_supply_list. data: ls_supply type tds_field_supply. if iv_object_id eq HDATAA. clear ls_supply. ls_supply-field = 'ZZFIELD1'. append ls_supply to ct_supply. * separation for next statement block append initial line to ct_supply.

clear ls_supply. ls_supply-field = 'ZZFIELD2'. append ls_supply to ct_supply. clear ls_supply. ls_supply-module = ZZCHECK_DATA_FIELD2_FORM. ls_supply-program = SAPMV45A. ls_supply-on_check = R. append ls_supply to ct_supply. * separation for next statement block append initial line to ct_supply. clear ls_supply. ls_supply-field = 'ZZFIELD3'. append ls_supply to ct_supply. clear ls_supply. ls_supply-module = ZZCHECK_DATA_FIELD3_FORM. ls_supply-program = SAPMV45A. ls_supply-on_check = R. append ls_supply to ct_supply. * separation for next statement block append initial line to ct_supply. clear ls_supply. ls_supply-field = 'ZZFIELD2'. append ls_supply to ct_supply. clear ls_supply. ls_supply-field = 'ZZFIELD3'. append ls_supply to ct_supply. clear ls_supply. ls_supply-module = ZZCHECK_DATA_FIELD23_FORM. ls_supply-program = SAPMV45A. ls_supply-on_check = R. append ls_supply to ct_supply. * separation for next statement block append initial line to ct_supply. clear ls_supply. ls_supply-field = 'ZZFIELD1'. append ls_supply to ct_supply. clear ls_supply. ls_supply-field = 'ZZFIELD2'. append ls_supply to ct_supply. clear ls_supply. ls_supply-field = 'ZZFIELD3'. append ls_supply to ct_supply. clear ls_supply. ls_supply-module = ZZPROCESS_DATA_FORM. ls_supply-program = SAPMV45A. ls_supply-on_check = R. append ls_supply to ct_supply. endif. endmethod.

6
6.1

Prerequisites, Constraints, and Recommendations

Decoupling

The prerequisite for integrating processing logic that is processed in the VA transaction into the LORD framework is that the business logic is decoupled from SAP GUI for Windows.

None of the commands used to map dialogs in SAP GUI for Windows (such as CALL SCREEN) are supported by the LORD interface and can lead to problems or errors. If the Lean Order interface is called or used, the corresponding business logic is executed in a dialogfree session, similar to a BAPI. It is not possible to call screens or popups. Yes/No decisions or selection dialogs should not be used or should be avoided by using default decisions.

6.2

Reusing Module Logic

In the LORD framework, it is not possible to call modules of dynpro flow logics directly. In the example above, the prerequisite was that the logic was mapped in the module solely by form routines without parameters. These form routines can be called by the LORD framework, and we recommend that you configure your customerspecific modules in the same way.

6.3

Using System Fields

In many routines (standard and customer-specific), system fields such as SY-TCODE, SY-CPROG, SY-REPID or SY-DYNNR are used to control or restrict the program logic. When using the Lean Order interface, the processing logic is called in a different environment than in the VA transactions. This is reflected especially in system fields that may contain changed or initial values that are not expected or cannot be evaluated. For example, the SY-TCODE field does not contain values such as 'VA01' or 'VA22' in LORD mode, even if the user is creating a sales order or changing a quotation. We also advise against querying the SY-DYNNR field since there is no reference to a UI in the LORD mode and therefore no dynpro numbers are known. For the transaction code, we recommend replacing queries on SY-TCODE by queries on T180-TCODE in routines that are processed during sales document processing (program SAPMV45A and others).

6.4

Identifying the LORD Mode

To find out if the program logic is run via the LORD interface or via the VA transaction, there are specific parameters that can be queried. This makes it possible to provide alternative process logics based on these parameters, or to bypass certain process steps if they cannot be supported in the LORD mode. If sales document processing is processed via the Lean Order interface, the following parameters are set: CALL_FUNCTION This parameter has the value 'X' in the LORD mode. The value is also set in BAPI mode. However, the BAPI indicator CALL_BAPI is not set in LORD mode. The CALL_FUNCTION parameter is declared in the MV45ACOM include and thus available in all programs that access this declaration. CALL_ACTIVITY This parameter has the value 'LORD' in the LORD mode. This parameter is declared in the MV45ACOM include and thus available in all programs that access this declaration. It is generally possible to call the DIALOG_GET_STATUS function module to find out if the business logic is processed without any dialogs, which is the case in LORD mode.

6.5

Function Code Processing

Function code processing (FCODE) is not supported in the same way as it is in the VA transaction. The LORD interface is designed to read and change data. Some activities can also be carried out for the object data (such as deletion, pricing, ATP check). In these cases, however, program logic is processed that only contains commands for the activity to be executed. Program logic for formatting, checking, and processing data should be independent and separate from any activities or function codes. In this context, note that next screen processing is not used in the LORD environment.