Kategorien
Allgemein

ABAP RESTful Application Programming Model

Das ABAP RESTful Application Programming Model (RAP)  ist das neue Programmiermodel der SAP, um APIs für Fiori-Anwendungen aber auch Web-APIs bereitzustellen.

Im Kontext mit Fiori-Apps handelt es sich hierbei um den Backend-Teil der Anwendung, der die Daten über einen OData-Service bereitstellt und verändert.

Das bestehende ABAP Programming Model for SAP Fiori wird durch das neue Programmiermodell vollständig ersetzt und sollte für Neuentwicklungen nicht mehr verwendet werden.

Ersatz bestehender Frameworks

Das ABAP RESTful Application Programming Model ersetzt, bzw. versteckt einige der bisher verwendeten Frameworks. So verschwindet z.B. das Business Object Processing Framework (BOPF) vollständig von der Bildfläche. 

Der OData-Service wird nicht mehr manuell verwaltet, sondern automatisch generiert. Über die Transaktion SEGW sind die entsprechenden Services dann nicht mehr zu verwalten und zu bearbeiten.

Managed / Unmanaged Szenario

Völlig neue Geschäftsobjekte (Greenfield) können mit dem sogenannten Managed Szenario entwickelt werden. Das Framework übernimmt hierbei die Beschaffung und Verwaltung der Daten des Geschäftsobjektes aus den Datenbanktabellen (CRUD-Operationen). Damit entfällt auch der dafür notwendige Implementierungsaufwand. Auch das Sperren der zu verändernden Objekte wird durch das Framework übernommen.

Im Gegensatz dazu steht das Unmanaged Szenario (Brownfield), das verwendet werden kann, um bestehende Geschäftsobjekte anzubinden. In diesem Fall muss das Daten-Handling zum Geschäftsobjekt durch eigenes Coding sichergestellt werden. Dieses Vorgehen ermöglicht es dann allerdings auch, bestehendes Legacy-Coding (z.B. SAP-BAPIs) für den Zugriff auf die Geschäftsobjekte zu verwenden. 

Draft-Handling

Das Draft-Handling kann für ein Managed Szenario aktiviert werden und ermöglicht das Zwischenspeichern von angelegten, bzw. geänderten Objekten. Im Zusammenhang mit einer Fiori-App erfolgt das Zwischenspeichern des Objektes automatisch mit jeder Feldänderung.

Dieses Verfahren hat den Vorteil, dass Objektänderungen beim Abbruch der App nicht verloren gehen und auch ein Wechsel des Gerätes während der Bearbeitung möglich ist.

Die Daten der Draft-Objekte werden in eigenen Datenbanktabellen gespeichert, die explizit vom Entwickler angelegt werden müssen. und im Wesentlichen den Tabelle des eigentlichen Geschäftsobjektes entsprechen.

Im Kontext mit dem Draft-Handling wird auch ein abweichendes Sperrkonzept verwendet. Während in einer zustandslosen (stateless) App ausschließlich eine optimistische Sperre verwendet wird, kommen hier wieder ausschließliche Sperren über den Sperr-Server zum Einsatz. Diese sind allerdings nicht an die Dialog-Session gebunden, sondern haben ihren eigenen Timeout.

Erweiterungen ABAP-Umgebung

Der Umfang der ABAP-Umgebung wurde wieder einmal erweitert. Im Bereich der Core Data Services (CDS) wurden neue Schlüsselworte und Annotationen bereitgestellt.

Für jedes Geschäftsobjekt kann ein Verhalten (Prüfungen, Initialisierungen, Aktionen) implementiert werden. Im Bereich der Core Data Services wird dafür eine Behavior Definition erstellt. Diese definiert, welches Verhalten für das Geschäftsobjekt zur Verfügung steht und referenziert auf eine ABAP-Klasse, in der die Behavior Implementation erfolgt.

Für den Zugriff auf die Daten der Geschäftsobjekte wurde eine sogenannte Entity Manipulation Language (EML) als Erweiterung des ABAP-Sprachumfanges neu erschaffen.

Über eine Service-Definition wird jetzt definiert, welche Bestandteile und Aktionen eines Geschäftsobjektes im Rahmen dieses Service bereitgestellt werden. Über das Service-Binding werden die Services bereitgestellt, und die Art des Service (SAPUI5 oder Web-API) wird hierbei definiert. Aus dem Service-Binding für einen UI-Service heraus, kann direkt eine automatisch generierte Fiori-Elements-Test-App gestartet werden.

Die Bearbeitung all dieser Objekte ist nur noch über die ABAP Development Tools (ADT) in Eclipse möglich. Über die Development-Workbench der SE80 können nur noch einzelne Teilobjekte (z.B. Klassen, DB-Tabelle) geändert werden.

Struktur im CDS

Für jede Entität des Geschäftsobjektes wird ein Basis-View definiert, der alle Felder und Assoziationen enthält. Darauf aufbauend wird dann noch ein Projektions-View (Consumption View) erstellt, der weitere Annotationen (z.B. Suche, Währungsschlüssel, usw.) enthält. Das Geschäftsobjekt wird dann auf Basis des Projektions-Views aufgebaut.

UI-Annotationen, die zur Steuerung der Anwendungsoberfläche in der App verwendet werden, werden in sogenannte Metdata Extensions ausgelagert, um die vom eigentlichen Datenmodell zu trennen.

Die Objekte, die das Verhalten des Geschäftsobjektes bestimmen, sind ebenfalls in zweigeteilt. Die Verhaltensdefinition bestimmt, welche Prüfungen, Initialisierungen und Aktionen zum Geschäftsobjekt generell zur Verfügung stehen und nimmt hierbei Bezug auf den Basis-View. Die Verhaltens-Projektion bestimmt wiederum, welche Bestandteile (hier auch der CRUD-Operationen) im konkreten Fall bereitgestellt werden – hierbei wird auf den Projektions-View Bezug genommen.

Kategorien
S/4HANA

S/4HANA Migration Cockpit

S/4HANA Migration Cockpit
S/4HANA Migration Cockpit, Übersicht Migrationsobjekte

Einordnung

Das S/4HANA Migration Cockpit ist das von SAP empfohlene Tool zur Datenmigration im Rahmen einer Greenfield-Implementation (Reengineering-Ansatz). SAP liefert bereits einen beachtlichen Umfang an Migrationsobjekten aus. Berücksichtigt werden hierbei allerdings nur Stammdaten und offene Posten. Für die Bereitstellung historischer Daten müssen andere Lösungen gefunden werden.

Die altbekannte Legacy System Migration Workbench (LSMW) existiert zwar auch im S/4HANA noch, allerdings rät SAP von der Verwendung ab und unterstützt das LSMW auch nicht mehr. Nach meiner Einschätzung ist das S/4HANA Migration Cockpit ein brauchbarer Nachfolger.

Mit dem S/4HANA Migration Object Modeler stellt SAP ein Werkzeug bereit, um bestehende Migrationsobjekte anzupassen und eigene Migrationsobjekte zu erstellen.

Datenquellen (Transfer-Optionen)

Excel-Dateien

Die Daten können über Excel-Dateien in die Workbench geladen werden. Der Aufbau der Dateien ist hierbei genau vorgegeben, entsprechende Vorlagen (Templates) können pro Migrationsobjekt direkt aus der Workbench heruntergeladen werden. Die erwarteten Strukturen sind in den Dateien gut dokumentiert. Diese enthalten ggf. mehrere Arbeitsblätter, sofern für das Migrationsobjekt mehrere Tabellen erwartet werden.

Dieses Verfahren eignet sich in der Regel nur für Migrationsobjekte kleineren Umfanges, die eventuell sowieso manuell aufbereitet werden müssen. Wer sich bereits am Massendaten-Handling mit Excel versucht hat, wird wissen warum.

Analog zum LSMW stellt SAP auch hier keine Programme für das ERP-System bereit, um die erforderlichen Daten zu extrahieren. Allerdings gibt es hierfür eine andere smarte Lösung (s.u.).

Staging-Tabellen

Ein zweiter Ansatz ist die Verwendung von sogenannten Staging-Tabellen. Es handelt sich hierbei um Tabellen in der HANA-Datenbank, die durch die Workbench generiert werden. Es ist zu beachten, dass für dieses Szenario ggf. ein eigenes HANA-System benötigt wird. Allerdings können die Staging-Tabellen mittlerweile auch direkt im S/4HANA-Datenbankschema generiert werden.

Diese Tabellen müssen durch externe Tools oder durch ABAP-Coding befüllt werden. Dieser Ansatz eignet sich auch für das Einspielen von Massendaten, allerdings primär aus Drittanbieter-Systemen.

Direct Transfer

Dieser Übernahme-Modus ermöglicht eine direkt Übernahme der Daten aus einem SAP ERP System, dass über eine RFC-Verbindung angebunden wird. Hierfür muss im ERP der Data Migration Server (DMIS) installiert werden, die entsprechende Lizenz ist im S/4HANA enthalten. Die Daten werden dann direkt aus den Tabelle des ERP-Systems gelesen und in die Workbench übernommen.

Die zu selektierenden Daten können über ein vordefiniertes Selektionskriterium eingeschränkt werden. Für das ERP-Szenario ist dies der Buchungskreis. Über den Object Modeler können weitere Einschränkungen je Migrationsobjekt erfolgen, in dieser Fall ist aber die Integrität der Daten selbst sicherzustellen.

Für dieses Szenario hat SAP eigene eigene FIORI-App bereitgestellt, während die anderen beiden Szenarien auf einer Web-Dynpro-Anwendung basieren. Dementsprechend muss auch das FIORI-Launchpad eingerichtet werden.

Funktionalität S/4HANA Migration Cockpit

Bereitstellung der Daten

Entsprechend der oben beschriebenen Transfer-Szenarien werden die Daten für das Cockpit bereitgestellt. Die Daten werden in das Cockpit geladen. Beim Laden der Daten werden bereits erste Prüfungen durchgeführt (z.B. auf Mussfelder).

Werden in der weiteren Verarbeitung Fehler an den Quelldaten festgestellt, können diese nicht im Cockpit selbst korrigiert werden. Die Korrektur muss in den Quelldaten (Excel-Tabelle, Staging-Tabelle, Quellsystem) erfolgen.

Verarbeiten / Mappen

Über ein Mapping (Strukturen und Felder) werden die Daten aus dem übergebenen Quellformat in das für das API (s.u.) benötigte Zielformat konvertiert.

Ein weiterer wesentlicher Punkt ist Werte-Mapping, über das die Schlüssel aus dem Quellsystem in die Schlüssel des Zielsystems konvertiert werden. SAP liefert bereits entsprechende Mapping-Objekte aus, die durch die Lade-Läufe bereits mit 1:1-Wertepaaren gefüllt werden Die Bearbeitung und Bestätigung dieser Zuordnungen ist ein weiterer Schritt im Ladeprozess. Die Mapping-Objekte sind in der Regel objektübergreifend und können daher für alle Migrationsobjekte verwendet werden (z.B. Buchungskreis, Währung, usw.).

Daten laden

Die aufbereiteten Daten werden über API-Funktionsbausteine in das System geladen. Vor dem eigentlichen Laden erfolgt ein Simulationslauf, d.h. das API wird mit den Daten bestückt, diese werden aber am Ende nicht verbucht. Lediglich das Ergebnis der Verarbeitung wird als Meldungen und in Form eines Status bereitgestellt. Damit werden auch Abhängigkeiten zu anderen Objekten geprüft.

Final werden die Daten dann über das API in das System übernommen. Der Lauf kann über Batch-Jobs automatisch parallelisiert werden.

Migrationsprojekte

Alle Aktivitäten innerhalb des Cockpits werden in Projekten organisiert. Innerhalb des Projektes werden dann die relevanten Migrationsobjekte ausgewählt und aktiviert. Bei der Anlage der Projektes muss die Transfer-Option ausgewählt werden, die dann für alle Migrationsobjekte innerhalb des Projektes gilt.

Alle Anpassungen, die an den Migrationsobjekten vorgenommen werden, erfolgen innerhalb des Projektes und nur für dieses Projekt.

Das Projekt kann nach einem erfolgreichen Test exportiert und in ein Folgesystem wieder importiert werden. Dies erfolgt nicht über Transportaufträge, sondern über ein PC-Download/Upload. 

Migration Object Modeler

Der Migration Object Modeler ermöglicht es, bestehende Migrationsobjekte anzupassen und kundeneigene Migrationsobjekte zu erstellen. Als Basis für kundeneigene Migrationsobjekte wird jeweils ein BAPI-Funktionsbaustein benötigt.

Für den Ansatz Direct Transfer sind die Anpassungsmöglichkeiten an bestehenden Migrationsobjekten recht beschränkt. Im Notfall muss auch in diesem Fall ein eigenes Migrationsobjekt erstellt werden.

In der Entwicklung ist zu beachten, dass die Makros und der verwendbare Pseudocode für Coding-basierte Anpassungen seitens SAP nicht dokumentiert ist (Stand April 2020).

Benötigen Sie Unterstützung in Ihrem Migrationsprojekt? Ich würde mich über eine Nachricht oder einen Anruf sehr freuen!

Kategorien
S/4HANA

SAP Geschäftspartner im ERP

SAP Geschäftspartner
SAP-Geschäftspartner-Dialog

Mit S/4HANA bringt SAP das aus anderen Bereichen bereits bekannte Geschäftspartner-Objekt auch für die klassischen ERP-Module FI, MM und SD in Stellung. Lesen Sie eine Zusammenfassung über die Struktur der Geschäftspartners und die möglichen Auswirkungen der Umstellung.

Benötigen Sie Hilfe bei der Analyse oder der Umstellung auf den SAP-Geschäftspartner? Zögern Sie bitte nicht, mich zu kontaktieren: Kontaktdaten.

Umfeld

Der Geschäftspartner ist keine neue Erfindung der SAP. In einigen Modulen (z.B. Banking, Treasury und CRM) wird der Geschäftspartner teilweise schon seit dem Ende der 90er Jahre verwendet.

Für die klassischen ERP-Anwendungen war die Nutzung des Geschäftspartners optional. Der überwiegende Teil der Kunden verwendet hier klassisch die Debitoren- und Kreditorenstammdaten (bzw. Kunden und Lieferanten).

Mit der Umstellung auf S/4HANA wird der Einsatz des Geschäftspartners verpflichtend.

Wesentliche Auswrikungen desssen sind unter anderem:

  • Die klassischen Dialoge für Kunden-/Lieferantenstamm bzw. Debitoren- und Kreditorenstamm entfallen, damit auch die Möglichkeit entsprechender BDC-Schnittstellen (Batch-Input, Call Transaction).
  • User-Exits und BAdIs der bestehenden Transaktionen werden nicht mehr durchlaufen.

Das hat sowohl Auswirkungen auf das Benutzererlebnis, als auch auf ggf. bestehende Kunden-Erweiterungen. Daher ist eine vorbereitende Analyse unerlässlich.

Struktur

Die Pflege der Geschäftspartnerdaten erfolgt über eine zentrale Transaktion (BP). Die Struktur des Geschäftspartners ist deutlich flexibler, als die der Kontokorrent-Stammdaten. So können z.B. mehrere Adressen und Adressverwendungen gepflegt werden. Einige Teilobjekte des Geschäftspartners können auch zeitabhängig verwaltet werden, d.h. sie erhalten einen Gültigkeitszeitraum (z.B. Adressen, Bankverbindungen).

Im Gegenzug verschwinden die bekannten Dialoge für die Pflege der Debitoren- und Kreditoren-Stammdaten. Die Transaktionscodes sind in den neueren S/4HANA-Releases wieder vorhanden, verzweigen jetzt aber in den Geschäftspartner-Dialog.

Geschäftspartner-Typ

Jeder Geschäftspartner wird zu einem der drei Typen:

  • Organisation
  • Person
  • Gruppe

angelegt. Eine nachträgliche Änderung ist auf regulärem Wege nicht vorgesehen. Gruppen vor allem im Banking-Bereich verwendet, z.B. um eine Ehe oder Lebenspartnerschaft abzubilden.

Geschäftspartner-Rollen

Ein Geschäftspartner wird zunächst in einer Basis-Rolle angelegt, die es ermöglicht, die wesentlichen Daten des Geschäftspartners (Name, Adresse, Kontaktdaten, usw.) zu pflegen.

Anschließend kann der Geschäftspartner um Rollen erweitert werden, z.B.:

  • Kunde
  • Debitor
  • Lieferant
  • Kreditor
  • Ansprechpartner

In Abhängigkeit von der jeweiligen Rolle sind dann auch jeweils unterschiedliche Felder des Geschäftspartners verfügbar, d.h. über die Rollen werden u.a. verschiedene Sichten auf den Geschäftspartner abgebildet. Im Bedarfsfall ist auch die entsprechende Organisationseinheit (z.B. Buchungskreis, Vertriebsbereich) anzugeben, für die die Pflege erfolgen soll.

Über die Rolle wird auch bestimmt, ob zu einem Geschäftspartner ein Kunde/Debitor oder Lieferant/Kreditor generiert wird (s.u.).

Geschäftspartner-Beziehungen

Über eine Geschäftspartner-Beziehung können zwei Geschäftspartner miteinander verknüpft werden. So kann ggf. ein ganzes Geschäftspartner-Geflecht aufgebaut werden.

Ein klassisches Beispiel ist die Ansprechpartner-Beziehung, d.h. die Zuordnung einer Person (Ansprechpartner) zu einer Organisation (Unternehmen). Eine Beziehung ist gerichtet (z.B. “hat Ansprechpartner” und “ist Ansprechpartner von”) und jeweils an beiden Geschäftspartnern sichtbar und pflegbar.

An der jeweiligen Beziehung können auch zusätzliche Daten gepflegt werden. Im Falle des Ansprechpartners sind diese sogar relativ umfangreich und im Customizing kann eine eigene Bildsteuerung dazu eingestellt werden.

Zum Beziehungstyp kann auch eingestellt werden, welche Geschäftspartner-Typen über die entsprechende Beziehung miteinander verbunden werden dürfen. Auch kann die maximale Anzahl der Beziehungen zu diesem Beziehungstyp an einem Geschäftspartner eingeschränkt werden.

Customer-Vendor-Integration (CVI)

Verschwinden mit S/4HANA die Kontokorrent-Stammdaten (Debitor/Kreditor)? 

Die Pflege dieser Daten erfolgt in der zentralen Geschäftspartner-Transaktion. Allerdings werden die Daten weiterhin in den altbekannten Tabellen abgelegt (z.B. KNA1, LFA1, usw.), d.h. die Datenbasis bleibt weitgehend erhalten.

Die Synchronisation zwischen den Geschäftsobjekten Geschäftspartner und Debitor/Kreditor erfolgt über eine SAP-interne Schnittstelle, die als Customer-Vendor-Integration (CVI) bezeichnet wird. Die CVI-Schnittstelle existiert bereits im klassischen ERP. Die Synchronisation kann (je nach Konfiguration) in beide Richtungen erfolgen. Eine Änderungs des Geschäftspartners wird dann in die Debitoren-/Kreditorenkonten durchgereicht und umgekehrt.

Über die Ansprechpartner-Beziehungen (s.o.) werden auch die Ansprechpartner-Daten zu den Debitoren- und Kreditoren aufgebaut. Auch dieser Teil der Schnittstelle arbeitet bidirektional.

Auf welchen Geschäftsobjekten arbeiten zukünftig die Anwendungen SAP MM (Materialwirtschaft) und SAP SD (Vertrieb)?

In diesem Bereich ergeben sich keine bahnbrechenden Änderungen, d.h. der Kundenauftrag wird weiterhin zum Kundenstamm angelegt und die Bestellung weiterhin zum Lieferanten. Der Geschäftspartner spielt in diesen Anwendungen (auch im S/4HANA) aktuell keine Rolle. Ob sich dies langfristig ändern wird ist aus meiner Sicht offen, denn mit dem aktuellen Zustand lässt sich die Flexibilität der Geschäftspartner in diesen Anwendungen nicht nutzen.

Business Data Toolset (BDT)

Des gesamte Geschäftspartner-Dialog im Backend baut auf dem sehr flexiblen Business Data Toolset (BDT) auf. Dieses Dialog-Framework ermöglicht es, modifikationsfrei eigene Bilder, Abschnitte oder Sichten (über das Einbinden von Subscreens) im Geschäftspartner-Dialog zu implementieren.

Neben der Steuerung zum Bildaufbau existiert u.a. auch eine Zeitpunkt-Steuerung. Diese ermöglicht es eigene Funktionsbausteine einzuhängen, die zu vordefinierten Zeitpunkten aufgerufen werden. Über diese Funktionsbausteine gelingt es, den eigenen Dialog nahtlos in den bestehenden SAP-Dialog einzubinden. Dia Abbildung erfolgt hierbei über eine Funktionsgruppe.

Grundsätzlich wird zwischen partizipierenden Anwendungen und besitzenden Anwendungen unterschieden. Die partizipierenden Anwendungen erweitern z.B. SAP-Standardtabellen um eigene Felder. Das Lesen und die Speicherung dieser Daten wird durch die bereits existierende BDT-Umgebung sichergestellt. Besitzende Anwendungen binden z.B. eigene Tabellen in den Geschäftspartner-Dialog ein. Hier muss sich die eigene Anwendung auch um das Lesen und Speichern das Daten kümmern.

ERP-Konvertierung S/4HANA

Geschäftspartner im Gesamtprojekt

Grundsätzlich empfehle ich, die Umstellung auf den SAP-Geschäftspartner weit vor der S/4HANA-Umstellung durchzuführen, denn alle erforderlichen Komponenten existieren aktuell bereits im ERP. Daraus ergeben sich folgende Vorteile:

  • Die Umstellung wird von der ebenfalls komplexen S/4HANA-Umstellung zeitlich, fachlich und technisch entkoppelt.
  • Die erforderliche Abschaltzeit für die S/4HANA-Konvertierung kann ggf. erheblich verkürzt werden.
  • Die Anwender können sich bereits im Vorfeld an das neue Geschäftsobjekt und ggf. neue Prozesse gewöhnen. Dieser Punkt fällt dann nicht mit den Änderungen zusammen, die durch die S/4HANA-Einführung ergeben.

Einmalige Umsetzung

Nachdem die Customer-Vendor-Integration (CVI) konfiguriert wurde, werden in einem einmaligen Massenlauf die Geschäftspartner aus Debitoren- und Kreditorenstammdaten generiert. Ziel ist hierbei, dass die Geschäftspartner unter denselben Nummern geführt werden, wie der Kontokorrent-Stammdaten. Das ist allerdings nur umsetzbar, wenn sich zwischen den verwendeten Debitoren- und Kreditorennummern keine Überschneidungen ergeben.

Eine Systemkonvertierung des SAP-ERP in ein SAP-S/4HANA-System kann nur erfolgen, wenn die Geschäftspartner-Generierung vollständig abgeschlossen wurde.

Komplexe Systemlandschaften

Besondere Herausforderungen ergeben sich, wenn an das ERP-System ein CRM-System angeschlossen ist, Personalstammdaten verwendet werden oder Lieferantenstammdaten für Mitarbeiter geführt werden.

Hierdurch ergeben sich zusätzliche Schritte für die Umsetzung des Systems, bzw. das Vorgehen muss gegenüber der Standard-Strategie vollständig angepasst werden.