Configuring SAP Gateway

One important aspect of the architecture of the World Wide Web is the use of abstract interfaces for component communication. These abstract interfaces are presented as connectors. A client and a server each use a connector component. There is a contract between both connectors that defines the application protocol. It defines the documents, their format, and the behavior. Any protocol can be chosen. By using the connector concept, both client and server are largely independent and exchangeable. Each connector translates the documents exchanged on the communication channel to the internal representations both on the server and on the client side, and vice versa.

The OData protocol defines such a contract by specifying a uniform protocol that has the necessary qualities. For instance, a connector attached to an SAP back-end system translates between ABAP APIs and OData entities. SAP Gateway is such a connector.

On the other side, a client connector translates between OData entities and the APIs of the consumer platform. The connector is specified here. As a consequence, any client platform with libraries supporting the contracted OData format can communicate with any server supporting the same contract.

OData follows the Representational State Transfer (REST) architecture design paradigm in the sense that the protocol transfers representations of the state of resources. The term resource denotes data that is addressable and accessible. The standard address representation or resource is the Uniform Resource Identifier (URI). A client requests a resource from a server by sending a request to a URI. The server processes the request by translating the URI to internal address data to access or manipulate the data, and then assemble the response.

OData is an open standard originally developed by Microsoft but now managed by the Oasis Organization. It is based on the Atom Publishing and Atom Syndication standards, which, in turn, are based on XML (Extensible Markup Language) and HTTP(S) (HyperText Transfer Protocol (Secure)). JSON (JavaScript Object Notation) is an alternative to XML to structure data.

The objective of the OData protocol is to provide a vendor-neutral, web-based API that fully complies with the design principles of Representational State Transfer (REST). OData provides database-like access to server-side resources. In this context, OData is also called ODBC for the Web.

OData is also extensible. This enables SAP to supplement the data types used by OData with extra information from the ABAP Data Dictionary. Another example is metadata-driven development for Web and mobile like SAP Fiori elements.

OData is available in version 2 (V2), version 3 (V3), and version 4 (V4). The versions are built on each other extending the previous version by adding new features. Most OData services are based on V2. SAP Gateway supports OData V2 since AS ABAP 7.00 and OData V4 since AS ABAP 7.50. OData V3 was skipped in SAP Gateway and is therefore not supported.

SAP offers various OData providers. SAP Gateway (up to the end of 2014 known as SAP NetWeaver Gateway) provides a single entry point to access business data of ABAP-based systems such as the SAP Business Suite or SAP S/4HANA. The SAP HANA Extended Applications Services (XS) has the same role in SAP HANA – just to name another important OData provider.

By using OData, business data can be shared among multiple environments and platforms. SAP knowledge is not required for the consumption of the data. Usually client-based applications consume SAP Gateway services and interact directly with the user. Applications in a Web browser are a common example.

However, it is also possible for an SAP Gateway service to be used as an API (Application Programming Interface) by a server-based application. Additional servers can be added to the communication path to enhance the possibilities for client and server. For mobile devices, the SAP Mobile Services add additional value to the applications.

For AS ABAP 7.00 to 7.31, SAP Gateway consists of individual add-ons that provide the OData functionality. These can be divided into the following areas:

Runtime

Provides the OData and thus the SAP Gateway service externally via the URI.

Design Time

Contains the development environment and programs for processing the requests to the service.

First introduced in AS ABAP 7.40 and finalized in AS ABAP 7.51, all add-ons are merged in the software component SAP_GWFND (SAP Gateway Foundation). This offers everything needed for the OData runtime and design time.

There are three possible deployment options for SAP Gateway (hub is a synonym for front-end server (FES)):

Hub deployment with development in back-end server (BES)

A hub deployment offers the possibility of routing and composition of multiple back-end systems. It is the single point of access to back-end systems when using OData. This increases security and flexibility in operation.

This is the recommended setup for SAP Business Suite.

Hub deployment with development in front-end server (FES)

When developing in the FES, data is only read via RFC-enabled function modules from the BES, which enables access to data of a BES not able to provide an OData service on its own. This grants more freedom in selecting a system as data source.

This is the recommended setup for integrating multiple BES with different releases.

Embedded deployment

When developing in the BES, the application source code has direct access to the definition of the data and other repository objects. This increases performance and efficiency in development.

This is the recommended setup for SAP S/4HANA.

There are four steps needed as basic configuration in SAP Gateway to enable the communication via OData:

1. Create RFC destination to BES in FES (not needed for embedded deployment)
2. Activate SAP Gateway in FES (in BES for embedded deployment)
3. Create system alias in FES (optional for embedded deployment)
4. Activate ICF nodes under /sap/opu in FES (in BES for embedded deployment)

Depending on the deployment option of SAP Gateway, the system alias needs certain settings:

• In a hub deployment with development in BES, neither the flag Local GW nor Local App must be set.

• In a hub deployment with development in FES, only the flag Local App must be set.

• In an embedded deployment, only the flag Local GW must be set.

The last combination with both flags set is only used in an embedded deployment for services developed originally for the hub deployment with development in FES.

Since AS ABAP 7.50 SP04 it is possible to route the whole processing of the OData request to the BES. The feature was called Micro Hub in AS ABAP 7.50 but was renamed to OData on Backend in AS ABAP 7.51. This may increase the performance of the service calls depending on the scenario concerning workload in FES and BES or of the network. The following steps are needed to enable OData on Backend for an SAP Gateway service:

1. Define a system alias in FES with flag OData on Backend enabled.
2. Register a service in FES using this system alias in processing mode Routing-based.
3. Register the same service in BES using no system alias in processing mode Co-deployed only.

In addition to the feature OData on Backend in a hub deployment, it is recommended today to register SAP Gateway services in an embedded deployment in processing mode Co-deployed only. This increases the general performance of OData requests by skipping any communication part in an AS ABAP normally involved when connecting FES to BES.

Beside the system alias connecting FES to BES, the SAP Gateway alias enables connection from BES to FES. This is not needed for calling an SAP Gateway service but gets useful when developing one. There are two steps needed to enable developers to register, manage, and test their OData services via the SAP Gateway Service Builder (transaction SEGW):

1. Create RFC destination to FES in BES (not needed for embedded deployment)
2. Create SAP Gateway alias in BES

In the Task Manager for Technical Configuration (transaction STC01), several task lists are in place to make initialization and handling of SAP Gateway easier:

SAP_GATEWAY_BASIC_CONFIG (since AS ABAP 7.40)

Performs basic configuration like activating SAP Gateway, central ICF-nodes, and metadata cache.

SAP_SAP2GATEWAY_TRUSTED_CONFIG (since AS ABAP 7.40)

Creates and configures a trusted RFC connection between BES and FES including single sign-on.

SAP_GATEWAY_ACTIVATE_ODATA_SERV (since AS ABAP 7.40)

Registers a list of SAP Gateway services routing-based or co-deployed.

/IWFND/TL_SERVICE_MAINTENANCE (since AS ABAP 7.54)

Enable mass maintenance of SAP Gateway services like handling system alias assignment, setting processing mode, service deletion or transport.

The SAP Gateway Service Maintenance (transaction /IWFND/MAINT_SERVICE) provides a list of all the OData V2 services registered in the system. Complete management of the SAP Gateway services is carried out here. The transaction is divided into three areas:

• Service Catalog (service name, description, and many other settings)
• ICF Nodes (maintenance of the ICF services and testing of the service)
  Hint

  Since SAP_GWFND 7.58, an ICF node is optional for calling an SAP Gateway service. The OData V2 services are then directly linked to the node /sap/opu/odata.
• System Aliases (maintenance of the connection to the back-end)
  Hint

  For services not connecting to other systems, the Processing Mode is set to Co-deployed only and no system alias is assigned.

OData V4 services are not registered as single instances. Instead, a service group consisting of multiple services is published. These service groups are created using the SAP Backend Service Administration (transaction /IWBEP/V4_ADMIN) and shipped by SAP or created by developers.

The SAP Gateway Service Administration (transaction /IWFND/V4_ADMIN) is used to publish service groups so that the services inside can be consumed in applications.

Using the SAP Gateway Client (transaction /IWFND/GW_CLIENT), all functions of an OData service can be tested. For a read request, it is enough to enter the request URI and execute. For a create, update, and delete request, more adjustments must be made, for example, a request body filled with data must be created. All adjustments can be saved as test cases for later usage.

The SAP Gateway Client can handle data formats like XML (Atom) and JSON for both OData V2 and V4 services.

Apart from these transactions, there are several more for SAP Gateway. All transactions are connected to each other via buttons and menu entries. Therefore, you can jump from the service maintenance to the client and back.

SAP Gateway is available in two branches (runtime and designtime) in the SAP Reference Implementation Guide (transaction SPRO) but also offers many transactions. Beside the SAP Gateway Service Builder (transaction SEGW) for developers, the transactions can be categorized in administration, management and monitoring. If a transaction starts with IWFND, it is connected to OData runtime (for hub deployment in FES). If it starts with IWBEP, it is connected with designtime (for hub deployment in BES)

/IWFND/IWF_ACTIVATE

(De-)Activate SAP Gateway for the whole system.

/IWFND/ROUTING

Define system aliases for accessing ABAP systems via RFC.

/IWFND/SOFTSTATE

(De-)Activate soft-state mode for all SAP Gateway services in the system.

Caution

Please check SAP Note 1986626 – Request could not be processed in soft state mode before activating.

/IWBEP/GLOBAL_CONFIG

Settings for logs, traces, and caching.

/IWFND(IWBEP)/CACHE_CLEANUP

Cleanup model cache in run- and designtime.

/IWFND/NOTIF_CLEANUP

Cleanup notifications in run- and designtime.

/IWFND/MED_ACTIVATE

(De-)Activate metadata cache for the whole system.

/IWFND/APPS_LOG

View general messages of services.

/IWFND(IWBEP)/ERROR_LOG

View error messages of services for run- and designtime.

/IWFND(IWBEP)/NOTIF_MONITOR

View notification queue status for run- and designtime.

/IWFND(IWBEP)/TRACES

Run and view performance and payload traces for run- and designtime.

/IWFND/STATS

View request statistics of services.

SAP Gateway offers some cleanup jobs to ensure that the software runs with optimal performance. The frequency specified depends on the load in your system to avoid a waste of disk and memory space. The SAP Reference Implementation Guide (transaction SPRO) offers sections for cleanup tasks for FES and BES. The following jobs can be scheduled directly in SPRO running daily at 3 am:

SAP_IWFND_SUP_UTIL_CLN

This job deletes logs of support utilities, such as error logs, traces, and performance logs.

SAP_IWFND_APPS_LOG_CLN

This job deletes SAP Gateway entries from the application log.

SAP_IWFND_NOTIF_CLN

This job deletes the SAP Gateway notifications.

SAP_IWBEP_SUP_UTIL_CLN

This job deletes logs of support utilities, such as error logs, traces and performance logs.

SAP_IWBEP_QRL_CLN

This job deletes the entries of the query result log.

In addition to these automatically scheduled jobs, the report /IWFND/R_SM_CLEANUP offers several cleanup scenarios. In SPRO, it can be run directly or scheduled as job using report variants for several scenarios like clean up the Application Log Viewer (scenario /IWFND/CLEANUP_APPSLOG) or Error Log (scenario /IWFND/SUPPORT_UTILITIES).

By default, OData communication is stateless. There are however certain business scenarios that do require the caching of data to improve the performance.

Since SAP Gateway 2.0 SP09 (SAP_GWFND 7.40 SP08), soft state enables the SAP Gateway runtime to process several requests in one ABAP application server session in a similar way to stateful behavior. The only difference is the behavior of the application server after the session times out: Instead of breaking the request processing with a time-out exception, the server creates a new session and processes the request as usual. The only thing that the consumer will observe is that the response time will be higher because data that was previously cached must be read or calculated again.

The session that is held by the Internet Communication Framework (ICF) results in a session held in the back-end system via RFC. There, the data (variables) processed in the SAP Gateway design time is cached in the data provider cache.

In addition, the Soft State Based Query Result Cache (SQRC) resides in the FES. If the client only wants to navigate through a result set, it can serve as a cache, avoiding unnecessary calls to the BES.

Using SAP Gateway Service Maintenance (transaction /IWFND/MAINT_SERVICE), the soft state is activated for single services supporting soft state. As a prerequisite, the session time out for the ICF node must be set to a value larger than 0. This can also be done from within SAP Gateway Service Maintenance using the ICF Node button.

The first service request using SQRC is significantly higher compared to a similar request without. The whole data is read at once from the database and cached. All following requests before the timeout read the next portion of data from the cache. This reduces the application time to 0, which also means that there is no RFC communication with the BES.

SQRC should only be used if all of the following conditions apply:

• The data retrieval is very expensive (slow).
• Caching of large data sets must be avoided.
• Cached data is not often changed.
• Memory is sufficiently available.

SAP system resources are occupied as long as the session is active. The more services that run in soft state mode in parallel, the more resources are permanently occupied. Therefore, the timeout should be very short. For more details, please read SAP Note 1986626 – Request could not be processed in soft state mode.