Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
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*
and earlier


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.


  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
    b) Adjust an already existing SAP system alias by choosing the “Use Micro Hub” check box.


In Frontend system


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.


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.


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


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)


One point of contact for multiple backend systems.

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


0 Kudos
nice overview.


0 Kudos
Thanks Alvise 🙂

0 Kudos

Hi Manikandan,
thank you for your blog, it's very helpful.
I have a question for you about that Co-deployment option.
It isn't very clear to me the utilization scenario.
For example, in an Embedded Deployment you said that Routing is not possible.
In fact, in our S/4HANA system with embedded Gateway and FrontEnd, all oData services are registered with Routing-based processing mode and system alias "LOCAL".
Is that correct? Should they be changed to co-deployed?

Best regards
0 Kudos
Hi Giulia,

Co-deployment / Micro-hub comes with a clause of certain configuration . A hub and a backend system will exist.

Hub will be routing based and BACKEND will be co-deployed.

You will have to do SPRO setting for detailed insight  please refer Andre Fischer blog .
0 Kudos

Hi Manikandan

If a landscape has a single S4HANA backend system, the embedded deployment option should be best for a Fiori configuration, correct?

Except for the network performance gain, this will also result in less user and authorization maintenance, as users no longer need to be maintained on back-end and front-end systems.


0 Kudos

Hi Manikandan,

We are on ECC EHP8 7.5 and done the Hub Deployment of the Gateway with the development on the ECC backend system. We are planning for S4 Hana 1809. Do we able to use the Hub deployment option with the development on the S4 Hana system and Register and Deploy the service on the hub system? SAP recommends embedded deployment in the blogs. 

Thank you,


0 Kudos
Hi Rohit,

Recommendation is still embedded deployment, but you would be still able to use Hub and Backend.
0 Kudos

Hi Mani,

Thanks for the detail overview. it is very useful .  🙂



0 Kudos
quick question, with

Type 4: HCP Odata Provisioning or Gateway as a service

where do you traces your request, we used to use /IWFND/TRACES on SAP Gateway,

now that Gateway is in the cloud, is there a tracing tools or can we used this transaction on the ERP backend instead ?


0 Kudos
Hi Manikandan Rajasekaran
Excellent blog.

I was very confused as 2 Tcodes still coexist
/IWFND/V4_ADMIN that scores many hits
/IWBEP/V4_ADMIN that is not much discussed

Though your article does not touch ODATA V4 please help in a issue I am currently facing

I want to know  how to "de-activate" Odata v4


Product and Topic Expert
Product and Topic Expert
0 Kudos
As I answered to the question you posted it is possible to de-activate an OData V4 service by deleting the respective service group.

But when using a code based implementation based on the SAP Gateway OData V4 framework it is not possible to publish such a service as OData V2 service out of the box.

You would need to re-implement the service using the OData V2 framework or better use RAP.

However RAP is not available in the first release you mentioned 1809 and it is only in its early stages in the second one you mentioned 1909.
0 Kudos
Thanks again Andre

I do get encouraging answers and this is one.

Spent so much effort searching this one I tried "my luck" also in
Manikandan Rajasekaran's excellent blog

Regards & Thanks