Integration (S/4)HANA / external syst (MS Sharepoint) via RFC / BAPI, rather than OData (Gateway)

[NTeunckens]

Hello people,

Important Note : We are running SAP ECC 6.0 at this time and will probably do so for a number of years ...

Can anyone provide Official Quotes / Documentation on the possibilities to use an RFC / BAPI in the HANA-context as a 'connection medium' to Non-SAP Platforms? Or some argumentation Pro-Con ...?

My inquiry : There are some third-party SAP-connectors out there, one of which we are currently 'exploring' into. It promises an easy Interface from our current ECC SAP-landscape to MS Sharepoint and back by leveraging the power of RFC's / BAPI's ... Now this shows promise, as the implementation and maintenance is actually very low.

However I'm a bit sceptical on the longevity of this solution, as my "gut-feeling" tells me that this will not be an ideal scenario in the SAP HANA-world. While I am looking into HANA-technology (New Years Resolutions and all), I've found some confusing / contradictory information on the use of RFC / BAPI's directly in an (S/4)HANA-environment.

So just to clarify : I'm aware (most of) the BAPI's will be in a HANA system and will be 'up to date' ...

Am I correct in assuming that, even though BAPI / RFC's are 'mutated' to the HANA Eco-System, it will actually be more of an effort to use the ABAP-layer of the HANA-landscape, to fetch data from a (custom) RFC / BAPI and expose these, rather than the OData method in combination with SAP Gateway?

The suggested solution is impressive in its simplicity but uses RFC / BAPI as it's source, which suits us fine in the short run, but actually inhibits us in learning / using OData and Gateway ... I believe this is a risk in a future(?) on-premise S/4HANA-project (and chances are, we will need to migrate sooner or later ofcourse).

Any help is much appreciated. Thanks in advance!

Nic T.

[clinton_jones2 · Accepted solution]

From a partner perspective, we've not received any indications that RFC is going away any time soon. However, that said, it makes sense that where possible, ODATA should be used as it makes more sense in the context of what is contemporary. This is not to say that RFC is irrelevant, just that it has its limitations - principally since the options for RFC communication are limited to BAPIs and remote enabled Function Modules. Our experience in the transaction automation space, has been that there are not BAPIs or rFMs for all transactional capability and this is a massive gap - especially for the future. Sure, customers can write their own, but that also represents a big overhead.

The issue with ODATA though is going to come down to the way that CRUDQ is or isn't supported with ODATA methods. One of the things we know with BDC's and BAPIs is that they are almost always single purpose. ODATA holds the promise of a single object that supports CRUDQ but we haven't really seen that with the SAP ones that we are familiar with - so the promise of simplification is not apparently there for leveraging ODATA interfaces. The second element is a question about just how high performance these ODATA methods are. While the standard 'it depends' answer remains ever-present, we're unsure of just how feasible it is to use ODATA interfaces for high volume mass throughput CRUDQ.

So I guess my conclusions are that you have to leverage what is available now and see what evolves. Also consider your specific use cases - are they single record, are they mass? DOes the interaction need to be synchronous or will asynchronous or queued do ? SAP seems stuck with the SAPGUI, BAPIs and RFC even though it is trying to converge on FIORI, NWBC and ODATA as the preferred focal technologies and methods but then this also means that ALE, IDOCS and PI/XI don't go away they simply become additional ways of exchanging data with different use cases, purposes and intent. Each has its strength.

[kammaje_cis]

I feel that OData and RFCs have their own use cases and do not replace each other.

If you are building a UI (ex: Fiori), I would suggest to use SAP Gateway to expose OData.

If you have a system to system integration, (ex: replicating EWM to ECC, DMS to ERP) then RFC definitely makes sence.

[NTeunckens]

Thank you for your comment, and I agree to that. But here I am describing a UI-change, from SAP-GUI to a WebPage on MS Sharepoint.

By expecting all from this solution, I feel we're de-SAP-ing our SAP-specific business processes.

Functional people are thinking of Portal-like applications that are basically exposing BAPI's that run MM or PM-functionality that is actually 'more complete' when setting them up as Fiori (standard) apps ... Before you know it, there's going to be people expecting a 'full-Fiori' or 'full-SAP' experience through a BAPI-enabled WebPage (what about validations / specific ErrorMessages) ...

And ofcourse it makes sense to provide specific (Non-SAP-Savvy or External) Users with a limited 'shell' that is accessible through a WebBrowser, so there are valid cases to provide this type of accessibility. But we're ending up with different UX, running the same Processes, possible via different Technical Logic (so both need to be maintained).

I understand that there is a Role for some IT-expert (maybe that will be me?) to atleast point out these differences and possible effects (maintenance Cost etc.) ...

I feel we definately need to investigate further, trying to 'align' the RFC / BAPI-functionality and the OData counterpart.

Thanks for your valuable advice.

[Former Member]

Nic,

Good question and I am sure a lot of SAP customers with existing interfaces through RFCs/BAPIs are grappling with this one. As far as I understand, Gateway itself connects to ERP or S/4 HANA via RFC/BAPI connections, so I doubt that RFC and BAPIs will just go away for on-premise deployments. For cloud-deployments of S/4 HANA, we have seen that the RFCs and BAPIs are no longer available.

Vikram

[NTeunckens]

Thank you for your insight.

With the increasing importance of the OData-protocol in the SAP-landscape, and things like CDS-to-OData or MBO-Facade to enable OData from Mobile Business Objects, I see various ways of 'ruling the RFC out' in favour of OData.

I too think the RFC / BAPI technology will not go away and has its relevance ... However my concern is that a 'RFC-BAPI'-based interface actually prevents us from using the recommended Protocol for Open Data ...

I get the feel we will keep ourselves in our 'comfort zone', not enabling the power of Code Pushdown and the like ...

Again, as I mentioned, I am far from being up to speed on HANA-Technology, but I'm looking into ways to gradually exposing some of the new paradigms, even on our current ECC (Upgrading to ABAP 7.5x / EhP 8 in near future). With regard to my inquiry:

If there are clear indications that such 'third-party' Interfaces, based on RFC / BAPI's have serious downsides for the (near) future (on ECC 6.0 EhP 8 or even S/4HANA), I'm interested in learning about this.

I would hate to see a 'quick win' now, put us lagging behind in knowledge and abilities in the future ... For instance, this product would basically eliminate the need for extensive use of SAP Gateway. But then we would loose control / ability of (standard) Fiori, which uses Gateway.

I'm basically in need of some statements on :

• Why would you DEFINATELY ONLY USE OData / Gateway to be productive / cost-effective / knowledgeable ...
• Would it even make sense to SKIP GATEWAY if you would need it in the near future for Fiori and other (Mobile - SMP) scenario's in favor of some third-party tool that would be very advantageous for the external Integration (SAP-to-Sharepoint / SAP-to-WebService), but not as usefull at all in SAP-to-SAP Integration (SAP-Fiori / SAP-to-Mobile)?

You probably notice I am somewhat sceptical in using any third-party 'single solution' for our Integration-issues, as I believe we will just move down to yet another path besides SOAP-Services / Gateway / Mobile processes via SAP Mobile Platform using OData or MBO ... I would like to be able to put "a word of warning" if need be.

Thanks again for your opinion, it is much appreciated ...

Kind regards

Nic T.