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

4

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

1

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.

2

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_MODULEmodule 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_ MODULEmodule 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_MODULEmodule check_data_field2_module input. perform check_data_field2_form in program sapmv45a. endmodule.

Module PROCESS_DATA_MODULEmodule process_data_module input. perform process_data_form in program sapmv45a. endmodule.

3

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_SINGLEmethod do_pbo_single. perform prepare_data_form in program sapmv45a. endmethod.

Method DO_PBO_SINGLEmethod 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_MODEmethod 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_SINGLEmethod 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.

4

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 > end of modification end of modification > end of insertion (modification) start of deletion (modification) > end of deletion (modification) > end of insertion (modification)