Deployment options with SAP Gateway

There are 4 deployment options provided by SAP which ensures the enablement of gateway framework and it can be chosen based on business needs.

1. Central hub deployment (Routing will be easy in case of multiple system)

2. Central Hub deployment with Development in hub (Routing will be easy in case of multiple system)

3. Embedded deployment (Routing is should not possible-as per framework)

4. HCP or HCI deployment

SAP NetWeaver Basis release	SAP Gateway Hub Framework**	SAP Gateway Backend Framework*
7.31 and earlier	GW_CORE, IW_FND	IW_BEP
as of 7.40	SAP_GWFND	SAP_GWFND

Generally, deployment means where the service is installed and where its consumed.

To be more specific two servers

1. SAP Gateway server

2. SAP Backend Business suite server

Type 1 : Central Hub deployment

The project will be created in backend system, which means it will be able to use all the DDIC and Genil objects and can implement the logic directly.

Genil Object – A class normally created globally can be accessed only in SAP Backend system.

If for example I have a class created in backend I will be able to use it directly during my logic implementation in DPC class.

The created service can be consumed in Frontend system by just registering the service in /N/IWFND/MAINT_SERVICE.

Once I call this service the processing will take place in Backend system but the output will be displayed in frontend system.

Advantages:

1. I can keep the hub as a single point of contact and route it to multiple backend systems.

2. The service can be created with direct reference to the DDIC objects or Genil objects (class) in DPC

3. Additional authentication measures like OAuth or SAML Browser protocol is supported

4. Performance can be improved by using Co-deployment (Microhub) option.

MicroHub or Co-deployment:

If this is enabled and the service is executed in frontend, the call will be transferred directly to the backend system via RFC to function module /IWFND/FM_MICRO_HUB_REQUEST in the backend system.

No need of maintaining system alias .

No process will be done in Frontend system you can check this with /N/IWFND/TRACES

Micro-hub enabled call stack:

Here the call is executed in Backend system none will be in front end system identifies based on configuration made .

Call stack for Non Micro-hub enabled system

Example: I have to create a project in Backend system ,write my logic in DPC class which will follow normal procedure until registering the service in backend.

During registration we need to set the processing mode as “Co-deployed” in transaction /N/IWFND/MAINT_SERVICE .

Now I can register my service in Frontend system in same maintain service transaction but with Processing mode as “Routing based”.

Prior to that I need to perform additional step as below in frontend system before adding system alias

1. Open Transaction “SPRO” on the hub system

2. Click on “SAP Reference IMG”

3. Follow the path “SAP NetWeaver” -> “SAP Gateway” -> “Configuration” ->

”Connection Settings” -> “SAP Gateway to SAP System” ->    “Manage SAP System Aliases”

4. Enable OData processing on the backend for SAP system alias (See screenshot).

a) Either create a new SAP system alias and choose the “Use Micro Hub” check box

or

b) Adjust an already existing SAP system alias by choosing the “Use Micro Hub” check box.

In Frontend system

Step1:

Step2: Processing mode:Routing Based

In Backend system:

Type 2: Central Hub with Development in Hub

Here the development of project ,registering service will be done in frontend where gateway component is installed, data retrieval (physical data from DB tables )will be happening at backend via RFC call.

This method can be chosen  when there is no chance of installing gateway components in backend system as they are older releases SAP 7.0 but data resides only in this backend system.

Working:

The project must be created in frontend system with binding of DDIC structure /Own structure to entities in project. So MPC will work in the same way.

But DPC logic for CRUD operation such as Create, Read, Update, delete has to be done via RFC call in Backend with DESTINATION parameter.

If the Genil objects are present inside the class it can be accessed inside an interface, but it cannot be directly referred in DPC class logic.

Advantages: No need to install gateway components in backend system

Disadvantages: Genil Objects such as class created in Backend system cannot be addressed directly in DPC logic it has to be exposed only via interfaces such as RFC, BAPI.

Type 3: Embedded Deployment:

Here the gateway project creation, registration and consumption of service everything is done in one SAP BACKEND SYSTEM .

The only disadvantage here is backend system should not act as a hub/frontend for another backend system.

But its theoretically possible for a backend system to act as a frontend for some other backend system.

If you have embedded architecture for 4 business suite system ,and fiori application then there should be four Launchpad of Fiori.

Why backend system (say A) should not act as a frontend for another background system (say B) ?

Because companies might be required upgrade system B to higher version of SAP 7XX for some business reason.

Now because of that upgrade the system B is on higher version and system A might be lower version which may cause some inconsistency.

So it’s always recommended to have SAP Gateway server on higher version comparing to backend SAP_GWFND component.

Advantage:

Result overhead is improved as there is no RFC call to backend as in Central hub deployment scenario.

Disadvantage:

Multiple times the same gateway configuration needs to be performed if there are ‘n’ number of systems to serve business purpose.

Type 4: HCP Odata Provisioning or Gateway as a service

It is  like type 1 Central Hub deployment strategy, except for which the SAP Gateway frontend part will be managed by SAP cloud platform.

Odata service ,SAP Fiori applications are connected to HANA cloud via cloud connector (secure way with several authentications before connecting to backend systems)

Advantages:

One point of contact for multiple backend systems.

Maintenance of SAP Gateway frontend will be taken care by cloud such as scaling etc.