Enterprise Resource Planning trifft auf Cloud

You know what the common theme is? If it’s in the best interest of the customer, you should do it.“ Mit diesen Worten umschrieb Bill McDermott, zu diesem Zeitpunkt CEO of SAP America, die Allianz zwischen Microsoft und dem „Coopetitor“ sowie gleichzeitigen Partner SAP [1]. Damals erwähnte er das ­gemeinsame Produkt Duet Enterprise, das ­eine enge Verzahnung zwischen Microsoft-Tools und dem SAP-Backend mit den Geschäftsprozessen ermöglicht. Elf Jahre später wurde diese Allianz und Partnerschaft mit der Em­brace-Initiative erneuert, indem Microsoft Azure als präferierte Public Cloud von SAP ausgewählt wurde [2]. Die Zielsetzung dieser gemeinsamen Embrace-Initiative ist die beschleunigte und vereinfachte Adaption von S/4HANA sowie der SAP Cloud Platform auf Azure bei gemeinsamen Kunden.

S/4HANA ist der Nachfolger der SAP Business Suite (ECC) und somit das SAP-ERP (Enterprise Resource Planning) der nächsten Generation. Technologisch werden die S/4HANA-Systeme auf Azure mit virtuellen Maschinen und software­definierten Infrastrukturkomponenten wie virtuellen Netzwerken bereitgestellt. Daher ist SAP on Azure im Kontext der Infrastructure as a Service (IaaS) einzuordnen.

Neben den SAP-Netweaver-Applikationsservern wird SAP S/4HANA ausschließlich mit der In-Memory-Datenbank SAP HANA betrieben. Selbst bei mittlerer Größe der SAP-Systeme sind HANA-Server mit mehreren Terabyte Hauptspeicher (RAM) die Regel. Neben den Vorteilen von S/4HANA wie der schnellen Verarbeitung von Massendaten für Analysen und Transaktionen in Realtime sowie vereinfachten Geschäftsprozessen steht die Migration von SAP ECC auf S/4HANA auch wegen des auslaufenden Standardsupports bis 2027 ganz oben auf Prioritätenliste vieler CIOs.

Somit stehen Kunden vor der Entscheidung, ob in HANA-Hardware in eigenen Rechenzentren investiert werden soll oder ob sie die Skalierbarkeit, Flexibilität und permanenten Innovationen einer Public Cloud für den Betrieb von SAP S/4HANA nutzen sollen. Unter den Public-Cloud-Anbietern ist Microsoft Azure mittlerweile führend in Bezug auf die Anzahl der für SAP HANA von SAP zertifizierten virtuellen Maschinen (VMs). Aktuell stehen zertifizierte VMs mit bis zu 12 TB RAM für das Deployment von HANA auf Microsoft ­Azure zur Verfügung. Somit können auch größere SAP-HANA-Systeme auf Azure migriert und dort betrieben werden [3].

Neben der vereinfachten und beschleunigten Migration von SAP S/4HANA auf Microsoft Azure ist die SAP Cloud Platform (SCP) on Azure der zweite technologische Baustein der Em­brace-Initiative. Die SAP Cloud Platform, basierend auf Cloud Foundry, kann von SAP-Kunden auf Microsoft Azure provisio­niert und genutzt werden. Als PaaS-Platform liegt der Fokus der SCP, speziell im Kontext von S/4HANA-Projekten, auf der Erweiterung von bestehenden SAP-Applikationen mit Entwicklertools wie dem SAP Business Application Studio [4] und auf der Integration von Applikationen durch Integrationswerkzeuge wie der SAP SCP Cloud Integration Suite.

Im Rahmen der Embrace-Initiative wurden gemeinsam mit Kunden neue Referenzarchitekturen beziehungsweise Use-Cases entwickelt. Gemeinsam haben diese Referenzarchitekturen ausgewählte Integrationsszenarien bestehend aus Microsoft Azure und SAP-SCP-Services. Die Referenzarchitekturen können als Vorlagen für Architekten und Entwickler für erste Integrationsszenarien genutzt oder erweitert werden.

Folgende Use-Cases wurden detailliert als Referenzarchitekturen ausgearbeitet:

Die letzte Referenzarchitektur ist besonders für Entwickler und Teams mit gemischtem SAP-Cloud-Platform- und Azure-Know-how eine wertvolle Vorlage. Hier bietet die SAP Cloud Platform die Möglichkeit, über die Cloud-Foundry-Umgebung und den dazugehörigen Open Service Broker Anwendungen zu entwickeln, die Azure-Services integrieren.

Aktuell können folgende Services über den Open Service Broker eingebunden werden:

Neben der Referenzarchitektur bieten ein Tutorial [5] sowie eine SAP Cloud Platform Developer Mission [6] die Möglichkeit, Wissen zu vertiefen und erste Erfahrungen zu sammeln.

Ein weiteres Beispiel für die Integration von SAP-Cloud-Platform-Workflows mit Office 365 findet man in dem Blogbeitrag von Harald Schubert. Dieses Integrationsszenario beschreibt die native Integration von SAP-Workflow-Aufgaben und -Prozessen in Office 365, siehe Bild 1. Beispielhaft kann der SAP-Nutzer Bestellungen in Outlook 365 annehmen oder ablehnen, ohne das Tool zu verlassen [7]. Wie in dem Blog beschrieben, wird die enge Integration von SAP-Workflows und Outlook über den Einsatz einer Kombination von Outlook Actionable Messages und Adaptive Card erreicht.

Die Beschreibung in dem Blog zum Ablauf der Anwendung gibt einen detaillierten Einblick in das Zusammenspiel von Office 365 mit der SAP Cloud Platform:

Zusammengefasst ist es für Benutzer so möglich, einen SAP-Cloud-Platform-Workflow innerhalb der eigenen Outlook-Inbox zu bestätigen oder abzulehnen. Das sorgt für eine nahtlose Integration zwischen Frontend- beziehungsweise Office-Tools und dem SAP-Backend.

Neben der Integration in Outlook ist die Integration in Microsoft Teams eine weitere Variante der möglichen Szena­rien, die häufig von Kunden und Partnern angefragt wird. Auch hier bieten Adaptive Cards eine ansprechende und einheitliche Möglichkeit zur Darstellung von SAP-Daten bis hin zu SAP-Produktdatenblättern in Microsoft Teams. Dieses Szenario wird in Teil 2 dieser Artikelreihe ausgeführt.

Für Entwickler stellt sich die Frage, wie man erste Erfahrungen mit SAP-Systemen sammeln kann, ohne mit dem unternehmenskritischen ERP arbeiten zu müssen. Teilweise sind hier schon die Berechtigungen für den Zugriff auf Entwicklungssysteme und entsprechende Konfigurationen für externe Zugriffe eine Herausforderung. Dies gilt auch für die benötigten Kenntnisse der ABAP-Programmiersprache sowie des Netweaver Stack. Für diese Fälle bieten sich folgende Möglichkeiten an, um erste Demos mit SAP zu entwickeln:

Somit bieten sich für Entwickler viele Möglichkeiten und Szenarien, um erste Erfahrungen mit der Integration von SAP-Systemen in Azure zu machen, ohne User oder Zugriffe für die internen SAP-Systeme beantragen oder überhaupt interne SAP-Systeme betreiben zu müssen.

Weiterhin erlauben die RESTful-HTTP-APIs und OData nun einen sehr einfachen und offenen Zugriff auf die wichtigsten SAP-Prozesse und Daten, wie im nächsten Abschnitt gezeigt wird. Moderne, auf Cloud Foundry und PaaS-Services basierende Entwicklungsumgebungen ermöglichen die einfache Integration von Azure-Services mit SAP-zentrischen Anwendungen über den Open Service Broker. Weiterhin bieten Referenzarchitekturen klare Vorlagen für Integrationsszenarien bis hin zu dem gezeigten Beispiel der nativen Integration von SAP-Cloud-Platform-Prozessen in Office 365.

Für die Kommunikation mit SAP Business Suite und SAP S/4HANA stehen verschiedene Technologien zur Auswahl, die je nach Anforderungen ihre Berechtigung haben. Einige dieser Technologien sind bereits älter (und bewährter), einige sind neuer. Glücklicherweise funktionieren auch die älteren Technologien mit S/4HANA, sodass auch bestehende Schnittstellen weiterhin in gleicher Weise angebunden werden können. Daneben existieren nun auch neuere Technologien, um SAP-Systeme wesentlich einfacher anzubinden.

Dieses Kapitel betrachtet sowohl die älteren Möglichkeiten des RFC-Protokolls als auch die neueren mit OData-Services. Der Vollständigkeit halber sei gesagt, dass man auch auf folgende Arten auf SAP-Systeme zugreifen kann:

Bisher wurde der Datenaustausch mit SAP Business Suite sowohl ein- als auch ausgehend vor allem mit dem RFC-Protokoll (Remote Function Call) hergestellt.

Obwohl im vergangenen Jahrzehnt SOAP und REST immer beliebter wurden, ist die RFC-Technologie nach wie vor stark im Einsatz, da sie klar definierte Schnittstellen liefert und ein Built-in Monitoring in SAP selbst unterstützt. Der Austausch mit RFC kann so stattfinden:

Als kleiner Vergleich, um es greifbarer zu machen: IDoc lässt sich vereinfacht mit einer transaktionalen Nachrichtenübergabe als HTTP-POST vergleichen, ein Funktionsbaustein mit einem Methodenaufruf. Beide Technologien, IDoc und Funktionsbaustein, sind transaktionssicher und dem zuvor üblichen Dateiaustausch weit überlegen.

Für den Zugriff aus Azure mit RFC auf Business Suite oder S/4HANA sind folgende Komponenten grundlegend:

In Teil 3 dieser Artikelserie werden wir in einer Demo zeigen, wie genau mit diesen drei Komponenten ein Dynamics CRM (der neue Name ist übrigens „Dynamics 365 Customer Engagement“) und die SAP Business Suite miteinander verbunden werden können.

Betrachtet man den Weg aus SAP heraus, kann eine Mischform der Legacy- und der modernen Technologien benutzt werden: IDocs können nicht nur an Logic Apps verschickt werden, sondern auch über HTTP und damit an jeden beliebigen Service-Endpunkt: Dies könnte eine Logic App sein, aber natürlich auch eine Azure Function oder eine Web-App.

Stark zu empfehlen ist hier:

Microsoft und SAP haben das Thema OData (Open Data Protocol) in den letzten Jahren massiv vorangetrieben. Dank OData-Konventionen kann man strukturiert und einheitlich REST-Services aufrufen und ähnlich einem Datenbank-Select auf Entitäten zugreifen. Einen praktischen Schnellstart ins Thema gewinnen Sie mit dem Northwind-Service auf Odata.org [19].

SAP Graph [8] erlaubt den Zugriff auf alle Kernprozesse in S/4HANA mit OData. Im Hintergrund stellen hier REST-Services per OData Stammdaten aus SAP bereit. Das heißt, dass für das Lesen von Stammdaten weder ein Funktionsbaustein noch ein extra SOAP-Service nötig sind, sondern direkt mit OData auf die Entitäten zugegriffen werden kann.

Auch in der Azure-Komponente Azure Data Factory wird das benutzt, mit welcher man sogar direkt auf Tabellen in SAP zugreifen kann. Diese bieten RFC und eben OData an; Letzteres ist dann perfekt, wenn man nicht große Workloads, sondern nur Deltas lesen möchte.

OData kann natürlich in S/4HANA mithilfe des NetWeaver Gateway [20], aber auch schon in SAP Business Suite bereitgestellt werden. Dort können zum Beispiel auch Funk­tions­bausteine als OData freigegeben werden, wie man in der Anleitung [21] sehen kann.

Zum Thema Sicherheit: Der Zugriff auf SAP-Systeme via OData, also über HTTP, muss natürlich entsprechend gut geschützt werden – egal ob das SAP on-premise liegt oder in der Cloud. Firewall-Einschränkungen im Zugriff auf den Service-Endpunkt sind ein Muss; diese werden für SAP on Azure in der Network Security Group (NSG) konfiguriert. Der Schutz muss aber weiter reichen, da es sich bei dem SAP-System ja um eines der wichtigsten in einem Unternehmen handelt. Eine starke Authentifizierung oder ein Application Proxy sind nötig:

Wie kann aber SAP aktiv mit neuen Technologien Daten verschicken? Zum einen können in SAP mit ABAP und Java eigene Services aufgerufen werden. Es kann allerdings auch das sogenannte ABAP SDK for Azure [22] benutzt werden, mit dem in ABAP sehr einfach verschiedene Azure-Komponenten wie Event Hub, Service Bus, Active Directory oder Log Analytics angebunden werden können. So können Azure-­Komponenten einfach aufgerufen werden.

Auch hier gilt, dass SAP-ausgehend OAuth oder Clientzertifikate eingesetzt werden können, um eine starke Authentifizierung zu ermöglich. Ein guter Business Case ist die Analyse der SAP-Geschäftsprozesse, um zu sehen, wie in SAP die Prozesse und Daten laufen. Ein Showcase von Microsoft beschreibt das ganz gut [23].

Eine weitere Möglichkeit zur Erstellung von eigenen Applikationen mit Anbindung an SAP-Systeme bieten die Micro­soft Power Apps. Mit diesem visuellen Werkzeug können Low-Code-Apps durch Power-User und Citizen Developer im Unternehmen erstellt werden. Neben der visuellen Entwicklungsumgebung für Power-User bieten Power Apps die einfache Datenanbindung von über 200 standardisierten Geschäftsentitäten durch Nutzung der Common Data Services (CDS, [24]). Dieses einheitliche CDS-Datenmodell modelliert Entitäten wie Accounts und bietet Datenmodelle für Domänen wie Sales, Finance und Commerce und ermöglicht so die einfache Anbindung von vordefinierten Datenmodellen an eigene Applikationen.

Neben der Möglichkeit für Citizen Developer, eigene Low-Code-Anwendungen zu erstellen, unterstützt der Power Automate Service die Erstellung von automatisierten Workflows und zur Prozessautomatisierung sogenannter Flows. Typische Beispiele für Workflows sind die Synchronisierung von Daten, das Erhalten von Notifikationen und das Sammeln von Daten. Power Automate unterscheidet zwischen folgenden Typen von Flows:

Mit UI Flows können RPA-Funktionalitäten (Robotic Process Automation) mit Power Automate kombiniert werden. Erreicht wird dies durch die Aufzeichnung (Recording) von Benutzerinteraktionen mit vornehmlich Legacy-Anwendern ­ohne moderne APIs. Insgesamt bieten Power Apps über 150 Konnektoren [25] für die Erstellung von Anwendungen. Die verfügbaren Konnektoren decken eine große Vielfalt von APIs und Herstellern wie ServiceNow, Workday, Teradata oder die Corda-Blockchain ab.

Für die Anbindung von SAP-Systemen bieten Power Apps und Automate einen dezidierten SAP-ECC-Konnektor (Bild 3) basierend auf dem SAP .NET Connector SDK von SAP [26]. Ebenfalls nötig ist das sogenannte On-Premise Data Gateway, um eine Verbindung zu den SAP-Systemen ­herzustellen.

Zur Authentifizierung der Benutzer kann die Windows- oder SAP-Anmeldung verwendet werden.

Die unterstützten SAP-Schnittstellen sind BAPI (Business Application Programming Interface) und RFCs inklusive der Bereitstellung von dynamischen Schemata zur Übermittlung von Ein- und Ausgabeparametern.

Neben den Aufrufen von BAPIs und RFCs besteht zusätzlich die Möglichkeit, SAP-Systeme über OData anzubinden. Für die Anbindung von SAP mit OData an Power Apps wurde auf GitHub [27] ein beispielhafter SAP OData Connector mit einer Power-App-Anwendung bereitgestellt. Die Power App verbindet sich mit dem öffentlichen SAP-Gateway-Demo-System.

Die Funktionalität der Power Apps umfasst klassische CRUD-Operationen wie die Anzeige, Änderung und Anlage von Produktdaten. Auf Basis dieser Anleitung können Entwickler erste Ideen und Einblicke erhalten, wie OData-basierte SAP-APIs wie der SAP-Graph oder SAP API Business Hub mit Power Apps kombiniert werden können.

Ein weiteres Anwendungsbeispiel für Power Apps im Kontext des Betriebs von SAP auf virtuellen Azure-Maschinen wurde von Microsoft auf GitHub bereitgestellt.

Das Beispiel demonstriert einen Paradigmenwechsel beim Betrieb von SAP-Entwicklungssystemen innerhalb der Micro­soft-IT. Anstatt SAP-Entwicklungssysteme permanent 24/7 zu betreiben, also die Entwicklungssysteme always-on zu belassen, werden Entwicklungssysteme nun zunächst immer heruntergefahren – sind also always-off. Mithilfe der Power App SAPSnooze können nun die SAP-Entwickler bei Micro­soft die Entwicklungssysteme auf Knopfdruck hochfahren. Nach einem definierten Zeitraum im ungenutzten Zustand werden die Systeme auch wieder heruntergefahren.

In Summe ermöglicht diese App Einsparungen durch die Kombination der Power App und der stundengenauen Abrechnung der Systemnutzung über das Pay-as-you-Go-Abrechnungsmodell von Azure [28].

Hiermit ist der Grundstein für eine Beschäftigung mit SAP gelegt. Im zweiten Teil der Artikelserie beschreiben wir beispielhaft an Dynamics 365, wie man mit Logic Apps in Realtime Stammdaten an eine SAP Business Suite übergeben kann. In Teil 3 werden wir einen Chatbot für Microsoft Teams bauen, der mit einem S/4HANA kommuniziert.