Fiori PO approval gateway service missing RFC calls

[Former Member]

Hi All,

I have got the Fiori PO approval working in an embedded gateway scenario.

However, going through the source code of the standard data provider class CL_GBAPP_APV_PO_RDP I do not see any calls to RFC's in case it is a central hub scenario, which got me thinking. It seems the methods in the DPC call the SAP_WAPI* functions directly without a destination which would mean it would run on the front-end server. This is in contrast to the other gateway services for ex. create sales order, track sales order etc... where it's very clear in the code that it calls the backend server via RFC in cases of central hub deployment. In a central hub scenario, the workflow work items would be in the backend server, as we have an embedded scenario I can't really test out the PO approval in a central hub setting.

Does anyone have any idea why I can't find any RFC calls in the PO approval scenario?

Thanks!

Regards,

Alex

Tags edited by: Michael Appleby

[kammaje_cis · Accepted solution]

Alex,

Data Provider Class is part of the backend component. So both in Central Hub as well as as embedded deployment, RFC call will not be made. (Because backend component will always be installed of ECC Server) Even in "Create Sales order" there might be a code in DPC to call with destination, but it will always be Local.

Difference will be in calls from the framework classes to DPC classes. This call will have RFC destination. Based on HUB/Embedded RFC or local call will be made.

Thanks

Krishna

[Former Member · Accepted solution]

Hi Krishna,

Thanks for your answer. I'm still a bit confused about the central hub deployment.

In a central hub scenario, the service calls would be:

Fiori client --> web dispatcher --> front-end server --> backend server

My understanding is that the OData services would be deployed on the front-end server right? That would mean that the calls to the URL's/SICF services for the OData service would happen in the front-end server. When I have a look at the standard Fiori Track Sales Order Component below:

The UI5 app points to "/sap/opu/odata/sap/SRA018_SO_TRACKING_SRV/" as the service URL. Which would mean that it's pointing to the same host as where the UI5 app is deployed on(front-end server). Unless there is a config table somewhere that points the app to the correct Gateway Service server?

If the Fiori UI5 applications are deployed on the front-end server and the OData services on the backend server, how do we tell the app to fetch data from another host(back-end server)? Also, will we not run into CORS(cross origin resource sharing) issues?

Is it through this configuration table?

I thought the reason I was seeing RFC calls in the OData services of the standard Fiori apps were because in central hub scenarios a system alias will be maintained in the table above and the OData services would call the relevant functions in the backend system to read the data. I see alot of RFC_READ_TABLE calls and call function destination calls in the other Gateway Services so I thought this was the reason.

Thanks again for all your help.

Regards,

Alex

[kammaje_cis · Accepted solution]

Alexander,

Gateway has two logical/software components.

1. OData framework (service agnostic) 

2. Service Implementation+Backend enablement (Service specific DPC MPC classes ++)

Both in Hub Deployment and in Embedded deployment, the second part resides with the backend ECC.

System alias of your service (you enter while registering the service in HUB) tells the OData framework where to go for fetching the Business data. (Or where to find the service specific DPC MPC classes)

UI5 app points to the frontend server, and based on the system alias,call gets routed to the local MPC DPC classes (in case of embedded) or to remote MPC DPC classes. (in case of HUB)

Hope it helps.

Regards

Krishna