Page tree
Skip to end of metadata
Go to start of metadata

Introduction

The parameters basically act as an abstraction layer, which allows mapping attributes of various objects that occur in different applications to a common parameter.
This of course only makes sense if the attributes match from their meaning.
The mapping of attributes to parameters will take place on DDIC structure component or data element level and is defined via customizing.

A typical example for a Parameter Mapping use case is:
An application 'A' contains a field called 'MATERIAL' and wants to pass this field during a navigation to application 'B' which knows a field called 'MATNR' and both fields are mapped to the same parameter, the Parameter Mapping will automatically do the job of translating 'MATERIAL' to 'MATNR'.
The mapping will also be processed during the Wiring if the Connector parameter 'Mapping Class' is set to '/PLMU/CL_FRW_W_MAP_PARAMETERS'.

Parameter Definition

Really essential is, that all applications use the same parameters and avoid the definition of duplicate parameters strictly!
So create parameters only if it is really necessary and after you thoroughly checked all existing parameters.
When creating a new parameter use short names e.g. the database field names (This is helpful for example during navigation where the parameters are passed via the URL).

The definition of a parameter is done via view /PLMB/V_FRW_PRM.

Map DDIC Objects to Parameter

This mapping is either based on:

  • Structure and field name (view /PLMB/V_MAPFLD)
  • Data element (view /PLMB/V_MAPDTL)

The data element based Parameter Mapping will be considered after the structure based mapping took place.

The static mapping of structure fields to parameters will be processed for all table entries of /PLMB/FRW_MAPDTL & /PLMB/FRW_MAPFLD for which the field type is left empty, which is the default.

Best Practice

  • Use the structure mapping whenever possible. Only for very dynamic UIs the data element based Parameter Mapping shall be used.
  • To simplify the mapping it is advisable to use small include structures that contain e.g. the key fields that need to be mapped to parameters.
    Those includes can then be reused in other structures since the Parameter Mapping will also consider include structures during the mapping process.
  • Always group fields that belong together.

Mapping via Structure and Field Name

Via view /PLMB/V_MAPFLD one needs to specify a structure name (STRUCTURE) plus a component name (FIELD) and the parameter (PARAM) to which the value of that field should be mapped to:

STRUCTURE

FIELD

GROUP_ID

PARAM

OTYPE

OTYPE_REF

FIELD_TYPE

MY_DDDIC_STRUCTURE

MY_STRUCTURE_FIELD

 

MY_PARAMETER

 

 

 

Grouping of Fields

In many cases there are several parameters within one structure which somehow belong together – e.g. compound keys.
If now within one structure those parameters occur more than once, it is needed to define parameter-groups.
E.g. in a structure the document key occurs twice. To avoid that the different key elements get mixed up, one needs to group the fields of the two keys:

GROUP ID

01

01

01

01

 

02

02

02

02

FIELD

DOKAR

DOKNR

DOKTL

DOKVR

MATNR

DOKAR_ORI

DOKNR_ORI

DOKTL_ORI

DOKVOR_ORI

So if e.g. the field DOKNR is selected when opening a context menu, the Parameter Mapping will now – due to the grouping – pick all fields of group '01' to fill the document key parameters.

Definition of the Object Type

An object type (OTYPE) can be (optionally) assigned to a field, which allows using object type related services such as context menus.
The object type can also be assigned dynamically by referencing the field that holds the object type information at runtime (OTYPE_REF).

Example for a static object type definition:

STRUCTURE

FIELD

GROUP_ID

PARAM

OTYPE

OTYPE_REF

FIELD_TYPE

MY_DDDIC_STRUCT_W_STAT_OTYPE

MY_STRUCTURE_FIELD

 

MY_PARAMETER

MY_OTYPE

 

 

Example entry for a dynamic object type definition:

STRUCTURE

FIELD

GROUP_ID

PARAM

OTYPE

OTYPE_REF

FIELD_TYPE

MY_DDDIC_STRUCT_W_DYN_OTYPE

MY_STRUCTURE_FIELD

 

MY_PARAMETER

 

MY_OTYPE_STRUCTURE_FIELD

 

Setting the Field Type

Furthermore the FIELD_TYPE gives the information regarding the meaning of a certain field. The possible values are:

  • <blank> (Standard Parameter)
  • SAP_INTKEY (Internal key e.g. GUIDs)

Mapping via Data Element

The Parameter Mapping via data element only makes sense in dynamic UIs, where no fixed DDIC structures can be used.
To avoid side-effects in other applications it is advisable to define own data elements in this case.

The data element based mapping is customized via view /PLMB/V_MAPDTL:

DTEL

GROUP_ID

PARAM

OTYPE

OTYPE_REF

FIELD_TYPE

MY_DATA_ELEMENT

 

MY_PARAMETER

 

 

 

The logic for the data element based mapping is analogue to the one that is based on a structure name and field name, so have a look at this chapter for more details.

Importance of Grouping

Fields that belong together (e.g. fields of a compound key) ALWAYS need to be grouped when using the mapping via data element, since those data elements might also be used in a structure where other components map into the same parameter.

  • No labels