Having your data scattered across many different data sources is a very common business scenario. These multiple data sources must be considered while planning your Neptune applications.
Recently, Neptune rebranded the products Neptune P8 (Now SAP Edition) and P9 (Now Open Edition) and unified both under the name Neptune DXP, as you can read here. With that in mind, we are going to explore three options on how to create Neptune applications consuming data from SAP ECC/S4 HANA, and external system:
Scenario I:
Using Neptune SAP Edition and connecting with the external system via SAP PI/PO
In this scenario, the Neptune front-end server lies within SAP.
Its front-end framework is SAPUI5. Neptune front-end entry point will be an SAP class that implements the interface /NEPTUNE/IF_NAD_SERVER. SAP data will be consumed as a regular SAP class would, directly selecting / posting data in the SAP tables or calling BAPIs.
For external system data, an interface between SAP S/4 HANA or SAP ECC with SAP PI/PO should be created, while SAP PI/PO must also have an interface with the external data sources, using the APIs provided by these applications. From the Neptune class, this PI/PO interface can be called via ABAP proxies that are generated during the interface creation.
This approach probably is the quickest one in terms of app development, especially if you already have the external system interfaces in SAP PI/PO, and the easiest for data manipulation, since the consumption of SAP data requires no APIs, meaning that all SAP data needed can be called with pure ABAP. Adding or removing fields from a structure in the SAP stack would require only ABAP coding. It also has the advantage that the front-end framework is SAPUI5, and not OpenUI5 as in the next two approaches. You can check the differences between the two versions of the frameworks here.
The main disadvantage is that the front-end server is locked with SAP. In a future scenario that SAP would be dropped, the front-end would have to be redesigned in Neptune Open Edition. Also, if the SAP server goes down, the Neptune apps will go down as well. Finally, if SAP is not your main data source, it would be necessary to create all the required interfaces in SAP PI/PO, reducing the rapid development perk.
Scenario II:
Using Neptune Open Edition and exposing SAP Data with SAP PI/PO
This approach would use Neptune Open Edition as the front-end server.
External systems would be connected via APIs directly to the Neptune server. This APIs are designed in the Neptune API Designer. The SAP data would also be an API designed in the API designer. The front-end apps then would call all the APIs to consume / post data.
One of the main advantages of this scenario is that the front-end server is totally SAP agnostic. If SAP server goes down or in a scenario that SAP would not be used anymore, the Neptune apps would still work normally, only without SAP Data. It also allows the usage of Neptune Open Edition features such as the local database (enabling better offline capabilities in environments with local area networks, but bad internet connection), the script editor, the PDF designer, among others.
The main disadvantage is that this is probably the slowest one, development-wise. Planning and mapping all the data needed from SAP is crucial. Since SAP data is consumed via web services, all data required from SAP will have to be created as interfaces in SAP PI/PO. Thus, adding a new field, changing a structure, or creating a new interface will require changes both in SAP PI/PO,
in the Neptune API designer and in the proxy call from ABAP. However, it is possible to import a JSON file in the API designer and the API fields are built automatically. It is also possible to fetch master data from SAP and save it into Neptune’s built-in database, but then a server script would be required in order to get this data regularly.
Scenario III:
Using Neptune SAP Edition as a middleware between SAP and Neptune Open Edition
It’s an in-between the first two approaches.
Here, the SAP is consumed by a regular SAP class that implements the interface /NEPTUNE/IF_RESTAPI. Then, in the Neptune SAP Edition API Designer, you can create APIs for all the methods of your class, as you can check in details in this article. This APIs created in Neptune SAP Edition can be exported and imported in Neptune Open Edition.
This approach is not as quick to develop as using Neptune SAP Edition as the front-end server, but is quicker and simpler than exposing all SAP Data through PI/PO. It isolates the front-end server from SAP as well and eliminates the need for another software to integrate SAP data and Neptune, since Neptune SAP Edition itself acts as a middleware. It also leverages the perks and features from SAP P9.
The scenarios above were described using SAP ECC/S4 as a key component and considering that SAP PI/PO is an option. It is possible, however, to build a Neptune system completely independent from SAP, leveraging the Neptune Open Edition API designer, consuming any kind of data exposed to the web, like in scenarios II and III. SAP data can be expose it to the web using any method you prefer (gateway, SOAMANAGER, etc.) and handled in Neptune Open Edition as a regular API.
