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.
- Central hub deployment (Routing will be easy in case of multiple system)
- Central Hub deployment with Development in hub (Routing will be easy in case of multiple system)
- Embedded deployment (Routing is should not possible-as per framework)
- HCP or HCI deployment
|SAP NetWeaver Basis release||SAP Gateway Hub Framework**||SAP Gateway Backend Framework*|
|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
- SAP Gateway server
- 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.
- I can keep the hub as a single point of contact and route it to multiple backend systems.
- The service can be created with direct reference to the DDIC objects or Genil objects (class) in DPC
- Additional authentication measures like OAuth or SAML Browser protocol is supported
- 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
- Open Transaction “SPRO” on the hub system
- Click on “SAP Reference IMG”
- Follow the path “SAP NetWeaver” -> “SAP Gateway” -> “Configuration” ->
”Connection Settings” -> “SAP Gateway to SAP System” -> “Manage SAP System Aliases”
- 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.
Thanks Alvise 🙂
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?
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 .
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.
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.
Recommendation is still embedded deployment, but you would be still able to use Hub and Backend.
Thanks for the detail overview. it is very useful . 🙂
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 ?