SAP und .NET 12.10.2020, 00:00 Uhr

Zwei Konkurrenten an einem Strang

Wie die Zusammenarbeit zwischen SAP- und Microsoft-Systemen funktioniert.
(Quelle: Autor)
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.

Das ist S/4HANA

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].

Das ist SCP

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.

SCP-Referenzarchitekturen

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:
  • SAP S/4HANA um SAP- und Microsoft-Services erweitern,
  • Business Process Integration zwischen SAP und Microsoft vereinfachen,
  • Prozesse zwischen SAP und Microsoft automatisieren,
  • Identity und Authentication Workflows zwischen SAP und Microsoft einrichten,
  • Microsoft-Azure-Services in der SAP Cloud Platform konsumieren.
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:
  • Azure CosmosDB
  • Azure SQL Database
  • Azure Database for MySQL
  • Azure Database for PostgreSQL
  • Azure Redis Cache
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.

SAP Cloud Platform Workflows

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.
Das Zusammenspiel von Office 365 mit der SAP Cloud Platform (Bild 1)
Quelle: Autor
Die Beschreibung in dem Blog zum Ablauf der Anwendung gibt einen detaillierten Einblick in das Zusammenspiel von Office 365 mit der SAP Cloud Platform:
  • Eine eigenentwickelte Java-Anwendung überprüft periodisch, ob neue Aufgaben in der SAP-Cloud-Platform-Workflow-Komponente angelegt wurden.
  • Für jede neue Aufgabe und deren Kontext wird eine Micro­soft Outlook Actionable Message im Adaptive-Card-Format angelegt.
  • Diese Microsoft Actionable Message wird über den angebundenen Mailserver an die Empfänger übermittelt.
  • Alle Empfänger erhalten eine Mail mit der zugewiesenen Aufgabe und können entsprechend Tasks annehmen oder ablehnen.
  • Bei der Verarbeitung des Tasks findet ein Callback von Office 365 in Richtung der Java-Anwendung statt.
  • Die Custom-Java-App erhält den Callback, überprüft die Authentifizierung und Gültigkeit der Anforderung und führt die Aufgabe im SAP-Cloud-Platform-Workflow aus.
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.

Zugriff auf Daten und Entwicklungssysteme

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:
  • SAP Graph: Aktuell noch im Beta-Stadium, bietet SAP Graph RESTful-HTTP-APIs über mehrere SAP-Systeme hinweg. Diese APIs ermöglichen den Konsum von Daten zu SAP-Kerngeschäftsprozessen wie Lead To Cash, Source to Pay, Recruit to Retire und den dazugehörigen Business-Entitäten. Hervorzuheben ist, dass keine tiefergehenden SAP-Kenntnisse nötig sind, um die APIs zu konsumieren [8].
  • SAP API Business Hub: Neben SAP Graph bietet der SAP API Business Hub Entwicklern die Möglichkeit, in einem zentralen Katalog nach APIs von SAP und selektierten Partnern zu suchen. Der SAP API Business Hub stellt APIs über eine Reihe von Line-of-Business-Applikationen zur Verfügung, während SAP Graph kuratierte und vereinheitlichte APIs zu den Kernprozessen des SAP Intelligent Enterprise aufführt. Interessant für Entwickler ist hier, die Code-Snippets und die APIs in Sandboxes ausprobieren zu können [9].
  • SAP Gateway Demo System: Das Public SAP Gateway Demo System bietet eine Umgebung, um erste Showcases und Demos zu bauen. Dafür stellt es verschiedene SAP-zentrische Datenmodelle für die Verwendung von OData-Services bereit. Grundsätzlich vermittelt dies einen guten Eindruck davon, wie durch SAP exponierte OData-Services konsumiert und verwendet werden können [10] [11].
  • SAP S/4HANA Fully-Activated Appliance: Falls die Anforderung besteht, mit einem voll ausgebauten S/4HANA-System erste Prototypen oder Demos umzusetzen, besteht die Möglichkeit, die SAP Cloud Appliance Library einzusetzen. Innerhalb der SAP CAL können Sie ein vorkonfiguriertes und mit Demodaten befülltes S/4HANA-System auf Knopfdruck auf Azure bereitstellen. Zu beachten ist, dass die Trial-­Lizenzen zur Nutzung der SAP S/4HANA Fully-Activated Appliance nach 30 Tagen auslaufen [12].
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.

Programmatischer Zugriff auf S/4HANA und Business Suite

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:
  • mit dem SAP Connector for .NET [13], um über .NET-Bibliotheken direkt auf SAP-Systeme zuzugreifen,
  • mit Middleware-Plattformen wie Microsoft BizTalk, der SQL-Erweiterung SSIS oder SAP Process Orchestration (SAP PO), um mit Adaptern auf SAP-Systeme zuzugreifen,
  • mit der SAP Cloud Platform Integration (SAP CPI), um aus der SAP-Cloud auf SAP-Systeme zuzugreifen.

Datenaustausch mit RFC

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:
  • Versand von IDoc-Nachrichten,
  • Empfang von IDoc-Nachrichten,
  • Aufruf von Funktionsbausteinen, entweder zur Übergabe oder zum Einholen von Informationen.
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:
  • Die Logic Apps bieten über 300 Konnektoren zu verschiedenen Systemen, neben Dynamics, Salesforce, Trello und vielen mehr auch zu SAP. Die Logic Apps sind eine wichtige Komponente der sogenannten Azure Integration Services [14], welche sich im Azure-Kosmos um die Enterprise-Integration kümmern. Mit dem sogenannten Enterprise Connector für SAP lassen sich IDocs empfangen und verschicken und Funktionsbausteine aufrufen. Hierbei kommt das On-Premises Data Gateway (OPDG) zum Einsatz. Ein Showcase von Derek Li, Microsoft, zeigt dies, indem eine Logic App ein IDoc entgegennimmt und dann einen Funktionsbaustein aufruft und so beispielhaft ein E-Commerce-System an SAP anbindet ([15], Minute 11:30).
  • Das On-Premises Data Gateway (OPDG) stellt die Verbindung zwischen Logic Apps, die serverless laufen, und SAP-Systemen her, die on-premises liegen können oder auf einer VM in einer Cloud. Das OPDG wird im selben VNET wie das SAP-System auf einem Windows-Server installiert. Es öffnet einen Outbound Socket und verbindet sich darüber aktiv mit der Logic App und kann von dieser danach aufgerufen werden. So gibt es keinen öffentlichen Endpunkt, der angegriffen werden könnte, sondern das im VNET installierte OPDG entscheidet über den Aufbau der Verbindung. Um IDocs aus dem SAP-System entgegenzunehmen, muss im OPDG eine Programm-ID bereitgestellt werden. Das OPDG kann übrigens neben SAP-Systemen auch noch SQL und FILE übertragen und eignet sich so sehr gut für Verbindungen aus Azure ins eigene Rechenzentrum [16].
  • Der Integration Account ist eine Logic-App-Erweiterung, die Mappings und Schemas bereitstellt. Da IDocs und Funk­tionsbausteine oft verschachtelte Schemas nutzen, sind es entsprechend auch die Datenmappings zu den Schnittstellen der Nicht-SAP-Systeme. Diese Datenmappings können als XSLT programmiert werden und in dem Integration Account abgelegt werden, nachdem man sie händisch oder mit einem Tool wie der Visual-Studio-Erweiterung für BizTalk-Projekte erstellt hat. Seit April 2020 können die SAP-Schemas mit der Transaktion WE60 direkt aus dem SAP-System übernommen werden.
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:
  • der Einsatz von API Managements in Azure [17] oder der SAP Cloud Platform [18], um den Service optimal bereitzustellen,
  • die Nutzung des Integration Account für komplexe Mappings,
  • das Einfordern einer starken Authentifizierung mit OAuth oder Clientzertifikat.

Datenabruf mit OData-Services

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:
  • Die Logic Apps können sich mit OAuth oder Clientzertifikaten direkt an den SAP-Services authentifizieren, was bedingt, dass im SAP-System die Services publiziert werden und die Authentifizierung unterstützt wird.
  • Ein Application Proxy Service wird benutzt, um die Verbindung aus dem VNET selbst zu starten, siehe Bild 2. Wie beim oben beschriebenen OPDG wird auch hier eine Komponente, der Application Proxy Connector, lokal im selben VNET wie das SAP-System installiert und öffnet eine Verbindung zum Application Proxy Service, der die Authentifizierung an das Azure AD delegiert. Über diesen Kanal können dann die Calls an das SAP gelangen. Vorteil hierbei ist, dass innerhalb des VNET keine starke Authentifizierung mehr nötig ist und das SAP-System damit nicht erweitert werden muss. Außerdem stellt SAP in diesem Szenario keinen öffentlichen Endpunkt bereit, der attackiert werden kann. Bedingung zur Nutzung des Application Proxy Service ist eine Azure-AD-D2-Lizenz.
Der Application Proxy Service ermöglicht die Authentifizierung an SAP Business Suite und SAP S/4HANA (Bild 2)
Quelle: Autor

Datenversand mit ABAP SDK

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].

Datenzugriff mit Power Plattform

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:
  • Automated Flows werden durch ein Ereignis ausgelöst und führen eine oder mehrere Aufgaben aus.
  • Button Flows: Repetitive Aufgaben können mit diesen Flows jederzeit durch ein mobiles Endgerät ausgeführt werden.
  • Scheduled Flows: Eine oder mehrere Aufgaben werden eingeplant.
  • Business Process Flows: Die Erstellung von Business-Workflows ermöglicht es, mehrere Mitarbeiter durch vereinheitlichte Prozesse mit konsistenter Dateneingabe zu leiten.
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.
Solution Architecture von Power Apps und SAP ECC (Bild 3)
Quelle: Bild: Microsoft-Blog [27]
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.
Anzeigen von SAP-Produktdaten in einer Power App (Bild 4)
Quelle: Autor
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].

Ausblick

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.
Dokumente
Artikel als PDF herunterladen


Das könnte Sie auch interessieren