Show TOC

Integrating Dialog InterfacesLocate this document in the navigation structure

Use

Data exchange in distributed environments is carried out without user interaction.

Sometimes, however, you may need to call dialog interfaces from remote systems. A typical example is to display the source document of a document held in another system.

Example

HR forwards payroll results to Accounting. Here the appropriate documents are posted. Each document in Accounting has a reference to the source document in HR. In the integrated system the document display is programmed in Accounting so that you can jump to the document display of the source document in HR.

If HR and Accounting are running on different systems, there is no purpose in Accounting reading the data via a BAPI and reprogramming the HR document display again. Instead the HR document display is called from the remote system.

Dialog interfaces are not provided in place of BAPIs, they are additional to BAPIs. We recommend that for each dialog interface you provide a relevant BAPI that returns the data as a background interface.

Currently dialog interfaces are primarily for display functionality in SAP to SAP distribution scenarios. Dialog methods with change functionality are currently not supported.

Dialog interfaces can also be called from external platforms.

Procedure

RFC is used to call dialog functionality from remote systems. Images can be transferred with RFC.

A dialog method is implemented through an RFC-enabled function module. The dialog is then called in this function module.

This function module must fulfill the same quality requirements as function modules for BAPIs:

  • English names for fields and parameters

  • A return parameter and no exceptions

  • Documentation must be provided

  • The interface must be frozen

The function module is modeled in the BOR. The same rules apply as for BAPIs, with two exceptions:

  • The function module can only be released internally.

  • The dialog flag must be set for the object method.

A dialog method is created as an API method, the same as a BAPI in the BOR. This ensures that the required coding in the BOR is generated and the dialog method can also be called via the BOR runtime environment. If changes are later made to a dialog method ensure that the BOR coding is also changed appropriately. A dialog method must be able to be called via the BOR runtime environment.

The internal release indicates that this method is used for SAP to SAP scenarios. The API flag indicates that this method can be called from a remote system. The dialog flag is set because a dialog interface is used as opposed to a background interface. The dialog flag delimits the dialog methods from the BAPIs.

Note

  • When you implement an object display, ensure that users cannot switch to change mode.

  • Currently, technical problems may arise if you want to call a pop-up from remote rather than an entire screen.

  • If you are working with reports, the command submit... and return must be used. submit... is not possible.

Naming Dialog Methods

Each object type in the BOR can be accessed through the method Display. However, in many cases the method has not been implemented. If the dialog method to be implemented is to display the object, Display should be used, if possible,

If Display has already been implemented, and changes have resulted that are incompatible with the BAPI quality requirements, a different method must be used.

Apart from the Display method, we recommend you use the suffix WithDialog for dialog methods when you are modeling them in the BOR.

Calling Dialog Methods

Dialog methods are called from an SAP system in the same way as BAPIs are called through RFC.

There are two different types of calls:

  • Calls with References to the Logical System

  • Calls Without References to the Logical System

    The logical system must be determined from the distribution model.

    Example

    The examples do not claim to be appropriate for all possible situations where methods are called. In particular, a standard procedure cannot be recommended for error handling because it depends on the application involved and the circumstances the call is made in. Before you incorporate a dialog method call into your coding, you should carefully consider how errors will be handled.

    If, for example, no destination for dialog calls can be determined for a server system, this may be because the server does not have dialog functionality for technical or security reasons. This situation can also occur in productive systems. You cannot interpret this as an inconsistently configured system.

    You should also keep in mind that the RFC implicitly executes a database commit, that is the LUW is completed. If you are not familiar with using RFC calls, you should first read the online help for the ABAP language element call function with the addition destination.