Konsistentes Change- und Release Management für SAP

Transkript

1 Konsistentes Change- und Release Management für SAP Josef Huber General Manager

2 Inhaltsverzeichnis 1. Change und Release Management im SAP Umfeld Transportaufträge im SAP Umfeld Change Management mit Conigma Integration des Change Managements in den Service Desk Release Management Delivery Management Workbench Heterogene Technologien im Change und Release Management Global SAP Template Support Sicherstellung der Sarbanes Oxley Compliance Importstrategien von Conigma Konsistenzsicherung durch Reimporte Tracking von Reimporten Ausgabe des SOA/SOX Reports

3 Abbildungsverzeichnis Abbildung 1: Change Request in Conigma... 6 Abbildung 2: Mögliche Prozessübergänge... 7 Abbildung 3: Releasebäume in Conigma... 8 Abbildung 4: Conigma Delivery Management Workbench... 9 Abbildung 5: SAP Template Support Abbildung 6: Importqueue Abbildung 7: Importhistorie

4 Tabellenverzeichnis Tabelle 1: Importhistorie Ausgangsstand Tabelle 2: Importhistorie erster Import Tabelle 3: Importhistorie Vorabimport Tabelle 4: Importhistorie abschließender Import

5 1. Change und Release Management im SAP Umfeld Die Conigma Suite deckt das Change- und Release Management für SAP Transportaufträge ab. Im Rahmen dessen werden funktionale Anforderungen (Change Requests) mit Transportaufträgen (CTS Request) verknüpft Transportaufträge im SAP Umfeld Die Propagierung von Änderungen auf andere Systeme ist im SAP Standard nur im Rahmen des mitgelieferten Transportmanagementtools (SAP-TMS 1 ) möglich. Jede Änderung an der Applikation oder Datenbank muss in einem SAP Änderungsauftrag (CTS-Request 2 ) hinterlegt werden. Dieser beinhaltet SAP Aufgaben (CTS-Task), die einzelnen Entwicklern zugewiesen sind. Somit stellt ein CTS-Task einen Container für alle Objekte dar, die im Rahmen des übergeordneten SAP Änderungsauftrages auf dem Quellsystem verändert wurden. Dieser Änderungsauftrag wird als eine Einheit vom aktuellen System entlang der Transportroute in das nachfolgende System transportiert, sobald die unterliegenden SAP Aufgaben und der zusammenfassende Änderungsauftrag freigegeben sind. Dabei ist von SAP vorgesehen, dass CTS-Aufgaben den Entwicklern und der CTS-Änderungsauftrag dem Entwicklungsverantwortlichen zugeordnet werden. Erst wenn alle Änderungsaufgaben freigegeben wurden, kann der Änderungsauftrag freigegeben werden. Die Transportroute eines Änderungsauftrages kann im Rahmen des SAP-TMS frei konfiguriert werden. Üblich ist eine dreistufige Systemlandschaft, so dass Änderungen vom Entwicklungssystem in das Qualitätssystem propagiert (transportiert) werden. Sobald die Änderungen dort getestet wurden, können diese in das Produktivsystem eingebracht (importiert) werden. Bei der Freigabe des Entwicklungsauftrages im Entwicklungssystem wird die Änderung exportiert und in eine Binärdatei auf dem Dateisystem hinterlegt und für den Import in das nachfolgende System vorgemerkt. Über diese Datei können die Änderungen in andere SAP Systeme importiert werden. Bei komplexen Systemlandschaften und sehr großen Unternehmen ist es üblich, dass eine Vielzahl von Qualitätssicherungssystemen und Produktivsystemen existieren. Die Wartung der Transportrouten und die Verwaltung der Änderungen stellt in diesem Fall eine sehr komplexe Herausforderung dar, die ohne externe Hilfsmittel kaum zu bewältigen ist 3. 1 SAP-TMS bezeichnet das SAP-Transport Management System 2 Die Abkürzung CTS bezeichnet das Correction and Transport System von SAP. 3 Für weitere Informationen wird auf [KöNe05] (KÖESEGI, A.; NERDING, R.: SAP Änderungs und Transportmanagement. Bonn: Galileo Press 2005, 2., aktualisierte und erweiterte Auflage) verwiesen. 5

6 1.2. Change Management mit Conigma Einem Change Request werden in Conigma - üblicherweise im Prozessschritt In Arbeit - SAP Änderungsaufträge zugewiesen. Während ein Änderungsauftrag immer genau einem SAP System zugeordnet ist, kann ein Conigma Change Request Änderungsaufträge von verschiedenen Systemen beinhalten. Durch diese Tatsache wird sichergestellt, dass Conigma die funktionale Anforderung konsistent über den gesamten Prozess hinweg verwaltet. Ein Beispiel für einen systemübergreifenden Change Request ist eine Anforderung, in der ein Report im Business Warehouse (BI) um eine weitere Spalte erweitert werden soll. Dazu muss der Report aber auch die Quelle der Daten, der Extraktor auf dem ERP System, angepasst werden. In diesem Fall beinhaltet ein Conigma Change Request mindestens zwei Transportaufträge unterschiedlicher Systeme. Sobald der Change Request in den Status Interner Test gesetzt wird, muss sichergestellt sein, dass die funktionale Einheit vollständig getestet werden kann. Dazu müssen die damit verbundenen Transportaufträge in die unterschiedlichen Systeme importiert worden sein. Abbildung 1: Change Request in Conigma 6

7 Change Requests werden im Conigma Repository Browser verwaltet, der unterschiedliche Sichten auf den Change Request gewährt. Abbildung 1 zeigt den Change Request BW Report Change in seinem aktuellen Prozessstatus In Arbeit. Dem Change Request sind zwei Änderungsaufträge von unterschiedlichen Systemen (B10 und T04) zugeordnet. Unter den Änderungsaufträgen werden die Aufgaben dargestellt. Über das Kontextmenü kann der Change Request in den nächsten, möglichen Status gebracht werden. Bei Statusübergängen werden oft Übergangsbedingungen (z.b. 4-Augen- Prinzip) überprüft. Abbildung 2 zeigt wie ein Change Request über das Kontextmenü in einen anderen Status überführt wird. Abbildung 2: Mögliche Prozessübergänge Die intelligente Conigma Logik stellt sicher, dass der Change Request stets als eine Einheit bewegt wird und vom Prozessbenutzer keinerlei Wissen über Transportrouten oder das Handling von Änderungsaufträgen notwendig ist. Zudem ist durch die Verknüpfung von Änderungsaufträgen zu Change Requests stets sichergestellt, dass Änderungsaufträge nicht vergessen werden und die funktionale Anforderung hinreichend getestet werden kann und somit kein zusätzlicher Aufwand für die Administration entsteht Integration des Change Managements in den Service Desk Üblicherweise wird Conigma mit einer Service Desk Applikation verknüpft. Dadurch wird eine nahtlose Kopplung zwischen dem Incident, Problem, Release und Change Management sichergestellt. Während Conigma den Change und Release Management Prozess abdeckt und technische Komplexitäten (z.b. automatische Definition der richtigen Transportrouten übernimmt), wird das Incident Management üblicherweise durch eine externe Applikation sichergestellt. 7

8 Service Desk Applikationen wie beispielsweise der SAP Solution Manager ServiceDesk, BMC Remedy, HP OpenView, IBM Tivoli, CA Unicenter Service Desk, CA Change Manager for Distributed oder Telelogic Change Synergy können als externe Applikationen nahtlos in Conigma eingebunden werden. Ein Change Request erscheint beispielsweise dann im Workflow, wenn dieser im externen Service Desk genehmigt wurde. Im Rahmen des Prozessmanagements kann der jeweilige Status des Conigma Change Requests an den Service Desk zurückpropagiert werden Release Management Die Release Management Komponente wird von Conigma durch die Zuordnung von Change Requests zu Releases dargestellt. Hier wird zwischen logischen und technischen Releases unterschieden. Ein technisches Release kann als eine Bündelung von Change Requests verstanden werden. Logische Releases dienen der Strukturierung von technischen Releases und der besseren Übersicht im Conigma Repository Browser. Ein Change Request muss immer genau einem technischen Release zugeordnet werden. Abbildung 3: Releasebäume in Conigma Abbildung 3 zeigt eine mögliche Ausprägung einer Release-Hierarchie in Conigma. Je nach Customizing können logische Releases beliebig tief geschachtelt werden. Blattknoten müssen jedoch immer technische Releases sein, da nur diesem Releasetyp Change Requests zugewiesen werden können. In diesem Bild stellt Release 1.0 ein logisches Release dar, während es sich bei Tagesrelease 1.0 und Notfall 1.0 um technische Releases handelt. Releases können ebenfalls über einen Prozess verfügen. Je nach Customizing kann beispielsweise das Release geschlossen oder geöffnet sein. Dadurch kann das weitere Verhalten der zugeordneten Change Requests beeinflusst werden. In Conigma können für Releaseobjekte Datumsfelder frei definiert werden mittels derer das Delivery Management in Conigma gesteuert werden kann. 8

9 1.5. Delivery Management Workbench Die Delivery Management Workbench (DMWB) ist die zentrale Steuerungskomponente in Conigma, die die Belieferung der notwendigen Systeme vornimmt, sobald ein Change Request in ein Nachfolgesystem importiert werden muss. Üblicherweise ist diese Applikation gescripted (wird in der Konfiguration hinterlegt), so dass automatisiert in Abhängigkeit vom Releasetermin eine Belieferung durchgeführt wird. Abbildung 4: Conigma Delivery Management Workbench Abbildung 4 zeigt die Oberfläche der Delivery Management Workbench. Die Funktionalität wird üblicherweise im Hintergrund automatisiert durchgeführt. In der Auftragsliste (linker Teil des Bilds) sind die untergeordneten Änderungsaufträge der Change Requests zu sehen, die in das nächste System importiert werden sollen. Basierend auf dieser Wunschliste, berechnet die Conigma Delivery Management Workbench all jene Änderungsaufträge, die importiert werden müssen, um die Konsistenz des Systems sicherzustellen (siehe Konsistenzsicherung durch Reimporte). Die Wunschliste ist dabei immer eine Teilmenge der tatsächlich importierten Menge. Dies bedeutet, diese Liste wird immer importiert. Je nach Zustand der nachfolgenden Importqueues, kann jedoch eventuell mehr importiert werden. 9

10 1.6. Heterogene Technologien im Change und Release Management Die Komplexität der Change und Release Managementprozesse steigt mit der Anzahl der unterschiedlichen SAP Technologien. Bei vollem Einsatz der SAP Netweaver Plattform und der neuen Technologien treten immer mehr Change Requests auf, die Änderungen auf unterschiedlichsten Technologieebenen erfordern. Im Gegensatz zur ABAP Entwicklung, die noch aus Mainframe Zeiten stammt und sich auch von der Entwicklung daran anlehnt, handelt es sich im Java Umfeld um eine Client / Server Entwicklung. Aufgrund dieser Tatsache sind auch die Entwicklungsparadigmen komplett verschieden. Schwierigkeiten entstehen besonders dann, wenn ein funktionaler Change Request Änderungen in unterschiedlichen Technologien erfordert. Eine manuelle Abstimmung der unterschiedlichen Prozessschritte ist in größeren Umgebungen dann nicht mehr möglich bzw. führt meist zu fehlerhafter Synchronisation und Mehraufwand durch Experten, um diese Fehlersituationen zu erkennen und zu lösen. Conigma ist in der Lage, in einem kundendefinierten Change Management Prozess funktionale Anforderungen zu managen, die aus Änderungen in unterschiedlichen Technologien bestehen. Durch die intelligente Logik des Repository Browsers werden technologiespezifische Komplexitäten automatisiert, so dass unabhängig von den eingesetzten Basistechnologien ein einheitlicher Prozess definiert werden kann Global SAP Template Support In der Vergangenheit hat sich gezeigt, dass der Trend zu SAP Templates immer mehr zunimmt. Darunter ist zu verstehen, dass eine zentrale Einheit SAP Module vorkonfiguriert und damit einen großen Teil der Anforderungen aus verteilten Organisationseinheiten abdeckt. Die verbleibenden notwendigen Änderungen werden dann lokal in den einzelnen Organisationen abgebildet. Dadurch kann die zentrale Einheit global einen gemeinsamen Nenner implementieren, womit sich mehrfache Implementierung derselben Anforderungen auf lokaler Ebene und der damit verbundene Mehraufwand erübrigt. Das Management eines SAP Templates stellt eine hohe Herausforderung an das Change- und Release Management, da sowohl der Change Management Prozess der zentralen Einheit als auch die Change Management Prozesse der verteilten Organisationseinheiten aufeinander abgestimmt werden müssen. Conigma unterstützt diesen Ansatz, indem es ermöglicht, einen übergreifenden Change Management Prozess für eine verteilte Organisation zu definieren. Dabei wird der Change Management Prozess so definiert, dass Änderungen die von der zentralen Einheit durchgeführt werden nach Fertigstellung in die einzelnen Organisationen abgegeben werden. Mittels Conigma kann stets in Erfahrung gebracht werden, welche Änderungen 10

11 am globalen Template lokal bereits installiert wurden. Durch die lokalen Organisationen kann die Planung auch über Conigma abgestimmt werden, da stets ersichtlich ist, welche Änderungen in Zukunft mit welchen Aufwänden zu erwarten sind. Abbildung 5: SAP Template Support Abbildung 1 zeigt hierbei den Template Prozess. In der Template Entwicklung werden Change Requests umgesetzt, die in den einzelnen Organisationseinheiten dann nachkonfiguriert und leicht adaptiert werden. Conigma kann diesen komplexen Change Management Prozess vollständig unterstützen, indem für jede logische Einheit ein eigenständiger Change Prozess definiert wird, jedoch zwischen den einzelnen Change Requests Querbeziehungen automatisiert von Conigma hergestellt werden. 11

12 1.8. Sicherstellung der Sarbanes Oxley Compliance Sarbanes Oxley Compliance erfordert, dass Belege für jede Veränderung, die im Produktivsystem durchgeführt wurde, mindestens 18 Monate aufbewahrt werden müssen. Der Conigma Sarbanes Oxley Report untersucht die Historie der Importqueues und ordnet den importierten Änderungsaufträgen den passenden Conigma Change Request zu. Sollte ein Änderungsauftrag ohne Change Request importiert worden sein, wird dies im Report dargestellt. Durch den Report wird sichergestellt, dass für alle am Produktivsystem durchgeführten Änderungen auch tatsächlich ein Change Request vorliegt. Bei der Auswertung der Reportausgabe kann es vorkommen, dass Änderungsaufträge ausgegeben werden, die im selektierten Zeitraum nicht explizit importiert wurden. Hierbei handelt es sich um sog. Reimporte, die Conigma durchführt, um die Konsistenz des Systems sicherzustellen. Im folgenden Kapitel werden die Importstrategien von Conigma erläutert. 2. Importstrategien von Conigma Die Transaktion stms_import verwaltet im SAP Standard die Änderungsaufträge, die für das entsprechende System zum Import anstehen. Über diese Oberfläche kann ein Import mit bestimmten Optionen durchgeführt werden. Abbildung 6: Importqueue Abbildung 6 zeigt einen Ausschnitt einer Importqueue. Die Icons im rechten Bereich des Bilds zeigen mögliche Importoptionen auf. Änderungsaufträge können generell vorab importiert werden oder abschließend importiert werden. Da ein Änderungsauftrag als ein Container für 12

13 binäre Sourcen dient, ist die Importreihenfolge mit der Exportreihenfolge gleichzusetzen. Wird nicht in dieser Reihenfolge importiert, ist damit zu rechnen, dass eventuell neuere Sourcen durch ältere überschrieben werden. Anstatt eine vollständige Importqueue zu importieren, können auch einzelne Änderungsaufträge importiert werden. Dies wird dann als Vorabimport bezeichnet. Um die mit Vorabimporten verbundenen Risiken zu vermeiden, bleibt der Auftrag in der Importqueue und wird beim nächsten Import der vollständigen Queue erneut importiert. Dies stellt sicher, dass die Export- und Importreihenfolge immer gleich ist. Änderungsaufträge, die in der Importqueue mit einem grünen Haken angezeigt werden, sind bereits abschließend importiert worden. Änderungsaufträge mit einem gelben Warndreieck in der Queue wurden bereits ein- oder mehrmals vorab importiert. Ein Änderungsauftrag kann nur dann abschließend importiert werden, wenn alle seine Vorgänger abschließend importiert wurden. Andernfalls ist die Regel im SAP, dass die Exportreihenfolge mit der Importreihenfolge übereinstimmen muss, verletzt Konsistenzsicherung durch Reimporte Die Steuerung der Delivery Management Workbench stellt sicher, dass die Änderungsaufträge unterhalb eines Change Requests stets mit den richtigen Optionen importiert werden. Conigma entscheidet je nach Status der Queue und Position des Änderungsauftrags in der Queue, ob abschließend importiert werden kann oder vorab importiert werden muss. Das aktuelle Verhalten von Conigma lässt sich anhand folgender Queuestände erklären: Transportauftrag Status C14K C14K C14K C14K C14K C14K Tabelle 1: Importhistorie Ausgangsstand 13

14 Als Beispiel soll Tabelle 1 den Stand einer Importqueue mit den einzelnen Änderungsaufträgen in der Ausgangslage symbolisieren. Das grüne Quadrat zeigt wie im SAP Standard an, dass die Änderungsaufträge zum Import bereit steht. Im ersten Fall werden die Änderungsaufträge C14K900101, C14K und C14K importiert. Da diese Änderungsaufträge einen Block am Beginn der Importqueue repräsentieren, kann niemals ein zu einem späteren Zeitpunkt exportierter Änderungsauftrag vor diesen Änderungsaufträgen in der Queue einsortiert werden. Aus diesem Grund werden diese Änderungsaufträge von Conigma abschließend importiert. Tabelle 2 zeigt den neuen Stand der SAP Importqueue. Transportauftrag Status C14K C14K C14K C14K C14K C14K Tabelle 2: Importhistorie erster Import Basierend auf diesem Schritt soll nun der Änderungsauftrag C14K importiert werden. Da dieser nicht am Beginn der Queue steht, handelt es sich hier um einen Vorabimport. Conigma importiert den Auftrag vorab, er muss später jedoch nochmals importiert werden. Die Queue würde dann wie in Tabelle 3 aussehen: Transportauftrag Status C14K C14K C14K C14K C14K C14K Tabelle 3: Importhistorie Vorabimport 14

15 Im Folgenden werden die Änderungsaufträge C14K90099 und C14K importiert. Conigma stellt fest, dass alle vorangehenden Änderungsaufträge bereits abschließend importiert sind. Dadurch können auch die Änderungsaufträge C14K90099 und C14K abschließend importiert werden. Diese Aufträge können jedoch Programmteile enthalten, die älter sind als die Programmteile, die in Auftrag C14K enthalten sind. Da dieser Änderungsauftrag bereits im Produktivsystem enthalten ist, würde in diesem Fall eine bereits aktive und aktuellere Version mit einer Älteren überschrieben werden. Um hier die Konsistenz zu sichern, wird der Auftrag C14K nochmals importiert (hier handelt es sich um einen Reimport). Im Beispiel werden die Änderungsaufträge C14K90099, C14K und C14K abschließend importiert. Die Queue ist danach erfolgreich abgearbeitet und alle Änderungsaufträge wurden abschließend importiert, wie Tabelle 4 zeigt. Transportauftrag Status C14K C14K C14K C14K C14K C14K Tabelle 4: Importhistorie: abschließender Import 2.2. Tracking von Reimporten Durch die Conigma Konsistenzlogik kann es dazu kommen, dass im SOA Report für einen bestimmten Zeitraum Change Requests ausgegeben werden, die innerhalb dieses Zeitraumes nicht explizit in das Produktivsystem importiert wurden. Hierbei handelt es sich um Reimporte, die Conigma automatisiert durchführt, um die Konsistenz zu sichern. Dabei ist zu beachten, dass Reimporte nur dann auftreten, wenn der Change Request bereits einmal manuell zum Import beauftragt wurde. In diesem Zusammenhang ist die Ausgabe des SOA Reports und das Verhalten von Conigma korrekt: Ein Reimport kann nur dann auftreten, wenn der zugehörige Change Request bereits vorab explizit im Conigma Prozessmodell produktiv gesetzt wurde. Durch den Reimport stellt Conigma die Konsistenz 15

16 sicher. Das erneute Importieren eines Änderungsauftrages ändert jedoch nichts an der SAP Systemkonfiguration Ausgabe des SOA/SOX Reports Das Reimport Verhalten von Conigma spiegelt sich im Sarbanes Oxley Report wieder. So kann es sein, dass für einen bestimmten selektierten Zeitraum Änderungsaufträge ausgegeben werden, die innerhalb dieses Zeitfensters nicht explizit für den Import beauftragt waren sondern durch die Konsistenzsicherung von Conigma nochmals importiert wurden. Sofern über das Ergebnis des SOA Reports ermittelt werden soll, wann ein Änderungsauftrag im gewählten Zeitfenster importiert wurde, kann dies über die Importhistorie geschehen. Die SAP Transaktion stms_import führt zur Importhistorie, in der alle Änderungsaufträge ersichtlich sind, die innerhalb eines frei gewählten Zeitfensters importiert wurden. Abbildung 7: Importhistorie Abbildung 7 zeigt die Importhistorie eines SAP Systems. Es besteht jedoch aus der Historie im Standard keine Möglichkeit zu ermitteln, auf welche Art und Weise ein Änderungsauftrag importiert wurde. Im kommenden Conigma CCM Release 3.20 kann mittels des Conigma ReportManagers festgestellt werden, weshalb und mit welchen Modes ein Change Request importiert wurde. 16