ALM Kaffeekränzchen XII – ITSM und ChaRM Archivierung
Ihr naht euch wieder, schwankende Gestalten,
Die früh sich einst dem trüben Blick gezeigt.
[…]
Und mich ergreift ein längst entwöhntes Sehnen
Nach jenem stillen, ernsten Geisterreich
Goethe – Faust
Es war einmal
Voller Begeisterung haben wir den Sprung in die ALM Cloud gewagt und mit dem Selective Data Transfer (SDT) unsere Solution Documentation (SolDoc) in SAP Cloud ALM (CALM) und (ziemlich mühsam) in unser DMS hochgeladen. In Letzterem stehen jetzt die Functional und Technical Specifications unserer Anpassungen und Eigenentwicklungen. Wir fühlen uns auf der sicheren Seite.
Wie von SAP empfohlen, haben wir alle ChaRM und Focused Build Vorgänge und danach die Zyklen beendet und dokumentieren jetzt unsere Transporte nur noch mit Hilfe von SAP Cloud ALM Features.
Dass CALM keine ITSM Lösung anbietet, stört uns nicht, da wir sowieso externe Ticketing-Systeme, eines für die Bugs, das andere für die Projektarbeit, seit Langem im Einsatz haben.
Bisher wurden mit Hilfe des grandiosen blueworks alm360 Hub und dessen SolMan API alle Focused Build Vorgangsarten aus unseren Ticketing-Systemen per Online-Synchronisation im SAP Solution Manager (liebevoll SolMan genannt) angelegt und fern-gesteuert.
Mit einem einzigen Eingriff wurde beim Wechsel in die Cloud die SolMan Seite der Synchronisation ausgetauscht: Jetzt werden alle transport-relevanten Workflows über CALM Features fern-gesteuert. Die Anwender arbeiten dabei weiterhin in ihrer gewohnten Umgebung auf den Ticketing-Systemen und haben den Wechsel kaum gespürt.
Alles funktioniert wie am Schnürchen – ach, kann das Leben schön sein!
Unsere interne Revisionsabteilung hat uns versichert, dass wir nach dem Testat der Revisionsgesellschaft all die alten CRM-Dokumente (ITSM, ChaRM, Focused Build) nicht mehr aufheben müssen.
Wir haben schliesslich als allerletzten Schritt die CSOL Funktionalität in der gesamten Transport-Landschaft ausgeschaltet und mutig den glorreichen SAP Solution Manager (gelobt sei sein Name!), der uns zwei Jahrzehnte lang täglich mit seiner Stringenz im Änderungsprozess leicht irritiert, aber auch kräftig unterstützt hat, heruntergefahren. Bald danach haben wir die beachtlichen Ressourcen beim Provider freigegeben. Die Kostenersparnis kam bei der CIO sehr gut an.
Eines schönen Tages werden hässliche Inkonsistenzen im Produktivsystem entdeckt, oder es startet ein neues Projekt, oder ein neuer externer Revisor will doch noch tiefer in die Vergangenheit schauen, oder was sonst noch so alles passieren kann – die Realität ist fast immer phantasievoller als uns lieb ist –, nun, was auch immer der Grund für die Zeitreise sein wird: Wir müssen zu einer oder mehreren vergangenen Änderungen am Produktivsystem wissen: Wer hat sie initiiert, wer hat sie entwickelt, wer hat sie getestet, wer hat sie transportiert?
Zum Glück haben wir im Produktivsystem den tp-Parameter «vers_at_imp = always» gesetzt und können so im jeweiligen Workbench Editor unter Utilities -> Versions -> Version Management leicht die schuldige Transportnummer ermitteln. Denn in einem ABAP System sind Transporte immer auch Versionen.
Leider bietet das Customizing keine Versionierung an. Hier muss man mit dem SE03 Tool «Find Objects in Requests/Tasks» ziemlich mühsam die importierenden Transporte identifizieren – schwer, denn Customizing Objekte können ziemlich komplex sein…
Wir haben jetzt die schuldigen Transportnummern ermittelt: Vielleicht verrät uns der Kurztext Einiges. Doch dieser ist dürftig und sehr unsicher.
Die Erkenntnis drängt sich uns schleichend auf, dass wir die alten CRM-Dokumente und ihre Verkettung vom Transport zurück bis zum Incident oder zum Requirement benötigten, um die Änderungen, die uns interessieren, nachzuvollziehen. Denn diese Information steht leider nicht in unseren brav migrierten SolDoc Dokumentationen. Vielleicht waren wir und unsere Revisionsabteilung viel zu optimistisch…
Backup ist das Kälte-Gefühl, dass den Rücken hoch (back up) kriecht, wenn man knirschend feststellt, dass man ein Backup benötigt, aber keins (mehr) hat!
Plötzlich verstehen wir, warum Goethes Faust, dessen Anfangsverse wir eingangs zitiert haben, den Untertitel «Eine Tragödie» trägt. Denn wir sehnen uns vergeblich nach den alten CRM-Dokumenten, doch diese sind zusammen mit dem glorreichen SolMan unwiederbringlich in die Vergangenheit hinabversenkt[RE1] worden.
Panik bricht aus: Gibt es denn wirklich nirgendwo mehr Unterlagen?
O Freunde, nicht diese Töne!
«Vorsicht ist die Mutter der Porzellankiste», haben sich hellsichtige und erfahrene IT Kollegen eines blueworks Kunden gesagt und beschlossen – man weiss ja nie -, die Incidents der von ihnen verwendeten ITSM Anwendung im SAP Solution Manager sicherheitshalber zu archivieren, bevor sie ihren SolMan entsorgten. Charm oder Focused Build waren nicht im Einsatz.
Ein entscheidendes Merkmal der benötigten Archivierungslösung war die Möglichkeit, mit Standard Office Anwendungen die archivierten Incidents durchsuchen zu können. Man entschied sich also für eine Excel Lösung (was denn sonst, könnte man als erfahrener ITler sich lachend fragen). Und da einige dieser Incidents wichtige Anhänge enthielten, gönnte man sich den kleinen Luxus und beauftragte uns, zusätzlich auch vorhandene Anhänge mitzuarchivieren.
So ist die erste Version des Archivierungsreports /BLUWRKS/INCIDENT2EXCEL_ARCH durch direkten Kundenwunsch geformt entstanden.
Der Report bietet eine Selektion der zu sichernden CRM-Dokumente nach Nummer oder nach Vorgangsart. Die Ausgabe besteht aus einem Tabellenblatt, wahlweise als Excel xlsx oder LibreOffice odt, das über die SAP Gui in ein Verzeichnis auf dem lokalen PC heruntergeladen wird; jede Zeile enthält in ihren Zellen alle relevanten Daten des Incident CRM-Dokuments. Sind Anhänge vorhanden, so wird pro Vorgang ein Unterverzeichnis mit dessen Vorgangsnummer angelegt und mit den Anhängen befüllt.
Da Excel eine Begrenzung für die Zeilenhöhe hat, ist es bei längeren Texten umständlich, diese in Excel zu lesen; daher bieten wir die Option an, die Texte zusätzlich als leicht lesbare html-Dokumente in das jeweilige Unterverzeichnis für Anhänge auszugeben.
Wir haben schlussendlich den Report beim Kunden ausgeführt. Eine Excel-Datei mit fast fünftausend Incidents und mit einigen Anhängen in den jeweiligen Unterverzeichnissen wurde erzeugt. Nach einem letzten «Beautifying» Schritt des Tabellenblattens konnte das Ganze dem Archivierungssystem übergeben und der glorreiche SAP Solution Manager heruntergefahren werden.
Adieu, alter Freund!
Crescendo
Der nächste Kunde, der endgültig nach SAP Cloud ALM migrieren wollte, war ein langjähriger Focused Build (FB) Nutzer. Er hatte die zusätzliche Anforderung, dass die CRM-Dokumente auch als PDFs archiviert werden sollten.
So haben wir das von /BLUWRKS/INCIDENT2EXCEL_ARCH erzeugte Tabellenblatt um mehrere Spalten mit ChaRM/FB spezifischen Informationen erweitert und mit einer Smartform-Ausgabe angereichert. Und damit der gesamte Belegfluss nachvollziehbar werde, haben wir, wo vorhanden, die Transportnummern und die Vorgänger- und Nachfolger-Beziehungen beiden Ausgabeformaten hinzugefügt.
Es wurde rasch klar, dass die Archivierung einer Armee von fast 15.000 lebendigen und inhaltsreichen Focused Build CRM-Dokumenten voller Kommentaren und Anhängen eine ganz andere Nummer darstellte.
Eine Verarbeitung im Batch musste ermöglicht werden.
Ferner verlangte das vom Kunden eingesetzte Archivsystem eine flache Struktur ohne Unterverzeichnisse für die Indizierung. So bieten wir jetzt die Möglichkeit an, sämtliche Ausgaben mit einem eindeutig identifizierenden Präfix zu versehen.
Nun, man kann nicht ständig als Firefighter fremde Probleme lösen, manchmal hat man das Bedürfnis, als Ausgleich eigene sich vorzunehmen, daher haben wir einfach aus Freude an der ABAP-Entwicklung zusätzliche Komfort-Schmankerl eingebaut, wie z.B. eine Kontrollübersicht der getätigten Selektion, die Aktivierung des Zeilenumbruchs in der Excel-Ausgabe für die mehrzeiligen Zellen und die Bereitstellung des Spool-Protokolls als zusätzliches PDF-Dokument, damit es mit-archiviert werden könne.
Finale Furioso
So sieht jetzt das Selektionsbild von /BLUWRKS/INCIDENT2EXCEL_ARCH aus:
Wir selektieren in diesem Beispiel sämtliche Focused Build Vorgangsarten aus unserem Sandbox-System und erwarten 980 Einträge im resultierenden Excel Tabellenblatt sowie 980 Unterverzeichnisse mit den Anhängen, den html-Texten und dem PDF.
Nach einer Laufzeit von kaum mehr als 25 Minuten erhalten wir bereits das Ergebnis:
[…]
Die Ausgabe erfolgte in ein dediziertes Verzeichnis auf dem PC:
Hier zwei ausgewählte Beispiele aus der für diese Anzeige komprimierten Excelliste, eine Defect Correction mit ihrem Defect:
Man kann hier sehen, dass der Übersichtlichkeit halber die Texte in zwei Zellen getrennt wurden, LOG_TEXTS für die manuell eingegebenen Texte wie z.B. Reason, Proposed Solution, usw., und LOG_INTERNAL_NOTE für die maschinell bei Aktionen erzeugten.
Die zwei Verzeichnisse mit den Anhängen der zwei Beispiel-Dokumente:
Die zusätzliche Ausgabe der Defect Correction als PDF:
Das PDF des Beispiel-Defects erspare ich uns, wer im Deutschunterricht aufgepasst hat, kennt bereits den Inhalt.
Rauschender Beifall
Wir sind überzeugt, mit /BLUWRKS/INCIDENT2EXCEL_ARCH eine praktische sowie vollständige Archivierungs-Lösung für die CRM-Dokumente des SAP Solution Managers realisiert zu haben, die sämtlichen möglichen Kundenwünsche befriedigt.
Sämtliche möglichen Kundenwünsche bereits berücksichtigt… – warum bricht hier ein homerisches Lachen aus?
Der Weg zum Ausgang
Wer seinen SAP Solution Manager stilllegt, sollte sich eine Frage stellen, bevor er oder sie die Ressourcen freigibt: Was brauche ich in drei Jahren noch?
/BLUWRKS/INCIDENT2EXCEL_ARCH gibt eine pragmatische Antwo
rt darauf. Kein Add-on, keine Projektlaufzeit, kein grosses Budget – ein ABAP-Report, der seine Arbeit still und gründlich erledigt.
