Investitionsschutz durch Übernahme in das S/4HANA

Custom Code Migration

Jedes Unternehmen stellt sich bei der Umstellung der Systemlandschaft auf S/4HANA die Frage: „Wie gehe ich mit meinen bestehenden Eigenentwicklungen um?“ Die Umstellung bietet eine sehr gute Gelegenheit, sich von „alten Zöpfen“ zu trennen, jedoch die relevanten Anpassungen in die neue Umgebung zu überführen.
Diese Überführung der Eigenentwicklungen nach S/4HANA wird „Custom Code Migration“ (CCM) genannt. Ziel der Custom Code Migration ist es, die benötigten Erweiterungen im neuen S/4HANA-System in mindestens gewohnter Qualität bereitzustellen. Hierbei wird dringend empfohlen, die Erweiterungen in Bezug auf Wartbarkeit sowie Usability zu prüfen und zu bewerten. Bei Erweiterungen, die von den Anwendern als benutzerunfreundlich oder aus technischer Sicht als wartungsintensiv bewertet werden, sollte geprüft werden, inwieweit ein Kosten- / Nutzenaufwand eine Neuimplementierung auf dem aktuellen Stand der Technik in Frage kommt.

Vorgehen

Die Custom Code Migration startet bereits in verschiedenen Vorprojekten
und Verfahrensänderungen lange vor dem eigentlichen Projektstart.

Vorbereitungsphase

Die Vorbereitungsphase beginnt bereits mit wesentlichen Aufgaben und Umsetzungen vor dem eigentlichen Hauptprojekt und dient dazu, Prozesse und Vorgehen anzupassen sowie geeignete Maßnahmen zu treffen, um eine effiziente, erfolgreiche Custom Code Migration zu gewährleisten.

Da das Hauptprojekt über mehrere Jahre Laufzeit angelegt ist, muss sichergestellt werden, dass sowohl der Anwendungsbetrieb wie auch die Wartung und benötigte Anpassungen fortgeführt werden. Aus diesem Grund werden verschiedene organisatorische Maßnahmen und bei den Eigenentwicklungen, Prozessanpassungen vorgenommen.

Anpassung der QS-Maßnahmen

Die Eigenentwicklungen werden auch während des S4-Projektes fortgesetzt und erst in der finalen Phase des Projektes, zur Frozen-Zone, gestoppt.

Die Softwareentwicklung sollte zwingend im Vorfeld der Migration auf S4-Ready Entwicklung umgestellt werden. Hierdurch wird sichergestellt, dass alle Anpassungen und Neuentwicklungen S4-Ready sind. Dies schützt die Investitionskosten und reduziert den späteren Migrationsaufwand.

Hierzu wird aktuell der Entwicklungsleitfaden auf S4-Ready Coding angepasst. Um die korrekte Umsetzung des Leitfadens sicherzustellen, werden technische Maßnahmen, wie der ATC-Check (siehe Abschnitt 2.1.2) eingesetzt. Bei dem ATC-Check (ABAP Test Cockpit) handelt es sich um eine technische Unterstützung, um den Quellcode (ABAP) auf die Umsetzungsqualität zu prüfen und bei Nichteinhalten der Richtlinien den Transport z.B. in das Produktionssystem zu verweigern.

Über einen zentralen Ansprechpartner werden sowohl die Qualitätsstandards sichergestellt und angepasst wie auch benötigte Ausnahmen hiervon genehmigt und protokolliert. Dieser Ansprechpartner sollte Teil des S4-Projektteams sein und sowohl der Entwicklungsleitung wie auch der Projektleitung reporten.

Die Sourcecode Anpassungen und Erweiterungen werden immer von einem internen Mitarbeiter oder hier-für ausgewählten Dritten nach dem 4-Augenprinzip geprüft und abgenommen. Die Überprüfung dient dazu, die Einhaltung des Entwicklungsleitfadens und den Wissenstransfer sicherzustellen.

Verwendungsnachweis

Das bestehende ECC-System wurde in den vergangenen Jahren immer weiter an die Bedürfnisse des BLBs angepasst. Dabei kommt es erfahrungsgemäß dazu, dass sich über die Jahre auch nicht mehr benötigte Entwicklungen im System befinden.

Innerhalb der S4-Umstellung sollten jedoch nur Erweiterungen übernommen werden, die noch in Verwendung sind, bzw. auch zukünftig weiterverwendet werden sollen. Daher sollte im Vorfeld ein Verwendungsnachweis erstellt werden.

Dieser Verwendungsnachweis erstellt einen Report über die Häufigkeit der Verwendung.

Da teilweise die Erweiterungen nur einmal im Jahr z.B. für den Jahresabschluss genutzt werden, sollte die Verwendungsprüfung lange genug, mindestens 13 Monate vor Projektstart, im Produktivsystem ausgeführt werden. Dieser beeinträchtigt die Gesamtperformance des ECC-Systems nicht.

Die Ergebnisse dieses Reports sind eine wichtige Basis der Custom Code Migration.

Add-On-Überprüfung

Die Add-On-Prüfung kann innerhalb des Hauptprojektes durchgeführt werden. Zur besseren Kostenabschätzung wird jedoch empfohlen, vor dem Start des Hauptprojektes zu prüfen, ob die verwendeten Add-Ons S4-Ready sind, bzw. ob es eine S4 kompatible Version des Add-Ons gibt. Sollte bei der Analyse festgestellt werden, dass ein benötigtes Add-On nicht im S4 verfügbar ist, kann dies höhere finanzielle Projektauswirkungen haben.

Custom Code Check und Anpassungen

Im Zuge des Custom Code Checks für S/4HANA ist eine vier- oder fünfstellige Anzahl an Befunden die Regel. Als Befunde werden Meldungen bezeichnet, bei denen der Custom Code gegen die Prüfkriterien verstößt.

Die Produktivsetzung einer Vielzahl von notwenigen Anpassungen zum gleichen Zeitpunkt kann den Supportaufwand zum Go-live des S/4HANA-Systems wesentlich erhöhen. Aus diesem Grund wird empfohlen, unkritische technische Änderungen an operativ benötigten Entwicklungen bereits vor der S/4HANA Umstellung in gut kontrollierbaren Wellen ins produktive ECC-System zu übernehmen.

Mit den Fachbereichen werden die Anwendungen hinsichtlich Usability und fachlicher Qualität bewertet. Mit den technischen Ansprechpartnern wird eine Bewertung in Bezug auf den aktuellen und zu erwarten-den Wartungsaufwand vorgenommen.

Erweiterungen bei denen entschieden wurde, diese im Rahmen des S4-Projektes neu zu entwickeln, können bereits S4-Ready implementiert und im Vorfeld produktivgesetzt werden. Es ist bei der vorgezogenen Entwicklung darauf zu achten, dass mit S4 viele technische Änderungen einhergehen, die im R3 nicht zur Verfügung stehen. Somit kann es bei der Migration dennoch nötig werden, Anpassungen an diesen Entwicklungen vorzunehmen.

Realisierungsphase

Die Realisierungsphase ist integraler Bestandteil des Hauptprojektes und wird typischerweise in einem eigenen Stream mit Teilprojektleitung umgesetzt.

Innerhalb der Realisierungsphase werden die weiterhin benötigten Eigenentwicklungen auf das neu installierte S/4HANA-System überführt und angepasst.

Notwendige Änderungen an den Eigenentwicklungen

Nachdem der Sourcecode der Eigenentwicklungen, innerhalb der Vorbereitungsphase S4-Ready gemacht wurde, ist es innerhalb des Hauptprojektes notwendig, diesen Sourcecode an die neuen Systembedingungen final anzupassen.

Die Vereinfachungsdatenbank

Um einen Überblick für die technischen Änderungen im S4 zu gewinnen, stellt die SAP eine Vereinfachungsdatenbank (Simplification Database) zur Verfügung. Diese Vereinfachungsdatenbank dient als Basis für den Custom Code Check und beinhaltet alle technischen Änderungen in SAP S/4HANA. Jede einzelne Änderung wird als Simplification Item bezeichnet und in der Regel durch einen SAP-Hinweis (SAP-Note) näher beschrieben. Für jedes neue Major Release von S/4HANA wird eine neue Simplification List zur Verfügung gestellt. Die Simplification List ist eine textuelle Beschreibung der Änderungen in SAP S/4HANA im Vergleich zu SAP ERP. Im Gegensatz dazu werden in der Vereinfachungsdatenbank die technischen Objekte (Transaktionen, Reports, Funktionen und vieles mehr) zusammengefasst, die von den Änderungen in SAP S/4HANA betroffen sind.

Die Vereinfachungsdatenbank beinhaltet aktuell rund 500.000 Objekte. Hieran ist gut zu erkennen, wie umfangreich die Erweiterungen und Vereinfachungen in S/4HANA im Vergleich zum ERP sind. Der Einsatz der Vereinfachungsdatenbank ist für den Custom Code Check obligatorisch, da es aufgrund der Vielzahl an Änderungen nicht möglich wäre, einen manuellen Abgleich auszuführen.

Mit der Vereinfachungsdatenbank wird der ATC-Check konfiguriert, sodass dieser die anzupassenden Objekte direkt im Quellcode identifiziert und anmerkt.

Kompatibilitäts-Views

Um den Umstellungsaufwand für die Eigenentwicklungen zu reduzieren, stellt SAP spezielle Kompatibilitätsobjekte zur Verfügung. In manchen Fällen kann eine Änderung der Eigenentwicklungen umgangen werden, indem man diese speziellen Objekte verwendet, die trotz der Änderung des Datenmodells auch mit SAP S/4HANA weiterhin kompatibel sind.

Im Zuge der technischen Umstrukturierung des Datenmodells für die Einführung von SAP Simple Finance wurden viele Summen- und Anwendungsindextabellen eliminiert. Aus Kompatibilitätsgründen wurden sogenannte Kompatibilitäts-Views eingeführt, mit denen ein ähnlicher Zugriff auf die Daten wie vor der Umstrukturierung möglich ist. Somit soll sichergestellt werden, dass mit minimalen Veränderungen an den Eigenentwicklungen, die Funktionalitäten weiterhin sichergestellt werden.

Bei einem neu aufgebauten S/4HANA-System steht seit dem Release 1511 die Kompatibilitäts-Views nur in der Version 2 zur Verfügung. Hierbei leitet die Datenbankschnittstelle automatisch alle SELECT-Anfragen an die ursprünglichen Datenbanktabellen auf den entsprechenden Kompatibilitäts-View um. Die Kompatibilitäts-Views werden daher auch als Redirect-Views bezeichnet.

Custom Code Migration App

Zur Unterstützung der Migrationsphase sollte die Custom Code Migration App genutzt werden. Diese App dient hierbei als zentrales Steuerungs- und Migrationswerkzeug bei der Custom Code Migration. Die App unterstützt hierbei sowohl die Mitarbeiter aus der Entwicklung wie auch das Management bei der Umsetzung der Custom Code Migration.

Für das Management stehen verschiedene Auswertungen zur Verfügung. Durch die grafisch aufbereiteten Auswertungen kann der Fortschritt gemessen und visualisiert werden. Es ist zudem möglich, die Auswertungen in Entscheidungsvorlagen für verschiedene Projekt-Boards (z.B. Lenkungsausschuss) zu verwenden.

Für Mitarbeiter, die die Custom Code Migration durchführen, stehen die Ergebnisse aus den ATC-Läufen, wie auch der Vereinfachungsdatenbank zur Verfügung.

Die Custom Code Migration App ist somit das zentrale SAP-Analysewerkzeug im Rahmen einer SAP S/4HANA-Konvertierung.

Vorgehen bei der Custom Code Migration

Die Custom Code Migration wird iterativ vorgenommen. Über die Custom Code Migration App wird ein ATC-Lauf angestoßen. Dieser listet alle im Code vorhandene Fehler und Auffälligkeiten auf. Zuerst werden im wesentlichen nur Syntaxfehler angezeigt. Diese müssen von den Entwicklern behoben werden. Erst wenn die Syntaxfehler behoben sind, kann das Prüfsystem mittels eines erneuten ATC-Checks weitere Inkompatibilitäten und Vereinfachungen detektieren. Diese werden behoben und der Vorgang so lange wiederholt, bis im ATC keine Befunde mehr vorhanden sind.

Nach dem Beheben aller Befunde wird eine Optimierungsphase dringend empfohlen.

In dieser Phase wird für alle Module die Perfomance optimiert. Außerdem sollte geprüft werden, welche Optimierungen der Oberfläche notwendig sind, um die Funktion im Fiori Launchpad nutzerfreundlich darzustellen.

Die gesamte Custom Code Migration sollte von einem erfahrenen Custom Code Migration Team begleitet werden. Die Migrationsexperten unterstützen hierbei die Entwickler bei der Auswahl der passenden Best Practices, bei der Lösung spezieller Anforderungen und entscheiden gemeinsam mit den Architekten, welche Ausnahmen im ATC hinterlegt werden. Dies ist wichtig, um eine hohe Migrationsqualität zu gewährleisten. Durch dieses Vorgehen wird zusätzlich sichergestellt, dass der ATC-Check nur Meldungen ausgibt, die für die Wartbarkeit und Codequalität eine Relevanz haben. Die Entwickler können sich somit auf relevante Meldungen konzentrieren und werden nicht durch alte, nicht relevante Meldungen, gestört.

In der Realisierungsphase werden auch Eigenentwicklungen umgesetzt, bei denen in der Vorbereitungsphase eine Neuimplementierung veranlasst wurde. Hierzu sollten die fachlichen und technischen Anforderungen im Vorfeld dokumentiert werden, die anschließend Basis für die Umsetzung sind.

Technische Umsetzung der Custom Code Migration

Die technische Umsetzung der Custom Code Migration fokussiert sich auf die Überprüfung der Eigenentwicklungen, die Analyse der Ergebnisse sowie der abschließenden Anpassung des Codes an die neu-en SAP S/4HANA-Richtlinien. Für die Bewertung und Durchführung dieser Systemumstellung stellt SAP unterstützende Tools zur Verfügung, die in den folgenden Abschnitten vorgestellt werden.

Vorbereitungsphase

Vor der Systemumstellung nach SAP S/4HANA muss eine Verwendungsprotokollierung und Analyse der erforderlichen Anpassungen der Eigenentwicklungen erfolgen

Verwendungsprotokollierung

Im Rahmen der Verwendungsprotokollierung soll der verwendete ABAP Custom Code bestimmt werden, der nach SAP S/4HANA übernommen werden muss. Die Verwendungsprotokollierung ermöglicht demnach, die Anzahl der zu migrierenden Eigenentwicklungen zu reduzieren und den damit verbundenen Aufwand zu minimieren.

Aufbauend auf dieser Protokollierung kann anschließend eine manuelle Analyse der Ergebnisse erfolgen. Dazu müssen die im SAP ECC-System vorhandenen Eigenentwicklungen mit den Verwendungsprotokollierungsdaten abgeglichen werden.

Aktivierung der Transaktion SCMON

Die Verwendungsprotokollierung wird über den ABAP Call Monitor (Transaktion SCMON) aktiviert. Dabei werden alle Zugriffe auf Reports, Funktionsbausteine, Klassen usw. im System protokolliert. Anschließend können die unverdichteten Daten direkt angezeigt, aber noch nicht genutzt werden. In diesem Fall bleibt die Aggregation, welche die gezählten Nutzungen der Objekte zu einem bestimmten Zeitpunkt festhält, noch aus.

Die Rohdaten werden in einer Liste angezeigt, die über den Button Display Data aufgerufen werden kann.

Es wird die aufrufende Transaktion, Anwendung oder der aufrufende Report (Request Type und Request Name) sowie das aufgerufene Objekt (Called Program Name und Called Object Name) mit seinem technischen Namen und Typ angezeigt. In der Spalte Processing Block Name werden aufgerufene Methoden oder Unterprogramme aufgeführt. In der Spalte Number of Calls wird die Anzahl der Ausführungen angezeigt, wodurch der Aufrufkontext zu einem genutzten Objekt festgehalten wird.

Aggregation der Verwendungsprotokollierungsdaten

Zur lokalen Aktivierung im protokollierten System wird für die Aggregation der Verbrauchsdaten die Transaktion SUSG gestartet und der Button Activate ausgewählt. Über die gleiche Transaktion kann die Protokollierung auch wieder deaktiviert werden. Nach der Deaktivierung kann sie mehrfach wieder gestartet werden.

Die Daten aus der Transaktion SCMON werden für einen bestimmten Zeitraum kopiert und in Form von Snapshots verdichtet, um dann zu einem späteren Zeitpunkt in der Custom Code Migration App verwendet werden zu können

Nach Start der Transaktion SUSG wird über den Button Snapshot erstellen ein Snapshot erstellt. Das System schlägt einen Namen für den Snapshot vor und gibt auch den Zeitraum und weitere Kriterien automatisch vor. Die Snapshots können verwaltet werden (Button Snapshots verwalten) und ebenso kann deren Lifecycle-Protokoll angezeigt werden (Button Protokoll anzeigen).

Die Snapshot-Daten selbst können nicht direkt in der Transaktion SUSG dargestellt werden. Über die Transaktion SE16N können allerdings die Inhalte dieser View angezeigt werden. Dazu muss als Tabelle/View der Name „SUSG_V_ODATA“ eingegeben werden.

Analyse der erforderlichen Anpassungen

Über den Custom Code Check werden die Eigenentwicklungen auf mögliche Inkompatibilitäten zu dem neuen SAP S/4HANA-Datenmodell hin analysiert. Wichtig ist, dass der Custom Code-Anpassungsprozess einschließlich aller folgender Empfehlungen, Prozesse und Tools nicht als einmalige Prozedur verstanden, sondern dauerhaft als fester Bestandteil des Entwicklungsalltags durchgeführt wird.

Die Eigenentwicklungen sollten noch im bestehenden SAP ECC-System analysiert und bereits vor der technischen Migration nach SAP S/4HANA bearbeitet werden, um den Anpassungsaufwand gering zu halten.

Das von der SAP empfohlene Werkzeug für die Codeanalyse im ECC-System ist das ABAP Test Cockpit (ATC). Das ATC führt Prüfungen an kundeneigenen Entwicklungen durch und stellt die Resultate übersichtlich zur Nachbearbeitung bereit. Das ATC kann aus anderen Systemen lesen und gegen Prüfvarianten prüfen, die lokal in dem System gespeichert sind, in dem das ATC installiert ist. Damit kann Code aus dem alten SAP ECC-System auf bestimmte Eigenschaften hin überprüft werden, die für SAP S/4HANA relevant sind, obwohl es diese Eigenschaften noch gar nicht kennt. Das Resultat des ATC-Checks ist eine Liste aller potenzieller Inkompatibilitäten

Realisierungsphase

In der Realisierungsphase werden die Eigenentwicklungen in das SAP S/4HANA-System übertragen. Der auf dem SAP ECC-System befindliche Kundencode wird auf Basis der Vereinfachungsdatenbank auf mögliche Inkompatibilitäten mit dem SAP S/4HANA-System geprüft. Das zentrale Prüfsystem wird auf dem neu aufgebauten Entwicklungssystem der SAP S/4HANA-Systemlandschaft eingerichtet. Die Verbindung zu dem zu prüfenden SAP ECC-System wird durch eine RFC-Verbindung realisiert. Das von SAP empfohlene Werkzeug zur Migration der Eigenentwicklungen ist die Custom Code Migration App (CCM-App).

Die CCM-App ist ein Aufsatz für das ATC und bietet die Möglichkeit, Nutzungsdaten für die Verwendungsprotokollierung zu integrieren. Die Ergebnisse können in grafischen Übersichten dargestellt werden. Die Analysemöglichkeiten sind umfangreicher als im ATC, so ist z.B. die automatische Ermittlung technischer Abhängigkeiten und der produktiven Relevanz möglich. Die Nutzungsdaten, die von der App direkt aus dem SAP ECC-System bezogen werden, können auch zum Löschen ungenutzter Objekte berücksichtigt werden. Eigenentwicklungen lassen sich über die CCM-App aus dem Quellsystem komfortabel in das Zielsystem übertragen.

Seit SAP S/4HANA 1809 ist die App Bestandteil der Standardauslieferung und kann ohne zusätzliche Lizenzen verwendet werden.

Die über den ABAP Call Monitor gewonnenen Daten können nach der Aggregation über die Transaktion SUSG in die CCM-App integriert und dort zur Reduktion der im Rahmen der Custom Code Migration betrachteten Objekte (Scoping) verwendet werden. Die Aktivierung und Auswertung der Datenaufzeichnungen können auch direkt im auszuwertenden System erfolgen.

Einrichten des ATC-Prüfsystems

Die Basis der CCM-App ist das ATC-Prüfsystem, weshalb zunächst die erforderlichen Einstellungen für den ATC-Check vorgenommen werden müssen. Um dem ATC-Prüfsystem den RFC-Lesezugriff auf das zu konvertierende SAP ECC-System zu ermöglichen, muss einmalig ein sogenanntes Objekt-Provider-Stub im SAP ECC-System eingespielt werden. Dieses kapselt die Funktionalität für den externen Zugriff.

Vereinfachungsdatenbank

Für die Durchführung des Custom Code Checks muss auch im zentralen Prüfsystem die Vereinfachungsdatenbank importiert werden.

Konfiguration einer RFC-Verbindung

Im nächsten Schritt muss eine RFC-Verbindung zwischen dem zentralen Prüfsystem und dem zu prüfenden SAP ECC-System angelegt werden.

1.1.1 Implementieren der Custom Code Migration App

Die CCM-App wird im SAP Fiori Launchpad zur Verfügung gestellt. Zur Aktivierung der App ist es notwendig, allen Personen, welche die ATC-Checks ausführen sollen, die erforderlichen Benutzerrollen zuzuweisen. Des Weiteren müssen die App-Bestandteile einzeln als OData-Services aktiviert werden.

Eine aktuelle Anleitung zur Einrichtung und Aktivierung der CCM-App in SAP S/4HANA On-Premise kann unter folgender URL im SAP Help Portal entnommen werden:

Anleitung Einrichtung CCM-App.

Migrationsprojekt anlegen

Die Custom Code Migration App läuft im SAP Fiori Launchpad (Transaktion /UI2/FLP).

Als Erstes wird in der App ein Migrationsprojekt erstellt. In diesem Projekt wird das Ziel-Release angelegt, eine RFC-Verbindung zum migrierenden System für die spätere Prüfung (Destination) sowie einige grundlegende Eigenschaften der geplanten Migration festgelegt. Diese Informationen werden auf der Registerkarte „Kopfdaten“ gepflegt.

Weitere einzustellende Prüfparameter sind:

Materialnummernlänge: In SAP S/4HANA kann eingestellt werden, ob die neue 40-stellige Materialnummer (Datentyp CHAR40) genutzt oder ob Materialnummern wie im SAP ECC-System weiterhin als Felder vom Typ CHAR18 behandelt werden sollen. In letzterem Fall entfallen ggfls. viele Befunde.
Erweiterte Betragslänge: In SAP S/4HANA gibt es einen Schalter, der größere Währungsbeträge zulässt. Währungsbetragsfelder mit einer Feldlänge zwischen 9 und 22 mit zwei Dezimalstellen wurden auf 23 Zeichen mit zwei Dezimalstellen erweitert, z.B. beim zentralen Datenelement DMBTR.

Erweiterte Bestands-/Bedarfsegmentlänge: Hier kann angegeben werden, ob die erweiterte Bestands-/Bedarfssegmentlänge genutzt werden soll.

Erweiterte Saison/Thema/Kollektionslänge: Hier kann angegeben werden, ob die erweiterte Saison-/Thema-/Kollektionslänge (CHAR10) genutzt werden soll.

Verwendungsdaten einbinden

Danach folgt in der Registerkarte „Verwendungsdaten“ die Einbindung der zu nutzenden Verwendungsstatistiken zu den Eigenentwicklungen. Diese Daten stammen aus dem ABAP Call Monitor (Transaktion SCMON). Falls an dieser Stelle keine Verwendungsstatistiken verfügbar sind bzw. ausgewählt werden, werden alle Eigenentwicklungen selektiert.

Dazu muss über die Eingabehilfe in der gleichnamigen Spalte eine „Destination für Verwendung“ ausgewählt werden. Diese entspricht in der Regel der Destination, die in der Registerkarte Header des Analyseprojekts bei Verwendung der Daten aus dem ABAP Call Monitor angegeben wurde. Gepflegt werden diese Destinationen in der Konfiguration des ATCs im Bereich Object Provider ∙ RFC-Objekt-Provider. In der Spalte VerwendBeschreib. muss eine Verwendungsbeschreibung ausgewählt werden. Hier sollte am besten auf die Werthilfe zurückgegriffen werden.

In den Verwendungsdaten sind standardmäßig alle direkt in den Nutzungsstatistiken auffindbaren Kundenobjekte sowie Objekte ohne Statistik (z.B. Datenbanktabellen). Nachdem die Nutzung definiert und gesichert wurde, sind alle Aktivitäten im Reiter Projekt abgeschlossen und es kann in den nächsten Reiter Scope gesprungen werden.

Um den Scope zu editieren, können einzelne Scope-Pakete oder Scope-Anfrageeinstiegspunkte ausgewählt werden:

Nach dem Klick auf den Link Scope-Pakete erscheint eine bearbeitbare Liste der Pakete, die aktuell im Scope enthalten sind. Zu Beginn ist das der Default-Scope.

Mit dem Klick auf den Link Scope-Anfrageeinstiegspunkte werden diese Einstiegspunkte angezeigt und können auch gepflegt werden. Dabei handelt es sich letztlich um die Startobjekte (Objektname und Aufrufkontext) der Aufzeichnungen im ABAP Call Monitor.

Sowohl die Liste der Pakete als auch die der Anfrageeinstiegspunkte kann so editiert werden (vgl. Abbildung 2.13). Damit können fehlende Objekte nachgetragen oder Objekte, die zukünftig sicher nicht mehr benötigt werden, aus dem Migrationsumfang entfernt werden.

Analyse und Darstellung der Befunde

Nachdem das Projekt gesichert wurde, erfolgt die Berechnung der zu berücksichtigenden Objekte (Scoping) und der ATC-Check dieser Objekte beginnt automatisch. Dieser Schritt kann je nach System und Objektmengen einen etwas längeren Zeitraum (einige Stunden) in Anspruch nehmen. Sobald der Status des Projekts auf Bereit für Scoping gewechselt ist, kann das Scoping vorgenommen bzw. angepasst werden. Um den grafischen Überblick über die Ergebnisse der Analyse anzuzeigen, muss Analyse ∙ Übersicht der Befunde ausgewählt werden. In der Übersicht der Befunde wird die Anzahl der Befunde gruppiert nach Prüftiteln. Damit werden die Befunde nicht einzeln aufgelistet, sondern thematisch gruppiert. Somit kann ein erster Eindruck verschafft werden, zu welchen Prüftiteln die meisten Befunde ausgegeben wurden.

Für die Gesamtplanung der Anpassungen ist die Darstellung übersichtlicher, die über die Funktion
Befunde analysieren aus der Analysesicht heraus aufgerufen werden kann.

Funktionale Anpassungen

Nach der Systemumstellung auf SAP S/4HANA können bestimmte Befunde aus dem Custom Code Check über Quick Fixes über die ABAP Development Tools (ADT) in Eclipse effizient bearbeitet werden. Eclipse ist eine integrierte Entwicklungsumgebung, in der über die ADT auch in ABAP programmiert werden kann. Es können Korrekturvorschläge für einzelne Codeabschnitte generiert werden. Eine Massenbearbeitung von Befunden ist ebenfalls möglich. So kann eine Vielzahl von SAP S/4HANA-Befunden in kürzester Zeit behoben werden. Nach Abschluss dieser Nacharbeiten steht das SAP S/4HANA-System zur Nutzung bereit.

Funktionale Anpassungen

Eclipse und ABAP Development Tools (ADT)

Zur weiteren Bearbeitung der funktionalen Anpassungen wird empfohlen, die aktuelle Version von Eclipse zu installieren und darauf basierend die aktuelle Version der ABAP Development Tools zu verwenden.

Performance Optimierung

Abschließend ist zu prüfen, welche Geschäftsprozesse, beispielsweise die Performance kritischer Datenbankabfragen, in SAP HANA optimiert werden müssen. Dazu muss überprüft werden, welche SQL-Anweisungen optimiert werden können. Es werden die relevanten Performance-Daten aller im Produktivsystem ausgeführten SQL-Anweisungen angezeigt. Hier werden die teuersten Geschäftsprozesse und die am häufigsten verwendeten SQL-Anweisungen angezeigt.

SQL-Monitor

Der SQL-Monitor protokolliert die Tabellenbenutzung in einem SAP-System für eine Tabelle oder einem View an einer bestimmten Stelle im Coding. Der Hauptnutzen des SQL-Monitors ist die Performanceanalyse.