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.