How To Implement a Remote RFC Function Call from the Gateway Service

Abstract

Some customers install NetWeaver Gateway Addons – Hub (GW_CORE) and Backend (IW_BEP) – on the same system, which becomes THE Gateway System. From this GW system they perform Service modeling and want to connect to other, non-Gateway ABAP systems via RFC functions.

The service development contains basically two parts: (a) entity modeling, and (b) implementation of access methods (CRUD) to these entities.

The CRUD methods can be implemented either by coding each CRUD operation manually, or by mapping them to the data source, e.g. to the RFC functions.

This blogs describes how to map an RFC function residing in a remote ABAP system to a certain CRUD operation, and which Gateway configuration settings are required to make it running.

All steps described below take place in the Gateway system, the Backend system does not require any changes (assumed, an RFC connection exists).

System Infrastructure

System Name	Gateway Addons Installed	RFC Destination	RFC Function
T18  (“The Gateway”)	GW_CORE and IW_BEP	IL1CLNT001 (trusted)
IL1 (“The Backend”)	None	T18CLNT001 (non-trusted)	ZBV_IL1_RFC_GET_MATNR

SEGW Service Model (CRUD is not yet implemented)

At this stage we look at the Service Model which has already defined the entities, but not yet the access methods (CRUD).

For the demo purposes, we have defined just one Entity Material_RFC with one key property “Matnr” and a property “Description”. We also defined internal ABAP field names and types for these properties.

Implement Read Operation using “Map to Data Source”

Now we start implementing the access methods and begin with the Read operation.

As we want to showcase the Gateway mapping functionality for remote RFC functions, we select from the pull-down menu “Map to Data Source” as shown on the next screenshot.

On the next dialog screen we can choose a remote RFC function by using our RFC destination IL1CLNT001.

Note: for this functionality we are using a trusted connection between the Gateway and the Backend propagating the current user (no technical user). This implies that the user must be available on both systems (though passwords may be different), and on the Backend the user has to possess the S_RFCACL authorization.

Mapping RFC Parameters to Gateway Properties

Service Builder provides us the mapping tool as shown on the next screenshot.

On the left hand side we can see the Gateway properties and on the right hand side the parameters of the RFC function.

The function “Propose Mapping” can map the parameters, based on the name similarity – when internal (ABAP) property names match to the RFC parameter names. In our case the names do not match, therefore we will show how to make the mapping manually.

First, we need to map the input parameters for the RFC. In our case it is the mapping
[GW]Matnr->[RFC]IV_MATNR. For that, you just drag the RFC parameter name IV_MATNR and drop it into the line “Matnr”, column “Data Source Parameter” (first line in the mapping table).

Next, we have to map our output parameters which we get from the RFC function back to the Gateway properties. For that, you map in the same way the field Description by dragging and dropping the RFC parameter name EV_DESCRIPTION into the line “Description”.

Less obvious part here is that we add a new line for the output parameter EV_MATNR and map it to the key property “Matnr”.

Note the mapping arrows between the Gateway properties and RFC parameters.

Once we are done with the mapping, we generate the runtime objects.

Note: the RFC parameter ET_BAPIRET2 has been identified as a “Log” parameter. We can remove it by clicking on the icon “Log” in the RFC parameter window, or keep it. If we define some RFC parameter as a “log”, the Gateway runtime will store its value in the Application Log (slg1).

Configuration of Gateway System Aliases

This configuration is performed by the Gateway Administrator in IMG (spro).

In NW7.40 the IMG path is as follows: SAP NetWeaver->Gateway->OData Channel->Configuration
->Connection Settings->SAP NetWeaver Gateway to SAP System->Manage SAP System Aliases.

Gateway system aliases

Let us describe first the different “types” of the aliases. They are presented on the next screenshot.

Alias LOCAL is used, when all components – Service Catalog (GW_CORE), Service Implementation (IW_BEP) and RFC Function are located locally, i.e. on the same Gateway system (T18).

Alias IL1_001 is used when Service Catalog (GW_CORE) is local (T18), Service Implementation (IW_BEP) is remote (IL1), and RFC Function is on the same system as the Service Implementation (IL1).

Alias IL1_001_LOCALBEP is used when Service Catalog (GW_CORE) is local (T18), Service Implementation (IW_BEP) is also local (T18), but the RFC function is remote (IL1). For that alias , the flag “For Local App” has to be set indicating, that IW_BEP resides locally.

System Alias	GW_CORE location	IW_BEP location	RFC Function location	Local GW	For Local App	RFC Destination
LOCAL	T18	T18	T18	X		NONE
IL1_001	T18	IL1	IL1			IL1CLNT001
IL1_001_LOCALBEP	T18	T18	IL1		X	IL1CLNT001

So for our purposes, we have to use the System Alias IL1_001_LOCALBEP.

Add Service to Service Catalog

For that, we start the /IWFND/MAINT_SERVICE, and extract the list of unpublished services from the System Alias IL1_001_LOCALBEP (using Add Service functionality).

Once the service is added to the catalog it should appear as shown on the next screenshot:

Note: ICF Node ODATA must be green and System Alias must have our system alias name.

Testing service in the Gateway Client

As we have implemented the READ method for the Entity Set Material_RFC_SET, we can test it by providing a property key as depicted on the next screenshot:

The result shows us the remote RFC function has been called successfully, and the parameter mapping has functioned properly.

Troubleshooting

You can recognize if the service is not functioning properly by analyzing the response in the Gateway Client (or Browser), in the Application Log, or in the Gateway Error Log.

Below is the example of using an incorrect system alias LOCAL when calling the RFC function remotely.

Gateway Client

In the Gateway response you will see the error message stating that the function is not found. The reason for that is, that the Gateway tries to call the function locally, which is implied by using the LOCAL system alias.

Application Log

In the Application Log (slg1) you can see the same RFC exception with the text “Function call failed; could not find the function)”.

Gateway Error Log

For analysis in the Gateway trace (/IWFND/TRACES), you can set the error log level to full.

In the Error Context section, you can see the error message along with the system alias (LOCAL) and destination (NONE).

About the author

Vladislav Bezrukov is Development Architect at SAP Consulting focusing on integration technologies, Web and REST Services in ABAP NetWeaver platform (ABAP WS, Gateway). His further professional interests extend to SAP UI5 and HANA technologies, which he is using in his projects in the past couple of years.

Email: vladislav.bezrukov@sap.com