Implementierung Eskalationsmanagement im HORIZON 1.1-Umfeld Erfahrungsbericht eines externen Dienstleisters Frank Gersbacher und Thorsten Berse, SUBITO AG | JBFOne 2009

Ziel dieses Vortrags Funktionalität Eskalationsmanagement (ESM) Technischer Ansatz Eskalationsmanagement (HORIZON 1.1) Erfahrungsberichte aus dem Projekt

Agenda Funktionalität Eskalationsmanagement Technischer Ansatz BatchJob-Kette Eskalationsmanagement Last- und Performancetests

Agenda Funktionalität Eskalationsmanagement Technischer Ansatz BatchJob-Kette Eskalationsmanagement Last- und Performancetests

Funktionalität ESM: Aufbau Eskalationsmanagement Nutzende Komponenten Eskalationsregeln bearbeiten Eskalationsregeln zuordnen Eskalationsbestand bearbeiten Überwachungsobjekte erzeugen Überwachungsobjekte beauskunften Eskalationsregeln Zuordnung Vorlagen / Regeln Zum einen können über zwei neue Funktionseinstiege im agree BAP die bankindividuellen Eskalationsregeln administriert sowie der Eskalationsbestand bearbeitet werden Zum anderen werden für nutzende Komponenten (z. B. Vorgang, GVM) Services bereitgestellt, um die Komponente Eskalationsmanagement zu integrieren. Überwachungsobjekte Eskalationsprotokoll = Funktionseinstiege Datenmodell Batchjob = Services

Funktionalität ESM: Überblick Facharchitektur am Beispiel Vorgang 1 2 3 4 Es können Eskalationsregel angelegt und geändert werden. Eine Regel kann unter anderen aus einer Warnung sowie 3 Eskalationsstufen bestehen. Eskalationsregeln werden den Vorlagen der nutzenden Komponenten zugeordnet. Jeder neue Vorgang bzw. Geschäftsvorfall, dem eine Eskalationsregel zugeordnet ist, erzeugt ein Überwachungsobjekt. Beim erzeugen des Überwachungsobjektes werden auf Basis der zugeordneten Eskalationsregel die Eskalationszeitpunkte ermittelt und mit abgespeichert. Bei der Anzeige in der To-do-Liste holt sich Vorgang von ESM den aktuellen Ampelstatus sowie den Eskalationszeitpunkt zu den einzelnen Objekten. (GVM macht dies in seiner eigenen Anwendung und geht nicht über die To-do-Liste.) Eskalationen können in ESM bearbeitet werden (verschoben, Maßnahmen erfassen) a: Über die nächtliche ESM Batchjobkette werden die aktuellen Eskalationen ermittelt und dem Vorgesetzen oder dem Organisationseinheiten-Leiter eine Eskalationsnachricht zugestellt b: Außerdem werden über die nächtliche ESM Batchjobkette die ÜO Historieneinträge aus der ESM Historientabelle zu Vorgang ins DWH übertragen und zu GVM in eine Archivtabelle Anzeige der Eskalationsnachricht als eigene Aktivität in der To-do-Liste 6 5 7 8

Funktionalität ESM: Eskalationsregeln anlegen Bei der Anlage der Eskalationsregel werden verschiedene Plausibilitätsprüfungen durchgeführt, z.B. darf die Warnung nicht vor der ersten Eskalationsstufe erfolgen Ist gibt eine Warnstufe und drei Eskalationsstufen Als Ersatzempfänger kann ein Bearbeiter oder eine Organisationseinheit ausgewählt werden Eskalationsregeln können nicht gelöscht werden, sondern nur deaktiviert werden Veränderungen der Eskalationsregeln werden in einer eigenen Historie gespeichert Über den Reiter „Zugerordnete Vorlagen“ werden die Vorgangsvorlagen und Vorgangselemente und die verknüpften Geschäftsvorfallvorlagen angezeigt

Funktionalität ESM: To-do-Liste Vorgang / Eskalationsnachrichten To-do-Liste Vorgang (Vorgangsbearbeitung) Eskalationsnachrichten (Vorgesetzter oder OE-Leiter) Der Eskalationsstatus und das Eskalationsdatum wird in der Vorgangs-To-do-Liste für den Anwender sofort angezeigt. Der Vorgesetzte oder Organisationseinheiten-Leiter erhält ab der Eskalationsstufe 2, bei GVM bereits ab der ersten Stufe, eine Eskalationsnachricht mit der Anzahl der Eskalationen als Aktivität Durch Aufruf der Aktivität gelangt man zu dem dazugehörigen Eskalationsbestand Die Aktivität verbleibt solange in der To-do-Liste, bis alle Eskalationen abgearbeitet wurden.

Funktionalität ESM: Eskalationsbestand Der Eskalationsbestand lässt sich entweder über die Aktivität oder über den direkten Aufruf des Funktionseinstieges bearbeiten Dazu sind allerdings besondere Berechtigungen notwendig Eskalationen lassen sich früher oder später terminieren. Außerdem können Maßnahmen erfasst werden, die dann entsprechend protokolliert werden.

Agenda Funktionalität Eskalationsmanagement Technischer Ansatz BatchJob-Kette Eskalationsmanagement Last- und Performancetests

Technischer Ansatz Modellierung Rational Software Architect (RSA) HORIZON 1.1 Projekt mit einer ORACLE-Datenbank Umsetzung gemäß agree Standardarchitektur (aSA), inklusive Mehrversionsfähigkeit DAM als Persistenz Cronacle-Batch-Jobs, File-API über LOB-Tab

Technischer Ansatz: Übersicht der Schnittstellen IKESA Eskalations- management Vorgang Kompetenz GVM Online Kalender- programm To-do-Liste Vorgesetzten- ermittlung Vertriebsmanagement Historisierung Batchjob Aktivitätenmanagement VTM Anbindung zum UG4.09 Interimsarchiv zum BAP UG1.10 Kombination Vorgang (BAP-Classic, DB2) mit ESM (HORIZON, ORACLE) war bisher nicht vorgesehen. Auswirkungen auf Baselibs, Build, Installationen, Controll-API  Inzwischen ist vieles in Standard übergegangen. spätere Aufbaustufe Interimsarchiv Zähler- bildung Cronacle Batch-Engine DWH spätere Aufbaustufe

Technischer Ansatz: Übersicht HORIZON Architektur G-PLEX agreeF 3 6 G M P agree H agree I F O W X Y NIB E DB2 A DWH-DB2 C JDBC-DB2 D Endkunde Bankanw. B R U V P-PLEX agree 1 1 2 4 5 J agree 2 8 9 A 7 D agree 3 L Q S T Z agree 7 E H I K N NIB 8 DB2 DWH-DB2 G JDBC-DB2 Endkunde Bankanw. TWS TWS Cronacle Cronacle CPS PPS TWS: Tivoli Workload Scheduler PPS: portalbezogener Processserver CPS: Central-Porcessserver Oracle Oracle BAP-Portale BAP-Portale Koexistenz

Technischer Ansatz: Kommunikationswege ESM P-Plex G-Plex Portal 1 Portal n Portal Process Server PS AQ-Listener JDBC ORACLE RAC HINWE JBF00 AQ 10g Erklärung aSA SOLARIS Trigger Files (LOB-Tabelle) z/OS TDB 1 TDB n agree® BASIS TWS OPC JCL/ COBOL MQ IMS-DB DB2

Agenda Funktionalität Eskalationsmanagement Technischer Ansatz BatchJob Kette Eskalationsmanagement Last- und Performancetests

BatchJob Kette Eskalationsmanagement BAP 3 BatchJob Kette Eskalationsmanagement BAP 3.5, Überwachung von Vorgängen / Geschäftsvorfällen SC_ESKAL_ESKALATIONJOB_00002 Lobfile Anlage von Überwachungsobjekten aus Vorgang (Online) FU306A VM237M SC_ESKAL_FAKTURAJOB_00001 Tivoli Workload Sceduler (TWS) Start einmal nach Dialogende ! FU306A Hostjob für SAP Anlage von Überwachungsobjekten aus GVM (Batch) Späte Vorgabe aus Produktion: 2 getrennte DWH-Jobs Restartfähigkeit LOBTab nicht gegeben, inzwischen gibt’s aber Lob-Tab-Implementierung mit eigener Transaktionsklammer. SC_ESKAL_DWHJOB_00001 FU306A DW589A SC_ESKAL_HISTLOESCHENJOB_00001 Cronacle Hostprogramm

BatchJob Kette Eskalationsmanagement BAP 3 BatchJob Kette Eskalationsmanagement BAP 3.6, Überwachung von Vorgängen / Geschäftsvorfällen / Vertriebsakten SC_ESKAL_ESKALATIONJOB_00002 Anlage von Überwachungsobjekten aus Vorgang (Online) Lobfile FU306A VM237M VM251M SC_ESKAL_FAKTURAJOB_00001 Tivoli Workload Sceduler (TWS) FU306A Start einmal nach Dialogende ! FU306A Lobfile Hostjob für SAP SC_ESKAL_BEARBEITUNGUO_00001 VM251M Programm erstellt ein sequentielles File mit relevanten VTM-Objekten, die an ESM gemeldet werden müssen. Das Programm reorganisiert die Tabelle TAVM0050 nach fachl. Kriterien (Programm ist Inhalt vom Projekt VTM) FU306A allg. Service-Programm zum Einfügen von Einträgen in der Oracle-Tabellen. Die Oracle-DB wird anhand der Daten des seq. File beschrieben. (Service-Programm steht in Produktion zur Verfügung) SC_ESKAL_BEARBEITUNGUO_00001 Java-Job liest Datensätze aus einem Lobfile. Anhand dieser Datensätze werden Überwachungsobjekte angelegt, weitergeleitet oder gelöscht. SC_ESKAL_FEHLERPARAMJOB_00001 Schreibt die Datensätze die aus fachlichen Gründen nicht verarbeitet werden konnten aus einer Oracle Tabelle in die Lobtab Liest die Datei mit den unverarbeiteten Datensätze aus der Lobtab und löscht die Datei nach dem einlesen aller Datensätze. ERSTEU01 Erstellt einen Incident, wenn unverarbeitete Datensätze vorhanden sind. SC_ESKAL_PARAMCLEANERJOB_00001 Löscht die unverarbeiteten Datensätze aus der Oracle Tabelle und die vom VM251M erstellte Lobfile mit den zu verarbeitenden Datensätze. SC_ESKAL_DWHJOB_00001 Anlage von Überwachungsobjekten aus GVM (Batch) FU306A DW589A SC_ESKAL_HISTLOESCHENJOB_00001 Cronacle Hostprogramm

Agenda Funktionalität Eskalationsmanagement Technischer Ansatz BatchJob Kette Eskalationsmanagement Last- und Performancetest Durchführung der Last- und Performancetest zu BatchJobs noch vor Beginn der PIT-Testphase Definition von Abnahmekriterien und Mengengerüste Probleme bei der Anlage einer Organisationsstruktur im BAP (Kompetenz)

Last- und Performancetests: ESM BatchJob Ermittlung der Eskalationen Testumgebung Die Last- und Performancetests wurden auf einem speziellen Testportal durchgeführt http://jportal10-ltest-e.bap.fiducia.de/ Testdaten 150.000 Überwachungsobjekte (ÜO) wurden in die Datenbank geladen Dies entspricht der Anzahl von ÜO einer großen Bank 40 % der ÜO eskalieren gleichzeitig in allen drei Stufen Eine umfangreiche Organisationsstruktur wurde angelegt BatchJob wurde mit unterschiedlichen Paketgrößen ausgeführt Testergebnisse Start Ende Durchlaufzeit Paketgröße Anzahl ÜO 15:13 Uhr 15:23 Uhr 10 Minuten 5.000 150.000 15:35 Uhr 15:45 Uhr 10.000 15:58 Uhr 16:09 Uhr 11 Minuten 25.000 16:27 Uhr 16:38 Uhr Erster Lasttest bereits vor PIT Start mit 2,5 Mio Überwachungsobjekten Vorgabe: 2,5 Mio ÜO in 2 Stunden Dabei wurde ein Problem bei Polymorpher-Suche identifiziert und behoben Des Weiteren wurden die SQL-Statements und Datenbank-Indizes optimiert Als endgültiges Abnahmekriterium wurden dann 150.000 ÜO von denen 40% eskaliert sind definiert

Last- und Performancetests: To-do-Liste Vorgang Testdaten Eine Vorgangsvorlage mit 10 parallelen Vorgangsschritten wurde definiert Dieser Vorgangsvorlage und den Schritten wurde eine Eskalationsregel zugeordnet, bei dem sowohl der Vorgang als auch die Schritte sofort eskalieren Auf der Lasttestumgebung wurden für 10 Bearbeiter jeweils 250 Vorgänge mit dieser Vorgangsvorlage angelegt (insgesamt 25.000 Vorgangsüberwachungsobjekte) Testdurchführung 50 virtuelle User wurden im Abstand von 15 Sekunden gestartet Diese 50 virtuellen User rufen die To-do-Liste-Vorgang über den JUnit-Testtreiber für die 10 Bearbeiter auf Parallel dazu wurde die To-do-Liste-Vorgang über den BAP-Dialog aufgerufen und die Ausführungszeit mit dem Command Flow Profiler (CFP) gemessen Ein Vorgang wird aus verschiedenen Vorgangselementen zusammengesetzt. Vorgänge wurden über Quick-Test automatisch angelegt

Last- und Performancetests: To-do-Liste Vorgang Testergebnisse Die durchschnittlich gemessene Ausführungszeit des Unit-Testtreibers gemessen über den LoadRunner lag bei unter 3 Sekunden Die Ausführungszeit für die To-do-Liste-Vorgang über den BAP (CFP-Messungen) lag zwischen 3 bis 6 Sekunden während des gesamten Testdurchlaufs Dies entspricht der Ausführungszeit von Vergleichsobjekten Auch unter Last verändert sich die Ausführungszeit nicht LoadRunner: Performance- und Lasttest Produkt von HP. Ermöglicht die Einrichtung von virtuellen Benutzern zur Erzeugung von Last oder zur Simulation der Produktivsituation Verbesserungsvorschläge: Verbesserung der Vorgaben und Bedingungen, unter der Last- und Performancetests durchzuführen sind Definition der zu messenden Parameter und damit diese vergleichbar gemacht werden können

Zusammenfassung Die neue agree BAP Komponente Eskalationsmanagement wird für Vorgang, Geschäftsvorfallsmanagement und Vetriebsmanagement zur Überwachung eingesetzt Weitere Komponenten können problemlos eingebunden werden ESM wurde unter HORIZON 1.1 entwickelt Die Erfahrungen aus dem Projekt sind in die Entwicklungs- und Testumgebungen eingeflossen

Fragen? – Diskussion? Frank Gersbacher SUBITO AG frank.gersbacher@subito.de 089 9943 – 3169 Thorsten Berse thorsten.berse@subito.de 06105 9702 - 188

Ihr IT-Partner Vielen Dank