Need to consume SAP Gateway oData APIs

[Bernard]

Hi,

We wish to consume APIs exposed by SAP Gateway. Does SAP Gateway, once installed, provide out of the box capability (pre-S4/HANA) or do we need to install Fiori Apps prior to an increasing set of API functionality becoming available?

Thanks for any help.

Bernard

[former_member184867 · Accepted solution]

Could you please elaborate a bit on the API expectation.

As a middleware, Gateway provides APIs to create OData service. However installing Gateway does not provide you pre-created OData services (is that what you mean by 'API'? ) fetching business data out of the box .

The Fiori application components come with their own resources, that once installed on Gateway , will give you the required OData service for that APP. 

[Bernard · Accepted solution]

Thanks Atuna.

Yes, by API i did mean the oData services (which I had viewed as REST API's serving oData).

That was what I feared - that to "populate" oData services I would need to install the Fiori apps. We have been building apps using OPENUI5 so are very familiar with SAP Fiori. So we thought we could easily leverage existing oData APIs.

How much work is involved in installing the Fiori apps to then look at what oData services are available?

Given we are going S4/HANA in early 2017 this problem should largely go away (the problem in this case being the absence of pre-populated oData services)

[kammaje_cis]

Bernard,

Gateway is just a tool to create OData services, and it itself does not provide you any APIs.

Yes, by installing various Fiori apps, you get OData services (APIs) that come with each app.

But I am not a fan of reusing OData services (which were built for a specific UI), and usually create my own OData service using top down approach (UI to dictate the OData model).

regards

Krishna

[Bernard]

Hi Krishna.

That's an interesting response. And contrary to what we were envisaging. Our expectation, just like we have done with our existing Warehouse Management System, is to avail a number of core data components (Master Data, reference data and core transactions) as reusable services.

Do you know how SAP approach it - i.e. given their significant number of Fiori apps being built I would expect them to have a registry of oData services (REST APIs) that Front End app builders could leverage.

Thanks for your response.

[kammaje_cis]

I have been working on Fiori from beginning and never saw a single service reused by SAP in more than one UI5 app. Also one of the design principle of Fiori is to have one app corresponding to one OData service.

One of the reason is that designing an OData-model as required by the UI (i.e. top down approach), makes your UI5 coding much faster and efficient. (no workarounds like fetching the data and converting into json model )

But I understand that there is no fun/efficiency in repeating same business logic in more than one OData service. So the trick here is to keep the Business logic out of the OData service implementation (say in a suite of Classes or FMs) and reuse (call) those classes in different OData service implementations.

So in summary, have separate OData models (thus services) for each of your app. that makes your UI efficient. But develop a suite of classes which can be reusable in these implementations.

You may read this interesting blog. It talks about a methodical approach, I have not tried though.

[Bernard]

Hi Krishna.

You did jog my memory on the one-to-one mapping re app and service.

This appears to break some non-SAP design principles but achieve some good short term wins?

Short term wins

• App devs can hack there endpoints without fear of reprisal (convenience and expedient)
• no governance required once we go past the class layer - and even then how is governance applied to achieve re-use if done by different devs without some sort of registry?

Have just chatted around this with our API team lead we agreed this is contrary to current practice: i.e. obtain re-use EVEN AT THE API level and front these with a BFF (Back-end to Front-end Facade).

This means adaptation to Front End happens in a thin facade and that the mess that must ensue in Gateway and GD (I presume) is avoided.

Long term wins

• lie in the realm of governed APIs (i.e. oData service endpoints) - this may be a future level of maturity for SAP Fiori Principles?

My gut is to look at this differently - it can't hurt to keep the number of oData endpoints in SG down. The BFF will likely be built in a different technology. The decision point for us here is beyond external principles that assume a specific scenario.

Our context is affected by the following factors:

• SG skills are hectically expensive and non-regional (and will get worse as demand increases)
• We have capably used the well established BFF pattern in realms which largely mirror what we hope to achieve with SAP and SG
• We have a consistent approach across all our core operational apps
• We manage down the proliferation of activity and embedding of (sometimes business) logic in Gateway which acts primarily as a broker for real-time integration into the SAP back-end - in a BFF scenario we encapsulate the business logic with a view to positioning this in a BRM tool - this has huge potential benefit

[kammaje_cis]

Bernard,

Interesting to know about your plans on BFF.

I read about BFF here Sam Newman - Backends For Frontends, and understand below as the key features of a BFF pattern.

- One BFF service per One UI

- Separation of Interface logic and Business logic

- BFF service/interface is defined by UI developers (as they are the consumers)

- lightweight, purpose built service

For me all the above sounded like responsibilities/capabilities of Gateway (in addition to providing in OData language).

On another thought,

If you plan to use SAPUI5 for frontend, it heavily is dependent on OData. So you may have to consider if your BFF system can handle OData as well.

[Bernard]

Krishna - you are right.

The difference for us lies in the context I spoke of: i.e. skills availability: shifting the above to .NET obviates the need for significant ABAP build (limited (read near 0) internal ABAP skills and again, expensive, because the abbr. SAP occurs in the skill requirement) out in SG as well as a dearth of SG skills (vs an abundance of .NET skills - where BFF will be built out).

As you know oData originated at Microsoft so .NET (Web API) consumption (of oData) can be seen as native. In fact the challenge we have is waiting for SAPUI5 to move to v3 or v4 of oData (on their roadmap but slow in coming)

Another thing I have noted is SAP Architecture recommendations tend to be insular (and therefore not creative) as either they assume a SAP-centric environment (and fail to understand how practice could be different / better in a more heterogeneous environment where SAP systems and technologies are not the only ones in the broader organisational IT landscape - but this Vendor-based outlook is not limited to SAP.)

In time an increasing realisation of a creative approach and combining of diverse technologies (read not just SAP technologies) will start becoming apparent to SAP and it will be interesting to see how they respond to this reality as their awareness grows.

This is already true of SAPUI5 - it incorporates a lot of non-SAP stuff (which they argue is the motivation for open-sourcing a subset of SAPUI5). The real reason may be different (on the basis of what I have heard from SAP internal staff and SAP mentors)

What is true of SAPUI5 is true more broadly - the apparent nature of this seldom comes through in discussions so the thinking is ours to do.

[brian_zhu]

hi Bernard,

if you only want to consume the available Odata services, which are in the backend ( for instance ERP) system, there is no need to install the product specific addons( apps).

then on top of that, you could develop your own UIs and deployed in your front end server.

Regards,

Yueqiang

[Bernard]

Hi Yueqiang,

Your answer conflicts with Atuna's and his answer confirms what I had been told. You may want to dig some more on this?

[brian_zhu]

Hi Bernard,

Firstly i assumed that you are going to use the typical landscape of fiori as follows:

1) product specific add-ons( UI5 artifacts) are stored in the ABAP Frontend server(Gateway server),

if you do not need sap standard UI5 artifacts, you do not need to install the fiori apps here.

2) the Odata service are stored on the ABAP backend server, i assumed that you are going to

use ERP with EHP7.

you could verify the standard odata services as per the apps library as follows:

Fiori Apps Library

for instance, if you want to use the odata service of My timesheet.

all you need to do is to verify if you have this add-on in your back-end system.

regards,

Yueqiang

[AbhishekSharma]

Hi Bernard,

I did some posting this may help you, please have look to below 2 posts:

If you are using WebIDE then you need to install Cloud connector where you will configure all your server and Gateways details to connection purposes.

First post explains how to install Cloud Connector and second post tells about how to use.

Hope this will help.

Thanks-

Abhishek

[Bernard]

Much appreciated Abhishek.

Will check out your articles - in our case we are building on-Prem.