Multiple Back End Support for the Adaptive RFC Model 

Features

Importing an Adaptive RFC Model and the resulting use of Adaptive RFC technology in a Java Web Dynpro application not only enables the reuse of functions that already exist in the SAP back-end system, but also offers another important advantage. It is possible to support more than one back-end system with a single Web Dynpro model, without having to install another Java Engine. Web Dynpro developers can therefore reuse the functions of several different back-end systems in a single application.

Use

The standard application scenario for the implementation of multiple back end support is the development of a Web Dynpro application that is integrated in the SAP Enterprise Portal and has access to the functions of different systems. Via the role maintenance, the Portal administrator controls the access authorization for the relevant back-end system. It is also possible to use a single Adaptive RFC model to implement the data retrieval for the Web Dynpro application across globally distributed systems. In this case, it is not necessary to assign authorizations via the portal roles.

Concept

Access from a Web Dynpro application to another SAP System is controlled by the logical metadata system. At design time, you must assign two logical system names per Adaptive RFC model – the interface between the user interface and the back-end system – even if only one system is called in the Adaptive RFC. A logical system name is required for the Dictionary metadata and the RFC metadata, and a further name for the application data itself. These two names are also always configured after deployment using the Web Dynpro Content Administrator, even if multiple back end support is not used in the current Web Dynpro application. Each of these logical system names represents a set of valid connection configuration data, which contains the information for creating a jRFC/JCO connection to a specific ABAP system.

To use the multiple back end support, it is now possible to change the logical system name, which was originally defined for obtaining the metadata after deployment. This is done via the relevant entries in the Web Dynpro Content Administrator, which allows you to define new logical system names including the configuration. Furthermore, the mapping of the existing logical system name to another logical system name is carried out by the Portal administrator.

Additional Information

The steps required for addressing another back-end system are described under Mapping Logical Systems.