SAP Fiori - NetWeaver Gateway

SAP NetWeaver Gateway: Capabilities and Key Benefits

SAP NetWeaver Gateway is a technology that provides a simple way to connect devices, environments and platforms to SAP software based on market standards.

Non-disruptive, any SAP business suite.
Ease to develop simple APIs and does not require any tool knowledge.
Based on REST, ATOM/OData. It allows connectivity to SAP applications using any programming language or model, without the need for SAP knowledge, by leveraging REST services and OData/ATOM protocols.
It provides plug-ins for well-known IDEs such as Eclipse, Visual Studio 2010 and XCode.

Connect SAP NetWeaver Gateway to SAP Business Suite

This involves configuring Back-end server as trusting system.

Step 1 − Use T-code: SM59

Step 2 − Click on create icon as shown below.

Step 3 − Enter the details as shown below −

RFC Destination Name
Connection Type: 3

Step 4 − Go to the Technical Settings tab and enter the details as explained below.

Step 5 − Enter the gateway host in the Target Host field and Instance number in the System Number field.

Step 6 − Go to the Logon & Security tab and enter the details.

Step 7 − Enter the client number and click on Current user for authentication.

Step 8 − Select Trust Relationship as Yes and click the save icon at the top.

Step 9 − Select Go back to the home screen and use T-code: SMT1

Step 10 − Click the create icon as shown below.

The Trusting Wizard will open.

Step 11 − Enter the details of RFC destination that you have just created and click Continue.

Step 12 − The information of trusted system is displayed. Click the Save button.

Here, you have defined trust relationship between your SAP system and NetWeaver Gateway host by configuring SAP system to be trusting system and NW host to be trusted system. This enables the remote logon for users to use the user data in SAP NetWeaver gateway and SAP system.

SAP NetWeaver Gateway: Deployment Options

There are two different deployment options available to deploy SAP NetWeaver gateway for SAP Fiori configuration.

Central Hub Deployment of SAP NetWeaver Gateway: Development in Back-End System

In this type of deployment option, central UI Add-On, Product specific UI Add-Ons and SAP NetWeaver gateway is contained in ABAP front-end server. The back-end server contains business logic and back-end data. Development takes place in ABAP back-end system.

The services are deployed on a back-end system and registered on the server. The Gateway service is deployed in Gateway back-end system. Either IW_BEP is deployed or system running on the 7.4 or higher version leverage the core component SAP_GWFND.

Advantages

It allows changes to the UI without development authorization in back-end.
It provides single point of maintenance for all UI issues.
It provides central place for theming and branding of Fiori Apps.
It provides single point of access to back-end system.
As there is no direct access to back-end system, it has enhanced security.
Direct local access to metadata (DDIC) and business data and ease of reuse of data.

Disadvantages

It requires separate SAP NetWeaver Gateway system.

Note − SAP recommends Central Hub deployment option for production environment.

Central Hub Deployment of SAP NetWeaver Gateway

In this option, Gateway server functionalities are used on one dedicated server, the hub system. As against the first option, service deployment takes place on the hub system.

This option is used if either no development must be performed on the back-end system or in case of releases prior to 7.40. if it is not allowed to deploy the Add-On IW_BEP in the back-end. In this case, the developer is limited to the interfaces that are accessible via RFC in the back-end.

Development takes place in Gateway hub system and Business suite back-end systems are not touched.

IW_BEP or SAP_GWFND is running in Gateway hub system and nothing is touched in SAP Business suite.

Advantages

In addition to the benefits given for the first option, this option has the advantage that it does not require the installation of Gateway Add-Ons in back-end system.

Disadvantages

There is no direct access to metadata (DDIC) and business data. Therefore, reuse of data is limited.
GENIL objects cannot be used remotely.
In this configuration, access is limited to remote enabled interfaces like RFC modules, BAPI’s etc.

Embedded Deployment

In Embedded deployment architecture, development takes place in SAP Business suite back-end system and Gateway system is also installed in the same system. Services are registered as well as published in the SAP Business Suite back-end system.

IW_BEP or SAP_GWFND is running in the same system in which SAP Business suite is installed.

Advantages

It requires less run time as one remote call is reduced.

Disadvantages

System should not be used as hub for additional Back-End systems.
In case of multiple SAP Business Suite systems, Gateway has to be configured multiple times.
This configuration is recommended only for sand box purposes.

Note − You should not use a SAP Business Suite System with embedded deployment as a hub system for additional back-end system. The reason is that it might lead to a situation where the SAP NetWeaver Gateway release of the hub system is lower than the version of the SAP NetWeaver Gateway back-end components of the remote back-end system.

To avoid such situation, you can use embedded deployment option for your SAP Business Suite systems.

If you go for a hub-based architecture, you should use a dedicated SAP NetWeaver Gateway Hub system that should run on the latest release of SAP NetWeaver Gateway.

Check the Deployment method in SAP Fiori System

Step 1 − Login to SAP Fiori back-end system using SAP GUI as shown in the image given below.

Step 2 − On the System menu, click Status.

Step 3 − A new window opens showing the System Status.

Under SAP System data, click the icon (magnifying glass) below the label Component version.

Step 4 − This will show you the list of the components installed on SAP back-end system as per NetWeaver Gateway Release.

With NW 7.31, IW_BEW and GW_Core components are installed and for NW 4.0, SAP_GWFND is installed and there are no individual components.

Now in this system, you have NW system installed on back-end system and all the UI Add-Ons components are in front-end system. Therefore, it represents a Hub Architecture method of deployment.

Overview of OData (Open Data Protocol)

OData is used to define best practices that are required to build and consume RESTful APIs. It helps you to find out changes, defining functions for reusable procedures and sending batch requests etc.

Some of the important features are −

OData provides facility for extension to fulfill any custom needs of your RESTful APIs.
REST stands for Representational State Transfer and it is sometimes spelled as "ReST".
It relies on a stateless, client-server, cacheable communication protocol. In virtually all cases, the HTTP protocol is used.
REST is defined as an architecture style for designing network applications.
OData helps you focus on your business logic while building RESTful APIs without having to worry about the approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats and query options etc.
OData RESTful APIs are easy to consume.

OData Service Life Cycle

The OData service life cycle includes span of an OData service. Given below are the key steps to be considered in an OData Service Life Cycle.

Activation of OData service.
Maintaining OData service.
Maintaining of models and services, up to the cleanup of the metadata cache.
RESTful applications use HTTP requests to post data to create or update, read data and delete data. REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.
REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services.

REST Architecture Components

Given below are the components of the REST Architecture.

Resources
A web of resources
Client-server
No Connection state
Proxy Servers