SnapMSV3service: Produktentwicklung in der Cloud in der Praxis

Wie gut eine IT-Infrastruktur funktioniert, hängt zu einem wesentlichen Teil von geeigneten Schnittstellen ab. Das gilt auch und besonders im SAP-Umfeld. Umso erstaunlicher ist, dass sich die SAP-Community zwar ausgiebig der Transition zur neuen S/4-Hana-Version der SAP-Core-Komponente widmet, die zwingend notwendigen Anpassungen im Integrationsbereich aber kaum thematisiert. Dabei ergeben sich beim Umzug in die Cloud gerade auch bei Schnittstellen völlig neue Problemstellungen, die radikal andere Zugänge verlangen.

Integration heißt Anpassung

Anpassungen gab es bei SAP von Beginn an, das zeigt ein Blick zurück: 1992 auf den Markt gekommen, war SAP R/3 schon zu Beginn ein recht offenes System, für das man mit den klassischen Technologien – RFC, ALE, BAPI und IDOC – gut Schnittstellen programmieren konnte. Im Lauf der Jahre hat sich SAP immer wieder – gerade auch im Integrationsbereich – neu erfunden und modernisiert. Waren es in der Vergangenheit die Öffnung gegenüber standardisierten Internet-Protokollen oder die Einführung von Middleware-Konzepten (und Produkten) so sind wir als SAP-Anwender heute – gerade auch im Cloud-Umfeld – zunehmend mit neuen Konzepten wie API-First und Event-basierter Kommunikation konfrontiert.

Und dann kam die Cloud

Diese Entwicklung haben viele Kunden nicht mitgemacht und stehen mit ihren Schnittstellen-Konzepten immer noch in der BAPI/IDOC/RFC-Ära. Der Move in die (Public) Cloud ist damit allerdings nicht möglich, denn die vergangenen Jahrehaben völlig neue Anforderungen und Konzepte ins Spiel gebracht – und das mit Nachdruck. Immer mehr Bestandteile klassischer Businessprozesse übersiedeln in die Cloud, mitunter auch das SAP Backend selbst. Da aber kaum ein Unternehmen seine Prozesse erstmals nur in der Cloud abbildet, entstehen hybride IT-Landschaften aus Cloud- und On-Premises-Installationen, die viele neue Fragen in Bezug auf Schnittstellen und Konnektivität mit sich bringen.

Dazu kommen technologische Ansätze wie API First oder Event-basierte Kommunikation, die genau so wie die neue strategische Oberflächen-Technologie Fiori, den Integrationsbedarf erhöhen. Und quasi on top steht Security als extrem wichtiges Querschnittsthema, um konkrete Anforderungen technisch sauber und den Compliance-Vorgaben entsprechend umsetzen zu können.

Viele versierte SAP-Profis und Programmierer sind gerade durch ihre langjährige Erfahrung auf die „alte Abap-Welt“ fokussiert, das sehen wir aus eigener Erfahrung. Gerade auch beim Thema Schnittstellen haben sie die Konzepte von BAPIs oder IDOCs liebgewonnen und zu beherrschen gelernt.

Nach dem Clean-Core-Konzept sind diese vertrauten Technologien allerdings definitiv nicht mehr die erste Wahl. Zudem sind diese auf SAP Public Cloud-Instanzen auch nicht mehr verfügbar. An Ihre Stelle sollen neue, moderne Technologien wie oData- oder SOAP-APIs treten. Aber sind diese wirklich gleichwertig? Oder ist es notwendig, Schnittstellen völlig neu zu denken?

Praxischeck

Um Antworten auf die vielen Fragen zu finden, haben wir uns dem Thema mit einer konkreten praktischen Anwendung gewidmet. Als Softwareentwickler im SAP-Umfeld haben wir ja die „Nase stets im Wind“, um Pain Points unserer Kunden zu identifizieren und dafür Lösungen anzubieten. So auch bei unserem jüngsten Produkt: SnapMSV3service ist ein in der SAP BTP integrierter Lieferverfügbarkeits- und Bestellprozess für Klinikapotheken auf Basis des Branchen-Protokolls MSV3. Unser Produkt hilft Krankenhäusern, Lieferengpässe bei Medikamenten frühzeitig zu erkennen und darauf zu reagieren.

Am Anfang stand die Vorgabe, Klinikapotheken im Prozess der Beschaffung von Arzneimitteln zu unterstützen. Bereits vor dem Bestellprozess sollte geklärt werden, ob ein Medikament bei einem bestimmten Pharmalieferanten verfügbar ist, und falls nicht, ob alternative Produkte oder andere Bezugsquellen in Frage kommen.

Dazu waren pharmazeutische Datenbanken in den digitalen Abfrage- und Bestellprozess gegenüber den Pharmalieferanten zu integrieren. Die Lösung sollte zudem tief mit den SAP Standard-Prozessen integriert sein und auch die Datenschutzerfordernisse der DSGVO erfüllen. Bislang wurde die Anforderung auf verschiedene Arten gelöst: in Form analoger Prozesse, mit Info-Systemen Marke Eigenbau, mit direkter MSV3-Anbindung zu den relevanten Lieferanten oder mit dem snap GHT APM Modul, einer On-Premises-Lösung auf GUI-Basis.

Nach den erforderlichen Recherchen war rasch klar, dass die Lösung eine Cloud-Anwendung sein sollte, nicht zuletzt aufgrund von drei zentralen Vorteilen: Einem einheitlichen, stets aktuellen Datenbestand für alle Kunden, der zentralen Konnektivität mit allen Arzneimittel-Herstellern und -Anbietern durch das MSV3-Protokoll und die Erweiterbarkeit auf non-SAP-Kunden. Unsere vorhandenen Skill-Sets in Bezug auf Technik und Prozesse sowie die „Cloud-Fähigkeit“ der geplanten Anforderung bestärkten uns darin, die Lösung auf der BTP zu realisieren. Entscheidend war auch die erreichbare Unabhängigkeit – und zwar sowohl von den SAP-Versionen als auch von speziellen SAP-Materialmanagement-Prozessen potenzieller Kunden.

Gute Lösungen, moderate Kosten

Selbstverständlich haben wir uns vor dem Projektstart auch die Kostenseite angesehen. Relevanteste Treiber sind die benötigten BTP-Lösungen (= „Services“). Das heißt, welche Runtime-Umgebung ist er-wünscht (Cloud Foundry/Kyma oder BTP Abap) und welche Datenbank ist damit möglich? BTP Abap ist eben nur in Verbindung mit einer Hana DB verfügbar, andere Runtimes ermöglichen auch PostgreSQL oder weitere Datenbanken. Dazu kommt, dass manche „Basis-Services“ immer benötigt werden – etwa das Business Application Studio als eigentliche Entwicklungsumgebung oder die Identity Services für die Benutzerverwaltung. Und natürlich ist – wie eingangs erwähnt – Integration ein wesentliches Thema. Beim snapMSV3service haben wir uns für die SAP Standard Lösung Integration Suite mit dem Middleware Produkt Cloud Integration in der Basic Edition entschieden. Unser Learning: Schon zu vergleichsweise geringen Kosten lassen sich gute Lösungen auf der BTP bauen. Allerdings sollte man sich mit dem Service-Katalog und den unterschiedlichen Metriken der benötigten Services vertraut machen – und die gewünschte Architektur sollte frühzeitig klar sein.

Separierter integrierbarer Prozess

Die zuvor definierte „Cloud-Fähigkeit“ unserer Lösung basiert darauf, dass es sich um einen (vom SAP Core) gut separierbaren und mit dem SAP Core integrierbaren Prozess handelt. Dieser Prozess umfasst drei Ebenen oder Systeme: das SAP Backend, das Portal selbst – also die snapMSV3service Anwendung – und die MSV3-Lieferantenseite. Die Kernkomponente zur Kommunikation zwischen diesen drei Ebenen ist die SAP Cloud Integration (SAP CI), die via SAP Cloud Connector die sichere Verbindung zwischen dem lokalen Kunden-Netzwerk (bei On-Prem) oder der S/4 Hana Cloud Instanz des Kunden und unserer SAP BTP Instanz herstellt. Im SAP Backend des Kunden X werden Bedarfe erzeugt und an das Portal übermittelt. Dort bearbeitet ein Portal-User des Kunden diese Bedarfe – er führt Verfügbarkeitsprüfungen gegen die MSV3 Lieferanten durch und reagiert auf deren Rückmeldungen. Dann beginnt der Bestellprozess mit einer wesentlichen Besonderheit: Es muss eine entsprechende Bestellnummer im SAP erzeugt werden, bevor tatsächlich beim MSV3 Lieferanten bestellt wird, damit diese als Referenz bei der MSV3 Bestellung mitgegeben werden kann.

Neue APIs: Ähnlich, nicht ident

An diesem Prozess namens „eine gemerkte Bestellung im Kunden SAP Backend anlegen/ändern“ (und die entsprechende Bestellnummer unmittelbar zurück erhalten ‒ wir sprechen also von einer strikt synchronen Schnittstelle) zeigt sich exemplarisch, wie sehr sich die „neue“ Cloud-Welt von der „alten“ On-Premises-Welt unterscheidet. Bisher erreichte man das gewünschte Ergebnis mit den für viele „alte Abap-Hasen“ selbsterklärenden Aufrufen BAPI_PO_CREATE1 und BAPI_PO_CHANGE. In der „neuen“ Cloud-Welt werden dafür oData APIs (Version 4) benötigt und die gewünschten Aufgaben mit deren Service-ID „API_PURCHASEORDER_2” (Post oder Patch, möchte man manche Positionen mit Löschvermerk versehen dann auch Delete) erledigt.

Es ist also nicht nur die gewohnte ursprüngliche Funktion nicht mehr vorhanden, es sind auch Syntax und Funktion völlig unterschiedlich. Um die gewünschte Funktionalität zu finden, bietet der Business Accelerator Hub (api.sap.com) zwar einen guten Ersteinstieg (auch direkt mit Beispielen und Testmöglichkeit). Im Detail fehlt es aber an Information – etwa, was welche Eigenschaft macht, oder welcher Wert für eine bestimmte Funktionalität zu setzen ist. Was die neuen APIs leisten, ist also ähnlich, aber bei Weitem nicht ident mit dem Gewohnten.

Erfolgsfaktoren für die Cloud

Nach unseren Erfahrungen mit dem snapMSV3service lassen sich folgende Schlüsselfaktoren für erfolgreiche Cloud-Lösungen zusammenfassen: Der geplante Prozess muss „Cloud-fähig“ sein, also vom SAP Core separierbar und mit dem SAP Core integrierbar sein. Das Thema Integration ist möglichst frühzeitig zu klären. Das Skill-Set der Architekten muss stimmen und die Architektur muss frühzeitig fixiert werden.

Um die neuen Cloud-Schnittstellen zu verstehen, braucht es zudem Fachwissen – etwa über die SAP Integration Suite – das man sich ehestmöglich aneignen sollte.

Um tatsächlich wirtschaftliche Lösungen zu realisieren, ist es notwendig, die BTP-Services und ihre Lizenzierungs-Metriken zu kennen. Und es ist definitiv lohnend, wenn man sich mit den neuen technischen APIs zur Realisierung konkreter fachlicher Aufgaben vertraut macht. Und das besser früher als später.

snapconsult.com

Zum Partnereintrag: