diff --git a/docs/clean-core/what-is-clean-core.md b/docs/clean-core/what-is-clean-core.md index 775a6ce..f8b84bf 100644 --- a/docs/clean-core/what-is-clean-core.md +++ b/docs/clean-core/what-is-clean-core.md @@ -18,16 +18,16 @@ nav_order: 1 ## Was ist Clean Core -Clean Core ist ein Konzept, und für manchen SAP Kunden eine Philosophie - Clean Core wird unterschiedlich aufgefasst, interpretiert und gelebt. Ein gemeinsames Verständniss der DSAG-Community wäre das folgende: +Clean Core ist ein Konzept und für einige SAP-Kunden eine Philosophie - Clean Core wird unterschiedlich verstanden, interpretiert und gelebt. Ein gemeinsames Verständnis der DSAG-Community wäre folgendes: -**"Clean Core"** - Streng genommen ist das Konzept so zu interepretieren: Systemupgrades sollen keinen Einfluss auf Kundenerweiterungen haben. Deshalb -dürfen die SAP Kunden nur freigegebene Schnittstellen für Geschäftprozesserweiterungen nehmen. +**"Clean Core"** - Streng genommen ist das Konzept so zu interpretieren: System-Upgrades sollen keinen Einfluss auf Kundenerweiterungen haben. Daher +dürfen SAP-Kunden nur freigegebene Schnittstellen für Geschäftsprozesserweiterungen verwenden. -**“Keep the core clean”** – Bedeutet, dass ein Unternehmen nach Clean Core Prinzipien - definierten Richtlinien in einem Unternehmen - Neuentwicklung aufsetzt. +**“Keep the core clean”** - Bedeutet, dass ein Unternehmen Neuentwicklungen nach Clean-Core-Prinzipien - definierten Richtlinien in einem Unternehmen - durchführt. -**“Make the core clean”** – Spricht die Unternehmenstransformation an und behandelt die iterative Reise zu einem Clean Core. +**Make the core clean"** - Bezieht sich auf die Unternehmenstransformation und die iterative Reise zu einem Clean Core. -Clean Core hat vier Fokusfelder: Geschäftsprozesse, Kundenerweiterungen, Geschäftsdaten und Integration. Vor allem die neuen Wege der Kundenerweiterungen stehen in diesem Leitpfaden im Fokus. +Clean Core hat vier Fokusbereiche: Geschäftsprozesse, Kundenerweiterungen, Geschäftsdaten und Integration. Vor allem die neuen Wege der Kundenerweiterungen stehen im Mittelpunkt dieser Roadmap. > „Die Erweiterbarkeitsfunktionen umfassen viele Optionen, die Kunden und Partner dabei unterstützen, Standard-Business-Software an ihre Geschäftsanforderungen anzupassen.“ @@ -38,66 +38,70 @@ Quelle: SAP Help Portal Clean Core {: .img-caption} -Das Clean Core Konzept mit seinen unterschiedlichen Facetten ist von SAP klar und deutlich bei der TechEd2023 kommuniziert. Die Schritt-für-Schritt Anleitung ist für etablierte Kunden, welche diverse „Legacy“ Technologien in ihren SAP-Systemen nutzen, ist dennoch unklar. -Es gibt zahlreiche Bestandskunden und SAP Partner, welche Mehrwerte durch Eigenentwicklung und Systemerweiterung, in Ihren Systemen geschaffen haben. Diese Mehrwerte gehören laut Definition nicht zum Clean Core - die Erweiterungen beruhen fast immer auf nicht freigegebene Schnittstellen. Es existieren unterschiedliche Nachfolge-Technologie-Matrizen für die sogenannten RICEFW-Objekte. Intern stellt sich primär die Fragen: „Wie können wir gegenüber unseren Kunden den Technologie-Wechsel vertreten? Und weshalb sollte ich jetzt gut-funktionierende Prozesse basierend bspw. auf Idocs, Nachrichten, RFCs, und ALV-Transaktionen umziehen? +Das Clean Core Konzept mit seinen verschiedenen Facetten wird von SAP in der [TechEd2023 - Clean Core: What It Is, Why to Do It, and How to Get There] (https://www.youtube.com/watch?v=jlzdD55ahqY) klar kommuniziert. Die Schritt-für-Schritt-Anleitung ist jedoch für etablierte Kunden, die verschiedene „Legacy“-Technologien in ihren SAP-Systemen einsetzen, unklar. +Es gibt zahlreiche Bestandskunden und SAP-Partner, die durch Eigenentwicklungen und Systemerweiterungen Mehrwerte in ihren Systemen geschaffen haben. Diese Mehrwerte gehören per Definition nicht zum Clean Core - die Erweiterungen basieren fast immer auf nicht freigegebenen Schnittstellen. Für die sogenannten RICEFW-Objekte gibt es verschiedene [Nachfolgetechnologie-Matrizen] (https://www.sap.com/documents/2022/10/52e0cd9b-497e-0010-bca6-c68f7e60039b.html). Intern stellen sich vor allem die Fragen: „Wie können wir den Technologiewechsel gegenüber unseren Kunden vertreten? Und warum soll ich gut funktionierende Prozesse, die z.B. auf Idocs, Messages, RFCs und ALV-Transaktionen basieren, jetzt umstellen? ### Zielgruppe -(Noch offen) -* SAP Kunden die auf S/4 HANA gehen - Greenfield Ansatz und stringent Clean Core bestimmen -* SAP Kunden die Brownfield auf S/4 sind- Clean Core nach und nach definieren und Neuentwicklung konform dazu halten +Im Wesentlichen sind im DSAG-Netzwerk zwei große Kundengruppen sichtbar: Die erste Gruppe entscheidet sich für eine große Investition in ihre SAP-Landschaft und arbeitet mit SAP und ihren Partnern zusammen, um auf einen Clean Core im Sinne der SAP-Definition zu gehen. Die andere Gruppe entscheidet sich für einen skalierten Ansatz, bei dem die Investitionen über mehrere Jahre verteilt werden. Hier einige Beispiele für mögliche SAP Kunden: + +* Szenario eins: Neue SAP-Kunden, die auf S/4 HANA migrieren. Hier sollte der Greenfield-Ansatz und das strikte Clean Core laut SAP angewendet werden. +* Szenario zwei - Brownfield to Bluefield: Bestandskunden von SAP, die seit Jahrzehnten mit SAP arbeiten und auf S/4 HANA migrieren. Je nach Investitionsbereitschaft kann schrittweise der Clean Core definiert und die Neuentwicklung konform dazu gehalten werden. Bestehende Kundenerweiterungen werden in Großprojekten auf eine Clean Core konforme Entwicklung umgestellt. +* Szenario drei - Brownfield to Greenfield: Bestands SAP Kunden, welche seit Jahrzenten mit SAP zusammenarbeiten und auf S/4 HANA migrieren. Hier kann eine Abbildung der Kundenerweiterungen mit sehr hohem Investitionsvolumen erfolgen. +* Szenario vier - Brownfield im S/4 HANA: Ist identisch mit Szenario zwei. ### Clean Core Definition -Im Kern dreht sich das Konzept des Clean Core darum, wesentliche Geschäftslogiken von nicht wesentlichen Funktionalitäten innerhalb der Software-Suite von SAP zu trennen. Durch die Isolierung von Kerngeschäftsprozessen und Datenstrukturen strebt SAP eine schlankere, agilere Grundlage an, die sich an sich ändernde Geschäftsanforderungen anpassen kann. +Im Kern dreht sich das Clean-Core-Konzept um die Trennung der Kerngeschäftslogik von der Nicht-Kernfunktionalität innerhalb der SAP-Software-Suite. Durch die Isolierung von Kerngeschäftsprozessen und Datenstrukturen strebt SAP eine schlankere und agilere Basis an, die sich an veränderte Geschäftsanforderungen anpassen kann. -Die neuen Wege der Kundenerweiterung heißt: ABAP Cloud, und “Side-By-Side Extensibility”. +Die neuen Wege der Kundenerweiterung heißen: ABAP Cloud und “Side-by-Side Extensibility”. -**ABAP Cloud oder auch “On-Stack Extensibility”** – Das sind zwei unterschiedliche Technologien: “Developer Extensibility” und “Key-User Extensibility” +**ABAP Cloud oder auch “On-Stack Extensibility”** - Das sind zwei unterschiedliche Technologien: “Developer Extensibility” und “Key-User Extensibility”. -**Side-By-Side Extensibility** – Ist die Aulagerungen von Kundenerweiterungen in die Business Technlogy Palltform – BTP. +**Side-by-Side Extensibility** - Ist die Auslagerung von Kundenerweiterungen in die Business Technology Platform - BTP. -Ein Beispiel: Statt an unterschiedliche Systeme das MATMAS Idoc – in heterogener Ausprägung an diverse Systeme zu schicken, sollten Sie auf die standardisierte Schnittstelle: Product Master API setzen. Um die SAP und Non-SAP-Systeme zu versorgen, nutzten Sie dann eine Schnittstelle, welche homogen ausprägt werden kann. +Ein Beispiel: Anstatt das MATMAS Idoc in heterogener Form an verschiedene Systeme zu senden, sollte die standardisierte Schnittstelle: Product Master API verwendet werden. Zur Versorgung der SAP- und Non-SAP-Systeme dient dann eine Schnittstelle, die homogen ausgeprägt werden kann. -Das Datenmodell darunter wird durch Key-User-Extensibility erweitert und auch in generischen Reports wie „embedded Analytics“, oder auch der SAP Analytic Cloud (SAC) verwendet. Bei komplizierter Kunden-Logik muss der Entwickler mit Developer Extensibility und dem RESTful Application Programming Model (RAP) diese Kunden-Logik erweitern. +Das Datenmodell darunter wird durch Key-User-Extensibility erweitert und auch in generischen Reports wie „Embedded Analytics“ oder auch der SAP Analytic Cloud (SAC) verwendet. Bei komplexer Kundenlogik muss der Entwickler diese Kundenlogik mit Developer Extensibility und dem RESTful Application Programming Model (RAP) erweitern. -Grundsätzlich heißt Clean Core, so wie der Hersteller es beschreibt: -1. Erweiterungen sind klar vom SAP-Code getrennt, und Erweiterungen verändern keine SAP-Objekte. -2. Nutzen Sie die neuen Erweiterungstechnologien und den SAP Standard. Erweiteren Sie mit den neuen Erweiterungsmethoden, wie Key-User, Developer und Side-by-Side Extensibility. -3. Erweiterungen verwenden nur stabile, freigegebene SAP-APIs und Erweiterungspunkte. Classical Extensibility sollte nur in zugelassenen Business Add-Ins, mit freigegebenen Entwicklungsobjekten stattfinden. -4. Die Legacy Technologien, wie bspw. RFCs, Idocs und kundeneigene Dynpro Transkationen, oder SAP Gateway Projekte sollen nicht mehr für neue Entwicklungen genutzt werden. -5. Alte Kundeneigene Entwicklungen / Erweiterungen sollen umziehen auf neue Technologien, oder die Geschäftsprozessanforderung wird im SAP Standard wiedergefunden. +Grundsätzlich ist Clean Core so, wie es der Hersteller beschreibt: +1. Erweiterungen sind klar vom SAP-Code getrennt und Erweiterungen verändern keine SAP-Objekte. +2. Nutzen Sie die neuen Erweiterungstechnologien und den SAP-Standard. Erweiterungen verwenden die neuen Erweiterungsmethoden wie Key-User, Developer und Side-by-Side Extensibility. +3. Erweiterungen verwenden nur stabile, freigegebene SAP APIs und Erweiterungspunkte. Classical Extensibility sollte nur in freigegebenen Business Add-Ins mit freigegebenen Entwicklungsobjekten stattfinden. +4. Legacy Technologien wie RFCs, Idocs und kundeneigene Dynprotransaktionen oder SAP Gateway Projekte sollten nicht mehr für Neuentwicklungen verwendet werden. +5. Alte kundeneigene Entwicklungen / Erweiterungen sollen auf neue Technologien migriert werden, oder die Geschäftsprozessanforderung wird im SAP Standard wiedergefunden. -Aus den Herstellerangaben bilden sich vier Anwedungsgebiete und die Fakten um ein Clean Core zu erreichen sehen wie folgt aus: +Aus den Herstellerangaben ergeben sich vier Anwendungsbereiche und die Fakten zur Erreichung eines Clean Core sehen wie folgt aus: #### Datenmodelle -* Egal ob einfache oder komplexe Anwendungsfälle zu implementieren haben ist eine Datenmodellierung /ein Umgang mit dem Virtual Data Model (VDM) notwendig. -* Es soll keine Direktzugriffe auf SAP Standard Tabellen geben. +* Unabhängig davon, ob einfache oder komplexe Anwendungsfälle implementiert werden sollen, ist eine Datenmodellierung / ein Umgang mit dem Virtual Data Model (VDM) erforderlich. +* Es sollte kein direkter Zugriff auf SAP Standardtabellen erfolgen. #### Anwendungslogik -* SAP Standard Coding soll nicht mehr klassisch erweitert werden -* Die Erweiterungen am Standard sollen in definierten, freigegebenen Badis migriert werden. -* Eigenentwicklung muss Clean Core konforme Entwicklungsobjekte benutzen (Stichwort: Release Contracts) +* SAP Standard Coding soll nicht mehr klassisch erweitert werden. +* Erweiterungen am Standard sollen in definierte, freigegebene Badis migriert werden. +* Eigenentwicklungen müssen Clean Core konforme Entwicklungsobjekte verwenden (Stichwort: Release Contracts). -#### Oberflächen -* Grundsätzlich sollen die Kunden die Standard Fiori Apps nutzen, oder SAP GUI for HTML mit Screen Personas verwenden um existierende, SAP Standard Transkationen zu nutzen. -* Die Standard Fiori Apps, und die Standard APIs dahinter sollten erweitert werden. -* Bei Custom Apps soll primär erst Fiori Elements + RAP und Standard APIs genommen werden. Die nächste Stufe wären dann Freestyle Fioris Apps. Oder Cloud Native Applications in der Cloud (Side-by-side Extensibility). Das Portfolio der SAP Build bieten auch weitere Lösungswege. +#### Schnittstellen +* Grundsätzlich sollen Kunden die Standard Fiori Apps oder SAP GUI for HTML mit Screen Personas verwenden, um bestehende SAP Standardtransaktionen zu nutzen. +* Die Standard Fiori Apps und die dahinterliegenden Standard APIs sollen erweitert werden. +* Für Custom Apps sollten zunächst Fiori Elements + RAP und Standard APIs verwendet werden. Der nächste Schritt wären dann Freestyle Fiori Apps. Oder Cloud Native Apps in der Cloud (Side-by-Side Extensibility). Das Portfolio von SAP Build bietet weitere Lösungsansätze. #### Schnittstellen -* Nur Clean Core-konforme, freigegebene Schnittstellen sollen benutzt werden -* Erweiterungen werden an APIs / Microservices durchgeführt, um die Funktionalität von SAP zu erweitern, ohne die Integrität des Kernsystems zu beeinträchtigen. -* Integration nach außen muss klar geregelt sein, Prozessintegration und die Middleware für das API-Management muss gegeben sein. -* Legacy Technologien wie Idocs, RFCs, und Gateway Projekte müssen sukzessive umgezogen werden. +* Es werden nur Clean Core konforme, freigegebene Schnittstellen verwendet. +* Erweiterungen werden an APIs / Microservices vorgenommen, um die Funktionalität von SAP zu erweitern, ohne die Integrität des Kernsystems zu beeinträchtigen. +* Die Integration nach außen muss klar geregelt sein, Prozessintegration und Middleware für das API-Management müssen vorhanden sein. +* Legacy-Technologien wie Idocs, RFCs und Gateway-Projekte müssen sukzessive abgelöst werden. -Zusammenfassend steht das Clean Core Konzept von SAP für einen Paradigmenwechsel im Design von Unternehmenssoftware. Die SAP setzt darauf neue Services nur im Cloud Bereich anzubieten, und die Schnittstellen zu dem Kern weiterauszubauen. Der Mehrwert gut-laufende Lösung auf eine neue Plattform zu bringen, ist erstmal nicht gegeben. Neue Lösungen sollte ein Unternehmen mit den neuen Erweiterugsarten gehen um sich zukunftsicher aufzustellen. Somit profitiert ein SAP Kunde von der Innovationen rund um den Standard. -Durch die Umsetzung der Prinzipien des Clean Core und strategischer Initiativen können Organisationen sich auf zukünftige SAP-Strategien, vor allem Cloud-Technologien vorbereiten. +Zusammenfassend stellt das Clean Core Konzept der SAP einen Paradigmenwechsel im Design von Unternehmenssoftware dar. SAP setzt darauf, neue Services nur noch in der Cloud anzubieten und die Schnittstellen zum Core weiter auszubauen. Der Mehrwert, gut laufende Lösungen auf eine neue Plattform zu bringen, ist vorerst nicht gegeben. Neue Lösungen sollte ein Unternehmen mit den neuen Erweiterungsarten gehen, um für die Zukunft gerüstet zu sein. So profitiert ein SAP-Kunde von den Innovationen rund um den Standard. Zum Paradigmenwechsel gehört auch die digitale Transformation: weg vom SAP GUI und Dynpros hin zum Fiori Launchpad, die Endanwender sollen primär im Browser arbeiten. Zu einem Clean Core gehört auch ein massives Change Management durch die IT und die Fachbereiche. + +Durch die Umsetzung der Prinzipien des Clean Core und strategischer Initiativen können sich Organisationen auf zukünftige SAP-Strategien, insbesondere Cloud-Technologien, vorbereiten. Laut SAP geht es bei Clean Core vor allem, dass die Kunden sich die Zukunft nicht versperren und standardisiert Schnittstellen aufbauen. Durch die Standardisierung von Geschäftsprozessen und den Einsatz der SAP BTP können SAP Services, oder auch Lösungen von SAP Partnern komplett verwendet werden.   Die Clean Core Strategie ist für viele Bestandskunden eine Philosophie, bis interne Richtlinien die Nutzungen der Nachfolge-Technologien regeln. Basierend auf den Richtlinien werden Entwickler organisatorisch ausgerichtet, und geschult. Ein Gremium um die „Clean Core Governance“ einzuhalten ist Pflicht, mit dem Mandat die Richtlinien zu pflegen, zu erweitern und zu forcieren. Research und Development sollte häufig betrieben werden, um die Mehrwerte durch SAP-Service herauszuarbeiten. ### Private/Public Cloud/BTP ... - +siehe [Mapping your journey to SAP S/4HANA Cloud Private Edition - A practical guide for senior IT leadership](https://d.dam.sap.com/x/HvXc6b7/94115_92460_enUS.pdf?rc=19&inline=true) ### Zielbild - Reise mit SAP, der Weg in die Public Cloud? Clean Core ist relevant und anwendbar für "SAP S/4HANA on-premise" und "SAP S/4HANA Cloud, private edition (RISE)" diff --git a/docs/documentation/index.md b/docs/documentation/index.md index 77e09b3..9c5d78e 100644 --- a/docs/documentation/index.md +++ b/docs/documentation/index.md @@ -40,12 +40,34 @@ Dokumentenvorlagen wie das arc42-Template müssen nicht immer vollständig “au Darüber hinaus kann eine veraltete Dokumentation irreführend sein. Deshalb sollte in allen Dokumenten der Stand und eine Versionierung enthalten sein, um die Aktualität bewerten zu können. +| BEST PRACTICE | +|---------------| +|Es sollte im Unternehmen geklärt werden, wie Dokumentation von Software erfolgen soll.| + Innerhalb einer SAP-Systemlandschaft bietet der SAP Solution Manager Möglichkeiten zur Projektdokumentation. Die nachfolgenden Links bieten weitere Informationen dazu. WEITERE QUELLEN 1. Das arc42-Template zur Architekturdokumentation, [Arc42-Template](https://arc42.org/download) (aufgerufen am: 19.09.2024) 2. Stefan Zörner: Softwarearchitekturen dokumentieren und kommunizieren. Carl Hanser Verlag GmbH Co KG, 2021. ISBN: 978-3446469280 +## Dokumentation zur Versionsverwaltung + +### Transportauftrag +Oftmals hilft es zum Transportauftrag zu dokumentieren +* Ticketnummer und Titel des Tickets +* Wichtigste Entwicklungsobjekte im Transport +* Abhängigkeiten zu anderen Transporten (sofern vorhanden) +* Kurzbeschreibung zu Änderungen im Transport +Die Dokumentation zu jeder Aufgabe und zu jedem Auftrag während der Auftragsbearbeitung im Reiter "Dokumentation" zu erfassen. Die Dokumentation kann bis zur Freigabe laufend erweitert werden. Nach der Freigabe des Auftrags ist dies nicht mehr möglich. + +Diese Dokumentation auf dem Reiter "Dokumentation" kann man für jeden Transportauftrag erstellen, der ins Produktive Systeme geht. Transporte von Kopien sollte man nicht dokumentieren, um redundante Dokumentation zu vermeiden. Letztlich interessieren nur die Transporte, die ins Produktiv System gehen sollen, bzw. bereits gegangen sind. + +### Git-Client +Sollte ein Git-Client wie abapGit oder gCTS eingesetzt werden, werden Code-Änderungen protokolliert. Zu jedem sogenannten Commit werden neben den Code-Änderungen noch Metadaten gespeichert. Zu den Metadaten zählen eine kurze Beschreibung, sogenannte Commit-Nachricht, Autor und Datum. Die so entstehende Commit-Historie ermöglicht, vergangene Commits zu sehen und die Code-Änderungen nachzuvollziehen. Wird ein Ticket-System, wie zum Beispiel Jira oder Azure DevOps, für die Erfassung der Anforderungen benutzt, hat jede Anforderung an die Entwicklung eine eindeutige ID. Viele Teams haben die Vorgabe oder die interne Vereinbarung, diese ID in den Commit-Nachrichten einzutragen, damit sich die Commits den Aufgaben zuordnen lassen. Wird das konsistent gemacht, lassen sich mittels Freitextsuche in den Commit-Nachrichten alle Commits identifizieren, die zu einer bestimmten Aufgabe gehören. Das erleichtert wesentlich das Wiederfinden und die Überprüfung der Umsetzung im Fall von Bugs. Gleichzeitig lassen sich dadurch ähnliche Aufgaben sehr schnell umsetzen, weil die Entwickler das bereits funktionierende Beispiel finden und verfolgen können. + +| BEST PRACTICE | +|---------------| +|Wir empfehlen bei Änderungen, die ins produktive Systeme gehen egal ob mit Transportauftrag oder Git-Client mit Angabe was geändert wurde und mit Bezug zu einem externen Tool wie Ticketsystem| ## Dokumentation von Entwicklungsobjekten Neben Methoden, Funktionsbausteinen und Reports, die Dokumentation im Quellcode enthalten können, existieren weitere Entwicklungsobjekte im ABAP-System, die keinen Quellcode besitzen und daher auf anderem Weg dokumentiert werden müssen. Beispiele dafür sind: @@ -53,10 +75,6 @@ Neben Methoden, Funktionsbausteinen und Reports, die Dokumentation im Quellcode * DDIC-Objekte * Transaktionen -| BEST PRACTICE | -|---------------| -|Wir empfehlen, für alle Entwicklungsobjekte und unabhängig vom Quellcode die Dokumentationsfunktion der ABAP-Workbench zu nutzen und die Aufgaben und Bedeutungen dieser Objekte im SAP-System zu dokumentieren. Hierbei sollte ausschließlich der Ist-Stand dokumentiert werden, gegebenenfalls angereichert um kurze Verweise auf die Änderungsdokumentation (Transportdokumentation, Defekt-Nummern).| - Da die Workbench-Dokumentation auch an das Transportwesen angeschlossen ist, steht sie in allen Einzelsystemen einer Systemlandschaft zur Verfügung. Weiterhin kann diese Dokumentation von allen Benutzern eingesehen werden und wird für Reports vom ABAP-System automatisch in die Benutzeroberfläche eingebunden. Ein weiterer Vorteil kann darin bestehen, dass die Dokumentation mehrsprachig geführt werden kann. Auf SAP-Systemen mit SAP_BASIS >= 7.40 können im Quellcode ABAP-Doc-Kommentare verwendet werden. Dies kann als Alternative zur Dokumentation in der ABAP-Workbench verwendet werden. Der volle Funktionsumfang von ABAP-Doc-Kommentaren lässt sich derzeit allerdings nur mit den ABAP-Development-Tools für Eclipse ausschöpfen. Bei Verwendung von Core Data Services zur Definition von DDIC-Objekten können wesentlich mehr Entwicklungsobjekte im Quellcode dokumentiert werden und die Notwendigkeit externer Dokumentation entfällt. Beginnend mit SAP NetWeaver 7.50 lassen sich die ABAP-Doc-Kommentare von Klassen und Schnittstellen als HTML-Dateien exportieren. Die SAP erweitert ihr Repertoire ab ABAP Plattform 7.55 um eine weitere Technologie zur Dokumentation von ABAP-Entwicklungsobjekten. Das Knowledge Transfer Document fokussiert sich auf die neuen Objekttypen, die primär aus dem ABAP Restful Application Programming Model (RAP) Kontext entstammen. Dieses umfasst unter anderem: CDS Views, Behavior Definitions, Service Definitions, Service Bindings, Annotation Definitions und Paket @@ -81,15 +99,19 @@ Seit ABAP Plattform 7.55 gibt es das Knowledge Transfer Document. KTD kann für KTD müssen im selben Paket wie das Entwicklungsobjekt sein. Es wird nicht automatisch mit dem Entwicklungsobjekt transportiert, aber wenn das Entwicklungsobjekt gelöscht wird, wird auch das dazugehörige KTD gelöscht. +| BEST PRACTICE | +|---------------| +|Wir empfehlen, für alle Entwicklungsobjekte und unabhängig vom Quellcode die Dokumentationsfunktion der ABAP-Workbench zu nutzen. Die Dokumentationsfunktion sollte in folgender Reihenfolge angewendet werden, je nachdem für welches Objekt welche Art von Dokumentationsobjekt verfügbar ist: 1. Knowledge Transfer Documents 2. abapDoc 3. Kurztexte Hierbei sollte ausschließlich der Ist-Stand dokumentiert werden, gegebenenfalls angereichert um kurze Verweise auf die Änderungsdokumentation (Transportdokumentation, Defekt-Nummern).| + ## Dokumentation im Quellcode ### Dokumentationssprache +Entwicklungsteams arbeiten heutzutage überwiegend international zusammen. Auch wenn Sie derzeit rein deutschsprachig entwickeln, kann Ihr Projekt im Laufe der Zeit internationalisiert werden. Der Aufwand, der dann durch Koordinationsprobleme oder sogar nachträgliches Übersetzen entsteht, steht in keinem Verhältnis zu dem vielleicht größeren Aufwand durch englische Dokumentation. Es hat sich außerdem gezeigt, dass die Lesbarkeit von Quellcode und Kommentaren durch englischsprachige Kommentare erhöht wird. Denn die ABAP-Befehle selbst sind englisch und im Stil von Sätzen aufgebaut. Der Leser des Quellcodes muss bei englischer Dokumentation also nicht ständig die Sprache wechseln. + | BEST PRACTICE | |---------------| -|Als Kommentierungssprache sollte Englisch verwendet werden.| - -Entwicklungsteams arbeiten heutzutage überwiegend international zusammen. Auch wenn Sie derzeit rein deutschsprachig entwickeln, kann Ihr Projekt im Laufe der Zeit internationalisiert werden. Der Aufwand, der dann durch Koordinationsprobleme oder sogar nachträgliches Übersetzen entsteht, steht in keinem Verhältnis zu dem vielleicht größeren Aufwand durch englische Dokumentation. Es hat sich außerdem gezeigt, dass die Lesbarkeit von Quellcode und Kommentaren durch englischsprachige Kommentare erhöht wird. Denn die ABAP-Befehle selbst sind englisch und im Stil von Sätzen aufgebaut. Der Leser des Quellcodes muss bei englischer Dokumentation also nicht ständig die Sprache wechseln. +|Es sollte im Unternehmen geklärt, was die Kommentierungssprache ist. Die Empfehlung ist in englisch zu kommentieren.| ### Dokumentation von Änderungen Ab dem Zeitpunkt der Produktivsetzung eines Programms sollte darauf geachtet werden, dass Änderungen in Programmen angemessen dokumentiert werden. Hier ist das richtige Maß wesentlich: Eine vollständige Versionshistorie aller Änderungen und auskommentierter Quellcode reduzieren die Lesbarkeit des Quellcodes. Trotz dieses Nachteils dokumentieren einige Entwicklungsteams bewusst alle Änderungen im Quellcode, um die Fehlersuche auf Produktiv- oder Testsystemen zu vereinfachen, in denen die Versionshistorie nicht zur Verfügung steht. @@ -101,12 +123,16 @@ Ab dem Zeitpunkt der Produktivsetzung eines Programms sollte darauf geachtet wer ### Kommentare im Quellcode Kommentare im Quellcode sollen dazu dienen, Entwicklern das Verstehen des Quellcodes zu erleichtern, sofern dies nicht durch geschickte Gestaltung des Quellcodes allein (Modularisierung, Namenswahl von Methoden und Variablen) erreichbar ist. -Kommentare sind für andere Entwickler und mit zunehmendem zeitlichen Abstand auch für den ursprünglichen Entwickler gedacht. Sie sollten die Frage beantworten, „Warum” etwas programmiert wurde und nicht „Was”. Letzteres ergibt sich aus dem Quellcode ohnehin, während die Beweggründe oft nicht klar erkennbar sind. Gerade sie helfen beim Verständnis aber wesentlich weiter. Dabei gilt der Grundsatz: So wenig Kommentar wie möglich, so viel Kommentar wie nötig. +Kommentare sind für andere Entwickler und mit zunehmendem zeitlichen Abstand auch für den ursprünglichen Entwickler gedacht. Stern-Kommentare sollten nur im Programmkopf oder für das temporäre Auskommentieren von altem Quellcode verwendet werden. Für alle anderen Kommentare empfiehlt SAP, Inline-Kommentare zu verwenden. Diese sollten jeweils vor dem Quellcode stehen, den sie dokumentieren, und genauso eingerückt sein wie dieser Quellcode. Letzteres wird (nur) für Inline-Kommentare auch vom Pretty Printer korrekt durchgeführt. +| BEST PRACTICE | +|---------------| +|Sie sollten die Frage beantworten, „Warum” etwas programmiert wurde und nicht „Was”. Letzteres ergibt sich aus dem Quellcode ohnehin, während die Beweggründe oft nicht klar erkennbar sind. Gerade sie helfen beim Verständnis aber wesentlich weiter. Dabei gilt der Grundsatz: So wenig Kommentar wie möglich, so viel Kommentar wie nötig.| + WEITERE QUELLEN 1. Horst Keller, Wolf Hagen Thümmel: ABAP-Programmierrichtlinien. SAP Press, 2009. ISBN: 9783836212861 diff --git a/docs/open-source/open-source-projects.md b/docs/open-source/open-source-projects.md index 1cc24b3..20e309f 100644 --- a/docs/open-source/open-source-projects.md +++ b/docs/open-source/open-source-projects.md @@ -9,11 +9,10 @@ nav_order: 5 --- {: .no_toc} - # Vorstellung ausgewählter Projekte 1. TOC - {:toc} +{:toc} ## Übersicht diff --git a/docs/testing/img/tricentis_tools_uebersicht.png b/docs/testing/img/tricentis_tools_uebersicht.png new file mode 100644 index 0000000..dfcba7c Binary files /dev/null and b/docs/testing/img/tricentis_tools_uebersicht.png differ diff --git a/docs/testing/recommended-tools.md b/docs/testing/recommended-tools.md index 0f63e01..503dda8 100644 --- a/docs/testing/recommended-tools.md +++ b/docs/testing/recommended-tools.md @@ -13,29 +13,62 @@ nav_order: 3 1. TOC {:toc} +Die nachfolgend aufgeführten Testwerkzeuge sind nicht ABAP-spezifisch, sondern generell im Rahmen der (SAP)-Softwareentwicklung zu sehen. Das bedeutet auch, dass von Seiten des ABAP-Entwicklers (maskulin?) nichts beachtet werden muss, was die Tests in irgendeiner Weise, also weder positiv oder negativ, beeinflussen könnte. -Die nachfolgend aufgeführten Tools (Testwerkzeuge?) sind nicht ABAP-spezifisch, sondern generell im Rahmen der (SAP)-Softwareentwicklung zu sehen. Das bedeutet auch, dass von Seiten des ABAP-Entwicklers (maskulin?) nichts beachtet werden muss, was die Tests in irgendeiner Weise (weder positiv oder negativ) beeinflussen könnte. +Die Auswahl in diesem Leitfaden beschränkt sich auf die von SAP bereitgestellten(?) oder (schon) im Lizenzumfang enthaltenen Produkte. Daneben gibt es noch viele weitere Lösungen auf dem Markt, die für die ABAP-Entwicklung verwendet werden können. -## SAP Cloud ALM +## Testwerkzeuge im SAP Solution Manager +--> Marco -Als Nachfolgeprodukt des SAP Solution Managers, dessen Mainstream-Wartungsende seitens SAP auf Ende 2027 datiert ist, wurde für das Application Lifecycle Management (ALM, link zu diesem Kapitel) im Jahr xxx2018?xxx SAP Cloud ALM vorgestellt. Das Cloud-Produkt beinhaltet - wie auch der Solution Manager - unter anderem ein integriertes Testmanagement, das sowohl eigenständig (für manuelle Testfälle) als auch in Verbindung mit einer Testautmatisierungslösung wie Tricentis Test Automation (siehe den nächsten Abschnitt) eingesetzt werden kann. SAP Cloud ALM und damit auch dessen Testmanagement-Funktionen werden kontinuierlich weiterentwickelt. +Der SAP Solution Manager (https://support.sap.com/en/alm/solution-manager.html // die Seite ist auf EN...) ist ein ausgereiftes System für das Application Lifecycle Management (ALM, Link zu diesem Kapitel), das unter anderem verschiedene Testwerkzeugen enthält. + +### Test Suite +xxx...Standard SolMan +https://help.sap.com/docs/SUPPORT_CONTENT/sm/3530264795.html + +### Test Steps Designer (oder das volle Programm hier?) +xxx...aus FB... ST-OST Add-on +https://support.sap.com/en/alm/focused-build.html +https://support.sap.com/content/dam/support/en_us/library/ssp/alm/sap-solution-manager/focused-solutions/Focused_Build/sp14/FB%20-%20Test%20Management%20-%20L2%20SP14.pdf + +### CBTA +xxx...Automatisierung...Standard SolMan +https://help.sap.com/docs/SUPPORT_CONTENT/sm/3530264810.html + +## eCATT (extended Computer Aided Test Tool) --> gehört nicht unter "Testwerkzeuge im SAP Solution Manager" !!! +xxx... +Verwendung von eCATT irgendwie referenzieren auf eigenes Kapitel? +https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/de-de/49/6d2fa0e0221ec6e10000000a42189b/frameset.htm +oder https://help.sap.com/saphelp_gbt10/helpdata/DE/20/e81c3b84e65e7be10000000a11402f/frameset.htm ??? + +## Testwerkzeuge in SAP Cloud ALM + +Als Nachfolgeprodukt des SAP Solution Managers, dessen Mainstream-Wartungsende seitens SAP auf Ende 2027 datiert ist, wurde für das Application Lifecycle Management (ALM, Link zu diesem Kapitel bzw. hab ich oben schon) im Jahr xxx2018?xxx SAP Cloud ALM vorgestellt. Das Cloud-Produkt beinhaltet - wie schon der Solution Manager - unter anderem ein integriertes Testmanagement, das sowohl eigenständig (für manuelle Testfälle) als auch in Verbindung mit einer Testautmatisierungslösung wie Tricentis Test Automation (siehe den nächsten Abschnitt bzw. Link dort hin) eingesetzt werden kann. SAP Cloud ALM und damit auch dessen Testmanagement-Funktionen werden kontinuierlich weiterentwickelt. + +--> Marco + Automatische Prozesstests mit CloudALM? (wie) geht das ? ## Tricentis Test Automation +--> Harald -Tricentis ist ein eigenständiges Unternehmen, das nicht zu SAP gehört, aber durch eine (langjährige, tiefgehende?) Partnerschaft sehr gut in die SAP-Welt integriert und daher im SAP-Kontext die empfohlene Lösung zur Testautomatisierung ist (https://support.sap.com/en/alm/partners/test-automation.html). +Tricentis ist ein eigenständiges Unternehmen, das nicht zu SAP gehört, aber durch eine strategische Partnerschaft sehr gut in die SAP-Welt integriert und daher im SAP-Kontext die empfohlene Lösung zur Testautomatisierung ist (https://support.sap.com/en/alm/partners/test-automation.html) / (https://www.tricentis.com/sap). ...verschiedene Ausprägungen...Lizenzen teilweise schon dabei... · Tosca: Integration in SAP SolMan – Link zu https://documentation.tricentis.com/tosca/2310/de/content/sap_solutionmanager/concept.htm · TTA: Integration in SAP Cloud ALM – Link zu https://support.sap.com/en/alm/partners/test-automation.html -(Grafik, welches Tricentis-Tool für welches ALM-System etc.?) + § Tool für automatische GUI-Tests über sämtliche Technologien (Webseiten, SAP GUI etc.) + +(Grafik selber machen auf deutsch, welches Tricentis-Tool für welches ALM-System etc., in Anlehnung an die Darstellung von SAP --> "Quelle...in Anlehnung an..."?) und die einzelnen Punkte kurz beschreiben +![Clean Core](./img/tricentis_tools_uebersicht.png) -(sollen wir auf 4 Ebenen gehen?) -### Mögliche Einsatzszenarien +### Mögliche Einsatzszenarien für automatisierte Testfälle #### Tägliche Smoke-Tests +--> Harald Daily Smoke Tests in Testumgebungen... #### Regressionstests +--> Harald Automatisierte Testfälle können hervorragend für Regressionstests in Prä-Produktionssystemen eingesetzt werden... was muss da beachtet werden??? Testdaten etc.? @@ -48,15 +81,3 @@ SAP Application Lifecycle Management: Test Automation https://support.sap.com/en Tricentis: Die empfohlene Testlösungvon SAP https://www.tricentis.com/de/sap ---------------------- -/// Stichpunkte aus der Word-Datei /// - -o Cloud ALM - § ?Automatische Prozesstests mit CloudALM? - · Geht das ? - § Stand Sept 2024 laut Marco noch nicht gut nutzbar. ( freundlich formulieren ) --> ist das noch so? -o Tricentis: https://www.tricentis.com/de/sap - § Hat erst mal mit ABAP-Entwicklung wenig zu tun, also da wäre nix zu beachten, aber als allgemeines Tool, um Software zu testen - § Tool für automatische GUI-Tests über sämtliche Technologien (Webseiten, SAP GUI etc.) - - - diff --git a/docs/version-management/dsagleitfaden-RECOVERY.drawio.png b/docs/version-management/dsagleitfaden-RECOVERY.drawio.png new file mode 100644 index 0000000..b31b902 Binary files /dev/null and b/docs/version-management/dsagleitfaden-RECOVERY.drawio.png differ diff --git a/docs/version-management/dsagleitfaden-customcode.drawio.png b/docs/version-management/dsagleitfaden-customcode.drawio.png new file mode 100644 index 0000000..7593b89 Binary files /dev/null and b/docs/version-management/dsagleitfaden-customcode.drawio.png differ diff --git a/docs/version-management/dsagleitfaden-normal.drawio.png b/docs/version-management/dsagleitfaden-normal.drawio.png new file mode 100644 index 0000000..37d6e1c Binary files /dev/null and b/docs/version-management/dsagleitfaden-normal.drawio.png differ diff --git a/docs/version-management/dsagleitfaden-parallel.drawio.png b/docs/version-management/dsagleitfaden-parallel.drawio.png new file mode 100644 index 0000000..55da8b4 Binary files /dev/null and b/docs/version-management/dsagleitfaden-parallel.drawio.png differ diff --git a/docs/version-management/dsagleitfaden-softwarelieferant.drawio.png b/docs/version-management/dsagleitfaden-softwarelieferant.drawio.png new file mode 100644 index 0000000..958561c Binary files /dev/null and b/docs/version-management/dsagleitfaden-softwarelieferant.drawio.png differ diff --git a/docs/version-management/dsagleitfaden-verteilung.drawio.png b/docs/version-management/dsagleitfaden-verteilung.drawio.png new file mode 100644 index 0000000..492da79 Binary files /dev/null and b/docs/version-management/dsagleitfaden-verteilung.drawio.png differ diff --git a/docs/version-management/images b/docs/version-management/images new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/docs/version-management/images @@ -0,0 +1 @@ + diff --git a/docs/version-management/index.md b/docs/version-management/index.md index 14782e6..3996d29 100644 --- a/docs/version-management/index.md +++ b/docs/version-management/index.md @@ -13,6 +13,11 @@ nav_order: 6 {:toc} ## Einleitung/Motivation +Zu den aufbewahrungspflichtigen Dokumenten gem. HGB, AO und GoBS gehören auch die Repositoriy-Objekten in ABAP. Dies wurde lange Zeit durch die integrierte Versionsverwaltung innerhalb der ABAP-Workbench (SE80) erreicht. In den letzten Jahren hat sich aber ABAP weiterentwickelt, sei es der Einsatz einer externen Entwicklungsumgebung (ABAP Development Tools), der Einsatz von Git-Versionsverwaltung oder die Entwicklung weiterer Repository-Objekten, die nicht in der ABAP-Workbench entwickelt werden können. Daher stellt sich für jeden ABAP-Entwickler, die zentrale Frage: +* Welche Versionsverwaltung soll ich wann nehmen? + +Dieses Kapitel soll daher einen Überblick und eine Gegenüberstellung von Versionsverwaltungs-Lösungen innerhalb des SAP-Universums für ABAP-Entwickler geben. + ## Git-Grundlagen ## Einsatz von gitbasierten Lösungen in der ABAP-Entwicklung @@ -28,10 +33,50 @@ nav_order: 6 – Man kann alles zu einer Anwendung speichern (Dokumentation, Frontendcode, Backendcode) – Versionierung (Tags) +## Versionskontrollsysteme im SAP-Umfeld +Folgende Versionskontrollsysteme gibt es im SAP-Umfeld +### Lokale Versionsverwaltung in der SE80 +### Versionsverwaltung in ABAP Development Tools +### abapGit +### gCTS +### SAP BAS + ## Vergleich der unterschiedlichen Versionskontrollsystemen +### Versionskontrollsysteme + +#### Lokale Versionsverwaltung in der SE80 +#### Versionsverwaltung in ABAP Development Tools +#### abapGit in SAP GUI +#### abapGit in Eclipse +#### abapGit in der Cloud +#### gCTS onPremise +#### gCTS in der Cloud +#### SAP BAS ## Einsatzszenarien +### Normale 3-System-Landschaft +Bei diesem Einsatzszenario geht es darum, dass der Code auf dem Entwicklungssystem in ein Git-Repository mit einem Git-Versionsverwaltungssystem übertragen wird. + +![Alt text](dsagleitfaden-normal.drawio.png) + +### Softwarelieferant +Dieses Einsatzszenario dient zum Austausch zwischen Quellcode von einem Softwarelieferant an seinem Kunden über ein Git-Repository. +![Alt text](dsagleitfaden-softwarelieferant.drawio.png) + +### Verteilung in verschiedene Systemlandschaften +Hier geht es darum, dass man zwischen seinen verschiedenen Systemlandschaften Quellcode austausch. So ist es möglich ohne Quertransporte den gleichen Quellcode zu nutzen und weiterzuarbeiten. +![Alt text](dsagleitfaden-verteilung.drawio.png) + +### Recovery +Dieses Szenario beschreibt die Möglichkeit, dass aus dem Git-Repository ein alter Stand zurückgewonnen werden kann. +Dabei muss nicht jedes Repository-Objekt einzeln zurückgeholt werden, sondern ein alter Stand einer ganzen Anwendung. +![Alt text](dsagleitfaden-RECOVERY.drawio.png) + +### Paralleles Arbeiten +![Alt text](dsagleitfaden-parallel.drawio.png) + +### Custom Code Migration +![Alt text](dsagleitfaden-customcode.drawio.png) -– Entwicklung als Partner – Auslieferbare Software – Kundenentwicklung in einer normalen 3-System-Landschaft – Entwicklung in verschiedene Systemlandschaften verteilen – Recovery in drei Systemlandschaft @@ -52,3 +97,5 @@ nav_order: 6 ## Risiken ## Zusammenfassung ## Empfehlung +## Quellen +https://www.rheinwerk-verlag.de/git-und-sap/?srsltid=AfmBOooMbM45uQOGPLDAiaKz5hHazrf45BIEVjmOIe8mz9HjpdHjgzZq diff --git a/docs/version-management/softwarelieferant.png b/docs/version-management/softwarelieferant.png new file mode 100644 index 0000000..3699596 Binary files /dev/null and b/docs/version-management/softwarelieferant.png differ