Konsistentes Change- und Release Management für SAP - Josef Huber General Manager 27.11.2007
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
GALILEO
G RO U P
Konsistentes Change- und
Release Management
für SAP
Josef Huber
General Manager
27.11.2007
1
GALILEO
G RO U P
Inhaltsverzeichnis
1. Change und Release Management im SAP Umfeld ........................................................................................ 5
1.1. Transportaufträge im SAP Umfeld ......................................................................................................... 5
1.2. Change Management mit Conigma ....................................................................................................... 6
1.3. Integration des Change Managements in den Service Desk ................................................................. 7
1.4. Release Management ............................................................................................................................ 8
1.5. Delivery Management Workbench ........................................................................................................ 9
1.6. Heterogene Technologien im Change und Release Management ...................................................... 10
1.7. Global SAP Template Support.............................................................................................................. 10
1.8. Sicherstellung der Sarbanes Oxley Compliance ................................................................................... 12
2. Importstrategien von Conigma™ .................................................................................................................. 12
2.1. Konsistenzsicherung durch Reimporte ................................................................................................ 13
2.2. Tracking von Reimporten .................................................................................................................... 15
2.3. Ausgabe des SOA/SOX Reports............................................................................................................ 16
2GALILEO
G RO U P
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 ..................................................................................................................... 11
Abbildung 6: Importqueue .................................................................................................................................... 12
Abbildung 7: Importhistorie .................................................................................................................................. 16
3GALILEO
G RO U P
Tabellenverzeichnis
Tabelle 1: Importhistorie Ausgangsstand ............................................................................................................. 13
Tabelle 2: Importhistorie erster Import ................................................................................................................ 14
Tabelle 3: Importhistorie Vorabimport ................................................................................................................. 14
Tabelle 4: Importhistorie abschließender Import ................................................................................................. 15
4GALILEO
G RO U P
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.
1.1. 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 Entwicklungsverantwort-
lichen 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 Änderun-
gen 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 ist3.
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.
5GALILEO
G RO U P
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 ver-
schiedenen 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 Trans-
portaufträ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 unterschied-
lichen Systeme importiert worden sein.
Abbildung 1: Change Request in Conigma
6GALILEO
G RO U P
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.
1.3. 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.
7GALILEO
G RO U P
Service Desk Applikationen wie beispielsweise der SAP Solution Manager ServiceDesk, BMC
Remedy, HP OpenView, IBM Tivoli, CA Unicenter Service Desk, CA Change Manager for Distri-
buted 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ück-
propagiert werden.
1.4. Release Management
Die Release Management Komponente wird von Conigma™ durch die Zuordnung von
Change Requests zu Releases dargestellt. Hier wird zwischen logischen und technischen Re-
leases 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 im-
mer 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 beispiels-
weise 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 ge-
steuert werden kann.
8GALILEO
G RO U P
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“, be-
rechnet 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.
9GALILEO
G RO U P
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.
1.7. 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
10GALILEO
G RO U P
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 nachkonfi-
guriert und leicht adaptiert werden. Conigma™ kann diesen komplexen Change Manage-
ment Prozess vollständig unterstützen, indem für jede logische Einheit ein eigenständiger
Change Prozess definiert wird, jedoch zwischen den einzelnen Change Requests Querbe-
ziehungen automatisiert von Conigma™ hergestellt werden.
11GALILEO
G RO U P
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
12GALILEO
G RO U P
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.
2.1. Konsistenzsicherung durch Reimporte
Die Steuerung der Delivery Management Workbench stellt sicher, dass die Änderungsauf-
trä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
C14K900101
C14K900094
C14K900098
C14K900099
C14K900118
C14K900112
Tabelle 1: Importhistorie Ausgangsstand
13GALILEO
G RO U P
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 Änderungsauf-
träge C14K900101, C14K900094 und C14K900098 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
C14K900101
C14K900094
C14K900098
C14K900099
C14K900118
C14K900112
Tabelle 2: Importhistorie erster Import
Basierend auf diesem Schritt soll nun der Änderungsauftrag C14K900112 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
C14K900101
C14K900094
C14K900098
C14K900099
C14K900118
C14K900112
Tabelle 3: Importhistorie Vorabimport
14GALILEO
G RO U P
Im Folgenden werden die Änderungsaufträge C14K90099 und C14K900118 importiert.
Conigma™ stellt fest, dass alle vorangehenden Änderungsaufträge bereits abschließend
importiert sind. Dadurch können auch die Änderungsaufträge C14K90099 und C14K900118
abschließend importiert werden. Diese Aufträge können jedoch Programmteile enthalten,
die älter sind als die Programmteile, die in Auftrag C14K900112 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 C14K900112 nochmals importiert (hier handelt es
sich um einen Reimport). Im Beispiel werden die Änderungsaufträge C14K90099,
C14K900118 und C14K900112 abschließend importiert. Die Queue ist danach erfolgreich
abgearbeitet und alle Änderungsaufträge wurden abschließend importiert, wie Tabelle 4
zeigt.
Transportauftrag Status
C14K900101
C14K900094
C14K900098
C14K900099
C14K900118
C14K900112
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
15GALILEO
G RO U P
sicher. Das erneute Importieren eines Änderungsauftrages ändert jedoch nichts an der SAP
Systemkonfiguration.
2.3. 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.
16Sie können auch lesen
