Documentation View

We are hiring and constantly growing! Have a look through our vacancies to find the right role for you!



PERFORM Short Reference   ROGBILLS - Synchronize billing plans  
This documentation is copyright by SAP AG.
SAP E-Book


Short Reference

                   $| ${USING bdc_tab $[MODE mode$]$} $]
                   $[EXPORTING p1 FROM a1 p2 FROM a2 ...$]
                   $[IMPORTING p1 TO a1 p2 TO a2 ...$].



2. ... USING bdc_tab $[MODE mode$]

3. ... EXPORTING p1 FROM a1 p2 FROM a2 ...

4. ... IMPORTING p1 TO a1 p2 TO a2 ...


The statement CALL DIALOG calls the dialog module whose name is contained in a flat character-like data object dialog. The data object dialog must contain the name in uppercase letters. The following can be specified for dialog:

  • Literal or constant
If the data object dialog is specified as a text field literal or as a constant, it is evaluated as a statically specified object by tools such as the extended program check or the where-used list.
  • Variable
If the data object dialog is specified as a variable, it is specified only dynamically, and the content is not evaluated statically.

When the statement is executed, dialog is not evaluated until runtime (in both cases). If the dialog module specified in dialog is not found, an uncatchable exception is raised.

When calling the dialog module, the assigned ABAP program is loaded into a new internal session. The session of the calling program is preserved. In contrast to CALL TRANSACTION, the called program runs in the same SAP LUW as the calling program.

After the ABAP program is loaded, the event LOAD-OF-PROGRAM is triggered and the dynpro defined as the initial dynpro of the dialog module is called. The dialog module is terminated when the corresponding dynpro sequence terminates upon reaching the next dynpro with dynpro number 0 or the program is exited using the statement LEAVE PROGRAM.


  • Dialog modules are the only language resource that can be used to open a new internal session without changing the SAP LUW. The following should be noted:

  • The statement COMMIT WORK starts the background or transactional remote function calls registered in the dialog module using CALL FUNCTION ... IN BACKGROUND UNIT and CALL FUNCTION ... IN BACKGROUND TASK (obsolete). If tRFC or qRFC are registered in a dialog module and are not started with COMMIT WORK, they are not executed by the COMMIT WORK of the caller.

  • Changes to persistent objects of the object services cannot be committed while CALL DIALOG is being executed. Changes made in the object services compatibility mode can be committed later using COMMIT WORK. On the other hand, calling the method END of a top-level transaction of the object-oriented transaction mode started in the called program has no effect either during or after CALL DIALOG. In object-oriented transaction mode, a transaction must be started before CALL DIALOG and then completed.

  • In the called program, SAP locks are inherited by the calling program.

  • Calling dialog modules is replaced by calling methods of global classes or by function modules where function modules that can call the classic dynpros of their function pool. It is usually not necessary to open an internal session without changing the SAP-LUW.

Addition 1



Under the same conditions as for the statement CALL TRANSACTION, this addition suppresses the display of the screen layout of the initial dynpro. If the called dialog module has input parameters for the mandatory input fields of the initial dynpro, they can also be filled using parameter passing instead of SPA/GPA parameters.

Addition 2

... USING bdc_tab $[MODE mode$]


This addition controls the called program by specifying a batch input table bdc_tab of the line type BDCDATA like in the statement CALL TRANSACTION. Only MODE can be used here as an addition to control the processing.
If a message is sent in the called program, this message is available in the system fields sy-msgid, sy-msgty, sy-msgno, sy-msgv1, ..., sy-msgv4 after the call.

Addition 3

... EXPORTING p1 FROM a1 p2 FROM a2 ...

Addition 4

... IMPORTING p1 TO a1 p2 TO a2 ...


These additions can be used to assign the appropriate actual parameters a1, a2, ... to the formal parameters p1, p2, ... of the dialog module. The formal parameters of a dialog module are always optional. They can have all data types except for reference types.
When loading the called program, the values of the actual parameters are assigned to the global data objects of the called program that are defined as formal parameters. If this data is linked with identically named dynpro fields, they are not overwritten by any SPA/GPA parameters.
If IMPORTING is specified, the system field sy-subrc is inherited implicitly by the called dialog module and unknown formal parameters are ignored by the system.


Outside of classes, the additions FROM a1, FROM a2, ... and TO a1, TO a2, ... in the parameter lists can be omitted if the formal parameters and actual parameters have the same names.


Non-Catchable Exceptions

  • Cause: A parameter name is too long.
  • Cause: The called dialog module is unknown.
    Runtime Error: CALL_DIALOG_NOT_FOUND
  • Cause: The called dialog module contains errors (error in entry in table TDCT).
  • Cause: No further paging area available for passing parameters.
  • Cause: The statement CALL DIALOG ... SCREEN ... PROGRAM ... is not supported.

rdisp/max_wprun_time - Maximum work process run time   General Data in Customer Master  
This documentation is copyright by SAP AG.

Length: 11683 Date: 20221127 Time: 033757     sap01-206 ( 161 ms )