Neptune DXP REST API connector

RESTifying SAP

Neptune’s approach provides you with the capability to wrap SAP’s functions around a modern RESTful API layer. Rather than treating SAP as a special component requiring a bespoke solution, Neptune DXP’s SAP connector readily implements an ABAP driven interface mechanism to map elements of SAP’s ABAP Classes (standard or bespoke) to those of a REST API, compliant to the OpenAPI 2.x or 3.x specification with only a limited amount of coding and configuration:

That means, Neptune DXP automates the process of handling API requests and responses animating an ABAP class as the data provider behind the API. As a result, it gives existing, standard and bespoke, functional capabilities a new lease of life becoming readily accessible as REST APIs and eliminates the need for an extraneous, strongly coupled interface or plugin in your application or microservice code.

This has the effect of turning SAP into yet another API service behaving similarly to an external SaaS service. Your apps and microservices can then safely consume Neptune DXP’s SAP REST APIs. Safe in the knowledge that only major/breaking changes to the REST API interface, as is the case with all SaaS services, bears any impact to your code. This enhances the lifetime value of your existing ABAP code limiting the need for intervention due to SAP updates or program alterations. Similarly, incremental improvements or patches need not result in expansive regression tests to re-establish your code’s correct operation.

Stateless vs. stateful APIs

Stateless API processing

By default, all SAP REST APIs created with the Neptune DXP SAP connector is stateless. This means that with each API request made a new SAP connection is established and when a response is served back the connection is terminated. This is common practice in both REST and OData APIs and requires the client initiating the API request to keep track of the state between multiple API requests.

For example, consider a request for a large set of data held in SAP such as a list of products. To manage the presentation effectively an initial API request can establish the total number of records. With that in place the client can then implement a pagination mechanism to orchestrate multiple GET requests to only fetch a subset of the data visible to the user:

Each request for a new page of the product will result in a new SAP connection without any prior knowledge of any previous requests. It is therefore the client’s responsibility to keep track of the pagination state and construct discrete API requests to fetch the correct subset of data each time. This could involve keeping track of the current page and a data structure such as a linked list to model the pagination parameters.

Stateful API Processing

With stateful connections, Neptune DXP connects to SAP to form a session. During that, you can persist in memory of your state, between API requests, in the ABAP Class acting as the data provider to the API. The context of the session is specific to the user used by Neptune DXP to authenticate into SAP and must be explicitly terminated to release any locked resources. The stateless API example above can be modified so that the API developed can record the pagination state in the ABAP class:

In this approach, the client can execute successive API requests to fetch the next (or previous, first, last,…) pages or request a specific page number. As the state is now persisted in the ABAP class the Neptune DXP API is now stateful. The degree of implementation effort is the same, but it may be argued that the client’s implementation matches more closely the user’s experience. Also, if the API is a reference by multiple applications we can achieve a higher degree of re-usability by outsourcing state management away from the client.

In more complex insert or update scenarios, an additional benefit of stateful APIs can be the locking of SAP resources to ensure the completion of transactions with multiple data table dependencies. For example, a stock movement can execute updates to multiple dependant resources such as table data dedicated to inventory, accounting, planning and potentially bespoke data:

Connect
1. Begin Session
  - Make API Call to Edit data & Lock resource(s)
  - Make API Call to Edit data & Lock resource(s)
  - Make API Call to Save data
  - Release Locked resource(s)
2. End Session
Disconnect

Importantly, if any failures are encountered, whilst in session can be mitigated by initiating a rollback of any preceding transaction steps, protecting the referential integrity of all dependant data entities.

The use of a stateful APIs means we can maintain a high degree of granularity when designing our Neptune DXP SAP API operations avoiding “fat” APIs that attempt to carry out too many steps to maintain data integrity. At the same time, we can preserve the state between requests without over-exposing the client to SAP implementation idiosyncrasies and guarantee the execution integrity of complex transactions.