Program Logic

Within the dialog flow, events defined by the BDT were used, for which the applications can develop a separate program logic in the form of function modules. The names of several function modules can be defined for each event and these modules will then be called up automatically by the BDT.

Figure 1 provides an overview of the flow in the dialog. The events have been illustrated using a darker background.

Menu path: Control <Object Start of the navigation path > Next navigation step Events End of the navigation path

The most important events for the dialog are described in detail below:

  • ISSTA (Initialization)

    The applications initialize their global variables and get the relevant control information from the BDT. Default values may also be assigned to the initial screen here.

    Runtime: Before the initial screen, the event will be processed in the initial screen when the activity is changed. Application area: All applications

    Naming convention: <Application>_<Application object>_EVENT_ISSTA

    (Customer: Function module name also has the prefix Y_ or Z_)

    Examples:

    • BUP_BUPA_EVENT_ISSTA

    • FI_BUPA_EVENT_ISSTA

      Action required:

    • Initialize the function group’s global variables

    • Get control information from the BDT

      • Activity

      • Editing mode (save or transfer mode)

      • Indicator: Display initial screen

      • Selected roles/role groupings

      • Roles to be edited (from the selected roles/role groupings)

      • Etc.

        To do this, call up the BDT function module BUS_PARAMETERS_ISSTA_GET and note the information in your function group’s global variables.

    • Set default values for the fields in the initial screen

      • Read default values using the BDT function module BUS_PARAMETERS_ISSTA_GET (interface table T_FLDVL)

      • If default values have been set for a field, these should be transferred to the relevant screen fields

      • If no default value has been set for a field, the SET/GET parameters should be read whereavailable

  • ISDAT (reading data)

    The applications which own the tables (not the applications using the tables!) read them and note the data in their update memory as both the new and the old status. Some application tables however must be read earlier in the PAI function modules for the initial screen views in order to conduct the necessary field checks. These tables do not have to be read again for ISDAT. Runtime: Between initial screen and first data screen

    Application area: Applications which own the tables

    Naming convention: <Application>_<Application object>_EVENT_ISDAT (Customer: Function module name also has the prefix Y_ or Z_)

    Example:

    • BUP_BUPA_EVENT_ISDAT

    • FI_BUPA_EVENT_ISDAT

      Action required:

    • Determine data from other tables if this is necessary to read own tables. The communication modules can be used to read a table.

    • Read own application tables.

      • Read in global memory if the data for the current instance has already been noted in this LUW (transfer mode).

      • If, in this LUW, the data for the current instance has not yet been transferred, it will be read from the database.

    • Note the data in current memory as the old and new status of current instance.

    • Draw temporary number (when creating with internal number assignment). In event DSAVC this number will be replaced by the final number.

    • Determine screen field values for fields of particular data types if the check is not to be carried out directly on the screen (see Screen Layout , Views).

  • ISDTS (distributing data)

    The applications using the table determine the contents of the table with the help of the function module for reading data. The data is noted as the old and new status in the current memory of the application using the table. Runtime: Between initial screen and first data screen.

    Application area: Applications using the tables.

    Naming convention: <Application>_<Application object>_EVENT_ISDST

    (customer: Function module name has the prefix Y_ or Z_).

    Action required:

    • Determine table data from the application which owns the table using the function module for reading data.

    • Note data in current memory as the old and new status.

  • XCHNG (data changed?)

    If the user attempts to leave data maintenance, a query dialog box must appear if the data has been changed. Within this event, the BDT determines whether data has been changed. This event is only processed in activity Change . In the activity Create the query always appears, whereas in the activity Display no data can be changed and a query is therefore unnecessary. Runtime: When leaving data maintenance (activity Change only). Application area: All applications. Naming convention: <Application>_<Application object>_EVENT_XCHNG

    (Customer: Function module name has the prefix Y_ or Z_). Examples:

    • BUP_BUPA_EVENT_XCHNG

    • FI_BUPA_EVENT_XCHNG

      Action required:

    • Compare old and new status of the current memory.

    • Inform the BDT whether data has been changed.

  • DCHCK (checks before saving)

    - Each application can carry out consistency checks before saving. Possible messages appear in a dialog box. If an error message is triggered at this time, it is not possible to save the data until the error has been removed.

    Call time: When saving the data

    Application area: All applications

    Naming convention: <Application>_<Application object>_EVENT_DCHCK

    (Customer: Function module name also has the prefix Y_ or Z_)

    Action required: Carry out consistency checks and output possible messages via the Message Handler

  • DSAVB (collecting data)

    The applications using the table transfer the new data status from their current memory to the application which owns the table. To do this, they call the table function module to collect the data. Runtime: When saving the data. Application area: Applications using the tables

    Naming convention: <Application>_<Application object>_EVENT_DSAVB

    (Customer: Function module name also has the prefix Y_ or Z_)

    Action required:

    • Transfer new data from the current memory to the application which owns the table. The function module defined for the table is called to collect the data.

  • DTAKE (transferring data to the LM)

    In the BDT, data is saved using several steps. Data from several instances can be saved together. This is used both in transfer mode and for background maintenance. In this first step, the application which owns the table writes the data from its current memory to its global memory. Runtime: When saving the data. Application area: Applications which own the tables. Naming convention: <Application>_<Application object>_EVENT_DTAKE

    (Customer: Function module name has the prefix Y_ or Z_). Example: BUP_BUPA_EVENT_DTAKE

    Action required:

    • Write new data from the current memory to the global memory for new data.

    • Write old data from the current memory to the global memory for old data, if the data for this object instance has been noted for the first time in this LUW. Note: In the event DSAVE, the global memory for each instance is checked to see whether changes have been made and whether the data therefore needs to be written to the database. This means the old status of the global memory must correspond to the old status of the current memory as it was when the data was first noted in the LUW.

  • DSAVC (completing data)

    The global memory is prepared for saving the data to the database. All actions for which errors may occur must be carried out here. However, within the event DSAVE, termination messages may only appear if the data is inconsistent or if there are program errors. Runtime: When saving the data. Application area: Applications which own the tables

    Naming convention: <Application>_<Application object>_EVENT_DSAVC

    (Customer: Function module name also has the prefix Y_ or Z_)

    Example: BUP_BUPA_EVENT_DSAVC

    Action required:

    • Draw object number (only when creating with internal number assignment).

    • Replace temporary number (see event ISDAT) with the number just drawn.

  • DSAVE (saving data to DB)

    The application which owns the tables writes the data from the global memory to the database. In view of the improved runtime, in particular for the direct input, array operations should always be used here. Runtime: When saving the data. Application area: Applications which own the tables

    Naming convention: <Application>_<Application object>_EVENT_DSAVE

    (Customer: Function module name also has the prefix Y_ or Z_)

    Example: BUP_BUPA_EVENT_DSAVE

    Action required:

    • Write new data from the global memory to database. The BDT will state, using a parameter of the function module BUS_PARAMETERS_ISSTA_GET, whether this is to be done with or without an update task.

    • Write change documents using the old and the new status from the global memory.

    • Issue success message (only application which owns application object).

  • DLVE1 (initializing the current memory)

    The current memory is initialized. When returning to the initial screen there is no (!) LEAVE TO TRANSACTION with the result that the current memory must be initialized at this point so that the next data maintenance will start correctly. The application which owns the application object will remove the lock. Runtime: When leaving data maintenance. Application area: All applications. Naming convention: <Application>_<Application object>_EVENT_DLVE1.

    (Customer: Function module name has the prefix Y_ or Z_).

    Example: BUP_BUPA_EVENT_DLVE1

    Action required:

    • Initialize current memory.

    • Remove lock for current instance (only application which owns application object).

  • DLVE2 (initializing the global memory)

    Runtime: When leaving data maintenance. Description: The global memory is initialized. Application area: All applications. Naming convention: <Application>_<Application object>_EVENT_DLVE2.

    (Customer: Function module name has the prefix Y_ or Z_). Example: BUP_BUPA_EVENT_DLVE2

    Action required:

    • Initialize global memory.