This article takes a look at what options exist to expose consumable services from an SAP (ABAP) Backend system.
Services can be exposed like this:
- RFC (RFC-enabled function modules / BAPIs are using the SAP-propietary protocol which must be known on consumer-side)
- SOAP (Web-Services based on WSDL and SOAP/http(s) internet standards)
- REST (Representational State Transfer protocol is a lean http-based protocol and currently state-of-the-art especially when consuming from mobile devices. Big advantages, esp. performance, are achieved when using the JSON format and not the XML-based ATOM format)
The architectural question is wheather the service is consumed directly (point-to-point) or mediated. Mediated means using a middleware between the consumer and the provider. The SAP middleware we look at is mainly
- SAP NetWeaver Process Integration (PI) / SAP NetWeaver Process Orchestration (PO) or
- SAP NetWeaver Gateway
Reasons for using a middleware (purely from a runtime perspective, not considering interface modeling):
- Mapping (conversions/transformation necessary)
- Protocol-Switch (consumer is using a different protocol than service provider)
- Routing (dynamic routing is needed, e.g. to select between different systems or services)
- Stateful Message Processing (allow integration patterns like e.g. async-sync communication or to correlate messages based in their contents)
- General Rule to NOT allow direct SAP backend connectivity (e.g. for security reasons)
The main reason to implement direct communication is runtime performance (minimizing the infrastructure components at runtime to achieve fast response times and avoid points of failure).
