SnapMSV3service—Product Development in the Cloud in Practice

How well an IT infrastructure works depends to a large extent on suitable interfaces. This is especially true in the SAP environment. It is therefore all the more astonishing that the SAP community is devoting a great deal of attention to the transition to the new S/4 Hana version of the SAP Core component, but is barely addressing the necessary adjustments in the area of integration. However, the move to the cloud also gives rise to completely new problems, especially with interfaces, which require radically different approaches.

Integration means adaptation

SAP has been making adjustments right from the start, as a look back shows: launched in 1992, SAP R/3 was already a fairly open system at the beginning, for which interfaces could be easily programmed using the classic technologies - RFC, ALE, BAPI and IDOC. Over the years, SAP has repeatedly reinvented and modernized itself, especially in the area of integration. While in the past it was the opening up to standardized Internet protocols or the introduction of middleware concepts (and products), today we as SAP users - especially in the cloud environment - are increasingly confronted with new concepts such as API-First and event-based communication.

And then came the cloud

Many customers have not kept up with this development and are still in the BAPI/IDOC/RFC era with their interface concepts. However, the move to the (public) cloud is not possible because the past few years have brought completely new requirements and concepts into play - and with great force. More and more components of traditional business processes are moving to the cloud, including the SAP backend itself. However, as hardly any companies are mapping their processes solely in the cloud for the first time, hybrid IT landscapes consisting of cloud and on-premises installations are emerging, which raise many new questions in terms of interfaces and connectivity.

In addition, there are technological approaches such as API First or event-based communication, which, just like the new strategic interface technology Fiori, increase the need for integration. And on top of all this, security is an extremely important cross-cutting issue in order to be able to implement specific requirements in a technically clean and compliant manner.

Many experienced SAP professionals and programmers are focused on the "old Abap world" due to their many years of experience, as we can see from our own experience. Especially when it comes to interfaces, they have grown to love and master the concepts of BAPIs or IDOCs.

However, according to the clean core concept, these familiar technologies are definitely no longer the first choice. They are also no longer available on SAP Public Cloud instances. They are to be replaced by new, modern technologies such as oData or SOAP APIs. But are these really equivalent? Or is it necessary to completely rethink interfaces?

Practical check

In order to find answers to the many questions, we have dedicated ourselves to the topic with a specific practical application. As software developers in the SAP environment, we always have our "nose to the grindstone" when it comes to identifying our customers' pain points and offering solutions for them. This is also the case with our latest product: SnapMSV3service is a delivery availability and ordering process for hospital pharmacies integrated into SAP BTP based on the MSV3 industry protocol. Our product helps hospitals to identify and react to supply bottlenecks for medicines at an early stage.

The initial aim was to support hospital pharmacies in the process of procuring medicines. Even before the ordering process, it should be clarified whether a medicine is available from a particular pharmaceutical supplier and, if not, whether alternative products or other sources of supply are possible.

Pharmaceutical databases had to be integrated into the digital query and ordering process for pharmaceutical suppliers. The solution also needed to be deeply integrated with the SAP standard processes and meet the data protection requirements of the GDPR. Up to now, the requirement had been solved in various ways: in the form of analog processes, with in-house information systems, with a direct MSV3 connection to the relevant suppliers or with the snap GHT APM module, an on-premises solution based on a GUI.

After the necessary research, it quickly became clear that the solution should be a cloud application, not least because of three key advantages: A standardized, always up-to-date database for all customers, central connectivity with all pharmaceutical manufacturers and providers through the MSV3 protocol and extensibility to non-SAP customers. Our existing skill sets in terms of technology and processes as well as the "cloud capability" of the planned requirement encouraged us to implement the solution on the BTP. Another decisive factor was the achievable independence - both from the SAP versions and from the specific SAP material management processes of potential customers.

Good solutions, moderate costs

Of course, we also looked at the cost side before starting the project. The most relevant drivers are the required BTP solutions (= "services"). In other words, which runtime environment is required (Cloud Foundry/Kyma or BTP Abap) and which database is possible with it? BTP Abap is only available in conjunction with a Hana DB, other runtimes also enable PostgreSQL or other databases. In addition, some "basic services" are always required - such as the Business Application Studio as the actual development environment or the Identity Services for user administration. And of course - as mentioned at the beginning - integration is a key issue. For snapMSV3service, we opted for the SAP standard solution Integration Suite with the middleware product Cloud Integration in the Basic Edition. Our learning: good solutions can be built on the BTP at comparatively low cost. However, you should familiarize yourself with the service catalog and the different metrics of the required services - and the desired architecture should be clear at an early stage.

Separate integrable process

The previously defined "cloud capability" of our solution is based on the fact that it is a process that can be easily separated (from the SAP core) and integrated with the SAP core. This process comprises three levels or systems: the SAP backend, the portal itself - i.e. the snapMSV3service application - and the MSV3 supplier side. The core component for communication between these three levels is SAP Cloud Integration (SAP CI), which establishes the secure connection between the local customer network (for on-prem) or the customer's S/4 Hana cloud instance and our SAP BTP instance via SAP Cloud Connector. Requirements are generated in the SAP backend of customer X and transmitted to the portal. There, a portal user of the customer processes these requirements - he performs availability checks against the MSV3 suppliers and responds to their feedback. The ordering process then begins with a significant special feature: a corresponding order number must be generated in SAP before an order is actually placed with the MSV3 supplier so that this can be entered as a reference in the MSV3 order.

New APIs: Similar, not identical

This process called "create/change a saved order in the customer SAP backend" (and receive the corresponding order number back immediately - we are therefore talking about a strictly synchronous interface) is an example of how much the "new" cloud world differs from the "old" on-premises world. Previously, the desired result was achieved with the calls BAPI_PO_CREATE1 and BAPI_PO_CHANGE, which were self-explanatory for many "old Abap hands". In the "new" cloud world, oData APIs (version 4) are required for this and the desired tasks are completed with their service ID "API_PURCHASEORDER_2" (Post or Patch, if you want to add a deletion note to some items then also Delete).

Not only is the familiar original function no longer available, but the syntax and function are also completely different. To find the desired functionality, the Business Accelerator Hub (api.sap.com) offers a good first step (also directly with examples and test options). However, there is a lack of detailed information - for example, what each property does or which value should be set for a particular functionality. What the new APIs do is therefore similar, but by no means identical to what we are used to.

Success factors for the cloud

Based on our experience with snapMSV3service, the following key factors for successful cloud solutions can be summarized: The planned process must be "cloud-capable", i.e. it must be separable from the SAP core and integrable with the SAP core. The issue of integration must be clarified as early as possible. The skill set of the architects must be right and the architecture must be fixed at an early stage.

In order to understand the new cloud interfaces, you also need specialist knowledge - about the SAP Integration Suite, for example - which you should acquire as soon as possible.

In order to actually implement economical solutions, it is necessary to know the BTP services and their licensing metrics. And it is definitely worthwhile to familiarize yourself with the new technical APIs for implementing specific business tasks. And better sooner than later.

snapconsult.com

To the partner entry: