Routing vs Co-deployed – OData Processing Modes

0
34

The SAP Gateway Foundation framework facilitates communication between client applications and backend services in SAP systems.

There are two processing modes available:

Routing-based (default)

In this mode, the framework uses the routing configuration for the service and passes the OData request via RFC (Remote Function Call) to one or more remote backend systems or, in case of a local deployment, uses a direct call to the local system. However, this direct call implementation only saves the RFC and network overhead but does not fully optimize data transfer and database accesses within the local system.

Co-deployed only

This mode is only applicable when the service is deployed locally on the same system. In this mode, the framework bypasses the routing configuration and directly passes the OData request to the local IW_BEP component (the backend runtime). This direct communication between the HTTP handler and the local backend runtime allows for optimized data transfer and shared memory access, resulting in improved performance.

When a service is deployed, registered, and activated locally on the same system, the framework offers a performance optimization by providing a shortcut between the HTTP handler (responsible for handling incoming HTTP requests) and the backend runtime (responsible for executing the service logic). This shortcut leads to two main performance benefits:

  1. Optimized usage of metadata via shared memory: Instead of transferring metadata over the network, the metadata can be shared and accessed directly in memory, reducing overhead and latency.
  2. Optimized usage of data containers for payload: The data containers used to transfer the request and response payloads can be optimized for local communication, further enhancing performance.
  3. Bypassing system alias lookup: Since the service is deployed locally, the framework doesn’t need to look up the system alias information, which would typically be required for remote service calls.

It’s important to note that when using the “Co-deployed only” mode, the service cannot be assigned additional system aliases, as the routing information is not used. If additional system aliases are added (e.g., via transport), the framework will display a popup in the /IWFND/MAINT_SERVICE transaction, prompting administrators to either change the processing mode back to “Routing-based” or remove the unnecessary system aliases.

Developers should choose the “Co-deployed only” processing mode when the service is registered and activated in the same system to leverage the performance optimizations provided by the SAP Gateway Foundation framework for local service processing.