SAP Connectivity

Neptune Software provides two advanced SAP connectivity mechanisms that surpass more traditional and inherently problematic approaches used by other platforms:

sap connectivity

Connectivity to a backend ERP solution, such as SAP tends, to be implemented by other MXDP platforms in the form of an interface or a plugin. These tend to either:

  • consume an IDoc message, SAP’s native format of message-based interfaces, or

  • establish an RFC connection to SAP invoking functions modules

Message-based connections require the use of a service bus or a queue manager with transformation capabilities. Whilst once a popular integration approach in recent years there has been a move away from middleware hubs as they introduce opaque business logic implementations that limit the adoption of a service orientated approach.

A plugin mechanism, typically, promotes boilerplate development and strong code coupling aiming to expose SAP’s functions as a public endpoint. They tend to come in the form of a:

  • bespoke library, for example. based on C++ or similar, to organise connectivity and the execution of RFC calls to your SAP system; the library functions are then invoked from within your code.

  • proxy web services as an evolution of the library model, whereby a bespoke web service is built and wrapped around a bespoke connection library to provide access to SAP via an HTTP interface.

A final approach is the implementation of RFC enabled SAP function modules so that they can be called externally by your client or microservice.

All of the above may give the impression of a standardised and abstract mechanism that seemingly accelerates your development. However, over the long term, they introduce technical debt and mounting maintenance costs. Whilst the integration via RFCs and IDocs is technically sound, they expose your application or microservice code to the idiosyncrasies of SAP artefacts and connection mechanism. Your scripts are forced to invoke SAP objects, such as a BAPI, a Function Module, or to consume a native IDoc message. Your code must make sense of SAP’s vernacular and engage in transformation tasks to map the various SAP elements. In effect, an interface or a plugin merely improves the “plumbing” necessary to expedite connectivity to SAP, but it retains all the unwanted strong references to a backend system. In a REST-led paradigm, this is an anti-pattern that leads to strong coupling. The consequence is repeated regression tests when even a minimal amount of refactoring is applied on any integrated SAP elements. Over time your SAP dependant application or microservices scripts become increasingly brittle requiring frequent changes with cascading effects on the rest of your code also dependant on them.