TECHNISCHE UNIVERSITÄT DRESDEN FAKULTÄT INFORMATIK. Institut für Systemarchitektur Lehrstuhl Rechnernetze DIPLOMARBEIT

Transkript

1 TECHNISCHE UNIVERSITÄT DRESDEN FAKULTÄT INFORMATIK Institut für Systemarchitektur Lehrstuhl Rechnernetze DIPLOMARBEIT Thema: Konzeption und prototypische Entwicklung eines systemübergreifenden Monitoring-Tools zur prozessorientierten Kontrolle, Analyse und Bearbeitung von Datenaustauschaufgaben im Rahmen der Prozesse zur Liberalisierung des Energiemarktes bei der ENSO AG Vorgelegt von: Frank Beyer geboren am: in: Dresden Matrikelnummer: Betreuer: Dr. rer. nat. Dietbert Gütter, TU Dresden Dr. rer. pol. Torsten Krause, ENSO AG Verantwortlicher Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill, TU Dresden Tag der Einreichung:

2 Aufgabenstellung und Ziel der Diplomarbeit Im Rahmen der Gesetzgebung zur Liberalisierung des Energiemarktes ist jeder Geschäftspartner verpflichtet bestimmte Geschäftsprozesse mit anderen Marktpartnern auf elektronischem Weg in einem vordefinierten Format und Prozess abzuwickeln. Bei der ENSO AG sind in diesem Rahmen verschiedene IT Systeme (SAP-Systeme, Middleware Transconnect bzw. SAP PI und Lotus Notes) involviert. Im produktiven Einsatz der Schnittstellen kommt es durch verschiedene Einflussfaktoren (Fehlbedienung der Anwender, Programmierfehler, fehlerhafte Nachrichten der Marktpartner, nicht betrachtete Ausnahmefälle im Prozessablauf, eingeschränkte Systemverfügbarkeit etc.) zu Problemen des Datenaustausches. Aufgrund der verteilten Systeme ist deshalb die Kontrolle des Datenaustausches und im Fehlerfall die Analyse und Bearbeitung der Fehler sehr komplex. Im Rahmen der Diplomarbeit wird auf der Basis der Geschäftsprozesse untersucht, wie ein systemübergreifendes und prozessorientiertes Monitoring aufzubauen ist. Dafür sollen existierende Monitoring-Tools untersucht und auf ihre Stärken und Schwächen analysiert werden. Eine Aufstellung, welche Daten und Einflussfaktoren aus welchem System in welcher (aggregierten) Form verfügbar sein müssen, sowie eine Sammlung sinnvoller Verknüpfungen zu den wichtigsten Bearbeitungsfunktionen sind im Rahmen eines Anforderungskataloges an ein Monitoring-Tool zusammenzutragen. Eine prototypische Umsetzung der herausgearbeiteten Anforderungen soll am Beispiel eines Geschäftsprozesses im Rahmen der von dem Bundesverband der Energie- und Wasserwirtschaft für den deutschen Markt festgelegten Datenformatausprägungen und durch die Bundesnetzagentur standardisierten Prozessabläufe erfolgen. Dazu sind exemplarisch anhand eines Nachrichtentyps verschiedene Fehlerfälle zu simulieren und die Funktionsfähigkeit und Aussagekraft des Monitoring-Tools zu präsentieren. 2

3 Selbstständigkeitserklärung Hiermit erkläre ich, dass ich die von mir am heutigen Tage eingereichte Diplomarbeit zum Thema Konzeption und prototypische Entwicklung eines systemübergreifenden Monitoring-Tools zur prozessorientierten Kontrolle, Analyse und Bearbeitung von Datenaustauschaufgaben im Rahmen der Prozesse zur Liberalisierung des Energiemarktes bei der ENSO AG vollkommen selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt, sowie Zitate kenntlich gemacht habe. Dresden, den 31. März 2009 Frank Beyer 3

4 Vorwort Diese Diplomarbeit wurde vorgelegt von Frank Beyer und ist an Informatiker und Studenten im Bereich Architektur verteilter Systeme gerichtet. Sie entstand im Umfeld des Energieunternehmens ENSO Energie Sachsen Ost AG in Dresden. Die vorliegende Arbeit beinhaltet 5 Kapitel im Hauptteil sowie einen Anhang, ein Glossar, ein Abkürzungsverzeichnis und das Literaturverzeichnis. Die Nummerierung von Abbildungen erfolgt fortlaufend. Der Anhang enthält ergänzende Abbildungen, Erläuterungen und Quellcode. Quellen werden in eckigen Klammern angegeben, welche eine Abkürzung der Namen der Autoren, das jeweilige Jahr der Veröffentlichung und gegebenenfalls eine Seitenangabe enthalten. Erfolgt die Angabe der Quelle am Absatzende, bezieht sich diese auf den gesamten Absatz. Alle in dieser Diplomarbeit verwendeten Firmen- und/oder Produktnamen sind Warenzeichen und/oder eingetragene Warenzeichen ihrer jeweiligen Hersteller in ihren Märkten und/oder Ländern. Die beiliegende CD-ROM enthält neben Abbildungen sowie Literatur und einer Kopie der Diplomarbeit im PDF-Format auch den vollständigen Java- und ABAP- Quellcode der im Rahmen dieser Arbeit vorgenommenen Implementierung. Danksagung An dieser Stelle möchte ich mich ganz herzlich bei meinen Betreuern Dr. Torsten Krause und Dr. Dietbert Gütter sowie Mitarbeitern der ENSO AG, insbesondere Uwe Löbel und Johannes Geppert, für ihre Unterstützung, Anregungen und konstruktive Kritik bedanken. Ebenfalls bedanke ich mich bei Prof. Schill, der mir es ermöglichte, die Diplomarbeit bei der ENSO AG anzufertigen. Ein besonderer Dank gilt meiner Familie, die mich während des gesamten Studiums unterstützt hat und mir jederzeit mit Rat zur Seite stand. 4

5 Inhaltsverzeichnis 1 Einleitung Einführung in die Thematik des Monitorings Geschichte und Entwicklung der Geschäftsprozesse des deutschen Energiemarktes Situation der ENSO AG Zielstellung und Aufbau der Arbeit Grundlagen Verteilte Systeme Definition und Eigenschaften verteilter Systeme Architekturmodelle verteilter Systeme Middleware in verteilten Systemen Geschäftsprozess und Workflow Monitoring von verteilten Systemen Monitoring Modell Event-Spezifikation Weitere Merkmale von Monitoring-Werkzeugen Anwendungsgebiete des Monitoring verteilter Systeme System-Monitoring Geschäftsprozess-Monitoring auf Basis von Data Warehouses und Workflow Management Systemen Geschäftsprozess-Monitoring mit Business Activity Monitoring28 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Gesetzliche Vorgaben und Umsetzung in der ENSO Geschäftsprozesse im Rahmen der Liberalisierung des Energiemarktes Datenaustauschformat EDIFACT Workflow Anwendung der ENSO Istzustand der Prozessabwicklung Identifikation der Benutzergruppen der Geschäftsprozesse Bestehende Monitoring-Werkzeuge Fehler in den Geschäftsprozessen Sollzustand der Prozessabwicklung Anforderungskatalog für Monitoring Monitoring-Konzept

6 4 Prototypische Umsetzung Vorhandener Prototyp in der ENSO Architektur und Funktionsweise des Prototyps Aufstellung fehlender Funktionalitäten im Prototyp Erweiterung des Prototyps Erzeugung der Monitor-Daten in der SAP-Anwendung Verarbeitung und Präsentation der übertragenen Daten in der Serveranwendung Validierung der Prototyp-Erweiterung Zusammenfassung und Ausblick Anhang Ergänzungen zu den Grundlagen Infrastruktur kommunikationsorientierter Middleware Erweiterungen nachrichtenorientierter Middleware Aufbau eines WSDL-Dokuments (Version 1.1) Ergänzungen zur Prozessanalyse und Entwurf des Monitoring-Konzeptes Darstellung des Lieferantenwechselprozesses als Sequenzdiagramm und in Form von eepks Zuordnung DA-Prozesse zum Wechselbeleg in Abhängigkeit der Rolle Legende für Zustandsübergangsgraphen des Metamodells Klassische 3-Tier-Architektur einer Webanwendung Ergänzungen zur Prototypischen Umsetzung Aufruf eines Web Service mittels einer XSLT-basierten Routingregel des Transconnect-Middleware Definition der Scheduler-Task in der Konfigurationsdatei des Spring-Frameworks Service-Klassen und Ant-Skript Suchmaske für DA-Aufgaben (SubView) Controller-Klasse und JSPs für Menupunkt DA(ausgehend) und SubView für die Suche nach DA-Aufgaben Glossar Abbildungsverzeichnis Abkürzungsverzeichnis Literaturverzeichnis

7 1 Einleitung 1 Einleitung 1.1 Einführung in die Thematik des Monitorings Monitoring steht im Allgemeinen für die Durchführung von Überwachungsaufgaben von Systemen. Auf dem Gebiet der Informationstechnik werden diese Aufgaben durch computergestützte Monitoring-Werkzeuge realisiert. Die Anwendungsbereiche solcher Werkzeuge sind äußerst vielseitig: im Verkehrswesen zur Flugüberwachung im Terminal, in der Medizin als Patientenüberwachungsmonitor, in der Automatisierungstechnik zur Überwachung der produzierenden Maschinen, um nur wenige Beispiele zu nennen. Ursprünglich stammt der Begriff Monitoring jedoch aus der Informatikwelt ([Kra98]). In diesem Kontext versteht man Monitoring als die Überwachung von Anwendungen und deren zugrunde liegender Hardware. Angefangen mit der Überwachung von Hardwarekomponenten, um beispielsweise Serverausfälle oder Netzwerküberlastungen festzustellen, entwickelten sich Monitoring-Werkzeuge kontinuierlich weiter zu komplexen Systemen mit einem beträchtlichen Funktionsumfang. Neue Anforderungen wie die Überwachung von Systemen in Echtzeit und die Überwachung verteilter Systeme wurden in Monitoring-Werkzeugen für das Application und System Engineering realisiert ([TsYa95], [Zor00], [DG+04] und [Kur00]). Ein weiteres Anwendungsgebiet für Monitoring ist durch den Trend der Unternehmensumgestaltung von der Aufbau- zur Prozessorganisation entstanden ([Bec05], S.6f.). Moderne Unternehmen richten sich nach ihren Geschäftsprozessen aus und versuchen diese technisch und möglichst automatisiert umzusetzen. Um dieses Ziel zu erreichen, müssen oftmals mehrere, meist heterogene Anwendungen innerhalb der Unternehmensgrenzen gekoppelt werden (Enterprise Application Integration). Die Folge dieser Entwicklung ist, dass für die vollständige Überwachung und Steuerung der Geschäftsprozesse ein systemübergreifendes Monitoring-Konzept, ein so genanntes Geschäftsprozess- Monitoring, benötigt wird. Die Ziele dieses Ansatzes sind einerseits die Möglichkeit, Abschätzungen über die allgemeine Performance von Geschäftsprozessen machen zu können und andererseits kontextbasierte Information zu laufenden Prozessinstanzen zu liefern, die operativen Mitarbeitern im Unternehmen eine Entscheidungshilfe anbietet, auf diese Instanzen steuernd Eingriff zu nehmen. Die Analyse der Geschäftsprozessperformance ist ein recht bekanntes Teilgebiet und wird bereits durch zahlreiche Monitoring-Werkzeuge aus dem Bereich des Business Intelligence unterstützt ([Ham07]). Das grundlegende Ziel dieser Werkzeuge ist die Optimierung der Geschäftsprozess- und Workflow-Modelle von Unternehmen. Die Überwachung laufender, systemübergreifender Prozessinstanzen ist ein noch recht junges und wachsendes Anwendungsgebiet. Hier liegt der Fokus auf dem zeitnahen Bereitstellen von Prozessinformationen für die Mitarbeiter, die die tägliche Betreuung von Geschäftsprozessen durchführen. Besonders das von Gartner seit 2001 geprägte Konzept des Business Activity Monitorings (BAM) bietet hier interessante Ansätze für die Realisierung von Monitoring- Lösungen ([Rei08], S.72). Flexible und zeitnahe Anpassung an neue Wettbewerbssituationen, Fehlerbehandlung laufender Prozessinstanzen in Echtzeit sowie proaktives Identifizieren von Problemen in Prozessabläufen sind die Kernziele dieses Konzeptes. [Cru06], [BaJo07], [HeFi02] Das operative Geschäft von Unternehmen unterschiedlichster Branchen kann durch den gezielten Einsatz von Lösungen des BAM optimiert werden. 7

8 1 Einleitung 1.2 Geschichte und Entwicklung der Geschäftsprozesse des deutschen Energiemarktes Mit dem Erlass des Energiewirtschaftsgesetzes (EnWG) von 1998 begann die Liberalisierung des deutschen Energiemarktes. Staatlich eingerichtete Gebietsmonopole wurden abgeschafft und es sollte sich ein freier Wettbewerb im Energiesektor etablieren, um die Verbraucher zu den günstigsten Konditionen marktgerecht versorgen zu können. Zahlreiche Energielieferanten sind seitdem in den Energiemarkt vorgedrungen. [EnWG98] Trotz der gesetzlichen Bestimmungen gab es nach Inkrafttreten des EnWG Barrieren für den Einstieg neuer Marktpartner. Diese Partner waren darauf angewiesen den Netzzugang mit den verschiedenen Netzbetreibern des betreffenden Versorgungsgebietes auszuhandeln und sich somit anzupassen. Der dadurch verursachte Mehraufwand führte zu Benachteiligungen der neuen Marktpartner gegenüber bereits existierenden und besonders gegenüber integrierten Energielieferanten. Der Markteintritt und die Marktexpansion wurden erschwert oder konnten schlichtweg nicht realisiert werden. Dies ließ sich mit den zwei folgenden Faktoren begründen: 1. Die historisch gewachsene, enge Kopplung einer Vielzahl von Energielieferanten an einen Netzbetreiber (integrierte Energielieferanten). 2. Das Fehlen einheitlicher Geschäftsprozessbeschreibungen und eines einheitlichen Datenaustauschformats zwischen Marktteilnehmern im Energieversorgungssektor. Die Lösung des ersten Problems wurde mit der Novellierung des EnWG im Jahr 2005 durchgeführt ([EnWG05]). Dieses sieht die Entflechtung der Marktpartnerrollen des Energielieferanten und des Netzbetreibers innerhalb eines Energieversorgungsunternehmens vor. Das zweite Problem wurde durch energiespartenbezogene Beschlüsse der Bundesnetzagentur in den Jahren 2006 und 2007 adressiert. Die dort getroffenen Vereinbarungen bezüglich der Geschäftsprozesse und des einheitlichen Datenaustauschformates sind für alle Marktteilnehmer bindend und müssen durch die verwendeten Informationssysteme in den Unternehmen unterstützt werden. Somit wurden die Grundlagen für einen diskriminierungsfreien Wettbewerb auf dem Energiemarkt geschaffen. [GPKE06_1], [GeLi07_1] Im Zuge der kontinuierlichen Umsetzung der gesetzlichen Forderungen treffen die Energieversorgungsunternehmen auf Herausforderungen, die besonders im IT-Bereich zu enormem Modellierungs- und Implementierungsaufwand führen. Speziell beim produktiven Einsatz der IT-Anwendungen, die die Geschäftsprozesse und das verwendete Datenaustauschformat technisch umsetzen, treten verschiedene Probleme auf, die gelöst werden müssen. An dieser Stelle kommen Monitoring-Tools für die Prozessüberwachung ins Spiel, die ein wertvolles Werkzeug zur effizienten Konfliktlösung darstellen können. 1.3 Situation der ENSO AG Die ENSO Energie Sachsen Ost AG, im Weiteren ENSO genannt, ist ein Energieunternehmen in den Sparten Strom, Erdgas, Wärme und Wasser und versorgt über eine halbe Million Kunden in Deutschland. 8

9 1 Einleitung Im Zuge der Umsetzung der genannten gesetzlichen Beschlüsse und der damit verbundenen Einführung neuer Geschäftsprozesse, wurde die IT-Abteilung der ENSO beauftragt, diese technisch zu unterstützen. Das Ziel war die Verarbeitung von Nachrichten im festgelegten Electronic Data Interchange Format für die einheitlichen Geschäftsprozesse weitestgehend zu automatisieren, um den Mitarbeitereinsatz gering zu halten und Kosten zu sparen. Mit der Produktivsetzung der entwickelten Anwendung im Jahr 2008 zeichnet sich jedoch ein anderes Bild ab. Verschiedene Fehler treten während der Durchführung der Geschäftsprozesse auf und müssen durch Mitarbeiter manuell behandelt werden. Der daraus resultierende tägliche Arbeitsaufwand ist unerwartet hoch. Die Hauptgründe für diesen Aufwand sind die Komplexität der entwickelten Anwendung und die Verwendung heterogener Systeme als Anwendungsplattform. Die daraus resultierende Vielfältigkeit der Fehlerursachen und die notwendige Beteiligung von Mitarbeitern aus verschiedenen Unternehmensbereichen erhöhen die Komplexität der Fehlersuche und Fehlerklärung. Zusätzlich ist das verwendete Datenaustauschformat Änderungen unterworfen, die in der bestehenden Anwendung zum Auftreten neuer und unvorhersehbarer Fehler führen kann. Die beteiligten Mitarbeiter werden bisher bei der Fehlersuche nur unzureichend durch vorhandene Monitoring-Werkzeuge in den am Geschäftsprozess beteiligten Systemen unterstützt. Diese Standard-Programme arbeiten dezentral, verfügen nur über eingeschränkte Funktionalitäten und bieten zum Teil nur eine technische Sicht auf die Durchführung der Geschäftsprozesse. Die Lösung der beschriebenen Probleme bei der Fehlersuche erfordert jedoch eine zentrale und prozessorientierte Überwachung. Mithilfe einer derartigen Lösung könnten die Fehlersuche beschleunigt, der Arbeitsaufwand der Mitarbeiter reduziert und die Kosten gesenkt werden. 1.4 Zielstellung und Aufbau der Arbeit Das Ziel der Arbeit ist die Entwicklung eines Monitoring-Konzeptes zur systemübergreifenden Überwachung der Geschäftsprozesse in der ENSO. Anschließend soll ein auf diesem Konzept basierender Prototyp entwickelt werden, um die Tauglichkeit des Konzeptes überprüfen zu können. Folgende Vorgehensweise für die Problemlösung wurde für die vorliegende Arbeit gewählt: Kapitel 2: Zu Beginn werden arbeitsrelevante Begriffe aus den Gebieten der verteilten Systeme und des Geschäftsprozessmanagements definiert. Des Weiteren wird auf das Monitoring verteilter Systeme eingegangen und der Leser erhält einen Überblick über verschiedene Anwendungsgebiete des Monitorings (State of the Art). Vorhandene Konzepte werden aufgegriffen und abgewogen, inwiefern sie für die gesuchte Lösung einen Mehrwert enthalten. Kapitel 3: Im Hauptteil der Arbeit werden zunächst die zu überwachenden Geschäftsprozesse vorgestellt. Anschließend wird anhand des Geschäftsprozesses Lieferantenwechsel beschrieben, wie die zu überwachende Anwendung arbeitet. Es folgt ein Überblick über die aktuelle Tool-Unterstützung der Mitarbeiter bei der Fehlerbearbeitung und das daraus resultierende Optimierungspotenzial bei der Verwendung einer zentralen Monitoring-Lösung. Die in der Anwendung auftretenden Fehler werden anschließend kategorisiert und deren Fehlerbehandlung erläutert. In einem Anforderungskatalog werden die funktionalen und 9

10 1 Einleitung qualitativen Anforderungen sowie die Rahmenbedingungen für die Einführung einer zentralen Monitoring-Lösung aufgestellt. Der Hauptteil wird mit der Formulierung eines umfassenden Monitoring-Konzeptes abgeschlossen. Kapitel 4: In diesem Kapitel wird das aufgestellte Konzept in Form eines Monitoring- Prototyps umgesetzt. Eine vorhandene Anwendung in der ENSO, die bereits Teile des Konzeptes integriert, wird vorgestellt und fehlende Funktionalitäten werden beschrieben. Es folgt die Weiterentwicklung der bestehenden Anwendung. Der Entwurf und die Implementierung der erweiterten Funktionalität werden dokumentiert. Anhand verschiedener Testszenarien wird die Funktionsfähigkeit der durchgeführten Erweiterung validiert. Kapitel 5: Zum Abschluss der Arbeit werden die Ergebnisse der Umsetzung des Konzeptes zusammengefasst und ein Ausblick über zukünftige Entwicklungen gegeben. Kapitel 6: Der Anhang im Kapitel 6 enthält weiterführende Informationen zu den verschiedenen Kapiteln der Arbeit. An den Anhang schließen ein Glossar, das Abbildungsverzeichnis sowie das Abkürzungs- und das Literaturverzeichnis an. 10

11 2 Grundlagen 2 Grundlagen In diesem Kapitel werden die Grundlagen und Hintergründe für die vorliegende Arbeit erläutert. Zunächst werden einige Begriffe aus dem Bereich der verteilten Systeme beschrieben (2.1). Im nächsten Abschnitt wird allgemein auf das Geschäftsprozessmanagement und die damit verbundene Funktion des Monitorings eingegangen (2.2). Anschließend werden wichtige Konzepte des Monitorings im Bereich der verteilten Systeme vorgestellt (2.3). Schließlich beschreibt Abschnitt 2.4 die verschiedenen Anwendungsgebiete des Monitorings und nennt beispielhafte Umsetzungen. Dabei wird besonders auf BAM eingegangen, da dies wichtige Lösungsansätze für diese Arbeit enthält. 2.1 Verteilte Systeme Definition und Eigenschaften verteilter Systeme Die Erklärung des Begriffes Verteiltes System wurde in der Literatur in vielen Werken vorgenommen ([TsYa95], [Kur00], [ScSp07], [TavS03], [Ham05]). In dieser Arbeit wird folgende Definition als Referenz verwendet: Ein Verteiltes System setzt sich aus mehreren Einzelkomponenten auf unterschiedlichen Rechnern zusammen, die in der Regel nicht über gemeinsamen Speicher verfügen und somit mittels Nachrichtenaustausch kommunizieren, um in Kooperation eine gemeinsame Zielsetzung - etwa die Realisierung eines Geschäftsablaufs - zu erreichen. [ScSp07], S.4 Unter dem Begriff Verteiltes System werden sowohl Softwarekomponenten als auch zugrunde liegende Hardwarekomponenten verstanden, die über vernetzte Computer miteinander kommunizieren. Die oberste Zielsetzung bei der Konzeption eines verteilten Systems ist es, eine Funktionalität bereit zu stellen, die erst durch die Kooperation der unabhängigen Einzelkomponenten möglich ist ([ScSp07], S.5). Die Funktionalitäten sind beispielsweise der gemeinsame Ressourcenzugriff, Daten- und Lastverteilung, die Erhöhung der Fehlertoleranz, der Ausfallsicherheit und der Verfügbarkeit sowie eine gute Skalierbarkeit ([ScSp07], S.5f.). Eng verbunden mit dem Begriff des verteilten Systems ist die verteilte Anwendung, die den wirklichen Mehrwert einer verteilten Architektur ausmacht: Eine verteilte Anwendung nutzt ein verteiltes System, um Anwendern eine in sich geschlossene Funktionalität zur Verfügung zu stellen. [Ham05], S.17 Eine verteilte Anwendung bezieht sich nur auf die Gesamtheit der Anwendungslogik. Dabei betont Hammerschall, dass das verteilte System als Kommunikationsinfrastruktur genutzt wird und somit eine verteilte Anwendung ohne ein verteiltes System nicht existiert. Abbildung 1 stellt den Zusammenhang zwischen verteiltem System und der verteilten Anwendung dar. 11

12 2 Grundlagen Verteilte Anwendung Knoten Netz Anwendungskomponente Anwendungskomponente Knoten Verteiltes System Abbildung 1: Verteilte Anwendung Quelle: vgl. [Ham05], S.17 Die Anzahl der Knoten eines verteilten Systems sowie die Verteilung der Anwendungskomponenten muss in Abhängigkeit der Anforderungen an die verteilte Anwendung festgelegt werden. Beispiele für verteilte Anwendungen sind einfache Internetanwendungen wie programme, FTP-Zugriffsdienste oder verteilte Informationssysteme wie Online-Banking, Internetshops und weitere spezielle Anwendungen aus den Bereichen der eingebetteten und mobilen Systeme ([Ham05], S.17f.). Bei der in dieser Arbeit untersuchten Anwendung handelt es sich um eine verteilte Anwendung, die durch die IT-Abteilung der ENSO entwickelt und betreut wird. Aus diesem Grund empfiehlt es sich, einen kurzen und allgemeinen Überblick über die Bestandteile und Architekturkonzepte von verteilten Systemen zu geben. Für weiterführende und umfangreichere Informationen sei auf die Spezialliteratur [ScSp07], [TavS03] und [Ham05] verwiesen Architekturmodelle verteilter Systeme Ein Architekturmodell beschreibt die verschiedenen Rollen der Komponenten einer verteilten Anwendung und deren Beziehungen. Nach [Ham05], S.22ff. werden vorrangig die Architekturmodelle Client-Server und Peer-to-Peer eingesetzt. Letzteres spielt im Kontext dieser Arbeit keine Rolle und wird nicht näher betrachtet, stattdessen wird auf die bereits genannte Spezialliteratur verwiesen. Das von verteilten Anwendungen häufig implementierte Client-Server-Konzept ist gekennzeichnet durch einen kurzlebigen Clientprozess, der Anfragen an einen langlebigen Serverprozess stellt. Der Clientprozess erfüllt eine festgelegte Aufgabe und wird anschließend beendet. Der Serverprozess hingegen läuft über einen längeren Zeitraum und muss explizit durch einen Administrator beendet werden. In der aktiven Zeit beantwortet der Serverprozess Anfragen von einem oder mehreren Clientprozessen. Bei dem Entwurf von verteilten Anwendungen ist das entscheidende Kriterium, wie die Komponenten auf die Knoten des verteilten Systems verteilt werden, um ein Maximum an Leistung und Sicherheit zu erreichen. Aus diesem Grund werden die n-tier-architekturen als Ergänzung zum Client-Server-Modell verwendet, die die Verteilung der Komponenten beschreiben. Der aus dem Englisch stammende Begriff Tier bezeichnet eine Stufe und steht in diesem Zusammenhang für einen eigenständigen Prozessraum innerhalb der Anwendung. Typischerweise werden die drei Aufgaben Präsentation, Anwendungslogik und Datenhaltung auf die Tiers verteilt. In der Praxis werden häufig 2- bis 4-Tier Architekturen eingesetzt. Bei einer 2-Tier-Architektur wird beispielsweise die Präsentationskomponente auf den Client-Tier und die Datenhaltungskomponente 12

13 2 Grundlagen auf den Server-Tier verteilt. Die Anwendungslogik wird individuell aufgeteilt. Der Vorteil einer 2-Tier-Architektur ist die einfache Programmierbarkeit von verteilten Anwendungen. Nachteilig ist, dass die Anwendungen mit steigender Komplexität schnell unstrukturiert werden und schlecht skalierbar sind ([Ham05], S.16). Aus diesen Gründen werden heute kaum noch 2-Tier-Architekturen verwendet, sondern 3-Tier oder n-tier-architekturen eingesetzt. Bei diesen wird die Anwendungslogik auf einen oder mehreren eigenständigen Tiers verteilt. Die Vorteile sind die zentrale Administrierbarkeit und eine gute Skalierbarkeit der Anwendung. Die Realisierung von Tier-Architekturen mit 3 und mehr Stufen erfolgt in der Praxis meist in Form von Middleware mit Hilfe eines Application Servers ([ScSp07], S.24) Middleware in verteilten Systemen Middleware-Produkte unterstützen die Entwicklung verteilter Systeme und haben verschiedene Ausprägungsformen. Für die vorliegende Arbeit wird folgende Beschreibung von Middleware als Referenz verwendet: Middleware ist eine [...] generische Softwareplattform, die ein Bindeglied zwischen Betriebssystem und Netzwerk einerseits und der Anwendung andererseits darstellt. [ScSp07], S.208 Middleware ist somit als eine Softwareschicht zwischen dem verteilten System und der verteilten Anwendung zu verstehen, die die Aspekte der Netzwerkprogrammierung so weit möglich und sinnvoll abstrahiert ([Ham05], S.19). Die Entwicklung verteilter Anwendungen soll durch den Einsatz von Middleware vereinfacht werden, da bestimmte Verteilungsaspekte verborgen und somit transparent werden. Ein typisches Beispiel einer solchen Transparenz ist der Zugriff auf Ressourcen. Einer Anwendungskomponente bleibt es weitestgehend verborgen, ob der Aufruf entfernt oder lokal stattfindet. Die Middleware übernimmt die Aufrufvermittlung. Weitere Arten von Transparenz sind Fehlertransparenz, Nebenläufigkeitstransparenz und Replikationstransparenz ([ScSp07], S.20f. und [Ham05], S.21). Der Umfang der Funktionalitäten, die der verteilten Anwendung durch eine Middleware zur Verfügung gestellt werden, ist sehr unterschiedlich und produktabhängig ([ScSp07], S.212 und [Ham05], S.19). In [Ham05], S.19 wird eine Einordnung in kommunikations- und anwendungsorientierte Middleware vorgenommen. Eine vergleichbare Charakterisierung wird in [ScSp07], S.208ff. vorgenommen. Eine kommunikationsorientierte Middleware stellt einer verteilten Anwendung eine Infrastruktur zur Verfügung, die die Kommunikation zwischen den einzelnen Komponenten ermöglicht. Diese Infrastruktur stellt ein Kommunikationsprotokoll, Techniken zur Datentransformation und Mechanismen zur Fehlerbehandlung bereit 1. Unterschieden werden bestehende kommunikationsorientierte Middleware- Technologien in Middleware, die auf Basis entfernter Aufrufe operiert, und nachrichtenorientierte Middleware. Zu den Technologien der entfernten Aufrufe zählen unter anderem der Sun Remote Procedure Call, Java Remote Method Invocation, SAP Remote Function Call (RFC) und auch Webservices mit dem SOAP- Kommunikationsprotokoll. Die Idee ist, dass lokale und entfernte Aufrufe nach einem einheitlichen Prinzip erfolgen. Der Ablauf eines entfernten Aufrufes ist in Abbildung 2 dargestellt. 1 Für weitergehende Erläuterungen zu den drei genannten Bestandteilen siehe Anhang

14 2 Grundlagen Clientprozess Serverprozess Clientfunktion Serverfunktion Client-Stub Server-Stub Abbildung 2: Ablauf eines entfernten Aufrufes Quelle: vgl. [Ham05], S.40f. Ein so genannter Client-Stub im Client-Prozess simuliert das Verhalten der aufgerufenen Serverfunktion und leitet den Aufruf mit den Parametern über das Netz an den Server weiter. Der Server-Stub nimmt die Information zum Aufruf entgegen und ruft die entsprechende Funktion auf. Die Ergebnisse der Funktion werden über den umgekehrten Weg an den Client zurückgegeben. Die Kommunikation findet synchron statt, da der Client während des Aufrufs blockiert wird. Dies führt zu einer engen Kopplung zwischen Client und Server. Außerdem muss der Server während des gesamten Aufrufs erreichbar sein. Der Vorteil der synchronen Kommunikation ist die zeitnahe Bereitstellung der gewünschten Informationen bei zeitkritischen Aufrufen. Im Gegensatz dazu basieren nachrichtenorientierte Middleware-Technologien auf asynchroner Kommunikation. Die Daten und Aufrufe werden in Form von Nachrichten zwischen Empfängern und Sendern transportiert (siehe Abbildung 3). Nachricht Nachricht Sender Empfänger Warteschlange Abbildung 3: Ablauf einer asynchronen Nachrichtenübermittlung Quelle: [Ham05], S.41 Die Nachrichten werden durch den Sender in eine Warteschlange eingestellt und zu einem beliebigen Zeitpunkt von einem oder mehreren Empfängern abgeholt. Der Sender wird nicht blockiert und überprüft nicht, ob die Nachricht wirklich ankommt. Der Vorteil dieser Kommunikation ist, dass Sender und Empfänger unabhängig voneinander arbeiten können und nicht gleichzeitig erreichbar sein müssen. Im Bereich nachrichtenorientierter Middleware existieren wenige Standards ([Ham05], S.42; [ScSp07], S.210). Den aktuell wichtigsten Standard stellt der Java Message Service dar, der in verschiedenen kommerziellen und Open- Source-Lösungen verwendet wird. Eine anwendungsorientierte Middleware erweitert die genannten Funktionalitäten einer kommunikationsorientierten Middleware um eine Laufzeitumgebung, weitere Dienste und ein Komponentenmodell ([Ham05], S.62) 2. 2 Eine Beschreibung der Erweiterungen anwendungsorientierter Middleware erfolgt im Anhang unter

15 2 Grundlagen Im Fokus steht die Unterstützung der verteilten Anwendung. Dies ist insbesondere bei software-intensiven Anwendungen wie Informationssystemen oder Internetanwendungen hilfreich. Die genannten Erweiterungen werden von existierenden Middleware-Technologien in unterschiedlicher Art und Weise unterstützt und in Abhängigkeit der verteilten Anwendung in verschiedenem Maße genutzt. Eine anwendungsorientierte Middleware wird generell durch einen Application Server implementiert. Auf dem Softwaremarkt existiert eine Vielzahl von kommerziellen und Open-Source-Lösungen von Application Servern ([ScSp07], S.212). Viele dieser Application Server unterstützen zudem Enterprise Application Integration (EAI) durch integrierte Werkzeuge und Schnittstellen ([ScSp07], S.211). EAI wird allgemein in [ScSp07], S.29 beschrieben: EAI bezeichnet eine Mischung aus Konzepten, Technologien und Werkzeugen, die in ihrer Gesamtheit die Integration heterogener Anwendungen unterstützen. Die Middleware-Produkte, die EAI unterstützen, bieten neben der Kommunikation zwischen Anwendungskomponenten auch die Interaktion zwischen vollständigen Anwendungen an. Diese Funktionalität wird unter anderem genutzt, um existierende Software an neue Systeme zu koppeln. Ein typisches Beispiel ist die Anbindung von SAP R/3 an die Middleware, um die betriebswirtschaftliche Standard-Software eines Unternehmens mit weiteren Anwendungen zu kombinieren. Es können Anwendungen, die auf verschiedenen Technologien basieren, miteinander kommunizieren ohne dass die Anwendungen verändert werden müssen. Die technischen Vorteile von EAI sind der vereinfachte Austausch von Software, aufgrund des niedrigen Kopplungsgrads zwischen den Anwendungen und die Verringerung der Komplexität durch weniger benötigte Schnittstellen, was besonders bei einer hohen Anzahl an Anwendungen den Implementierungsaufwand senkt. Des Weiteren ermöglicht EAI die Trennung der Anwendungslogik von der Schnittstellenprogrammierung. Der wesentliche Vorteil von EAI für den Anwender ist die Möglichkeit, neue und leistungsfähigere Geschäftsabläufe zu realisieren. In [Kel02], S.5ff. werden verschiedene Anwendungsgebiete für EAI beschrieben. Eines dieser Gebiete ist die Geschäftsprozessintegration, bei der zur Durchführung eines Geschäftsprozesses auf verschiedene Anwendungen zugegriffen wird (Abbildung 4). Abbildung 4: EAI-Geschäftsprozessintegration Quelle: [Kel02], S.26 Die Ankopplung der Anwendungen wird durch eine EAI-Middleware übernommen und der Ablauf des Geschäftsprozesses wird durch Nutzung eines Workflow Management Systems (WFMS) gesteuert. Die in dieser Arbeit zu untersuchende Anwendung enthält eine EAI-Komponente, die in Teilabschnitt beschrieben wird. 15

16 2 Grundlagen Eine weitere Möglichkeit EAI zu realisieren ist die Verwendung von Web Services ([Fer08]). Sie wurden entwickelt, um die Kommunikation zwischen Maschinen in heterogenen Umgebungen zu ermöglichen. Stellvertretend für eine Vielzahl von Definitionen von Web Services wird an dieser Stelle die Beschreibung vom World Wide Web Consortium (W3C) angeführt: A Web service is a software system designed to support interoperable machineto-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. [W3C04] In der Beschreibung der Schnittstelle eines Web Service werden die zur Verfügung stehenden Operationen mittels Kombination der konsumierten und produzierten Nachrichten definiert. Die Programmiersprache, die für die Implementierung der Operationen genutzt wird, ist irrelevant. Es existieren unter anderem Web Service-Lösungen für die Java-Plattform,.Net-Plattform, und für PHP ([Ham05], S.122). Web Services sind eine Implementierung der Serviceorientierten Architektur. Die wichtigsten Basistechnologien von Web Services sind SOAP, WSDL und UDDI. UDDI steht für Universal Description, Discovery and Integration und wird als standardisiertes Dienste-Verzeichnis eingesetzt. UDDI spielt im Kontext dieser Arbeit eine untergeordnete Rolle. Für nähere Informationen wird auf die Spezialliteratur in [ApMe02] verwiesen. SOAP und WSDL werden im Folgenden näher vorgestellt. SOAP: SOAP ist das vom W3C standardisierte Nachrichtenprotokoll zur Übertragung von Datenpaketen im XML-Format zwischen Web Services. Es setzt auf vorhandenen Transportprotokollen auf, vorwiegend HTTP. Eine SOAP-Nachricht besteht aus einem Header, der Zusatzinformationen wie Transaktions- und Sicherheitsattribute beinhaltet und einem Body, der die Nutzdaten enthält (Abbildung 5). Die aktuelle Version ist 1.2. SOAP-Envelope SOAP-Header Zusatzinformationen SOAP-Body Daten Abbildung 5: Aufbau einer SOAP-Nachricht Quelle: [Ham05], S.119 WSDL: WSDL steht für Web Service Description Language und ist ein XML- Dokument, das die Spezifikationen, wie der Web Service verwendet wird, enthält. In einem WSDL-Dokument werden die verfügbaren Operationen eines Web 16

17 2 Grundlagen Services in Form von Nachrichten, die zwischen den Kommunikationspartnern ausgetauscht werden, den darin verwendeten Datentypen, dem verwendeten Transportprotokoll, sowie der Adresse unter welcher der Service aufrufbar ist, beschrieben. WSDL ist ein W3C-Standard, der in der aktuellen Version 2.0 vorliegt. Oftmals wird noch Version 1.1 in Web Service-Engines eingesetzt ([Bra08_1]). Der Aufbau eines WSDL-Dokuments in der Version 1.1 wird im Anhang unter beschrieben. WSDL-Dokumente werden selten von Hand erfasst. Spezielle Werkzeuge von Web Service-Frameworks übernehmen die Generierung einer WSDL- Schnittstellendefinition aus der Schnittstellendefinition spezifischer Programmiersprachen. Zusammenfassend ist die Verwendung eines Web Service auf Basis von SOAP und WSDL zwischen dem Dienstnutzer (Web Service Client) und dem Dienstanbieter (Web Service Provider) in Abbildung 6 dargestellt. Client Anwendung Server Anwendung Nutzdaten Nutzdaten XML Web Service Client find WSDL publish XML Web Service Provider bind SOAP HTTP Abbildung 6: Funktionsweise Web Service Quelle: vgl. [Bra08_1] Ein Dienstnutzer interagiert mit einem Dienstanbieter, der die Schnittstellenbeschreibung des Web Service in Form einer WSDL-Datei direkt an den Nutzer übergibt oder in einem öffentlichen Dienste-Verzeichnis registriert. Anschließend bindet sich der Nutzer an den gewählten Dienst, lässt die gewünschte Operation ausführen und erhält das Resultat. 17

18 2 Grundlagen Folgende Vor- und Nachteile kennzeichnen die Technologie von Web Services (vgl. [Ham05], S.125 und [Bra08_1]): Vorteile: Interoperabilität aufgrund offener Standards für Schnittstellenbeschreibung und Nachrichtenaustausch Nutzung und Erhaltung vorhandener Anwendungsfunktionalität Plattform- und Programmiersprachenunabhängigkeit Ausreichende Unterstützung der Implementierung durch Werkzeuge Kostengünstige Realisierung, da nur geeignete Webinfrastruktur benötigt wird Nachteile: Performance-Verlust aufgrund von XML-Overhead der Nachrichten und Notwendigkeit des XML-Parsings Web Services werden vorrangig im Internet und unternehmensübergreifend eingesetzt. Das Ziel ist die Realisierung komplexer Geschäftsmodelle durch Zusammenarbeit mehrerer Web Services ([Ham05], S.120). Die Orchestrierung von Web Services zur Realisierung komplexer Geschäftsprozesse erfolgt mittels Prozessbeschreibungssprachen, beispielsweise Business Process Execution Language (BPEL). Dennoch können Web Services auch in EAI Anwendungen, also innerhalb von Unternehmen, Verwendung finden. 2.2 Geschäftsprozess und Workflow Nachdem die technischen Grundlagen von verteilten Systemen im vorangegangenen Abschnitt behandelt wurden, wird im Folgenden auf den Einsatz von verteilten Anwendungen in Unternehmen eingegangen. Wie in der Definition einer verteilten Anwendung beschrieben, soll durch sie eine geschlossene Funktionalität zur Verfügung gestellt werden. Diese Funktionalität dient in Unternehmen der Unterstützung von Geschäftsprozessen. Ein Geschäftsprozess kann wie folgt beschrieben werden: Ein Geschäftsprozess ist eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen oder Organisationseinheiten unter Nutzung von Informations- und Kommunikationstechnologien ausgeführt werden können. Er dient der Erstellung von Leistungen entsprechend den vorgegebenen, aus der Unternehmensstrategie abgeleiteten Prozesszielen.[ ] [Gad08], S.46 Die konkrete Ausprägung eines Geschäftsprozesses wird als Geschäftsprozessinstanz bezeichnet. Eng verbunden mit dem Begriff des Geschäftsprozesses ist der Workflow. Während ein Geschäftsprozess die Frage beantwortet, was getan werden soll, beschäftigt sich ein Workflow mit der Aufgabe wie ein Geschäftsprozess umgesetzt werden soll ([Gad08], S.59): Ein Workflow ist ein formal beschriebener, ganz oder teilweise automatisierter Geschäftsprozess. Er beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die für eine automatische Steuerung des Arbeitsablaufes auf der operativen Ebene erforderlich sind. Die hierbei anzustoßenden Arbeitsschritte sind zur Ausführung durch Mitarbeiter oder durch Anwendungsprogramme vorgesehen. Von dem Workflow als Typ oder Schema eines teil- bzw. automatisierten 18

19 2 Grundlagen Arbeitsablaufes zu unterscheiden ist eine Workflow-Instanz, die eine konkrete Ausprägung des Workflows bezeichnet. [Gad08], S.53 Wie aus den Definitionen hervorgeht, ist es nicht erforderlich, dass eine verteilte Anwendung oder Software in einem Geschäftsprozess involviert ist. Aus diesem Grund unterscheidet Gadatsch in Workflows nach dem Grad ihrer Computerunterstützung ([Gad08], S.58). So werden freie Workflows vollständig manuell durch Personen bearbeitet, wo hingegen automatisierte Workflows ohne Eingriff eines personellen Bearbeiters durch ein Programm ausgeführt werden. Eine Mischform dieser beiden Arten stellt der teilautomatisierte Workflow dar. In vielen Branchen ist es heutzutage aus Aufwands- und Kostengründen notwendig, computergestützte Anwendungen, beispielsweise Informationssysteme, bei der Durchführung von Geschäftsprozessen einzusetzen. Inwieweit diese Anwendungen verteilt sind, hängt von den geforderten Funktionalitäten ab (siehe 2.1.1). Ein typisches Beispiel für die Unterstützung eines Geschäftsprozesses durch eine verteilte Anwendung ist ein Internetshop. Der Prozess des Bestellungseingangs wird vollständig durch die Anwendung abgewickelt. Der Bestellungseingang umfasst das Anlegen einer Bestellung durch den Kunden, die Aufnahme einzelner Positionen aus einem Warenkatalog, Auswahl einer Zahlungsmethode und das Versenden der Bestellung an das Lieferunternehmen. Die anschließenden Prozesse von der Bestellungsprüfung bis zum Warenversand können durch betriebswirtschaftliche Standardsoftware, beispielsweise ERP- Systeme, unterstützt werden. Aufgrund des anhaltenden Kostendrucks sind Unternehmen daran interessiert, ihre Geschäftsprozesse möglichst effizient zu gestalten, zu optimieren und an sich ändernde Gegebenheiten anzupassen. Diese Ziele können mit Hilfe des Geschäftsprozess- und Workflowmanagements (BPM und WFM) realisiert werden. BPM und WFM sind integrierte Bestandteile eines Konzeptes, das [...] dem Abgleich mit der Unternehmensstrategie, der organisatorischen Gestaltung von Prozessen sowie deren technischer Umsetzung mit geeigneten Kommunikationsund Informationssystemen dient. ([Gad08], S.1). BPM definiert die Geschäftsprozesse auf der fachlich-konzeptionellen Ebene und WFM erweitert die Prozesse um Spezifikationen auf der operativen Ebene, die die Umsetzung im Unternehmen beschreiben. Dieses Konzept wird nicht einmalig für ein Unternehmen durchgeführt, sondern muss vielmehr als ein zyklischer Vorgang verstanden werden, der die kontinuierliche Sicherung und Verbesserung der Prozessqualität zum Ziel hat. Für die Durchführung des WFM wird ein WFMS eingesetzt. Ein WFMS besteht aus zwei Komponenten ([Bec05], S.14): 1. Entwicklungsumgebung zur Modellierung und Prüfung von Workflows 2. Laufzeitumgebung zur Ausführung, Überwachung und Steuerung von Workflowinstanzen Ein WFMS kann in betriebswirtschaftlicher Standardsoftware integriert sein ([Bec05], S.269) und dient als optionale Steuerungsschicht oberhalb der Basis- Funktionalitäten. Ein Beispiel ist das Produkt Business Workflow der SAP AG, das auch in der ENSO eingesetzt wird. Für die Überwachung der Workflows ist im WFMS Modell der Workflow Management Coalition eine eigens dafür zuständige Schnittstelle angegeben ([Bec05], [Gad08]). Diese Schnittstelle beschreibt den Zugriff auf den Workflow Audit Trail, der die Verarbeitung der Workflowinstanzen innerhalb eines WFMS protokolliert. Je nach eingestellten Detailgrad werden mehr oder weniger Bearbeitungsschritte 19

20 2 Grundlagen der Workflowinstanzen in einer Log-Datei zur Laufzeit abgespeichert. Darauf basierende Monitoring-Werkzeuge werden in erläutert. 2.3 Monitoring von verteilten Systemen Monitoring ist ein Anwendungsgebiet der Informatik, das bereits seit über 30 Jahren existiert ([DG+04]). Grundlegende Arbeiten, wie [JG+87] und [SaSl92], beschreiben Erkenntnisse, die heute noch als Referenz gelten. In diesem Abschnitt werden die grundsätzlichen Konzepte und Begriffe des Monitorings von verteilten Systemen und Anwendungen überblickartig dargestellt Monitoring Modell Zunächst soll der Begriff des Monitoring näher betrachtet werden. Diese Erklärung basiert auf der von Kurschl durchgeführten Analyse in [Kur00], S.33. Demnach stammt der Begriff Monitor vom lateinischen Wort monere ab, was übersetzt als Aufseher bzw. Mahner zu verstehen ist. Ein Monitor in der Informatik wird als Programm oder System verstanden, das Überwachungsaufgaben durchführt. Monitoring verteilter Systeme wird allgemein als die Tätigkeit der Überwachung und Beobachtung eines verteilten Systems definiert. In [JG+87] werden die Tätigkeiten von Monitoring genannt: The monitoring of distributed systems involves the collection, interpretation, and display of information concerning the interactions among concurrently executing processes. Das Monitoring verteilter Systeme umfasst demnach die Sammlung, Interpretation und Darstellung von Informationen nebenläufiger Prozesse. Diese Informationen beschreiben den Zustand des überwachten Systems. Zustandsänderungen werden in Form von Events aufgezeichnet. Jedem Event können Attribute zugeordnet werden, die beispielsweise Zeitpunkt, Ort und Zusatzinformationen der Aktivität beschreiben. Anhand dieser Attribute, der Reihenfolge der aufgetretenen Events und des aktuellen Zustands kann das Verhalten des Systems bzw. seiner Komponenten rekonstruiert werden. Zur Beschreibung von Monitoring-Systemen kann das in [Kur00], S.66 erläuterte Modell verwendet werden. Dieses umfasst die folgenden drei Aktivitäten: Erzeugung: Verarbeitung: Präsentation: Relevante Zustandsinformationen des verteilten Systems oder der verteilten Anwendung werden identifiziert und zu Berichten zusammengefasst. Diese Aktivität umfasst die Verarbeitung der erstellten Berichte. Die Monitoring-Informationen werden validiert, korreliert, gefiltert und zusammengefasst. Die gesammelten Rohdaten werden in Abhängigkeit des gewünschten Abstraktionsgrades verdichtet, gespeichert und gegebenenfalls an verschiedene Empfänger weitergeleitet. Die verdichteten Informationen werden den Nutzern in geeigneter Form angezeigt. 20

21 2 Grundlagen Dieses Monitoring-Modell wird in der Literatur in identischer oder ähnlicher Form als Referenz verwendet ([Zor00], [Kur00], [TsYa95], [Kra98], [Bec05]). Auf die drei Aktivitäten wird in Teilabschnitt anhand der Architektur des BAM näher eingegangen Event-Spezifikation Events können auf verschiedenen Abstraktionsebenen liegen und müssen in Abhängigkeit der Aufgabe des Monitorings spezifiziert werden. [Luc02], S.11ff. beschreibt die allgemeine Schichtenarchitektur einer verteilten Systemlandschaft innerhalb von Unternehmen und die Events, die den verschiedenen Schichten zugeordnet werden können (Abbildung 7). Business Layer Business Processes and Operations Application Layer Internet Portal Teamware Purchase App Middleware Layer CORBA Information Buses Network Layer Networks Gateways Firewalls Abbildung 7: Architektur verteilter Systemlandschaft Quelle: vgl. [Luc02], S.11 Die oberste Schicht beschreibt die Planung und Durchführung der Geschäftsprozesse eines Unternehmens unter der Nutzung verschiedener Anwendungen. Ein Beispiel für ein Event auf dieser Ebene ist der Abschluss eines Bestellprozesses, bei dem mit verschiedenen Lieferanten verhandelt wurde. Die Events auf der Anwendungsschicht beschreiben Nutzerinteraktionen oder nutzer-verständliche Aktivitäten, wie beispielsweise das Versenden einer oder das Auslösen einer Bestellungsanfrage. Die darunter liegenden Events auf der Middleware-Schicht umfassen die Kommunikation zwischen Anwendungskomponenten oder separater Anwendungen. Die Events auf der Netzwerkschicht beziehen sich auf die Datenübertragung zwischen den Rechnerknoten und die Hardware eines verteilten Systems. Typische Events dieser Schicht sind das Eintreffen von Datenpaketen, das Eintreten von Fehlern während der Übertragung und die Auslastung der Prozessor- und Speicherkapazität. Diese Schichten repräsentieren die verschiedenen Abstraktionsniveaus von E- vents. Zwischen den Events bestehen schichtenübergeifende Abhängigkeiten (vertikale Abhängigkeit) und Abhängigkeiten innerhalb von Schichten (horizontale Abhängigkeiten). Diese Abhängigkeiten müssen bei der Auswahl der zu 21

22 2 Grundlagen überwachenden Events für einen Monitor berücksichtigt werden, damit dieser die gewünschte Funktionalität erfüllt. In diesem Zusammenhang müssen prinzipiell zwei Probleme gelöst werden: Zum einen müssen die Events auf der Schicht überwacht werden, auf der der Nutzer des Monitorings im Unternehmen arbeitet. Zum anderen müssen die Events innerhalb der Schicht in entsprechender Form dargestellt werden, so dass der Nutzer bei der Erfüllung seiner Aufgaben hinreichend unterstützt wird (vgl. [Luc02], S.50). Eine geeignete Darstellungsform kann durch Aggregation von Events erreicht werden. Kurschl unterscheidet in [Kur00], S.67f. aus diesem Grund einfache Events, die einen geringeren Informationsgehalt haben, und zusammengesetzte Events, die eine größere Aussagekraft haben und damit das Verständnis des überwachten Systems erhöhen. Ein zusammengesetztes Event entsteht durch die Aggregation von einfachen oder bereits zusammengesetzten Events. Ein simples Beispiel wäre die Aggregation der Events Senden und Empfangen einer Nachricht zum Event Nachricht übertragen. Diese Aggregation ist beispielsweise sinnvoll, wenn eine Auswertung der Übertragungsdauer durchgeführt werden soll Weitere Merkmale von Monitoring-Werkzeugen Eine weitere Klassifizierung von Monitoring-Werkzeugen ist anhand verschiedener Merkmale möglich. In [DG+04] wird eine Taxonomie beschrieben, die eine Einteilung von Monitoring-Werkzeugen, die zur Erkennung von Software-Fehlern genutzt werden, in vier Kategorien und jeweilige Unterkategorien vornimmt. Für diese Arbeit wird nur eine begrenzte Auswahl von Merkmalen vorgestellt, die besonders relevant für die durchzuführende Anforderungsanalyse sind: Zeitgesteuertes und Eventgesteuertes Monitoring: Die Zustandsinformationen der überwachten Objekte in verteilten Systemen und Anwendungen werden durch Sensoren erfasst und an einen Monitor übertragen (Erzeugung). Der Sensor kann durch eine Zustandsänderung oder durch die direkte Anfrage des Monitors ausgelöst werden. Eine Auslösung durch Zustandsänderung wird als eventgesteuertes Monitoring bezeichnet. Diese Form des Monitoring kann als Push-Methode verstanden werden, da die Übertragung der Statusinformation durch das Zielsystem initiiert wird. Beim zeitgesteuerten Monitoring wird der Sensor in periodischen Zeitabständen durch Request- Response-Anfragen des Monitors ausgelöst und sendet den aktuellen Zustand eines überwachten Objekts zurück. Diese Vorgehensweise wird als Polling bezeichnet und hat entscheidende Nachteile gegenüber dem eventgesteuerten Ansatz. Ein Kritikpunkt ist die inhärente Verzögerung bei der Benachrichtigung von Zustandsänderungen. Falls das Abfrageintervall zu groß definiert wird, können außerdem mehrere Zustandsänderungen innerhalb eines Intervalls nicht nachvollzogen werden, da nur der aktuelle Status übertragen wird. Durch die Verringerung des Abfrageintervalls wird das überwachte System leistungsmäßig stärker beeinträchtigt und eine größere Datenmenge muss übertragen und durch den Monitor verarbeitet werden. Aus diesen Gründen wird besonders bei Monitoring mit Echtzeit-Anforderungen der eventgesteuerte Ansatz verwendet. Bei einer Vielzahl von Zustandsänderungen im überwachten System ist es erforderlich, die Überwachung auf eine Teilmenge der Events zu beschränken oder eine Event- Aggregation bereits im Zielsystem durchzuführen, um die anfallende Datenmenge zu begrenzen. [MuRo00], [Kur00] 22

23 2 Grundlagen Instrumentierung: Die im vorhergehenden Absatz genannten Sensoren dienen der Bereitstellung von Daten für den Monitor. Die Sensoren müssen im Zielsystem installiert werden. Dieser Vorgang wird als Instrumentierung bezeichnet. Es existieren verschiedene Techniken, ein Zielsystem zu instrumentieren. Ein wichtiger Aspekt, der bei der Instrumentierung und der späteren Analyse der Monitoring-Daten berücksichtigt werden muss, ist der Einfluss der Sensorinstallation auf das Zielsystem. Ein Monitor benötigt Ressourcen wie CPU-Zeit, Speicher und Bandbreite zur Kommunikation. Müssen diese Ressourcen mit dem Zielsystem geteilt werden, resultiert daraus eine direkte Veränderung des Laufzeitverhaltens und eine Verfälschung der Monitoring-Daten. Diese Folge der Instrumentierung wird in der Literatur Untersuchungseffekt genannt ([Kur00], S.36). Auswirkungen auf das Verhalten des Zielsystems sind beispielsweise: Verzögerung von Zustandsübergängen aufgrund geringerer Systemleistung Veränderung der Reihenfolge von Zustandsübergängen Auftreten von Deadlock-Situationen durch Zugriff auf gemeinsame Ressourcen Falsche Resultate durch Ausführung einer instrumentierten Anwendung In Abhängigkeit der gewählten Instrumentierungsmethode fällt der Untersuchungseffekt unterschiedlich stark aus. Ein Monitor kann allgemein als Hardware-, Software oder Hybrid-Monitor klassifiziert werden. In [Kur00], S.45 wird darauf hingewiesen, dass bei Auswahl einer der genannten Instrumentierungskonzepte die Geschwindigkeits-, Portabilitäts- und Flexibilitätsanforderungen an den Monitor berücksichtigt werden müssen. [TsYa95], [Zor00], [DG+04] und [Kur00] beschreiben die drei genannten Klassen genauer. Für den Hintergrund dieser Arbeit ist eine komprimierte Beschreibung ausreichend: Hardware-Monitor: Die Sensoren werden in Form von separater Hardware direkt an die Systembusse des Zielsystems gekoppelt. Low-Level-Events wie Lese/Schreibe-Operationen, Interrupt-Signale und Anweisungen werden aufgenommen und zur Verarbeitung an die separate Monitor-Plattform weitergeleitet. Der Vorteil dieses Implementierungsansatzes ist die minimale Beeinträchtigung des Verhaltens des Zielsystems, da kein Instrumentierungscode benötigt wird und wenig bis keine Systemressourcen geteilt werden. Des Weiteren stehen die Daten unmittelbar nach Auftreten der Ereignisse dem Monitor zur Verfügung, da separate Hardware zum Einsatz kommt. Aus diesen Gründen werden Hardware- Monitore vorrangig bei der Überwachung von Echtzeitsystemen mit strengen zeitkritischen Anforderungen eingesetzt. Die Nachteile dieser Methode sind die Kosten für die zusätzliche Hardware, geringe Flexibilität und Portabilität so wie eine schwierige Interpretation der maschinennahen Daten. Software-Monitor: Die Sensoren dieser Monitor-Klasse werden als Software- Konstrukte im Zielsystem angelegt. Der Monitor ist als Anwendung im Zielsystem integriert und verwendet somit die Ressourcen des Zielsystems. Das führt zu einem stärker ausgeprägten Untersuchungseffekt, der die oben genannten Probleme zur Folge haben kann. Aus diesem Grund ist ein Einsatz dieser Monitor- Klasse in Echtzeitsystemen meist nicht zweckmäßig. Die Vorteile dieses Monitoring-Ansatzes sind hohe Flexibilität, um neue Anforderungen zu realisieren, hohe Portabilität, falls keine betriebssystem- oder hardwarespezifischen 23

24 2 Grundlagen Funktionen verwendet werden, und die problemlose Interpretation der Monitoring-Daten, aufgrund des anwendungsbezogenen Abstraktionsniveaus. Die Software-Instrumentierung wird prinzipiell unterschieden in Quellcode- und Objektcode-Instrumentierung ([Kur00], S.77ff.). Die häufig gewählte Methode ist das Einfügen von Anweisungen in den Quellcode, da sie mit geringerem Realisierungsaufwand verbunden ist. Das Einfügen der Instrumentierungsanweisungen kann automatisiert, beispielsweise durch den Compiler oder ein Visualisierungswerkzeug, oder manuell durch den Entwickler erfolgen. Hybrid-Monitor: Dieser Ansatz kombiniert die Vorteile der beiden beschriebenen Varianten. Die Sensoren werden in Form von Software im Zielsystem implementiert, um möglichst leicht interpretierbare Monitoring-Daten zu erhalten. Die anschließende Verarbeitung, Weiterleitung und Präsentation der Daten wird mit Hilfe separater Hardware-Ressourcen durchgeführt. Diese Maßnahme sichert auf der einen Seite die genannten Vorteile eines Software-Monitors und begrenzt die Auswirkungen des Untersuchungseffekts. Online- und Offline-Monitoring: Die Verarbeitung der durch Sensoren erfassten Monitoring-Daten erfolgt entweder zur Laufzeit des Zielsystems (online) oder nach dem Ende der Ausführung des Zielsystems (offline). Durch Online-Monitoring können Fehler im Ablauf des Zielsystems frühzeitig erkannt werden. Außerdem lassen sich die Sensoren dynamisch zur Laufzeit ein- und ausschalten. Die Zeitverzögerung zwischen Erzeugung und Verarbeitung der Daten ist wesentlich geringer als beim Offline- Monitoring. Im Offline-Fall müssen die Sensoren im Vorfeld festgelegt werden und die Messung erfolgt gewöhnlich über einen längeren Zeitraum. [Kur00], S.99 Eine zusätzliche Anforderung an einen Online-Monitor ist die Echtzeit-Fähigkeit ([TsYa95]). Diese Eigenschaft bezieht sich auf die zeitnahe und besonders zeitgerechte Bereitstellung der Informationen des überwachten verteilten Systems für den Nutzer. Steuerndes und nicht-steuerndes Monitoring: Diese Unterscheidung bezieht sich auf die Möglichkeit eines Monitoring- Werkzeuges in der Verarbeitung nach Auswertung der Monitoring-Daten Aktivitäten im Zielsystem auszuführen. Eine Aktivität ist beispielsweise das Aufrufen einer Methode oder das Beenden eines Prozesses. Dieser Zugriff wird entweder manuell durch den Anwender des Monitors ausgelöst oder erfolgt automatisiert nach dem Event-Action-Paradigma ([TsYa95], S.66ff.). Dieses Paradigma beschreibt die Überwachung der aktiven Prozesse im Zielsystem durch reaktive Prozesse im Monitor. Im Vorfeld der Prozessausführung wird durch ein Event-Action-Mapping definiert, welche Aktion bei Eintreten eines Ereignisses auszuführen ist. Automatisierte steuernde Eingriffe in das Zielsystem werden durch Regelsysteme definiert. In diesem Zusammenhang besteht ein großes Analyse- und Entwicklungspotenzial. Besonders heuristische Methoden und Ansätze künstlicher Intelligenz können in Zukunft neue Formen von Anwendungen hervor bringen ([Rei08], S.100). Ein nicht-steuernder Monitor dient lediglich der Anzeige von Informationen und führt keine Aktivitäten im Zielsystem aus. Aktives und Passives Monitoring: Passives Monitoring beschränkt sich auf die Visualisierung der verarbeiteten Monitoring-Daten. Der Anwender muss in diesem Fall selbst aktiv werden und die 24

25 2 Grundlagen entsprechenden Informationen durch Starten des Monitors abrufen. Aktives Monitoring setzt den jeweiligen Informationsempfänger automatisch durch Alarmierungen, über aufgetretene Fehler bzw. Normabweichungen in Prozessen in Kenntnis. Typische Formen von Benachrichtigungen sind das Versenden von s, SMS oder Paging-Nachrichten. 2.4 Anwendungsgebiete des Monitoring verteilter Systeme Wie aus dem vorangehenden Abschnitt hervor geht, sind verschiedene Entwurfsfragen bei der Entwicklung einer Monitoring-Lösung zu berücksichtigen. Die beiden entscheidenden Ausgangspunkte zur Beantwortung dieser Fragen sind einerseits die Zielpersonen, die mit der zu entwickelnden Lösung arbeiten werden, und die Aufgaben, die mit Hilfe des Monitoring unterstützt werden sollen. Im Vorfeld der Entwicklung des Monitoring-Konzeptes für die ENSO wurde eine Literaturrecherche in verschiedenen Anwendungsgebieten des Monitoring durchgeführt. Bestehende Ansätze wurden analysiert und auf Verwendbarkeit für die Aufgabenlösung geprüft. Folgende Anwendungsgebiete wurden untersucht: System-Monitoring, Geschäftsprozess-Monitoring auf Basis von Data Warehouses und WFMS und Geschäftsprozess-Monitoring mit BAM. Die Analyse ergab, dass BAM die interessantesten Ansätze für die Bearbeitung der Aufgabenstellung liefert. Aus diesem Grund wird auf das Anwendungsgebiet von BAM näher eingegangen. Zunächst werden die beiden anderen Bereiche überblicksartig vorgestellt und es wird begründet, warum derartige Lösungen für das zu entwickelnde Konzept nicht geeignet sind System-Monitoring Lösungen des System-Monitorings sind Hilfswerkzeuge für Entwickler und IT- Administratoren von verteilten Systemen. Entwickler verwenden derartige Werkzeuge für die Überprüfung funktionaler Anforderungen und die Durchführung von Performanz- und Lasttestanalysen von Anwendungen in der Test- und Wartungsphase ([Kur00], S.34 und [Fug03]). In [Kur00], S.114ff. werden verschiedene Monitoring-Lösungen vorgestellt, die die Entwicklung von Anwendungen auf Supercomputern und Workstations unterstützen. Ein Beispiel ist das ZM4/SIMPLE-Monitoringsystem, das für umfassende Leistungsanalysen und bewertungen von parallelen und verteilten Systemen eingesetzt wird. [DG+04], S.4ff. gibt einen Überblick über bestehende Monitoring-Lösungen, die auf die Erkennung von Softwarefehlern spezialisiert sind. Java with Assertions ist ein Monitor, der vor dem Kompilierungsprozess Java- Programme instrumentiert, um Fehler zur Laufzeit zu entdecken. In [BaGu05_1] und [BaGu05_2] wird die Monitoring-Lösung Dynamo beschrieben, die instrumentierte Web Service BPEL-Prozesse dynamisch zur Laufzeit überwacht. Unter anderem können die Aufrufparameter der Web Services kontrolliert werden. Mit Hilfe eines Prioritätsparameters kann die Überwachung zur Laufzeit aktiviert bzw. deaktiviert werden. System-Monitoring für IT-Administratoren bezieht sich auf die Überwachung und Pflege von IT-Systemen und Netzwerken. Das Ziel ist die störungsfreie Ausführung von Anwendungen bei optimaler Systemperformanz. Dieses Monitoring wird unter anderem von Dienstleistungsunternehmen eingesetzt, um die Verfügbarkeit und Qualität ihrer angebotenen Dienste zu überwachen. Typische Überwachungskriterien sind Prozessorlast, Speicherplatz und Netzwerkverkehr. Vertragliche Festlegungen über Dienstanforderungen, so genannte Service Level Agreements, werden mit Hilfe dieser Monitoring-Lösungen eingehalten. Aus die- 25

26 2 Grundlagen sem Grund werden die Monitoring-Daten in Echtzeit erzeugt, verarbeitet und den entsprechenden Administratoren zur Verfügung gestellt. Fehler oder hohe Ausfallwahrscheinlichkeiten von einzelnen Diensten oder Ende-zu-Ende-Diensten werden ereignisgesteuert überwacht. Zahlreiche kommerzielle Produkte dieser Monitore sind auf dem Markt verfügbar. Als Beispiel sei Nagios als Open-Source- Lösung genannt ([Nag]). Die Monitore dieses Anwendungsgebietes sind für die Problemlösung in der ENSO nicht geeignet, da sie technisches Hintergrundwissen der überwachten Systeme erfordern und ihre primäre Zielgruppe Entwickler und Administratoren sind. Die Mitarbeiter der ENSO, die die Geschäftsprozesse betreuen, sind in erster Linie Anwender der bestehenden Software und lösen fachliche Probleme Geschäftsprozess-Monitoring auf Basis von Data Warehouses und Workflow Management Systemen Die Überwachung auf der Geschäftsprozessschicht wird durch das Anwendungsgebiet des Geschäftsprozess-Monitoring beschrieben. Es können prinzipiell zwei Konzepte unterschieden werden: zum einen die Business Intelligence (BI) und zum anderen der Einsatz von WFMS ([Bec05], S.1f.). Die BI liefert Werkzeuge, die komplexe Analysen über vergangene und Prognosen über zukünftige Geschäftsabläufe ermöglichen. Die Informationsempfänger sind Mitarbeiter des oberen Managements, die mit Hilfe der gesammelten Daten die aktuelle Unternehmensstrategie überwachen und gegebenenfalls anpassen. Der Aufbau einer klassischen BI Lösung ist in Abbildung 8 dargestellt. BI Tools DWH ETL-Layer Data Model ODS1 ODS2 ODS3 Abbildung 8: Klassisches BI-Konzept Quelle: vgl. [BaJo07], S.71 Aus den operationalen Datenbanken des Unternehmens und anderen externen Datenquellen (ODS1-3) werden mittels Extraktions-, Transformations- und Ladetechnologien (ETL-Schicht) Daten periodisch und stark zeitverzögert in ein unternehmensweites Data Warehouse (DWH) geladen. Diese Erzeugung der Monitoring-Daten erfolgt durch zeitgesteuerte Batch-Verfahren. Die darauf aufbauenden BI-Werkzeuge verarbeiten die gesammelten Daten und präsentie- 26

27 2 Grundlagen ren diese in geeigneter Form. Die Technologie der BI wird von einem Datenmodell getrieben ([Bec05], S.20f.; [BaJo07], S.2 und [Rei08], S.71f.). Ein Überblick über verschiedene BI-Produkte auf dem Markt wird in [Ham07] gegeben. Der Einsatz dieser periodischen Informationserfassung als Lösung für die Überwachung der Geschäftsprozesse in der ENSO ist nicht ausreichend. Die gesammelten Monitoring-Daten befinden sich zwar auf dem richtigen Abstraktionsniveau, können aber durch die Zeitverzögerung nicht für die tägliche Betreuung der Geschäftsprozesse eingesetzt werden. Aktuelle Events, die direkten Einfluss auf die operativen Tätigkeiten der Mitarbeiter der ENSO haben, müssen in Echtzeit erfasst werden. Eine Möglichkeit der Echtzeitüberwachung für operative Mitarbeiter stellt die Nutzung der Monitoring-Schnittstelle von WFMS dar. Diese Schnittstelle beschreibt den Zugriff auf den Workflow Audit Trail, der die Informationen zu laufenden und abgeschlossenen Workflowinstanzen protokolliert. Die Überwachung laufender Instanzen wird von [MuRo00], S.1f. als Workflow Monitoring definiert. Die Funktionalität ist vergleichbar mit dem beschriebenen Online-Monitoring. Das Monitoring abgeschlossener Instanzen wird als Workflow Controlling bezeichnet und ist gleichzusetzen mit der genannten Offline-Analyse. Mit Hilfe der Schnittstelle können prozessorientierte Daten ausgelesen und die Workflowinstanzen visualisiert werden. Die Mitarbeiter, die für die Durchführung der Geschäftsprozesse verantwortlich sind, können mit Hilfe des Online-Monitoring steuernd in die aktuellen Prozesse eingreifen oder anderweitige Maßnahmen einleiten. Die Offline-Analyse vergleicht die Ist-Daten der abgeschlossenen Instanzen mit den Soll- Daten des zugrunde liegenden Workflow-Modells und stellt Abweichungen fest. Diese Auswertung der Monitoring-Daten und die darauf folgenden Aktivitäten sind Bestandteile des BPM und WFM. Beispiele für WFMS, die einen integrierten Workflow-Monitor anbieten, sind u. a. MQ Workflow, Lotus Workflow oder der Oracle Process Manager. Ein gemeinsamer Nachteil dieser Monitor-Lösungen ist, dass die Überwachung der Workflows nicht anwendungs- und systemübergreifend möglich ist. Außerdem wird eine Anpassung der Präsentation der Monitoring-Daten an individuelle Kundenwünsche nur mangelhaft unterstützt ([BR+05], S.2). Eine vom WFMS unabhängige Lösung ist der in [MuRo00] beschriebene PISA- Prototyp. Es handelt sich um eine webbasierte verteilte Monitoring-Anwendung, die die Auswertung von Workflow-Protokoll-Daten unter Berücksichtigung von Vorgabedaten aus Prozessmodellen unterstützt. Als Datenquellen kommen vorrangig die Workflow Audit Trails von WFMS zum Einsatz. Ein zentraler Server sammelt die Informationen aus den verschiedenen Datenquellen, wertet diese auf Basis einer Bibliothek mit Evaluierungsmethoden aus und leitet diese an benutzerspezifische Clients weiter. Der Nachteil dieser Lösung ist die notwendige individuelle Adapterentwicklung für die anzuschließenden WFMS. Des Weiteren besteht die inhärente Abhängigkeit von der Qualität der Monitoring-Daten in den Workflow Audit Trails. Werden bestimmte Details oder Zusammenhänge nicht protokolliert, können diese entweder nicht überwacht werden oder der überwachte Workflow muss angepasst werden. In der ENSO werden integrierte Monitoring-Funktionalitäten verwendet, die auf den Workflow Audit Trail eines am Prozess beteiligten WFMS zugreifen. Die angezeigten Workflow-Daten sind auf dem korrekten Abstraktionsniveau und in Echtzeit verfügbar, aber sie bieten keinen vollständigen Überblick über die laufenden Workflowinstanzen, da das integrierte WFMS nur einen Teil des 27

28 2 Grundlagen Workflows abbildet. Das gesuchte Monitoring-Konzept muss anwendungs- und systemübergreifend angelegt sein, um die Workflowinstanzen vollständig darzustellen. Dies ist eine der Kerneigenschaften des BAM, das im folgenden Abschnitt beschrieben wird Geschäftsprozess-Monitoring mit Business Activity Monitoring BAM ist ein vom Marktforschungsunternehmen Gartner Group im Jahr 2001, wie folgt, definierter Begriff: the concept of providing real-time access to critical business performance indicators to improve the speed and effectiveness of business operations. ([BaJo07], S.1 und [Rei08], S.72) BAM ist als ein Konzept zu verstehen, das geschäftskritische Daten in Echtzeit zur Verfügung stellt, um die operative Geschäftstätigkeit zu optimieren. Eine zentrale Eigenschaft dieses Monitoring-Konzeptes ist die geschäftsprozess- und eventorientierte Bereitstellung der Informationen über Systemgrenzen hinweg (vgl. [Rei08], S.73 und [BaJo07], S.2). Aus den genannten Eigenschaften kann abgeleitet werden, dass BAM für das zu erstellende Monitoring-Konzept in der ENSO wichtige Basisansätze bietet: die Monitoring-Daten befinden sich auf dem Abstraktionsniveau der Geschäftsprozess-Schicht, sind in Echtzeit verfügbar und werden systemübergreifend gesammelt. Die primären Benutzer von BAM sind operative Mitarbeiter, also Anwender, die an der täglichen Betreuung der Geschäftsprozesse beteiligt sind ([Rei08], S.74). Dies wird in Abbildung 9 anhand eines Vergleichs mit den Anwendungsgebieten des System-Monitoring und der BI, bezogen auf die Empfänger und die Verzögerung der Information, verdeutlicht. Management Business Intelligence Operative Mitarbeiter Business Activity Monitoring Systemadministratoren System Monitoring Informationsverzögerung Abbildung 9: Zusammenhang der Monitoring-Anwendungsgebiete Quelle: vgl. [Rei08], S.75 Aus Abbildung 9 geht hervor, dass BAM nicht vollständig deckungsfrei gegenüber den anderen Anwendungsgebieten ist. Vielmehr ist BAM als Ergänzung zu den bisherigen Ansätzen zu verstehen, das durchaus Synergieeffekte nutzen soll ([BaJo07], S.3 und [Hau07], S.13). Eine Kombination mit BI kann durch Vergleich mit historischen Daten aussagekräftige Analysen und Vorhersagen über Prozessentwicklungen ermöglichen. Werkzeuge des System-Monitoring könnten 28

29 2 Grundlagen BAM-Lösungen mit Informationen zu Events auf der System- und Netzwerkschicht versorgen. Ein Problem, das BAM anhaftet, ist die Tatsache, dass es kein ausgereiftes und einheitliches Konzept darstellt ([Rei08], S.83 und 99). Aufgrund fehlender Standards und der besagten Überschneidungen zu bestehenden Ansätzen existiert eine Vielzahl von Lösungen, die als BAM-Produkt vermarktet werden und zum Teil völlig unterschiedliche Funktionalitäten anbieten. Unterschieden werden klassische BAM-Lösungen, die als unabhängige Systeme fungieren, BI-Plattformen, die BAM-Funktionalität integrieren und EAI-basierte Systeme. Ein Beispiel für eine unabhängige Lösung ist der ARIS Process Performance Manager der Firma IDS Scheer, der Informationen über die Prozessausführung aus verschiedenen Datenquellen in einer Datenbank sammelt, aggregiert und nutzerabhängig präsentiert ([BR+05], S.2). Ein generelles Problem derartiger BAM-Lösungen ist die Anbindung an die Applikationen, die die Laufzeit-Daten verwalten. Falls keine proprietären Schnittstellen vorhanden sind, ist eine aufwendige Adapter- Implementierung erforderlich ([BaBo06], S.1). Beispiele für EAI-basierte Systeme sind das ebam Studio der Sun Java Composite Application Plattform Suite und die BAM-Komponente des Microsoft BizTalk Servers. In den Arbeiten von [Rei08] und [Hau07] wird anhand von fiktiven Geschäftsprozessen dargestellt, wie diese BAM-Lösungen zur Überwachung eingerichtet und eingesetzt werden können. Die genannten Produkte sind in die jeweilige EAI-Plattform integriert und können nicht universell eingesetzt werden. In der Definiton von BAM werden die zu überwachenden Informationen anhand von Indikatoren festgelegt, auf die in Echtzeit zugegriffen wird. Ein Indikator ist ein zahlenmäßiges oder grafisches Signal, das zu einem bestimmten Zeitpunkt über die geplante oder tatsächliche Merkmalsausprägung eines überwachten Objektes berichtet ([Hau07], S.32). Indikatoren können aus einzelnen oder mehreren Events zusammengesetzt sein und dienen dem Anwender als Hilfsmittel, um nicht direkt analysierbare Abläufe nachvollziehen zu können. [Hau07], S.33ff. und [Cru06], S.4 unterscheidet vier Kategorien von Indikatoren, die durch BAM gemessen werden können: Volumenbezogene Indikatoren Zeitbezogene Indikatoren Indikatoren zur Fehlerüberwachung Spezielle Indikatoren Volumenbezogene Indikatoren beziehen sich auf übertragene Volumina und Mengen von Geschäftsprozessen. Typische Beispiele sind die Anzahl von Prozessereignissen und Umsatz beziehungsweise Kosten einer Prozessausführung. Zeitbezogene Indikatoren bilden den zeitlichen Verlauf eines Prozesses ab, beispielsweise Prozessdurchlaufzeit, Wartezeiten zwischen Events und Abweichungen von Soll-/Istzeit bei der Prozessausführung. Die Kombination von zeitund volumenbezogenen Indikatoren wird in BAM-Lösungen oft eingesetzt, um die Performance eines Unternehmens zu messen. Dies ist ein wichtiges Verkaufsargument von BAM und der Grund, warum die bestehenden Lösungen auf diese Indikatoren fokussiert sind. Die für diese Arbeit wichtigsten Indikatoren sind die Indikatoren zur Fehlerüberwachung. Die Integration von unterschiedlichen Systemen und Anwendungen zur Prozessausführung führt zur Erhöhung der Komplexität der IT-Landschaft und tendenziell zum Anstieg der Fehlerzahl. Das Auftreten von Fehlern verursacht Kosten und höhere Durchlaufzeiten. Die Fehlerüberwachung von BAM dient der 29

30 2 Grundlagen Messung der Performanz des Unternehmens und der Lokalisierung der Fehlerquellen. Für die Monitoring-Lösung in der ENSO ist besonders die automatische Fehlererkennung relevant. Performanz-Messungen hinsichtlich der Fehlerindikatoren stehen nicht im Vordergrund dieser Arbeit, werden aber an entsprechender Stelle im Monitoring-Konzept genannt. In [Hau07], S.35 wird betont, dass sowohl systembedingte Fehler als auch fachliche Fehler, verursacht durch Mitarbeiter, von BAM erkannt werden. Beispiele für Indikatoren zur Fehlerberwachung sind Timeouts von Prozessen, nicht übereinstimmende Kundendaten, falsch formatierte Daten oder inhaltlich fehlerhafte Daten. Auf die verschiedenen Fehler, die in der Anwendung der ENSO zu überwachen sind, wird in Abschnitt näher eingegangen. Die letzte Kategorie umfasst spezielle Indikatoren, die an das individuelle Tagesgeschäft einer Anwendergruppe angepasst sind und nur für diese einen Mehrwert bilden. Der Aufbau einer BAM-Lösung ist in Abbildung 10 dargestellt. BAM Layer Architektur Event Action, Delivery and Display Event Processing and Filtering Event Absorption Technische Ereignisse Geschäftsereignisse Unternehmen + Umfeld Abbildung 10: BAM Layer Architektur Quelle: vgl. [Rei08], S.84 Der Aufbau ist an das genannte Monitoring-Modell in angelehnt. Es handelt sich um einen generalisierten Aufbau, der in realen Lösungen in unterschiedlicher Ausprägung umgesetzt wird ([BaJo07], S.5f. und [Rei08], S.85ff.). Die Events werden durch die Event Absorption erzeugt, anschließend durch die Schicht der Event Processing and Filtering verarbeitet und in der obersten Schicht präsentiert und gegebenenfalls weiterführende Aktivitäten ausgeführt. Auf die einzelnen Schichten wird nachfolgend näher eingegangen: Erzeugung (Event Absorption): Die Vielzahl der Events eines Unternehmens, sowohl auf Geschäftsprozess- als auch auf Systemebene, werden durch diese Schicht erfasst und in einer Datenbank gespeichert. Im Idealfall wird im Unter- 30

31 2 Grundlagen nehmen eine EAI-Middleware eingesetzt, aus der Events durch die BAM-Lösung aufgenommen werden können. Aus den erfassten Events werden die relevanten Events gefiltert und im optimalen Fall in ein einheitliches Format transformiert, das durch den Event Processing Layer weiterverarbeitbar ist. Die Vorgehensweise bei der Gewinnung der Monitoring-Daten ist eventorientiert und wird auch als Event-Driven Data Integration bezeichnet. Der grundlegende Gedanke dieser Vorgehensweise ist die Ausführung der Geschäftsprozesse durch Monitoring- Sensoren zu instrumentieren. Diese Sensoren werden bei der Prozessausführung durchlaufen und es werden die gewünschten Informationen aus dem Prozessverlauf kopiert und an die BAM-Lösung weitergeleitet. In [Hau07], S.80 werden diese Punkte als Wired Taps bezeichnet. Dies ist ein gravierender Unterschied zu den genannten Data Warehouse und WFMS-basierten Ansätzen, bei denen die Informationen aus Log-Files und anderen vorhandenen Datenquellen extrahiert werden. Diese Log-Files können zusätzlich in BAM-Tools eingesetzt werden, um die übertragenen Daten mit Kontextinformationen anzureichern. Verarbeitung (Event Processing and Filtering): Die relevanten Events werden durch diese Schicht in Echtzeit analysiert und verarbeitet. Die Monitoring-Daten werden mittels vordefinierter Regeln überprüft, um Abweichungen zum Normalverhalten zu entdecken. Falls eine definierte Regel verletzt wird, kann ein Alarm generiert und an die oberste Schicht der BAM-Architektur weitergeleitet werden. BAM-Lösungen unterscheiden sich stark in der Funktionalität der Verarbeitung. Die Spanne reicht von einfachen Lösungen, die nur das Auftreten von Events erkennen, und komplexen Lösungen, die verschiedene Prüfkriterien anbieten. Ein Kriterium ist beispielsweise die Mustererkennung, die die kausale Abhängigkeit zwischen Events berücksichtigt. Ein aufkommendes Thema in diesem Zusammenhang ist das Complex Event Processing, das sich mit der Erkennung, Analyse, Aggregation und Verarbeitung von abhängigen Events beschäftigt. Für eine ausführliche Behandlung dieser Thematik wird auf Spezialliteratur in [Luc02] und [MF+06], S.231ff. hingewiesen. Die Erstellung von Regeln ist eine schwierige und aufwändige Aufgabe bei der Entwicklung einer BAM-Lösung. Mangelhafte Regeln können zu falschen Folgeaktivitäten in den Geschäftsprozessen der Unternehmen führen, weil entweder unnötige Probleme angezeigt werden oder tatsächliche Prozessfehler nicht erkannt werden. Die Regelerstellung kann durch verschiedene Werkzeuge, die der Konfiguration und Simulation der Regeln dienen, unterstützt werden. Des Weiteren werden die gesammelten Informationen durch Filtermechanismen verdichtet und für die Anzeige in der oberen Schicht der BAM-Architektur aufbereitet. Präsentation (Event Action, Delivery and Display): Die erzeugten Monitoring- Daten werden anhand der festgelegten Indikatoren in geeigneter Form für den Anwender dargestellt. BAM-Tools unterstützen aktives und passives Monitoring. Eine wichtige Anforderung an aktives Monitoring ist die Bereitstellung von ausreichend Kontext, um anschließend die korrekten Maßnahmen einleiten zu können. Für passives Monitoring werden häufig Dashboards eingesetzt, die ein ganzheitliches Bild über den aktuellen Status der Geschäftstätigkeiten liefern. Wie aus dem allgemeinen Aufbau von BAM hervorgeht, müssen in der Entwicklung einer derartigen Lösung verschiedene Faktoren berücksichtigt werden, um das Potenzial dieses Konzeptes nutzen zu können. In [Rei08], S.103 wird darauf hingewiesen, dass die erfolgreiche Einführung von BAM in einem Unternehmen mit einem nicht unerheblichem Aufwand verbunden ist. Aus diesem Grund wird ein Vorgehensmodell in [Rei08], S.105ff. beschrieben, das Unternehmen als Leit- 31

32 2 Grundlagen faden für die Einführung von BAM dienen soll. Das Modell besteht aus sieben Phasen, die nachfolgend vorgestellt werden: Phase 1 Strategieentwicklung Die Strategieentwicklung enthält die Teilschritte Unternehmensanalyse, die Integration des Managements und die Festlegung einer Strategie zur Einführung von BAM. In der Unternehmensanalyse werden Aufbau und Abläufe des Unternehmens untersucht. Im Fokus stehen die Organisationsstrukturen, Geschäftsprozesse und die genutzten Informationssysteme. Eine Einbeziehung des Managements ist notwendig, um den langfristigen Erfolg einer BAM-Lösung zu sichern. Entscheidet sich ein Unternehmen, BAM einzuführen, so wird ein Pilotprojekt gestartet, das sich über die Phasen 2-7 erstreckt. Die Phase 1 wird in dieser Arbeit als abgeschlossen betrachtet. Aufgrund der in 1.3 genannten Probleme haben sich das Management und die operativen Mitarbeiter der ENSO für die Einführung einer Monitoring-Lösung entschlossen. Die vorliegende Arbeit soll das Konzept für dieses Monitoring liefern. Phase 2 Pilotprozessauswahl In dieser Phase wird aus verschiedenen Prozesskandidaten anhand von Bewertungskriterien ein Pilotprozess ausgewählt, der bei Einsatz von BAM einen möglichst großen Mehrwert für das Unternehmen generieren kann. Phase 3 Pilotprozessdesign Das Pilotprozessdesign besteht aus den Teilschritten der Identifikation der Benutzergruppen, der Prozessanalyse, der Entwicklung der Indikatoren und der Festlegung der grafischen Oberfläche, Alarmierungen und automatischen Aktionen. Die am Prozess beteiligten Benutzergruppen werden zunächst erfasst und es wird untersucht, wie hoch das jeweilige Nutzungspotenzial durch den Einsatz von BAM ist. Die anschließende Prozessanalyse findet unter Einbeziehung der Benutzergruppen statt. Diese Analyse umfasst die Beschreibung des Pilotprozesses und die Identifikation der involvierten Anwendungen, Datenquellen, Systeme und der technischen Infrastruktur. Des Weiteren werden die Schwachstellen des Pilotprozesses ermittelt. Darauf aufbauend werden die Indikatoren beziehungsweise die zu überwachenden Events und die verwendeten Regeln festgelegt. Im letzten Teilschritt wird die Gestaltung der grafischen Benutzeroberflächen, bezogen auf die definierten Indikatoren, bestimmt. Unter anderem muss definiert werden, welche Mitarbeiter welche Daten und in welcher Form angezeigt bekommen. Des Weiteren werden die Alarmierungen und automatische Aktionen, basierend auf den entwickelten Regeln und Events, festgelegt. Phase 4 Infrastrukturplanung Nach der Designphase wird der Einsatz geeigneter Infrastruktur geplant. Für jede der drei genannten Schichten der BAM-Architektur müssen unter Berücksichtigung der in Phase 3 erzielten Ergebnisse geeignete Kommunikations- und Infrastrukturtechnologien definiert werden. Kann die gewünschte Funktionalität nicht mit vorhandenen Technologien abgedeckt werden, müssen nach entsprechender Kosten-/Nutzenanalyse fehlende Produkte angeschafft werden. 32

33 2 Grundlagen Phase 5 Umsetzung Diese Phase beschreibt die Integration der in Phase 4 definierten BAM- Technologien in die bestehende Unternehmensinfrastruktur. Anschließend folgt die eigentliche Implementierung der in Phase 3 entworfenen BAM-Lösung. Die Phasen 2, 3 und 4 umfassen den Hauptteil dieser Arbeit. Die Durchführung dieser Phasen wird in Kapitel 3 behandelt. Phase 5 wird durch die Umsetzung des Prototyps in Kapitel 4 beschrieben. Die weiteren Phasen des Vorgehensmodells sind nicht Bestandteil dieser Arbeit und werden aus diesem Grund nur kurz erläutert. Phase 6 beschreibt die Inbetriebnahme und die anschließende Evaluierung und Anpassung der BAM-Lösung. In Phase 7 werden die Ergebnisse an das Management weitergeleitet, das über die Expansion des BAM-Konzeptes entscheidet. 33

34 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes 3 Prozessanalyse und Entwurf eines Monitoring- Konzeptes Das folgende Kapitel stellt den Hauptteil dieser Arbeit dar und wird in drei Abschnitte gegliedert. Im ersten Abschnitt (3.1) werden die gesetzlichen Vorgaben der Geschäftsprozesse der Energieversorgung und deren technische Umsetzung in der ENSO vorgestellt. Im zweiten Abschnitt erfolgt die Analyse des Istzustands der Prozessabwicklung (3.2). Mit der Beschreibung des Sollzustands der Prozessabwicklung wird das Kapitel abgeschlossen (3.3). 3.1 Gesetzliche Vorgaben und Umsetzung in der ENSO Zunächst werden die Geschäftsprozesse und das verwendete Datenaustauschformat EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) vorgestellt. Anschließend wird die IT-Umsetzung der vorgestellten Geschäftsprozesse in der ENSO beschrieben Geschäftsprozesse im Rahmen der Liberalisierung des Energiemarktes Die Beschlüsse der Bundesnetzagentur aus den Jahren 2006 und 2007 legen die Geschäftsprozesse für die Energieversorgung und EDIFACT als das zu verwendende Datenaustauschformat fest ([GPKE06_1], [GeLi07_1]). Zur Versorgung der Endverbraucher wurden acht Geschäftsprozesse definiert, die den Informationsaustausch zu Kunden und Entnahmestellen zwischen den verschiedenen Marktteilnehmern regeln: 1. Lieferantenwechsel: Interaktion zwischen den Marktteilnehmern, für den Fall, dass ein Kunde an einer Entnahmestelle von seinem derzeitigen Energielieferanten zu einem neuen Lieferanten wechselt 2. Lieferende: Interaktion zwischen den Marktteilnehmern, für den Fall, dass ein Kunde seinen Liefervertrag beendet und keine neue Energiebelieferung an dieser Entnahmestelle aufnimmt 3. Lieferbeginn: Interaktion zwischen den Marktteilnehmern, für den Fall, dass ein Kunde eine neue Belieferung an einer neuen Entnahmestelle aufnimmt 4. Ersatzversorgung: Beschreibung des Ablaufs für den Übergang von der Grundversorgung in die Ersatzversorgung 5. Zählerstand- und Zählwerteübermittlung: Ablaufbeschreibung bei der Übermittlung von Zählerständen und Zählwerten durch den Netzbetreiber an den Lieferanten 34

35 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes 6. Stammdatenänderung: Beschreibung des Austauschs von geänderten Stammdaten eines Verbrauchers oder einer Entnahmestelle zwischen Marktteilnehmern 7. Geschäftsdatenanfrage: Ablauf bei Anfrage von Geschäftsdaten zu Kunden und Entnahmestellen zwischen Markteilnehmern unter der Voraussetzung, dass Anfragender eine Anfragevollmacht besitzt 8. Netznutzungsabrechnung: Beschreibung der Kommunikation zwischen Netzbetreiber und Lieferant bezüglich der Abrechnung der Netznutzung Die Prozesse eins bis drei zählen zu den Geschäftsprozessen, die einen Wechsel des Lieferanten aufgrund vertraglicher Lieferbeziehungen beschreiben. Der Prozess der Ersatzversorgung beschreibt den Sonderfall des Lieferantenwechsels aufgrund gesetzlicher Lieferbedingungen ([EnWG05]). Dieser Fall tritt ein, wenn die Belieferung einer Entnahmestelle keinem bestimmten Liefervertrag zugeordnet werden kann oder der bisherige Energielieferant insolvent wird. Ein festgelegter Grundversorger übernimmt dann die Belieferung dieser Entnahmestelle, um eine plötzliche Aussetzung der Belieferung zu verhindern. Die restlichen Prozesse dienen dem Austausch von Daten zu bestehenden Lieferantenverträgen oder werden als Annexprozesse im Zuge des Lieferantenwechsels verwendet. An jedem der beschriebenen Geschäftsprozesse sind mehrere Rollen beteiligt, die durch verschiedene Marktteilnehmer eingenommen werden. Der Lieferantenwechsel soll im Weiteren als Grundlage für das zu entwickelnde Monitoring- Konzept dienen. Diese Festlegung ist vergleichbar mit der Auswahl des Pilotprozesses in Phase 2 des Vorgehensmodells zur Einführung von BAM und hat die folgenden Gründe: 1. Der Geschäftsprozess des Lieferantenwechsels enthält einen großen Anteil der verschiedenen Fehlerfälle, die mittels des Monitoring-Konzeptes erfasst werden sollen. 2. Am Lieferantenwechselprozess sind alle Rollen beteiligt. Durch die Analyse anhand des Lieferantenwechsels kann ein umfassendes Konzept erstellt werden, das die spätere Einbindung der restlichen Geschäftsprozesse erleichtert. Auf den Prozessablauf wird im Folgenden näher eingegangen, um die verschiedenen Rollen und deren Interaktion vorzustellen. Diese Beschreibungen sind Bestandteil der in Phase 3 des Vorgehensmodells durchzuführenden Prozessanalyse. Geschäftsprozess Lieferantenwechsel Der Geschäftsprozess Lieferantenwechsel beschreibt den standardisierten Ablauf für den Fall, dass sich ein Kunde für einen neuen Energielieferanten an der gleichen Entnahmestelle entschieden hat. Ein Lieferantenwechsel kann unterschiedliche Ursachen haben. Typische Gründe sind unter anderem niedrigere Energiekosten, Angebote mit Fixkostenverträgen und besseres Serviceangebot. 35

36 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Der Ablauf des Lieferantenwechselprozesses wird zunächst erläutert (informal) und anschließend in Abbildung 11 in BPMN-Notation dargestellt (semi-formal). Die Prozessbeschreibung und -darstellung konzentriert sich auf den Regelfall des Lieferantenwechsels. Sonderfälle werden genannt, aber nicht näher betrachtet. Hierfür wird auf die gesetzlichen Dokumente verwiesen ([GPKE06_2], [Ge- Li07_2]). Am Geschäftsprozess des Lieferantenwechsels sind die vier folgenden Rollen beteiligt: 1. Kunde = Person, die Energieversorger an ihrer Entnahmestelle wechselt 2. Altlieferant = der bisherige Energieversorger 3. Neulieferant = Energieversorger, der Altlieferant ablöst 4. Netzbetreiber = Inhaber und Verantwortlicher der Netzinfrastruktur des Versorgungsgebietes, in dem die Entnahmestelle des Kunden liegt Der Beginn des Prozesses wird durch den unterzeichneten Vertrag zwischen Kunde und Neulieferant markiert. Dieser Vertrag enthält in der Regel eine Vollmacht des Kunden, die es dem Neulieferant erlaubt alle nötigen Schritte für die Umstellung der Energieversorgung einzuleiten. Diese Schritte beinhalten das Versenden der Kündigung an den Altlieferanten und die Anmeldung der Versorgung beim zuständigen Netzbetreiber. Beide Schritte können parallel ausgeführt werden. Der Altlieferant prüft daraufhin die Richtigkeit der Kündigung (z. B. Kundendaten, Datum der Umstellung, etc.) und sendet eine Kündigungsantwort an den Neulieferanten zurück. Gleichzeitig oder unmittelbar danach verschickt der Altlieferant eine Lieferabmeldung an den Netzbetreiber. Der Netzbetreiber hat nun die Aufgabe alle eingegangenen Meldungen zu prüfen und eine Bestätigung oder Ablehnung als Antwort auf die Anmeldung des Neulieferanten und auf die Abmeldung des Altlieferanten zu senden. Diese Prüfungsaktivität ist komplex, da verschiedene Situationen der Lieferantenkonkurrenz, beispielsweise in Form von Terminkonflikten und Mehrfachanmeldungen, eintreten können. Falls der Netzbetreiber den Wechsel bestätigt, ist damit der Kernprozess des Lieferantenwechsels beendet. Die nachfolgenden Annexprozesse, die durch den Netzbetreiber durchgeführt werden, beinhalten das Versenden von aktualisierten Bestandslisten und die Zählerstandsübertragung der Entnahmestelle unmittelbar vor dem Wechseldatum an die beteiligten Lieferanten. Abschließend versendet der Netzbetreiber eine Abschlussrechnung über die Netznutzung an den Altlieferanten. Nachfolgende BPMN-Darstellung in Abbildung 11 visualisiert den Prozessablauf des Lieferantenwechsels. Die BPMN-Notation wurde gewählt, da sie eine kontrollflussorientierte Prozesssicht ist und eine gute Auflösung der Rollenbeteiligung zulässt ([Gad08]). Im Teilabschnitt des Anhangs befinden sich ein Sequenzdiagramm (angelehnt an die UML-Notation) und zugehörige eepk- Diagramme, die eine alternative Sicht auf den Geschäftsprozess ermöglichen. 36

37 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Abbildung 11: BPMN-Darstellung Geschäftsprozess Lieferantenwechsel Quelle: vgl. [GPKE06_2], S.13 37

38 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Datenaustauschformat EDIFACT Die Kommunikation zwischen den Marktteilnehmern zur Umsetzung der beschriebenen Geschäftsprozesse wird durch den elektrischen Datenaustausch im EDIFACT-Format realisiert. EDIFACT ist ein internationales, branchenübergreifendes Standardformat für elektronische Daten im Geschäftsverkehr, welches von der UN/CEFACT verwaltet wird ([UNECE]). In den Beschlüssen der Bundesnetzagentur wurden die Datenformate CSV und XML ebenfalls in die Entscheidungsfindung einbezogen, aber aus verschiedenen Gründen nicht verwendet (siehe [GPKE06_1], S.41f.). Im Kontext der Geschäftsprozesse der Energieversorgung werden die EDIFACT- Dateien als Text-Dateien versendet. Die am meisten verbreitete und auch von der ENSO verwendete Übermittlungsart ist die Versendung der Nachrichten als Anhang von s über das SMTP-Übertragungsprotokoll. Alternativ kommen die Transportprotokolle SFTP, X.400 und AS2 zum Einsatz, die im Weiteren aufgrund der geringen Verbreitung nicht betrachtet werden. [BDW08_1] Die Struktur einer EDIFACT-Datei ist in Abbildung 12 dargestellt. UNA UNB UNZ UNH UNT UNH UNT UNH UNT DATEN DATEN DATEN Abbildung 12: Aufbau einer EDIFACT-Datei Quelle: [BDW08_2], S.6 Eine EDIFACT-Datei wird in verschiedene Ebenen eingeteilt, die von Service- Segmenten umklammert werden. Das optionale UNA-Segment stellt eine Ausnahme dar und dient lediglich zur Festlegung der verwendeten Trennzeichen innerhalb der Text-Datei, falls diese vom Standardzeichensatz der UN/CEFACT abweichen. Das UNB-UNZ-Segmentpaar markiert den Beginn und das Ende der zu übertragenden EDIFACT-Übertragungsdatei. Es folgen die einzelnen Nachrichten, die jeweils durch ein UNH-UNT-Segmentpaar umklammert werden. Die Daten innerhalb dieser Nachrichten werden als Felder gespeichert und in Segmenten und Segmentgruppen angeordnet. Die zu übertragenden Daten enthalten u.a. Sender/Empfänger-Informationen, Datumsangaben, Belegreferenzen, technische und betriebswirtschaftliche Stammdaten. Die EDIFACT-Nachrichten werden unterschieden in die Kategorien der datenflussorientierten und kontrollflussorientierten Nachrichten. Datenflussorientierte Nachrichten enthalten Stamm- und Bewegungsdaten zu Geschäftsvorgängen einer Geschäftsvorgangsart. Eine Geschäftsvorgangsart beschreibt einen Teilschritt der genannten Geschäftsprozesse. Im Kontext des Lieferantenwechselprozesses sind die drei Vorgangsarten Kündigung, Anmeldung und Abmeldung definiert. Ein Geschäftsvorgang steht für eine konkrete Ausprägung einer Vorgangsart, also beispielsweise die Kündigung des Kunden M. Mustermann. Die Geschäftsvorgangsarten, die mittels einer EDIFACT-Nachricht 38

39 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes übertragen werden können, werden durch die Verwendung von EDIFACT- Nachrichtentypen definiert. Folgende datenflussorientierte Nachrichtentypen und deren Verwendungszweck wurden von der Bundesnetzagentur für den Energiesektor festgelegt: 1. UTILMD für den Stammdatenaustausch 2. MSCONS für den Bericht über die Lieferung von Daten zu Energiemengen 3. REQDOC für die Übermittlung von Dokumentenanforderungen 4. REMADV zur Übermittlung von Zahlungsavise 5. INVOIC zur Übermittlung von Netz- und Energiedienstleistungsabrechnungen Für das Beispiel des Lieferantenwechsels sind alle EDIFACT-Nachrichten, die keine Zählerstand- oder Rechnungsvorgänge beschreiben, vom Typ UTILMD. Eine UTILMD-Nachricht, die eine Kündigung zwischen zwei Lieferanten darstellt, ist in Listing 1 aufgeführt: UNB+UNOC: : :500+UTILMD+A' UNH+1+UTILMD:D:04B:UN:4.1a' BGM+E ' DTM+137: :203'DTM+735:?+0100:406' NAD+MR ::293'NAD+MS ::293' IDE k ' DTM+471: :102' STS+7++E03'RFF+MG: ' NAD+UD+++Michael Mustermann:::::1' NAD+IT++++Am Musterweg::9:a+Musterstadt ' UNT+13+1' UNZ ' Geschäftsvorgang EDIFACT- Nachricht EDIFACT- Datei Listing 1: Beispiel einer UTILMD-Nachricht mit fiktiven Daten Das UNB-Segment enthält die ILN-Nummern des Senders und Empfängers und den zu übertragenden Nachrichtentyp. Das UNH-Segment signalisiert den Beginn der EDIFACT-Nachricht und beschreibt die verwendete Version des Nachrichtentyps. Im BGM-Segment wird durch den Identifier E35 die Geschäftsvorgangsart, in diesem Fall die Kündigung, der enthaltenen Geschäftsvorgänge charakterisiert. Anschließend folgen in den DTM- und NAD- Segmenten allgemeine Informationen der EDIFACT-Nachricht (u.a. Versendedatum). Der konkrete Geschäftsvorgang wird durch das IDE-Segment eingeleitet. Das folgende DTM-Segment enthält den Kündigungstermin. Im STS-Segment wird der Geschäftsprozess durch die Identifier 7 und E03 beschrieben (Lieferantenwechsel) und eine Referenz zum technischen Objekt des Zählers mitgegeben. Die folgenden Segmente des Geschäftsvorgangs enthalten die Kundendaten. Das Ende des Vorgangs wird durch das UNT-Segment signalisiert, das für eine interne Prüfung die Anzahl der Nachrichten-Segmente angibt. Das Ende der gesamten EDIFACT-Datei erfolgt durch das UNZ-Segment. Kontrollflussorientierte Nachrichten enthalten keine Informationen zu Stammund Bewegungsdaten, sondern beziehen sich auf die syntaktische und inhaltliche Korrektheit von EDIFACT-Dateien. Mit Hilfe dieser Nachrichten quittiert der Empfänger dem Sender den Empfang einer Datei und teilt zusätzlich mit, ob die Datei 39

40 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes verarbeitet werden konnte. Unterschieden werden die kontrollflussorientierten Nachrichten in zwei Nachrichtentypen: 1. CONTRL zur Übermittlung von Syntax- und Übertragungsprotokollnachrichten 2. APERAK zur Übermittlung von Anwendungsfehler- und Bestätigungsmeldungen Der Aufbau der CONTRL- und APERAK-Nachrichten wird durch die Dokumente [BDW08_3] und [BDW08_4] des BDEW vorgeschrieben. Diese Dokumente enthalten unter anderem Fehlercodes, die die Fehleridentifikation für den Kommunikationspartner erleichtern. Eine CONTRL-Nachricht ist in Listing 2 aufgeführt. Das UCI-Segment enthält die Referenznummer auf die datenflussorientierte Nachricht und den Identifier zur Anzeige des Fehlerstatus ( 7 steht für fehlerfreie Übertragung). Die weiteren Segmente sind äquivalent zur Verwendung in datenflussorientierten Nachrichten. UNB+UNOC: : :500+CONTRL' UNH CONTRL:D:3:UN:1.3a' UCI : :14+7' UNT ' UNZ ' Listing 2: Beispiel einer CONTRL-Nachricht mit fiktiven Daten Die Datenstruktur aller genannten Nachrichtentypen wird durch Dokumente der UN/CEFACT und speziell für den Energiesektor durch Dokumente des BDEW vorgeschrieben. Innerhalb einer EDIFACT-Datei dürfen nur Nachrichten des gleichen Typs verwendet werden. [GPKE06_1], [UNECE], [BDW08_2] Workflow Anwendung der ENSO Mit der Notwendigkeit der Einführung der einheitlichen Geschäftsprozesse sowie dem zu verwendeten Datenaustauschformat EDIFACT musste in der ENSO eine Entscheidung getroffen werden, wie diese Neuerungen durch Informations- und Kommunikationstechnologien unterstützt werden. Vorhandene Systeme sollten möglichst wieder verwendet werden und der Aufwand musste sich in einem kosteneffektiven Rahmen bewegen. Aufgrund der Vielzahl an Lieferantenwechseln und dem damit verbundenen täglichen Datenverkehr fiel die Entscheidung auf eine verteilte Workflow Anwendung (WF Anwendung). Diese soll eine weitestgehend automatisierte Durchführung des Nachrichtenaustauschs ermöglichen und damit manuelle Steuerungseingriffe durch Mitarbeiter auf ein Minimum reduzieren. Der Nachrichtenaustausch umfasst dabei alle Aktivitäten der Geschäftsprozesse, die den Empfang/Versand von EDIFACT-Nachrichten und deren interner Verarbeitung betreffen. Die Umsetzung der verteilten WF Anwendung innerhalb der ENSO wird durch die Kopplung von zwei bestehenden verteilten Anwendungen mittels einer EAI- Middleware realisiert (siehe Abbildung 13). 40

41 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Abbildung 13: Übersicht über Komponenten der verteilten Workflow Anwendung Lotus Notes stellt als -Anwendung -Dienste zur Verfügung. Transconnect als EAI-Middleware realisiert die Anbindung von Lotus Notes an die SAP IS-U Anwendung, die als Backend die Verbuchung der Prozessdaten vornimmt. Mit Hilfe der WF Anwendung werden die folgenden Workflows realisiert: 1. Workflow für eingehende EDIFACT-Nachrichten: Dieser Workflow umfasst den Empfang der s mit EDIFACT-Dateien als -Attachments, die anschließende Transformation in das Backendformat und die Verbuchung der Nachrichten im Backend. 2. Workflow für ausgehende EDIFACT-Nachrichten: Dieser Workflow beschreibt das Erstellen der Nachricht im Backendformat, die anschließende Transformation in eine EDIFACT-Datei und das Versenden dieser EDIFACT-Datei als - Attachment. Die drei Komponenten der WF Anwendung und deren Aufgaben für die Durchführung der genannten Workflows sollen an dieser Stelle erläutert werden: Lotus Notes: Lotus Notes ist eine dokumentenorientierte Datenbankanwendung mit enger -Integration, welche als Groupware-Lösung in Unternehmen eingesetzt wird. Für die Realisierung der Workflows werden vorrangig die Standard- -Funktionalitäten verwendet. Lotus Notes übernimmt dabei folgende Aufgaben: Senden, Empfangen und Verwalten von s mit EDIFACT- Attachments. Zur Realisierung der beschriebenen Workflows werden unterschiedliche Postkörbe verwaltet. Dies hat zwei Gründe: 1. Die ENSO kann in den Rollen des Netzbetreibers und als Neu- oder Altlieferant innerhalb einer Geschäftsprozessinstanz auftreten. Aufgrund der gesetzlichen Regelungen müssen diese beiden Rollen betriebswirtschaftlich, rechtlich und auch informatorisch getrennt werden ([EnWG05]). 41

42 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes 2. Zusätzlich wird die IT-technische Umsetzung der Geschäftsprozesse anderer kleinerer Energieunternehmen, vorrangig Stadtwerke aus der umliegenden Region, vom IT-Bereich der ENSO verwaltet. Aus diesem Grund wird der Nachrichtenaustausch mehrerer Marktteilnehmer mit separaten -Konten in der WF Anwendung abgebildet. Transconnect: Transconnect ist eine anwendungsorientierte Middleware, die als zentrale EAI-Plattform für die unternehmensweite Integration von Anwendungen eingesetzt wird ([TCHb], S.14). Bezogen auf die Geschäftsprozesse der ENSO, hat sie die komplexe Aufgabe der nachrichtenbasierten Kommunikation zwischen SAP IS-U und Lotus Notes zu realisieren. Mit Hilfe definierter Adapter und zeitgesteuerter Jobs wird auf die Daten und Funktionalitäten der angebundenen Anwendungen zugegriffen. Die interne Nachrichtentransformation wird mit Hilfe einer Nachrichtenqueue und nachrichtentypspezifischer Routingregeln durchgeführt. Des Weiteren führt Transconnect Syntax- und Semantikprüfungen der EDIFACT-Dateien durch und stößt prüfungsabhängige Aktionen an. Eine lokale Datenbank dokumentiert den aktuellen Verarbeitungsstatus der übertragenen Nachrichten und dient als persistente Zwischenspeicherung für die transaktionsorientierte Zustellung der Nachrichten. SAP IS-U: Die SAP IS-U Anwendung verwaltet die betriebswirtschaftlichen und technischen Stammdaten des Unternehmens. Im Rahmen der beschriebenen Workflows dient es zum Empfang und der Verarbeitung eingehender IDocs und zur Erstellung und Übergabe neuer IDocs an die Middleware. Diese Funktionalitäten werden mit Hilfe des integrierten WFMS Business Workflow durchgeführt. Aufgrund der gesetzlichen Bestimmungen existieren für die einzelnen Marktteilnehmer und ihrer jeweiligen Rolle als Netzbetreiber oder Lieferant separate SAP-Mandanten. Ein Mandant stellt eine handelsrechtlich, organisatorisch und datentechnisch abgeschlossene Einheit innerhalb der SAP-Anwendung dar. Die informatorische Trennung in unterschiedliche Marktteilnehmer und ihre Rollen als Netzbetreiber und Lieferant ist in Abbildung 14 schematisch dargestellt. Abbildung 14: Informatorische Trennung in der WF Anwendung 42

43 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Die ein- und ausgehenden Nachrichten werden in der Nachrichtenqueue von Transconnect eingespeist und sequentiell an die Mandanten von SAP IS-U und die -Konten von Lotus Notes geroutet. Der Ablauf der genannten Workflows wird nachfolgend beschrieben: 1. Workflow für eingehende Nachrichten Für die Ablaufbeschreibung des Workflows ist es erforderlich, das Datenmodell mit den entsprechenden Datenobjekten vorzustellen. Folgende Datenobjekte sind am Workflow für eingehende Nachrichten beteiligt: Datenobjekt, das durch die -Komponente empfangen, verwaltet oder versendet wird Mail-Attachment: Datei-Anhang einer EDIFACT-Datei: EDIFACT-XML: IDoc-XML: IDoc: DA-Aufgabe: Text-Datei, die EDIFACT-Nachrichten kapselt XML-Nachricht der Middleware, die Informationen zu Geschäftsvorgängen einer EDIFACT-Nachricht beinhaltet XML-Nachricht der Middleware, die Informationen zu Geschäftsvorgängen einer EDIFACT-Nachricht in einer für den Backendadapter einlesbaren Struktur beinhaltet SAP-spezifischer Datenbehälter, der die Informationen zu Geschäftsvorgängen einer EDIFACT-Nachricht in einer vordefinierten IDoc-Struktur beinhaltet SAP-spezifisches Datenobjekt, das Informationen zu einem Geschäftsvorgang enthält Eine Datenaustausch-Aufgabe (DA-Aufgabe) wird für ein- und ausgehende Geschäftsvorgänge angelegt. Jeder DA-Aufgabe wird ein Datenaustausch-Prozess (DA-Prozess) zugeordnet, der die Geschäftsvorgangsart genauer beschreibt. Es wird zwischen ein- und ausgehenden Vorgängen unterschieden und zusätzlich geprüft, ob es sich um eine Antwort handelt, die sich auf einen vorhergehenden Geschäftsvorgang bezieht. Für die Geschäftsvorgangsart der Kündigung existieren vier DA-Prozesse: eingehende Kündigung, ausgehende Kündigung, eingehende Kündigungsantwort und ausgehende Kündigungsantwort. Wechselbeleg: SAP-spezifisches Datenobjekt, dem die verschiedenen DA-Aufgaben einer Geschäftsprozessinstanz des Lieferantenwechsels zugeordnet werden Ein Wechselbeleg enthält alle relevanten Informationen zu einem konkreten Lieferantenwechsel zwischen den beteiligten Marktteilnehmern. In Abhängigkeit der Rolle an einer Prozessinstanz werden einem Wechselbeleg verschiedene DA- Prozesse zugeordnet (Zuordnung siehe Anhang 6.2.2). In Abbildung 15 sind die beschriebenen Datenobjekte im Datenmodell dargestellt. 43

44 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes 0 * EDIFACT- Datei 1 1 * Attachement EDIFACT- XML 1 1 Wechselbeleg 1 1 DA- Aufgabe 1 * IDoc-XML Abbildung 15: Datenmodell Workflow eingehender Nachrichten Wie Abbildung 15 zu entnehmen ist, kann eine mehrere Attachments enthalten 3. Ein -Attachment kann eine EDIFACT-Datei oder eine andere beliebige Datei, beispielsweise eine -Signatur, sein. Falls eine EDI- FACT-Datei vorliegt, so werden aus dieser die einzelnen EDIFACT-Nachrichten im XML-Format erzeugt. In Abhängigkeit der vorliegenden EDIFACT- Nachrichtenkategorie, wird aus der EDIFACT-XML-Nachricht eine IDoc-XML-Nachricht erstellt, die wiederum genau ein IDoc erzeugt. Aus diesem IDoc entsteht für jeden enthaltenen Geschäftsvorgang eine DA-Aufgabe. Anschließend wird jede DA-Aufgabe einem Wechselbeleg zugeordnet. In Abbildung 16 ist der Ablauf des Workflows in BPMN-Notation dargestellt. Die verschiedenen Komponenten werden durch die BPMN-Lanes repräsentiert. Zwischen diesen Komponenten werden Dokumente über die definierten Middleware-Adapter transportiert. 1 IDoc 1 1 Abbildung 16: Workflow eingehender Nachrichten 3 Laut BDEW-Richtlinien ist es nur zulässig, s mit genau einem Attachment zu versenden, aber diese Vorgabe wird in der Praxis nicht von allen Marktteilnehmern berücksichtigt ([8, S.10]). 44

45 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Der dargestellte Workflow besteht aus fünf Teilprozessen, auf die im Folgenden näher eingegangen wird. Der Beginn des Workflows wird durch den Empfang einer im - System definiert. Jeder Marktteilnehmer stellt für die Verarbeitung von EDIFACT- Nachrichten ein -Konto mit einer öffentlich bekannten -Adresse zur Verfügung. Diese -Adresse soll laut Vorgaben des BDEW nur für den EDI- FACT-Nachrichtenaustausch genutzt werden ([BDW08_5]). Diese Regelung wird von einigen Marktpartnern jedoch nicht durchgängig beachtet und somit gelangen auch s mit anderen fachlichen Belangen in den EDIFACT-Posteingang. Ein weiteres Problem in diesem Zusammenhang stellt der Empfang von Spam- Mails dar. Diese s werden im Vorfeld durch den Teilprozess der - Vorverarbeitung aussortiert, um Folgefehler im Workflow zu vermeiden und die Performanz der Anwendung zu verbessern. Ein zyklisch aufgerufener Mail-Agent analysiert die Dateiendungen der -Attachments aller im Posteingang vorliegender s und verschiebt die relevanten s in einen Ordner, auf den die Middleware zugreift. Im nächsten Schritt werden die s durch einen von der Middleware zyklisch ausgelösten Job in einen Ordner für s, die sich in Bearbeitung befinden, verschoben. Dieser Vorgang ist notwendig, um die wiederholte Verarbeitung ein und derselben zu verhindern. Eine wiederholte Bearbeitung würde zum Auftreten von Verbuchungsfehlern im Backend führen, die durch Mitarbeiter geprüft und behandelt werden müssten. Die Aktivitäten zwischen Middleware und dem -System werden mit Hilfe eines -Adapters durchgeführt und werden durch die Middleware getriggert. Aus dem Bearbeitungs-Ordner werden die s in die Middleware importiert. Die s durchlaufen nun sequentiell den Teilprozess der EDIFACT2XML- Konvertierung. Die Attachments der einzelnen s werden aus Archivierungsgründen im lokalen Dateisystem der Middleware als Kopie abgelegt. Anschließend werden die Attachments gegebenenfalls entpackt und geprüft, ob EDIFACT- Dateien vorliegen. Durch diese Prüfung werden alle nicht-edifact-attachments einer aussortiert und die tatsächlichen EDIFACT-Dateien an den EDIFACT- Konverter übergeben. In Abhängigkeit der Nachrichtenanzahl innerhalb der EDI- FACT-Datei und des Nachrichtentyps werden durch die Konvertierung eine oder mehrere EDIFACT-Nachrichten im XML-Format erzeugt (EDIFACT-XML). Das Splitting der EDIFACT-Dateien erfolgt auf Basis der UNH-UNT-Segmentpaare. Während der Konvertierung werden die EDIFACT-Dateien einer syntaktischen Prüfung und anschließend einer Modellprüfung unterzogen. Diese Prüfungen erfolgen mittels XML-Metadaten, denen Prüfungsregeln der UN/CEFACT und des BDEW zu Grunde liegen. Nach der erfolgreichen Syntax- und Modell-Prüfung liegen die typbasierten EDIFACT-XML-Nachrichten in der Middleware vor und werden in eine Nachrichtenqueue zur weiteren Bearbeitung eingestellt. Der Teilprozess der Konvertierung wird beendet, in dem die bearbeitete im Mailsystem in einen Ordner für erfolgreich bearbeitete s verschoben wird. Die in der Verarbeitungsqueue vorliegenden Nachrichten werden nun sequentiell mittels nachrichtentypbasierter Routing-Regeln weiterverarbeitet. Diese Regeln basieren auf XSLT-Transformationen. In dieser Nachrichtenqueue laufen alle empfangenen EDIFACT-Nachrichten der verschiedenen -Konten der Marktteilnehmer ein. Die korrekte Zuordnung der Nachrichten zu den jeweiligen Backendmandanten wird durch die Erstellung spezifischer Transconnect- Nachrichtentypen auf Basis der -Adresse des Empfängers vorgenommen. Nach erfolgreicher Konvertierung werden datenflussorientierte und kontrollflussorientierte EDIFACT-XML-Nachrichten unterschiedlich weiter verarbeitet: 45

46 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes 1. EDI2IDoc-XML-Transformation (trfc-asynchron): Eine datenflussorientierte Nachricht kapselt die Geschäftsvorgänge einer Geschäftsvorgangsart. Der Inhalt der Nachricht muss im Backend in Form von Stamm- und Bewegungsdaten hinterlegt werden. Aus diesem Grund wird die Nachricht im nächsten Schritt in eine XML-Nachricht transformiert, die der Struktur des Backendformats, d.h. eines IDocs, entspricht (IDoc-XML-Nachricht). Dieses Nachrichten-Mapping ist notwendig, um den an das Backend angeschlossenen SAP-Adapter mit einer verarbeitbaren XML-Nachricht ansteuern zu können. Der Adapter überträgt die IDoc-Struktur durch einen asynchronen RFC- Aufruf an einen FuBa im SAP, der das entsprechende IDoc erstellt. 2. CONTRL/APERAK-Transformation (RFC-synchron): Liegt eine kontrollflussorientierte Nachricht vor, so bezieht sich diese auf eine vom Empfänger bereits versendete datenflussorientierte EDIFACT-Nachricht. Die kontrollflussorientierte Nachricht enthält die Information, ob die referenzierte Nachricht vom Kommunikationspartner verarbeitet werden konnte. Um diese Information im Backend zu verbuchen, wird mittels des SAP-Adapters synchron ein FuBa aufgerufen, der den Zustand der datenflussorientierten Nachricht, auf die sich die Nachricht bezieht, im Backend aktualisiert. Bei erfolgreicher Rückmeldung des RFC an die Middleware, ist der Workflow für eingehende kontrollflussorientierte Nachrichten beendet. Zusätzlich wird durch jede EDIFACT-XML-Nachricht die lokale Middleware- Datenbank aktualisiert. Diese Datenbank sichert den Verarbeitungsstatus der ein- und ausgehenden EDIFACT-Nachrichten, um bei Systemausfällen und anschließender Systemwiederherstellung die Verarbeitung fortsetzen zu können. Im Fall der datenflussorientierten Nachricht wird der Workflow im Backend durch den Teilprozess der IDoc-Verarbeitung fortgesetzt. Es wird ein weiterer SAP-FuBa aufgerufen, der das IDoc in die enthaltenen Geschäftsvorgänge splittet. In diesem FuBa wird für jeden Geschäftsvorgang die zugehörige DA-Aufgabe zugeordnet und angelegt. Im letzten Schritt werden die erstellten DA-Aufgaben vorgangsspezifisch verbucht. Vorgangsspezifisch bedeutet in diesem Zusammenhang, dass in Abhängigkeit der vorliegenden DA-Aufgabe unterschiedliche Folgeaktivitäten durchgeführt werden. Diese Folgeaktivitäten lösen weitere Workflows aus, erstellen neue SAP-Objekte, aktualisieren vorhandene SAP- Objekte oder legen die eingegangene Nachricht einfach ab. Im Fall des Lieferantenwechsels wird jede DA-Aufgabe einem Wechselbeleg zugeordnet. Bei einer eingehenden Kündigung wird zunächst ein Wechselbeleg erzeugt und diesem wird die DA-Aufgabe der Kündigung zugeordnet. Anschließend werden verschiedene Prüfungen auf den vorliegenden Kunden- und Vertragsdaten durchgeführt und die verantwortlichen Mitarbeiter aus der Fachabteilung informiert. Eine Antwortnachricht wird in Abhängigkeit der Kundendaten automatisch oder manuell durch einen Mitarbeiter generiert und versendet. Dieser Prozess der Erstellung und Versendung von Nachrichten, ausgehend vom Backend, wird durch den Workflow für ausgehende Nachrichten realisiert. 2. Workflow für ausgehende Nachrichten Im Folgenden wird der Workflow für ausgehende Nachrichten beschrieben. Die durch diesen Workflow zu versendeten Nachrichten werden im Backend erstellt und sind ausschließlich datenflussorientiert. Ausgehende kontrollflussorientierte Nachrichten werden als Antwort auf eingehende datenflussorientierte Nachrichten 46

47 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes in der Middleware nach der durchgeführten Prüfung in der EDIFACT2XML- Konvertierung des eingehenden Workflows erstellt und als versendet. In Teilabschnitt 3.2.3, S.53f. wird auf ausgehende, kontrollflussorientierte Nachrichten näher eingegangen. Die Datenobjekte des Workflows für ausgehende Nachrichten und deren Anwendung unterscheiden sich zum Teil von den Datenobjekten des Workflows für eingehende Nachrichten. Das zugehörige Datenmodell ist in Abbildung 17 dargestellt. Wechselbeleg 1 1 * DA- Aufgabe 1 1 IDoc 1 2 * 1 Aggreg. IDoc EDIFACT- XML 1 1 IDoc-XML EDIFACT- XML Abbildung 17: Datenmodell Workflow ausgehender Nachrichten Der Workflow für ausgehende Nachrichten beginnt mit der Erstellung eines Wechselbelegs, der anschließend verschiedene DA-Aufgaben erzeugt. Jede DA- Aufgabe steht für einen einzelnen Geschäftsvorgang. Der Hauptunterschied zum Datenmodell des Workflows eingehender Nachrichten ist die Unterscheidung in zwei IDoc-Objekte. Aus jeder DA-Aufgabe wird zunächst ein IDoc erstellt. Die erstellten IDocs können für den gleichen Nachrichtenempfänger über einen definierten Zeitraum aggregiert und zu einem neuen IDoc zusammengefasst (Aggregiertes IDoc) werden 4. Falls ein einzelnes IDoc aggregiert wurde, wird es nicht weiter verarbeitet, so dass keine doppelte Versendung des gleichen Geschäftsvorgangs durchgeführt wird. Für jedes versendete IDoc entsteht anschließend eine IDoc-XML-Nachricht. Aus dieser IDoc-XML-Nachricht wird eine EDIFACT-XML-Nachricht mit angehängter EDIFACT-Datei erstellt. Aus diesem Konstrukt entsteht eine mit der EDIFACT-Datei als Attachment. Der Ablauf des Workflows für ausgehende Nachrichten besteht aus vier Teilprozessen und ist in Abbildung 18 dargestellt. 4 In der WF Anwendung ist das Aggregieren von IDocs für die Geschäftsvorgangsarten des Lieferantenwechsels noch nicht implementiert, aber in Planung. Für die Entwicklung des Monitors soll die IDoc-Aggregation berücksichtigt werden, um den daraus entstehenden Implementierungsaufwand gering zu halten. 47

48 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Abbildung 18: Workflow ausgehender Nachrichten Der Beginn des Workflows wird durch eine vorgangsspezifische Initialisierung im Backend definiert. Beispiele für eine solche Initialisierung sind das Anlegen einer Kündigung, der Empfang einer Kündigung, das Eintragen eines neuen Zählerstands oder die Durchführung einer Abrechnung. Im Teilprozess der IDoc-Erstellung wird durch die Initialisierung eine DA-Aufgabe zu jedem Geschäftsvorgang angelegt, die die notwendigen Daten für den empfangenden Marktteilnehmer beinhaltet. Aus jeder DA-Aufgabe wird ein IDoc erstellt, welches abhängig vom Geschäftsvorgang mit anderen IDocs zu einem aggregierten IDoc zusammengefasst wird. Ein zyklisch durchgeführter Hintergrund-Job überträgt die IDocs per asynchronen RFC an den SAP-Adapter der Middleware. Dieser Adapter wandelt die IDocs sequentiell in IDoc-XML- Nachrichten um und stellt diese in die Nachrichtenqueue der Middleware ein. Im Teilprozess der XML2EDIFACT-Konvertierung werden die erstellten IDoc-XML- Nachrichten, analog zum Workflow für eingehende Nachrichten, durch nachrichtentypbasierte Routing-Regeln weiterverarbeitet. Zunächst wird ein Eintrag in der lokalen Datenbank der Middleware für ausgehende EDIFACT-Nachrichten erzeugt. In diesem Datenbankeintrag werden die Informationen zum Backendsystem, von dem die IDoc-XML-Nachricht empfangen wurde, hinterlegt, um die spätere Zuordnung zum korrekten Postausgang der -Komponente zu ermöglichen. Anschließend wird die IDoc-XML-Nachricht durch eine XSLT- Transformation in eine EDIFACT-XML-Nachricht umgewandelt und an den EDI- FACT-Konverter übergeben. Während der Konvertierung wird eine syntaktische Prüfung der Nachrichten durchgeführt. Nach bestandener Prüfung wird die EDI- FACT-XML-Nachricht mit angehängter EDIFACT-Datei erstellt und wieder in die Nachrichtenqueue verschoben. Im anschließenden Teilprozess wird mit Hilfe des Mail-Adapters eine generiert, die die erzeugte EDIFACT-Datei als -Attachment beinhaltet. Der Mail-Adapter verschiebt die erstellte in den korrekten Postausgang des Mail-Systems. 48

49 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Im letzten Teilprozess wird vom Mail-System ein zyklischer Mail-Agent aufgerufen, der das Versenden der erstellten s im Postausgang initiiert. Mit dem Verschieben der s in einen Ordner für bereits versendete s ist der Workflow beendet. Zusammenfassung: In diesem Abschnitt wurden die Geschäftsprozesse der Energieversorgung, das Datenaustauschformat EDIFACT und die WF Anwendung der ENSO erläutert. Diese Anwendung realisiert die Verarbeitung der ein- und ausgehenden Nachrichten und stößt weitere Workflows in den Mandanten des SAP-Backends an. Im fehlerfreien Fall wird der Nachrichtenaustausch durch die beschriebenen Workflows vollautomatisiert durchgeführt. Falls Fehler auftreten, können diese zum Teil durch die Anwendung automatisch erkannt und behandelt werden (Standardfehler). Weitere komplexe Fehler treten an verschiedenen Punkten in den beiden Workflows auf und können nicht automatisiert behandelt werden. In diesen Fällen müssen Mitarbeiter in den jeweiligen Workflow eingreifen und die Fehler beheben. Im folgenden Kapitel wird der Istzustand der Prozessabwicklung erläutert. 3.2 Istzustand der Prozessabwicklung In diesem Abschnitt werden zu Beginn die an den Geschäftsprozessen beteiligten Benutzergruppen und die derzeit verwendeten Monitoring-Werkzeuge vorgestellt. Anschließend werden die verschiedenen Fehlerstellen in den Workflows diskutiert Identifikation der Benutzergruppen der Geschäftsprozesse Die operativen Mitarbeiter der beschriebenen Geschäftsprozesse sind organisatorisch in Fachbereiche, Anwendungsbetreuung und Entwicklung/Administration aufgeteilt. Fachbereiche: Jeder Marktteilnehmer hat verschiedene Fachbereiche für die inhaltlich korrekte Abwicklung der Geschäftsprozesse. Beispiele für Fachbereiche sind die Abrechnung, die verantwortlich für die Rechnungslegung über die Netznutzung ist und das Zählerwesen, das die technischen Stammdaten verwaltet. Die Lieferantenwechselprozesse haben direkten Einfluss auf deren Verantwortungsgebiete. Die Arbeit der Fachbereiche mit der verteilten WF Anwendung beschränkt sich auf die Nutzung des Backends. Bei erfolgreicher Verbuchung der EDIFACT-Nachrichten wird der jeweilige Fachbereich mittels der SAP-Workflow-Inbox über durchzuführende Aktivitäten informiert. Zu diesen Aktivitäten zählen unter anderem die Kundenidentifikation bei Abweichungen zwischen Nachrichtendaten und den Backenddaten sowie die Wechselprüfung bei Großkunden. Eine weitere Aufgabe ist die Pflege von Stammdaten im Backend. Neue Marktteilnehmer und neue Netzgebiete müssen angelegt und bestehende Daten angepasst werden. Fachliche Fehler bei der Verbuchung von EDIFACT-Nachrichten, beispielsweise das Fehlen von Daten, müssen durch Mitarbeiter der Fachbereiche behoben werden. Die Fachbereiche interagieren mit den beteiligten Marktteilnehmern, Kunden und anderen Mitarbeitern. Sie geben Auskunft über den aktuellen Zustand von Prozessinstanzen und lösen fachliche Konflikte, die nicht automatisiert durch die Workflows behandelt werden können. 49

50 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Anwendungsbetreuung: Die Aufgabe der Anwendungsbetreuung ist die gesamte Fehlererkennung und Koordination der Fehlerbehandlung der Geschäftsprozesse, die über die WF Anwendung abgewickelt werden. Alle Fehler, die bis zur erfolgreichen Verbuchung von EDIFACT-Nachrichten auftreten, werden durch die Mitarbeiter dieses Bereiches analysiert und die notwendigen Fehlerbehandlungsmaßnahmen eingeleitet. Unter anderem werden Anpassungen an Funktionsbausteinen im Backend vorgenommen und Stammdaten nachgepflegt. Bei spezifischen Fehlern interagiert die Anwendungsbetreuung mit den Mitarbeitern der Entwicklungs- und Administrationsabteilung und den verschiedenen Fachbereichen. Werden beispielsweise fehlende Funktionalitäten, Programmierfehler oder Systemausfälle entdeckt, so wird die Entwicklungs- und Administrationsabteilung zur Fehlerbehebung eingeschaltet. Komplexe fachliche Fehler, die vorgangsspezifisches Prozesswissen erfordern, werden an die Mitarbeiter des verantwortlichen Fachbereichs adressiert. Eine weitere Aufgabe der Anwendungsbetreuung ist die Umsetzung der vom BDEW regelmäßig veröffentlichten Änderungen der Geschäftsprozesse in der WF Anwendung ([GPKE06_1], S.45f.). Diese Änderungen betreffen die genutzten Felder der verwendeten EDIFACT-Nachrichtentypen, die Prozessabläufe und die Kommunikation zwischen den Marktteilnehmern. In diesen Fällen wird in Zusammenarbeit mit dem Fachbereich über das zukünftige Vorgehen entschieden. Die Entscheidung wird der Entwicklungs- und Administrationsabteilung mitgeteilt, die die Anpassungen an der WF Anwendung durchführt. Entwicklung/Administration: Die Mitarbeiter der Entwicklung/Administration sind verantwortlich für die Entwicklung, Erweiterung und Wartung der verteilten Anwendung und der zugrunde liegenden Systemlandschaft. Diese Benutzergruppe hat für jede der drei Komponenten der WF Anwendung spezielle Ansprechpartner. Die Entwickler und Administratoren werden durch die Anwendungsbetreuung kontaktiert, falls eine Korrektur oder Erweiterung der bestehenden Anwendung erforderlich ist. Anhand der Aufgaben der beteiligten Benutzergruppen kann abgeleitet werden, dass das größte Potenzial einer BAM-Lösung die Unterstützung der Fachbereiche, der Anwendungsbetreuung und der Administration bei der täglichen Arbeit der Nachverfolgung von Nachrichten und der Fehlererkennung ist. Eine weitere potentielle Benutzergruppe für eine BAM-Lösung ist die Unternehmensführung (Management) der jeweiligen Marktteilnehmer. Diese Benutzergruppe ist verantwortlich für die strategische Unternehmensplanung. Eine BAM-Lösung kann als Entscheidungshilfe für diese Planung Statistiken über die gesammelten Daten der Geschäftsprozesse, beispielsweise die Anzahl der Lieferantenwechsel über einem definierten Zeitraum, erstellen und in entsprechender Form anzeigen Bestehende Monitoring-Werkzeuge Die derzeit verwendeten Monitoring-Werkzeuge in der ENSO werden nachfolgend beschrieben. SAP IS-U, Transconnect und Lotus Notes enthalten separate Monitoring-Funktionalitäten, die jeweils eine komponentenspezifische Sicht auf die Geschäftsprozesse und den damit verbundenen Nachrichtenverkehr ermöglichen. 50

51 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes -Monitor: Für die Überwachung der -Komponente wird der klassische -Client, der zur Verwaltung der -Konten der verschiedenen Marktpartner eingesetzt wird, verwendet. Für eine übersichtlichere Analyse des gesamten -Verkehrs werden die -Konten der verschiedenen Markteilnehmer durch Ordner strukturiert. Die Sortierung der einzelnen s in die definierten Ordner wird durch die Mail-Agenten und durch die Middleware vorgenommen. Für das Auffinden bestimmter Geschäftsvorgänge werden die im -Client integrierten Such- und Sortierfunktionalitäten verwendet. Die Mitarbeiter der Fachbereiche und Anwendungsbetreuung benutzen die in den Dateinamen der Attachments und in der Betreffzeile enthaltenen Informationen als Suchkriterien für die Volltextsuche im -Client, um Nachrichten zu einem speziellen Geschäftsvorgang zu finden. Middleware-Monitor: Transconnect bietet standardmäßig keine BAM- Komponente, wie bei den in Teilabschnitt genannten Produkten, an. Im Lieferumfang steht lediglich das Werkzeug Transconnect Manager zur Verfügung, welches als Administrations- und Entwicklungswerkzeug für die in der Middleware laufenden Prozesse eingesetzt wird. Dieses Produkt erhebt nicht den Anspruch Informationen auf der Geschäftsprozessebene bereit zustellen. Die in der Middleware vorliegenden XML-Nachrichten können durch Anzeige der verschiedenen Nachrichtenqueues überwacht werden. Zusätzlich können Logfiles der verwendeten Adapter analysiert werden. Die Suche nach bestimmten Geschäftsvorgängen und die damit verbundene Nachverfolgung von Geschäftsprozessinstanzen gestalten sich mit dem Transconnect Manager schwierig. Die Nachrichtenqueues werden in Form von Listen dargestellt und zeigen die XML-Nachrichten nur mit den middlewarespezifischen Namenskonventionen an. Der Inhalt der Nachrichten kann nicht im Transconnect Manager angezeigt werden. Die jeweilige Nachricht muss in der Liste selektiert werden, auf das lokale Dateisystem des Mitarbeiters exportiert werden und kann mittels eines beliebigen XML-Editors angezeigt werden. Die Logfiles werden innerhalb des Transconnect Managers in einem Texteditor angezeigt und enthalten technisch orientierte und umfangreiche Informationen über den Verlauf der Aufrufe zu den Systemen, die mit der Middleware interagieren. Die Mitarbeiter der Fachbereiche und der Anwendungsbetreuung haben nicht das benötigte technische Hintergrundwissen und die Zeit, um aus diesen ungefilterten Informationen den Verlauf eines konkreten Geschäftsvorgangs nachzuvollziehen. Besonders in Fällen, in denen direkt mit dem Marktpartner einer Geschäftsprozessinstanz kommuniziert wird, ist die Nutzung des Transconnect Manager für Mitarbeiter der Fachbereiche nicht zweckmäßig. Außerdem sind Such- und Sortierfunktionalitäten nur in geringem Umfang enthalten. Falls Fehler bei der Nachrichtenverarbeitung innerhalb der Middleware auftreten, werden die betreffenden Nachrichten in eine Fehlerqueue eingestellt und müssen durch Mitarbeiter der Administration behandelt werden. SAP-Monitor: Im Backend stehen den Mitarbeitern die drei folgenden SAP- Transaktionen (SAP-TA) zur Verfügung: Transaktion I Transaktion II Transaktion III = Statusmonitor für IDocs (SAP-TA: BD87) = Anzeige von DA-Aufgaben (SAP-TA: EDATEXMON01) = Überwachung der Wechselbelege (SAP-TA: ESWTMON01) Jede dieser Transaktionen bietet SAP-Standard-Suchoptionen, wie beispielsweise die Suche nach Nachrichten aus einem bestimmten Erstellungszeitraum und nach 51

52 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes objektspezifischen Attributen, an. Die Transaktionen I und II dienen zur Überwachung der Backend-Datenobjekte, die zur Abwicklung aller Geschäftsprozesse der Energiebranche relevant sind. IDocs und DA-Aufgaben werden Status aus einem definierten Satz zugeordnet, die die aktuelle Verarbeitung der Objekte anzeigen. Die Überwachung der Wechselbelege ermöglicht die fachliche Sicht auf die kompletten Instanzen des Lieferantenwechselprozesses. In den Teilprozessen IDoc-Erstellung und IDoc-Verbuchung der beiden beschriebenen Workflows treten Fehler auf, die direkten Einfluss auf die Erstellung der Backend-Datenobjekte haben. Die potentiellen Fehler müssen mit Hilfe der Transaktionen I und II erkannt werden. Ist beispielsweise das IDoc einer eingehenden Nachricht fehlerhaft und kann nicht verbucht werden, werden die enthaltenen Geschäftsvorgänge nicht als DA-Aufgaben angelegt. Ein Fehler dieser Art kann nur mit Hilfe der Transaktion I erkannt werden, da Transaktion II nur DA-Aufgaben anzeigt. Im Gegensatz dazu werden bei ausgehenden Nachrichten zum Teil fehlerhafte DA-Aufgaben angelegt, aus denen kein IDoc generiert wird. In diesem Fall muss die Transaktion II verwendet werden, um den Fehler zu erkennen. Die Transaktion III greift auf den Workflow Audit Trail des WFMS zu und dient zum Auffinden der an einer Geschäftsprozessinstanz beteiligten DA-Aufgaben und zur Anzeige der initiierten Workflows im Backend. In Abhängigkeit der Rolle des Marktpartners kann der Verlauf der Geschäftsprozessinstanzen des Lieferantenwechsels anhand des Wechselbelegs nachvollzogen werden. Für die Fehlererkennung und die anschließende Fehlerbehandlung ist es für die Mitarbeiter notwendig zwischen diesen Transaktionen zu navigieren. Mehrere SAP-Modi müssen geöffnet werden und die Referenznummern der beteiligten Datenobjekte werden durch Kopieren in die Zwischenablage in die verschiedenen Modi transferiert. Eine vollständige Übersicht über den Verlauf der Workflows im Backend ist nicht verfügbar und mit zunehmender Anzahl der zu überwachenden Prozessinstanzen wird das Arbeiten mit den drei genannten Transaktionen unübersichtlich. Wie aus der Beschreibung der verschiedenen Monitor-Werkzeuge hervorgeht, sind diese nur teilweise geeignet die Mitarbeitergruppen bei ihrer täglichen Arbeit zu unterstützen. Folgende Tabelle gibt einen Überblick über die Verwendung der genannten Monitorfunktionalitäten: -Monitor Middleware- Monitor SAP-Monitor Werkzeug Mitarbeiter Fachbereiche Anwendungsbetreuung Entwicklung/ Administration oft verwendet selten verwendet nicht im Einsatz Tabelle 1: Verwendung der Monitoring-Werkzeuge pro Mitarbeitergruppe Fazit: Die beschriebenen Monitoring-Werkzeuge unterstützen die Fachbereiche und die Anwendungsbetreuung nur unzureichend bei der Betreuung der Geschäftsprozesse. Die Defizite der gesamten Monitoring-Situation sollen nachfolgend zusammengefasst werden: 52

53 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Verwendung von drei verschiedenen Monitoring-Werkzeugen hoher Navigationsaufwand, hoher Einarbeitungsaufwand keine prozessorientierte, systemübergreifende Sicht auf Nachrichten aufgrund fehlender Verknüpfung der Datenobjekte über die verschiedenen Monitore aufwändige Suche nach Nachrichten fehlendes Kontextwissen zum aktuellen Zustand einer Nachricht und keine Möglichkeit innerhalb der Monitoring-Werkzeuge durchgeführte und durchzuführende Fehlerbehandlung zu dokumentieren hoher Kommunikationsaufwand, um abteilungsübergreifende Fragen und Probleme zu lösen keine Statistiken über volumen- und zeitbezogene Indikatoren (Beispiele: Anzahl der Lieferantenwechsel über bestimmte Zeit, Anzahl und Werte von elektronischen Rechnungen) Neben der für den Fachbereich relevanten Nachverfolgung von Nachrichten ist die Erkennung und Behandlung von Fehlern im Workflow die entscheidende Aufgabe der zu entwickelnden BAM-Lösung. Der folgende Teilabschnitt beschreibt die Fehlerproblematik in der WF Anwendung der ENSO Fehler in den Geschäftsprozessen Die in diesem Abschnitt vorgestellten Fehlerkategorien beziehen sich auf die EDI- FACT-Dateien in den beschriebenen Workflows, deren Verarbeitung aus verschiedenen Gründen fehlschlägt. Für die jeweilige Geschäftsprozessinstanz hat dies zur Folge, dass ein Geschäftsvorgang nicht durchgeführt wird und die damit verbundenen Folgeaktivitäten nicht ausgelöst werden. Die gesamte Prozessinstanz befindet sich somit in einem fehlerhaften Zustand und kann nicht erfolgreich beendet werden. Das Ziel der Fehlerbehebung ist die erfolgreiche Fortsetzung der Prozessinstanzen innerhalb der gesetzlich in [GPKE06_1] und [GPKE06_2] vorgegebenen Übertragungsfristen. Die Fehler repräsentieren die Indikatoren für die Erstellung der BAM-Lösung. Aus den Indikatoren werden Regeln abgeleitet, wie diese Fehler im Monitor anzuzeigen sind. Die Regeln definieren die folgenden Workflow-Zustände: GRÜN Workflow ok GELB Workflow fehlerhaft, keine manuelle Bearbeitung erforderlich ROT Workflow fehlerhaft, manuelle Bearbeitung erforderlich. Fehler im Workflow eingehender Nachrichten Aussortierte s: Im Teilprozess der -Vorverarbeitung werden die empfangenen s anhand der Dateiendungen der Attachments gefiltert. Die zulässigen Dateiendungen werden durch die Kommunikationsrichtlinie des BDEW vorgegeben ([BDW08_5]). Fehlerhafte s werden in einen separaten Ordner im Lotus Notes verschoben. Regel für Monitoring: Darstellung der eingegangen durch zwei Status: GRÜN = in Bearbeitungsordner verschoben ROT = aussortiert 53

54 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Eine Überwachung dieser Fehler durch den Monitor ist notwendig, da zum Teil s aussortiert werden, deren Attachments durch Übertragungsfehler verändert oder durch den sendenden Marktpartner falsch benannt worden sind. Der Nachrichteninhalt ist korrekt, aber die zugehörige wird aussortiert. In diesen Fällen können die Mails direkt oder nach geringfügiger Anpassung in den Bearbeitungsordner, auf den die Middleware zugreift, verschoben und erfolgreich verarbeitet werden. Der Ordner für fehlerhafte Mails wird unregelmäßig kontrolliert und es ist organisatorisch nicht festgelegt, wer diese Überprüfung vornimmt. Aufgrund dieser Tatsache bleiben die enthaltenen Geschäftsvorgänge über längere Zeit unbearbeitet und die Mitarbeiter werden nicht über die Problematik informiert. In einer zentralen Monitoring-Lösung können die aussortierten Mails als Fehler angezeigt werden und nach einer Untersuchung durch zuständige Mitarbeiter weiter verarbeitet oder endgültig aussortiert werden. Entkopplungsfehler: Nach der Übertragung der an die Middleware werden die -Attachments sequentiell durch die WF Anwendung entkoppelt (siehe EDIFACT2XML-Konvertierung in Teilabschnitt 3.1.3). Bei diesem Vorgang können unterschiedliche Fehler auftreten: der Adapter zum lokalen Filesystem ist nicht verfügbar, die komprimierten Attachments können nicht dekomprimiert werden oder es liegen nach der Dekomprimierung keine EDIFACT-Dateien vor. Treten derartige Entkopplungsfehler auf, wird die eingegangene in einen Fehlerordner im Mail-System verschoben, der durch die Mitarbeiter unregelmäßig kontrolliert wird. Eine BAM-Lösung könnte diese Fehler automatisch erkennen und den Mitarbeitern anzeigen. Regel für Monitoring: Darstellung der eingegangenen durch zwei Status: GRÜN = Attachment ist EDI-Datei ROT = Fehler beim Entkoppeln, in Fehlerordner verschoben Nach Entkopplung der Attachments liegen die EDIFACT-Dateien in der Middleware vor. Für die automatisierte Abwicklung von Standardfehlern in EDIFACT- Nachrichten werden die EDIFACT-Dateien in Abhängigkeit des Nachrichtentyps einer Syntaxprüfung und anschließend einer Modellprüfung unterzogen. Die Prüfungen werden im Folgenden beschrieben: Die Syntaxprüfung basiert auf Regeln der UN/CEFACT, die die Nachrichtenstruktur der verwendeten EDIFACT-Nachrichtentypen vorgeben. Diese Regeln beschreiben das Format, die Anzahl und die Anordnung der Felder und Segmente innerhalb der EDIFACT-Dateien. Unter anderem werden Felder und Segmente als Pflichtelemente oder optionale Elemente deklariert und die maximale Anzahl von Elementen innerhalb einer Datei wird festgelegt. Die Syntaxregeln sind unabhängig vom fachlichen Inhalt der Nachrichtenfelder und dem Geschäftsbereich, in dem die EDIFACT-Nachrichten verwendet werden. Die Ergebnisse der Syntaxprüfung werden als CONTRL-Nachricht an den Kommunikationspartner übermittelt. Wenn die eingehende EDIFACT-Datei syntaktisch korrekt ist, wird die Modellprüfung durchgeführt. Die Modellprüfung bezieht sich auf den fachlichen Inhalt der Nachricht und basiert auf Modellregeln des BDEW, die das Datenmodell und die zugehörigen Attribute der verwendeten Geschäftsobjekte in der Energiebranche berücksichtigen. Diese Prüfregeln operieren auf Feldebene der EDIFACT-Dateien und definieren zusätzliche Pflichtfelder und kontrollieren vorgegebene Wertebereiche. Des Weiteren wird eine im Vergleich zur Syntaxkontrolle erweiterte Formatprüfung vorgenommen, die auf Basis regulärer Ausdrücke die Nachrichtenfelder 54

55 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes kontrolliert. Wenn eine EDIFACT-Datei die Modellprüfung nicht besteht, wird eine APERAK-Nachricht an den Kommunikationspartner versendet. Bezogen auf die WF Anwendung der ENSO können folgende Fehlerfälle eintreten: Syntaxfehler: Eine EDIFACT-Datei liegt in der Middleware vor und soll durch den EDIFACT-Konverter in EDIFACT-XML-Nachrichten umgewandelt werden. Bei der Syntaxprüfung wird jedoch ein Fehler in der Datei festgestellt. Dadurch wird die Konvertierung abgebrochen und automatisch eine CONTRL-Nachricht erzeugt und als Mail-Attachment versendet. Die eingehende , die die fehlerhafte EDIFACT-Datei enthält, wird in einen Fehlerordner in der -Anwendung verschoben. In diesem Fehlerfall muss zunächst kein Mitarbeiter eingreifen. Sollte der Sender der Nachricht Fragen zu der negativen CONTRL-Antwort haben, setzt er sich mit dem Fachbereich des Empfängers in Verbindung. Die Mitarbeiter dieses Fachbereichs können die eingegangene fehlerhafte EDIFACT-Datei und die automatisch generierte CONTRL nicht im Backend nachvollziehen und wenden sich an die Anwendungsbetreuung. Der entstehende Kommunikationsaufwand könnte mit Hilfe einer BAM-Lösung, die eine prozessorientierte Sicht integriert, verringert werden. Regel für Monitoring: Darstellung der EDIFACT-Datei durch zwei Status: GRÜN = EDI-Datei syntaktisch ok, positives CONTRL versenden GELB = Syntaxfehler, negatives CONTRL versenden Modellprüfung fehlerhaft: Werden Fehler in der eingehenden EDIFACT-Datei durch die Modellprüfung festgestellt, erzeugt der Workflow eine APERAK- Nachricht. In der -Anwendung wird automatisch eine mit dieser Nachricht als Attachment erstellt und versendet. Analog zur Syntaxprüfung wird die zugehörige in den Fehlerordner der -Anwendung verschoben und das manuelle Eingreifen durch Mitarbeiter ist vorerst nicht erforderlich. Regel für Monitoring: Darstellung der EDIFACT-Datei durch zwei Status: GRÜN = Modellprüfung ok GELB = Modellprüfung fehlerhaft, APERAK versendet Die Antwortzeiten für die zu sendenden CONTRL- und APERAK-Nachrichten sind durch den BDEW in [BDW08_6], S.10f. vorgeschrieben, damit der Sender der Nachricht in Kenntnis gesetzt wird, ob die gesendete Nachricht beim Empfänger eingegangen ist, fehlerfrei geprüft wurde oder ob Fehlerbehandlungsmaßnahmen eingeleitet werden müssen. Bei Nichteinhalten dieser Antwortfristen können Marktteilnehmer durch die Bundesnetzagentur sanktioniert werden. Aus diesem Grund ist die Überwachung der zu versendenden kontrollflussorientierten Nachrichten erforderlich. Im jetzigen Monitoring werden Fehler beim Senden dieser Nachrichten nicht direkt angezeigt. Die -Anwendung verschiebt die Nachrichten in den Fehlerordner der -Anwendung, der manuell überprüft wird. Eingehende kontrollflussorientierte Nachrichten werden im Teilprozess der CONTRL/APERAK-Transformation verarbeitet (siehe Teilabschnitt 3.1.3). Diese Nachrichten beziehen sich auf bereits versendete EDIFACT-Dateien der WF Anwendung. Folgende Fehlerfälle können eintreten: Negative CONTRL empfangen: Auf eine ausgehende mit EDIFACT-Datei wird eine negative CONTRL-Nachricht empfangen. Es liegt entweder ein Syntaxfehler in der EDIFACT-Nachricht vor, der im Workflow bei der Erstellung der ausgehenden Nachricht verursacht wurde, oder die Syntaxprüfung des beteiligten Marktpartners wird nicht korrekt durchgeführt, da sie beispielsweise auf 55

56 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes veralteten Meta-Daten basiert. Die CONTRL/APERAK-Transformation schreibt den fehlerhaften Status in das IDoc des SAP Backends. Die Fehlererkennung erfolgt mit Hilfe der Transaktion I. Die zugehörige ausgehende EDIFACT-Datei wird durch die Mitarbeiter der Anwendungsbetreuung untersucht. Falls keine Fehler im Workflow festgestellt werden können, wird ein Ansprechpartner des beteiligten Marktpartners zur Fehlerklärung kontaktiert. Liegt ein Fehler im Workflow und damit in der Anwendung vor, wird der Fehler behoben und der Workflow erneut im Backend gestartet. Regel für Monitoring: Darstellung der versendeten durch zwei Status: GRÜN = positive CONTRL empfangen (Syntax ok) ROT = negatives CONTRL empfangen (Syntaxfehler) Keine CONTRL empfangen: Ein zusätzlicher Status kann für versendete s eingeführt werden, der das Überschreiten der Antwortfrist von eingehenden CONTRL-Nachrichten anzeigt. Dieser Sonderfall tritt ein, wenn die vom Marktteilnehmer aufgrund von Übertragungsfehlern nicht empfangen werden konnte oder der empfangende Marktteilnehmer keine CONTRL-Nachricht versendet hat. Regel für Monitoring: Darstellung der versendeten durch zusätzlichen Status GELB : GRÜN = positive CONTRL empfangen (Syntax ok) GELB = keine CONTRL innerhalb der Antwortfrist erhalten ROT = negatives CONTRL empfangen (Syntaxfehler) APERAK empfangen: Auf eine ausgehende mit EDIFACT-Datei wird eine APERAK-Nachricht empfangen, die einen Modellfehler beschreibt. Die Erkennung und Behandlung der Fehler aus dieser Kategorie ist äquivalent zum Empfang einer negativen CONTRL-Nachricht. Ein Unterschied besteht für die resultierende BAM-Regel im fehlerfreien Fall. Während bei der Syntaxprüfung eine positive CONTRL-Nachricht als Antwort auf eine syntaktisch richtige Nachricht und Empfangsbestätigung vorgesehen ist, wird bei der positiven Modellprüfung keine Antwort-Nachricht versendet. Der Sender der Nachricht kann nur anhand der APERAK-Antwortfrist entscheiden, ob die Nachricht beim Empfänger erfolgreich verarbeitet werden konnte. Wird die Frist überschritten und ist gleichzeitig keine APERAK-Nachricht eingegangen, kann der Status auf GRÜN gesetzt werden. Regel für Monitoring: Darstellung der versendeten durch zwei Status: GRÜN = keine APERAK empfangen ROT = APERAK empfangen (Modellprüfung fehlgeschlagen) Nachdem der Backend-Adapter der Middleware ein IDoc aus der IDoc-XML- Nachricht erzeugt und an das Backend versendet hat, muss dieses im SAP IS-U verbucht werden (siehe Teilabschnitt 3.1.3). Die Verbuchung wird durch Aufruf eines FuBas durchgeführt, bei dem Fehler der folgenden zwei Kategorien auftreten können: Nicht unterstützte Geschäftsvorgangsart: Nach Erstellung des IDocs wird kontrolliert, ob für die konkrete Geschäftsvorgangsart Verarbeitungsfunktionalitäten im Backend implementiert sind. Ist dies nicht der Fall, werden keine DA-Aufgaben erzeugt und das IDoc erhält einen Fehlerstatus. Die fehlerhaften IDocs können nur mittels der in Teilabschnitt beschriebenen Transaktion I erkannt werden. Die Ursachen für diese Fehlerkategorie sind zum einen, dass bestimmte Vorgangsarten Informationen enthalten, die im 56

57 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Unternehmen nicht weiter verwendet werden und zum anderen, dass die zugehörigen Verarbeitungsfunktionalitäten noch entwickelt werden. Regel für Monitoring: Darstellung des IDocs durch zwei Status: GRÜN = Geschäftsvorgangsart unterstützt ROT = Geschäftsvorgangsart unbekannt DA-Aufgabe-Verbuchungsfehler: Wie bereits in der Workflowbeschreibung erwähnt, werden aus den einzelnen Geschäftsvorgängen eines IDocs DA- Aufgaben generiert. Aus verschiedenen Gründen können diese DA-Aufgaben fehlerhaft angelegt werden. Die Ursachen können nachrichtenbedingt, d.h. fehlende oder fehlerhafte Daten innerhalb der Geschäftsvorgänge, oder anwendungsbedingt, also fehlende Daten im SAP IS-U, sein. Im nachrichtenbedingten Fall enthält die eingehende Nachricht Fehler, die nicht durch die Syntax- und Modellprüfung der Middleware erkannt werden. Ein Beispiel ist das vollständige Fehlen von Segmenten, die laut Modellprüfung Pflichtfelder enthalten. Die Segmente sind optional und müssen entsprechend der Syntaxprüfung nicht in der Nachricht enthalten sein. Die Syntaxprüfung zeigt aus diesem Grund keine Fehler an. Die anschließende Modellprüfung prüft nur die Felder in den vorhandenen Segmenten. Der Fehler bleibt unentdeckt und die Nachricht wird in das Backend eingespielt. Die DA-Aufgabe wird fehlerhaft angelegt, weil die Daten aus den fehlenden Feldern benötigt werden, um die anschließenden SAP-Workflows zu initiieren. Ein anwendungsbedingter Fehler beim Anlegen der DA-Aufgaben kann beispielsweise durch das Fehlen von Stammdaten zum sendenden Marktteilnehmer auftreten. In diesen Stammdaten wird hinterlegt, welche DA-Prozesse mit dem jeweiligen Marktpartner vereinbart sind (Agreements) und durch das Backend unterstützt werden. Ein weiterer anwendungsbedingter Fehler entsteht, wenn die Zuordnung einer DA-Aufgabe zu einem bestehenden Wechselbeleg fehlschlägt. Das fehlerhafte Anlegen von DA-Aufgaben führt zur Rückschreibung eines Fehlerstatus in das zugehörige IDoc. Die Fehler dieser Kategorie können mittels Transaktion I und II erkannt werden (siehe Teilabschnitt 3.2.2). Regel für Monitoring: Darstellung des IDocs durch zwei Status: GRÜN = DA-Aufgaben erfolgreich angelegt ROT = Mind. eine DA-Aufgabe fehlerhaft angelegt Darstellung der DA-Aufgabe: GRÜN = Vorgang verbucht ROT = Vorgang nicht verbucht Fehler im Workflow ausgehender Nachrichten RFC-Versendefehler: Ein zu versendendes IDoc wird im Normalfall an die Middleware per asynchronen RFC versendet. Vor dem Versenden erhält das IDoc den Status versandfertig und wird anschließend in die RFC-Queue des Backends verschoben. Bei der Verarbeitung dieser Queue tritt in seltenen Fällen der Konflikt auf, dass mehrere IDocs gleichzeitig versendet werden. Nur eines der gesendeten IDocs wird vom Adapter der Middleware verarbeitet. Die restlichen IDocs verbleiben in der RFC-Queue und gelten als abgearbeitet. Fehler dieser Kategorie können nur mit Hilfe des Zeitstempels der letzten Zustandsänderung des IDocs in Transaktion I erkannt werden. In diesen Fällen kann die Wiederverarbeitung der IDocs manuell durch eine Transaktion im Backend ausgelöst werden. Die IDocs werden erneut versendet, womit der Workflow fortgesetzt wird. 57

58 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Regel für Monitoring: Darstellung des IDocs durch zwei Status: GRÜN = IDoc an Middleware übergeben ROT = IDoc nicht versendet Syntaxfehler: Die zu verarbeitenden XML-Nachrichten werden in der Transconnect-Middleware der Syntaxprüfung unterzogen. Diese Prüfung ist analog zur Syntaxprüfung bei eingehenden Nachrichten. Fehler in der Syntax einer ausgehenden Nachricht lassen sich auf Programmierfehler in den Funktionsbausteinen des Backends zurückführen, die bei der Erstellung der IDocs aufgerufen werden. Die Konvertierung wird abgebrochen und das zugehörige IDoc-XML-Dokument wird in eine Fehlerqueue in der Middleware verschoben. Im jetzigen Monitoring- Konzept werden diese Fehler per der Anwendungsbetreuung gemeldet. In einer BAM-Lösung könnten diese Fehler zentral, d.h. allen Mitarbeitern, angezeigt werden. Regel für Monitoring: Darstellung des IDocs durch zwei Status: GRÜN = EDIFACT-Datei syntaktisch korrekt ROT = EDIFACT-Datei syntaktisch falsch -Versendefehler: Vor dem automatischen Versand im Lotus Notes werden die s im Entwurfsordner erstellt. Die s werden im Normalfall an die von der Middleware mitgelieferte -Adresse versendet. In der Praxis ist der Fall eingetreten, dass diese Adresse nicht korrekt im Header der eingetragen wird, da Stammdaten im Backend nicht gepflegt sind. Die s bleiben im Entwurfsstatus und werden nicht versendet. Mit den jetzigen Monitoring-Werkzeugen bleiben diese Fehler unerkannt. Der Entwurfsordner muss manuell untersucht werden und anhand der Zeitstempel der s können derartige Fehler bemerkt werden. Die Folge dieser Fehler ist das zeitverzögerte Versenden der in den s enthaltenen Geschäftsvorgänge. Regel für Monitoring: Darstellung der durch zwei Status: GRÜN = versendet ROT = -Verweildauer in Entwurfsordner überschritten Die aufgestellten Fehlerkategorien definieren Fehler, die in der WF Anwendung bereits aufgetreten sind. Die Gesamtheit der Fehler wird mit diesen Kategorien jedoch nicht erfasst. Besonders Programmierfehler oder systembedingte Ausfälle der Einzelkomponenten der WF Anwendung führen zu verschiedenen Fehlerfällen, die nicht im Voraus berücksichtigt werden können. Derartige Fehler werden unter der Kategorie Sonstige Fehler eingeordnet. Eine weitestgehend automatische Erkennung dieser Fehler sollte in der BAM-Lösung angestrebt werden. Die Vielfältigkeit der Fehler lässt sich durch folgende Faktoren im Rahmen der Geschäftsprozesse des Energiemarktes begründen: 1. Spezielle Geschäftsvorgänge, die mittels EDIFACT-Nachrichten abgebildet werden können, aber noch nicht durch Marktteilnehmer eingesetzt bzw. durch die WF Anwendung nicht unterstützt werden Erweiterung der WF Anwendung erforderlich 2. Regelmäßige Überarbeitung der EDIFACT-Nachrichtenformate durch den BDEW zur Optimierung der Geschäftsprozesse Anpassung der WF Anwendung notwendig 58

59 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes 3. Steigenden Anzahl der Energielieferanten auf dem Markt Aktualisierung der Kontaktdaten in der WF Anwendung erforderlich Zusammenfassung: Zu Beginn des zurückliegenden Abschnitts wurden die verschiedenen Benutzergruppen vorgestellt, die an den Geschäftsprozessen beteiligt sind. Es erfolgte eine Beschreibung der aktuell verwendeten Monitoring-Werkzeuge und eine Aufstellung der damit verbundenen Defizite bei der Betreuung der Geschäftsprozesse. Abschließend wurden die potentiellen Fehler erläutert, kategorisiert und Regeln aufgestellt, wie diese Fehler in einem Monitor anzuzeigen sind. 3.3 Sollzustand der Prozessabwicklung Nachdem Abschnitt 3.2 die derzeitige Prozessabwicklung behandelt hat, soll in diesem Abschnitt beschrieben werden, wie durch Einführung einer BAM-Lösung die zukünftige Betreuung der Geschäftsprozesse, bezogen auf die Transparenz der Nachrichtenverarbeitung und Fehlerreaktionszeit, optimiert werden kann. In Teilabschnitt werden die verschiedenen Anforderungen an eine BAM- Lösung formuliert und begründet. Anschließend wird eine konzeptuelle Umsetzung des Monitors auf Basis des erstellten Anforderungskatalogs vorgestellt (Teilabschnitt 3.3.2) Anforderungskatalog für Monitoring Die aufgestellten Anforderungen sind in die drei Kategorien funktionale Anforderungen, Qualitätsanforderungen und Rahmenbedingungen eingeteilt (vgl. [Poh08]). Funktionale Anforderungen: Funktionale Anforderungen beschreiben die Funktionalitäten, die der Monitor den Benutzern zur Verfügung stellen soll. 1. Zentrale Nachrichtenüberwachung auf Basis der verteilten WF Anwendung und des zu Grunde liegendem verteilten Systems (Single Point of Control): Die Workflowinstanzen für ein- und ausgehende Nachrichten sollen systemübergreifend in einem Monitoring-Werkzeug dargestellt werden. Alle Statusänderungen der laufenden Instanzen sollen angezeigt werden (Online- Monitoring). Die Monitoring-Lösung soll alle Mitarbeiter der vorgestellten Abteilungen bei der Durchführung ihrer jeweiligen Aufgaben unterstützen. 2. Automatische Fehlererkennung: Auf Basis der beschriebenen Fehlerkategorien und der aufgestellten Regeln sollen die Fehler in laufenden Instanzen automatisch erkannt und angezeigt werden. Zusätzliche Kontextinformationen zur Fehlerursache sind, wenn vorhanden, anzugeben. Die Benachrichtigung der verantwortlichen Mitarbeiter in Form von s bei Eintreten von Fehlern ist wünschenswert (aktives Monitoring). 3. Integrierte Suchfunktionen: In Abhängigkeit des Verarbeitungsstatus können Workflowinstanzen anhand typischer Kriterien gesucht werden. Diese Kriterien richten sich nach den Attributen der erstellten Datenobjekte einer Workflowinstanz: 59

60 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes IDoc-Nummer Wechselbelegnummer -Betreff Kundennummer und Kundendaten (Vor- und Nachname) Transconnect-ID Notes-ID EDIFACT-Nachrichtenreferenz Datum und Uhrzeit der Nachricht Sender- und Empfängerinformationen Mittels dieser Informationen können die Mitarbeiter aus den verschiedenen Abteilungen bestimmte Geschäftsvorgänge schneller finden. Dies ist insbesondere für die Mitarbeiter der Fachbereiche hilfreich, wenn sie mit Kunden oder Marktteilnehmern interagieren. Die Suchmasken sollten die Kombination von Suchkriterien ermöglichen. 4. Links auf Datenobjekte der Workflowinstanzen: Besonders für die Anwendungsbetreuung ist es notwendig die eingehenden und ausgehenden Nachrichten im Fehlerfall zu untersuchen. Aus diesem Grund soll der Monitor den Zugriff auf folgende Datenobjekte ermöglichen: mit Attachment(s) EDIFACT-XML Die s mit EDIFACT-Dateien als Attachments werden in der WF Anwendung nach Ablauf einer definierten Zeit in ein Langzeit-Archiv verschoben. Im Monitor soll der Zugriff auf diese Datenobjekte auch nach Archivierung bestehen bleiben. 5. Aufruf von Bearbeitungsfunktionen der Komponenten der WF Anwendung: Im Monitor sollen abhängig vom Workflowstatus Bearbeitungsfunktionen der drei beteiligten Komponenten ausgeführt werden können (steuerndes Monitoring). Beispiele für derartige Funktionen: SAP: Transaktion zur Bearbeitung der Stammdaten von Marktteilnehmer (SAP-TA: EEDMIDESERVPROV02) Transaktion zum Customer Interaction Center (SAP-TA: CIC0): Anzeige und Verwaltung technischer und betriebswirtschaftlicher Kundendaten Transaktion zum erneuten Versenden von IDocs bei Eintreten von RFC- Versendefehlern (SAP-TA: BD87) spezifische Reports aufrufen zur Bearbeitung bzw. Statussetzung der IDocs Transconnect: Verschieben der XML-Nachricht aus Fehlerqueue in aktuelle Bearbeitungsqueue Lotus Notes: verschieben in Bearbeitungsordner 60

61 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes 6. Fehlerbehandlung anzeigen: Für die einzelnen Workflowinstanzen soll eine Möglichkeit angeboten werden, Kommentare zur Fehlerbehandlung einzufügen. Optional soll ein Bearbeitungsstatus eingeführt werden, der für die einzelnen Workflowinstanzen anzeigt, welcher Mitarbeiter den nächsten Bearbeitungsschritt durchzuführen hat. Mit den genannten Maßnahmen soll der Kommunikationsaufwand zwischen den verschiedenen Abteilungen verringert werden. 7. Abstraktionsniveaus für Prozess- und Nachrichtensicht: Neben der Überwachung der einzelnen Workflowinstanzen und den damit verbundenen Nachrichten soll eine aggregierte Sicht auf Geschäftsvorgänge einer Prozessinstanz ermöglicht werden (vgl. Transaktion III in Teilabschnitt 3.2.2). 8. Reporting-Funktionalitäten: Der Monitor soll Statistik-Funktionalitäten für das Management des jeweiligen Unternehmens anbieten. Im Funktionsumfang sollen Standardberichte als auch konfigurierbare adhoc-berichte, die sinnvolle Kombinationen der Monitoring- Objekte und deren Attribute ermöglichen, enthalten sein. Das Reporting soll folgende Berichte beinhalten: Anzahl der Vorgänge einer Geschäftsvorgangsart Anzahl der Vorgänge nach Verbrauchsmenge der Kunden (Groß- und Kleinkunden) Abgleich der im SAP erstellten Rechnungen mit den versendeten INVOIC- Nachrichten Gesamtanzahl der fehlerhaften Geschäftsvorgänge Anzahl fehlerhafter Geschäftsvorgänge nach Fehlerkategorie durchschnittliche Bearbeitungsdauer von Fehlern 9. Archivierung der Monitoring-Daten: Eine Workflowinstanz gilt als abgeschlossen, wenn sie erfolgreich beendet wurde oder manuell durch Mitarbieter einen Status erhalten hat, der keine weitere Bearbeitung anzeigt. Nach Ablauf von vier Wochen sollen diese Instanzen automatisch in ein Monitoring-Archiv verschoben werden. Qualitätsanforderungen: Qualitätsanforderungen definieren Merkmale, die von der Anwendung bei der Durchführung der funktionalen Anforderungen erfüllt werden sollen. 1. Sicherheit: Sicherheitsaspekte spielen bezogen auf Monitoring-Tools ebenfalls eine wichtige Rolle und werden im Entwurf meist vernachlässigt oder gar nicht berücksichtigt ([HN+07]). Dies betrifft bei einem Monitor zum einen den Zugriff auf die gesammelten Monitoring-Daten (Vertraulichkeit) als auch die Korrektheit der Monitoring-Daten (Integrität). Aus Datenschutzgründen werden folgende Anforderungen bezüglich der Vertraulichkeit definiert: a) Zugriffskontrolle: Es sollen nur die an den Geschäftsprozessen beteiligten Mitarbeiter mit dem Monitor arbeiten. Aus diesem Grund muss vor Nutzung des Monitors eine Authentifizierung über einen Nutzernamen und einem entsprechendem Passwort erfolgen. 61

62 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes b) 3-stufiges Berechtigungskonzept für die Anwender: Nach Anmeldung am Monitor soll dem Nutzer eine Rolle zugewiesen werden, die ihm die maximal notwendigen Rechte im Monitor in Abhängigkeit der folgenden Stufen zuordnet (least-privilege-prinzip, vgl. [Gro07], S.4). Stufe 1 - Mandantenabhängige Anzeige: Aufgrund der Abwicklung der Geschäftsprozesse mehrerer Energieunternehmen mittels der WF Anwendung müssen die gesammelten Daten mandantenspezifisch getrennt werden. Mitarbeiter dürfen nur Einblick in die Geschäftsprozesse der Unternehmen erhalten, die sie betreuen. Stufe 2 - Netzbetreiber- und Lieferantensicht: Die Unternehmen, die sowohl als Netzbetreiber und als Lieferant auf dem Energiemarkt tätig sind, müssen laut Novellierung des EnWG informatorisch getrennt werden ([EnWG05]). Aus diesem Grund müssen diese beiden Sichten im Monitor berücksichtigt werden. Stufe 3 - Einschränkung der Monitoring-Funktionalität aufgrund des Verantwortungsbereiches und der Aufgaben der Mitarbeiter: In Abhängigkeit der Abteilung stehen dem Mitarbeiter nur bestimmte Funktionalitäten des Monitors zur Verfügung. Folgendes vereinfachtes Berechtigungskonzept kann für die verschiedenen Abteilungen aufgestellt werden: Rollen Fachbereiche Abhängig vom Verantwortungsbereich Anwendungsbetreuung+ Entw/Admin Management Rechte Mandant Mandanten aus Verantwortungsbereich Alle Mandanten Netz/Vertrieb Netz und Vertrieb Mandanten des jeweiligen Netz und Vertrieb Unternehmens Tabelle 2: Vereinfachtes Berechtigungskonzept Monitor- Funktionalität Alle außer techn. Bearbeitungsfkt. und Reporting Alle außer Reporting Nur Reporting Entsprechend Tabelle 2 stehen den Fachbereichen nur betriebswirtschaftliche Bearbeitungsfunktionen zur Verfügung. Diese Funktionen enthalten alle Transaktionen, die zur Stammdatenpflege im Backend genutzt werden. Technische Bearbeitungsfunktionen, wie das Editieren und das Neu-Versenden eines IDocs, bleiben Mitarbeitern der Anwendungsbetreuung und der Entwicklung/Administration vorbehalten. Die Reporting-Funktionalitäten stehen nur dem Management zur Verfügung. Die Überwachung einzelner Instanzen ist nicht relevant für diese Mitarbeitergruppe. Die Integrität der Monitoring-Daten soll bei der Auswahl einer geeigneten Technologie zur Erzeugung der Monitoring-Daten und Sicherheitsmechanismen für die Persistenz der Daten berücksichtigt werden. 2. Performanz: Die Performanz umfasst die Auswirkungen der Instrumentierung auf die WF Anwendung (siehe Instrumentierung in Teilabschnitt 2.3.3) und die Leistung der Monitor-Anwendung: Die Instrumentierung soll die Verzögerung der Workflows gering halten. Des Weiteren soll der Monitor die Workflow-Informationen möglichst in Echtzeit 62

63 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes anzeigen, d.h. Zustandsänderungen bzw. Fehler der aufgestellten Fehlerkategorien sollen möglichst eventgesteuert erkannt werden. Eine gleichzeitige Nutzung durch maximal 20 Mitarbeiter muss gewährleistet sein. 3. Flexibilität: Veränderungen der Geschäftsprozesse und die damit verbundenen Nachrichtenformate sollen im Monitor ohne großen Programmieraufwand berücksichtigt werden können. 4. Skalierbarkeit: Bei steigender Anzahl von Nachrichten, die mit Hilfe der WF Anwendung verarbeitet werden, muss die Verfügbarkeit und die Bedienbarkeit des Monitors gewährleistet sein. Die entsprechend verwendete Soft- und Hardware zur Realisierung des Monitors muss ausreichend dimensioniert werden. 5. Geeignete Benutzeroberfläche: Die verwendete graphische Benutzeroberfläche im Monitor soll leicht verständlich und gut bedienbar sein. Die Darstellung der Ende-zu-Ende-Überwachung von Workflowinstanzen und die verschiedenen Abstraktionsniveaus sind zu realisieren (Prozess- und Nachrichtensicht). Rahmenbedingungen: 1. Technologieauswahl: Für die Erzeugung der Monitoring-Daten soll eine hohe Entkopplung zwischen der WF Anwendung und dem Monitor realisiert werden. Diese Maßnahme ist notwendig, da mittelfristig eine neue Middleware-Komponente, SAP Process Infrastructure (SAP PI), für die Nachrichtentransformation eingesetzt wird. Um eine hohe Wiederverwendbarkeit der Monitoring-Lösung zu gewährleisten, soll die Technologie standardisiert sein und von der neuen Middleware unterstützt werden. 2. Geringer Installationsaufwand für Nutzung des Monitors: Die Maßnahmen zur Einrichtung des Monitors auf den Workstations der jeweiligen Mitarbeiter soll möglichst gering gehalten werden. Die Bereitstellung einer Bedienungsanleitung, die das Starten des Monitors und seine Funktionalitäten beschreibt, ist für den späteren produktiven Einsatz erforderlich. 3. Keine zusätzlichen Beschaffungskosten für fehlende Software: Um die Entwicklungskosten möglichst gering zu halten und die Praxistauglichkeit des Konzeptes zu testen, soll vorerst nur Open-Source-Software für die Umsetzung des Monitors eingesetzt werden Monitoring-Konzept In folgendem Abschnitt wird das Konzept beschrieben, das zur Umsetzung der BAM-Lösung eingesetzt wird. Die aufgestellten Anforderungen sollen weitestgehend berücksichtigt werden. Im Rahmen dieser Arbeit können jedoch nicht alle Anforderungen detailliert behandelt werden. Aus diesem Grund wird insbesondere auf die zwei elementaren funktionalen Anforderungen zentrale Nachrichtenüberwachung und automatischen Fehlererkennung eingegangen. 63

64 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Auf Basis der beschriebenen Workflows und der aufgestellten Fehlerkategorien wurde ein Metamodell erstellt, das die Grundlage für die Nachrichtenüberwachung und die Fehlererkennung liefert. Dieses Metamodell spezifiziert die Events, die zur Erzeugung von Monitoring-Informationen führen. Des Weiteren definiert das Modell die Eventattribute und Bearbeitungsfunktionen, die für die Betreuung der Geschäftsprozesse notwendig sind. Metamodell: Basierend auf dem Datenmodell der Workflows für ein- und ausgehende Nachrichten wird zunächst eine Einteilung in Aktivitäten vorgenommen, die die Abläufe der Nachrichtenverarbeitung beschreiben: Aktivität -Eingang Konvertierungs- Eingang Nachrichten-Eingang DA-Eingang DA-Ausgang Nachrichten-Ausgang Beschreibung -Empfang und Vorverarbeiten der Entkopplung der EDIFACT-Datei bis Modellprüfung Einstellen der datenflussorientierten Nachricht in die Messagequeue der Transconnect-Middleware bis zur Verbuchung des IDocs in SAP Anlegen der DA-Aufgabe bis Verbuchung der DA-Aufgabe Anlegen der DA-Aufgabe bis zur Übertragung des IDocs an die Middleware Erstellung IDoc-XML bis Versenden der EDIFACT-Datei als E- Mail-Attachment CONTRL- und APERAK- Eingang CONTRL- und APERAK- Ausgang Zuordnung der CONTRL/APERAK zu ausgehender Nachricht bis zur Status-Verbuchung im SAP Erstellung der CONTRL/APERAK bis Versenden der CONTRL/APERAK als -Attachment Tabelle 3: Aktivitäten des Metamodells Die beschriebenen Aktivitäten der Workflows stehen in Beziehung zueinander, die in Abbildung 19 dargestellt sind: 64

65 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes 1 Workflow (eingehend) löst aus Workflow (ausgehend) beeinflusst Zustand bestehender Aktivität XOR-Verknüpfung AND-Verknüpfung Hinweis: Die angegebenen Ziffern identifizieren die Aktivitätsübergänge. Abbildung 19: Abhängigkeiten der Metamodell-Aktivitäten Mit Hilfe dieser Einteilung ist die Beschreibung aller Workflowinstanzen der Anwendung möglich. Die Anzahl und Art der Aktivitäten pro Instanz ist von der Anzahl der Datenobjekte (siehe Datenmodell in Teilabschnitt 3.1.3) bzw. der auftretenden Fehler (siehe Fehlerkategorien in Teilabschnitt 3.2.3) abhängig. Die Workflowinstanz einer eingehenden Nachricht beginnt mit der Aktivität -Eingang und löst im Normalfall einen Konvertierungseingang, einen CONTRL-Ausgang für die positive CONTRL-Nachricht, einen oder mehrere Nachrichten-Eingänge aus, die wiederum eine oder mehrere Aktivitäten des Typs DA- Eingang initiieren. Tritt bereits ein Fehler beim -Eingang auf, wird nur diese Aktivität angelegt. Eine ausgehende Workflowinstanz beginnt mit einer oder mehreren Aktivität(en) des DA-Ausgangs. Im fehlerfreien Fall wird die Aktivität Nachrichten-Ausgang 65

66 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes ausgelöst und die Nachricht erfolgreich versendet. Kontrollflussorientierte Nachrichten werden als Antwort empfangen und beeinflussen den Zustand der erstellten Aktivität des Nachrichten-Ausgangs. Anhand der Aktivitäten ist es bereits möglich, den groben Verlauf der Nachrichtenverarbeitung sowie die Anzahl der an einer Workflowinstanz beteiligten Datenobjekte nachzuvollziehen. Für die konkrete Fehlersuche und Fehlerbehandlung ist diese Einteilung nicht ausreichend. Besonders für die Fehlererkennung müssen die Abläufe der Workflows präzisiert werden. Aus diesem Grund werden den Aktivitäten Zustände und Zustandsübergangsgraphen zugeordnet, die die Verarbeitungsschritte der Nachrichten innerhalb der Aktivitäten detaillierter beschreiben und somit die Granularität der Monitoring-Daten erhöhen. Unmittelbar nach Eintreten dieser Zustände in der WF Anwendung sollen diese eventgesteuert an den Monitor übertragen werden (Erzeugung). Im Monitor kann der Verlauf der Workflowinstanzen anhand der übertragenen Zustände überwacht werden. Bestimmte Fehlerfälle werden bereits durch die eventgesteuerte Zustandsübergabe erkannt. Alle weiteren Fehler, besonders die Kategorie der sonstigen Fehler, sollen durch zyklische Kontrolle der Zeitstempel der Zustände erkannt werden. Anhand der aktuellen Zustandswartezeit und einer im Vorfeld definierten Maximalwartezeit können diese Fehler als Timeouts angezeigt werden. Die Überprüfung soll nicht unter Nutzung zeitgesteuerter Request/Response- Anfragen an die WF Anwendung durchgeführt werden, sondern innerhalb der Verarbeitungsschicht des Monitors durch eine zyklische Überwachung der gesammelten Monitoring-Daten. Die Vorteile dieser Maßnahme sind: keine zusätzliche Instrumentierung der WF Anwendung (Performanz) höhere Entkopplung zwischen Monitor und WF Anwendung zusätzlicher Implementierungsaufwand für Request/Response-Anfragen der drei Komponenten entfällt Die Festlegung der Maximalwartezeiten für die Zustandsübergänge muss unter Berücksichtigung der durchschnittlichen Bearbeitungszeiten im Workflow geschehen. Zwischen der durchschnittlichen Bearbeitungsdauer und der Wartezeit sollte ein entsprechendes Sicherheitsintervall definiert werden, um die Streuung der korrekten Zustandsübergangszeiten und die maximal zulässige Verzögerungszeit zur Fehlerbehandlung zu berücksichtigen. Die Ziele dieser Vorgehensweise sind einerseits die Anzahl falsch erkannter Timeout-Fehler 5 auf ein Minimum zu beschränken und andererseits die Reaktionszeit der Fehlererkennung zu minimieren. Des Weiteren muss das Zeitintervall der zyklischen Überwachung aller Maximalwartezeiten der Zustandsübergänge bei dem Entwurf des Monitors berücksichtigt werden. Im Worst-Case-Szenario wäre die maximale Verzögerung der Anzeige eines Timeout-Fehlers im Monitor gleich der Summe aus Maximalwartezeit und dem Zeitintervall der zyklischen Abfrage. Im Folgenden werden die Zustandsübergangsgraphen der einzelnen Aktivitäten dargestellt und beschrieben. Es werden die Attribute definiert, die pro Aktivität 5 Falsch erkannte Timeout-Fehler betreffen Workflowinstanzen, die nach Überschreiten der Maximalwartezeit in der WF Anwendung korrekt weiterverarbeitet werden. Im Monitor werden diese Instanzen zunächst als Timeout-Fehler angezeigt. Nach dem Auslösen des Monitoring-Events, das die Fortsetzung der Verarbeitung in der WF Anwendung signalisiert, wird die Workflowinstanz im Monitor fehlerfrei angezeigt. 66

67 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes im Monitor angezeigt und zur Verarbeitung im Monitor benötigt werden. Zusätzlich werden die Datenobjekte und Bearbeitungsfunktionen angegeben, auf die ein Zugriff im Monitor für die Mitarbeitergruppen sinnvoll ist. Die Legende der Zustandsübergangsgraphen ist im Anhang unter abgebildet. Workflow eingehender Nachrichten: -Eingang: Attribute: Notes-ID (interner Primärschlüssel der ), Sender- und Empfänger- Adresse, Postkorb, Postkorb-Ordner, -Betreff, Zeitstempel der Zustände Datenobjekte: mit Attachment(s) Bearbeitungsfunktionen: Timeout ( verschieben): - Agent PutInFolder manuell aus führen 1 aussortiert: - editieren und in Bearbei tungsordner verschieben - archivieren/löschen Abbildung 20: Zustandsübergangsgraph ( -Eingang) Die Aktivität des -Eingangs in Abbildung 20 wird durch zwei positive Workflow-Zustände beschrieben, die den Empfang der und das Verschieben in den Bearbeitungsordner darstellen. Nachdem die in der Inbox von Lotus Notes vorliegt, wird diese durch den Mailagent PutInFolder verschoben. Der Agent ist in Java programmiert und wird zyklisch im Abstand von 15 Minuten gestartet. Bei Ausfall des Agenten wird ein Timeout-Fehler im Monitor angezeigt. Aufgrund des Agentenzykluses soll die Maximalwartezeit des Zustandes empfangen 20 Minuten betragen. Falls der Agent wieder zur Verfügung steht und die später verarbeitet wird, kann die Aktivität vom Timeout-Fehler in die Folgezustände übergehen. Nach Ausführung des Mailagenten erhält die Aktivität entweder den Fehlerzustand aussortiert oder den regulären Zustand in Bearbeitungsordner. Im Fehlerfall ist der Workflow vorerst beendet und ein Mitarbeiter muss die analysieren. Liegt die im Bearbeitungsordner, wird diese durch die zeitgesteuerte Aufgabe in die Middleware importiert. Die Aufgabe EDI-Import ist die Instanz einer Java-Klasse, die von der Scheduler- Basisklasse der Transconnect-Middleware abgeleitet wird ([TCHb], S.139), und im zeitlichen Abstand von 10 Minuten alle im Bearbeitungsordner vorliegenden s abholt. Die vollständige Bearbeitung der abgeholten s dauert abhängig von der Anzahl und Größe der s höchstens eine Minute 6. Die Maximalwartezeit für den Timeout des -Imports wird aus diesem Grund auf 15 Minuten festgelegt. Die EDI-Import-Aufgabe führt die Entkopplung der Mail- Attachments und die Syntax- und Modellprüfung durch (siehe Konvertierungseingang in Abbildung 21). 6 Dieser Wert basiert auf der Befragung des Transconnect-Administrators der ENSO 67

68 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Konvertierungseingang: 1 Attribute: Notes-ID (Fremdschlüssel zur E- Mail), EDIFACT-Nachrichtentyp, UNB-Referenz, BGM-Segment, ILN-Nummer von Sender und Empfänger, Zeitstempel der Zustände, Fehlergrund (Syntaxund Modellfehler) Datenobjekte: mit Attachment(s) 2 Abbildung 21: Zustandsübergangsgraph (Konvertierungseingang) Für jedes Attachment der eingegangenen wird eine Aktivität Konvertierungseingang im Monitor erzeugt (Abbildung 21). In Abhängigkeit der Ausführung der zeitgesteuerten Aufgabe EDI-Import werden verschiedene Zustände erreicht und verschiedene Folgeaktivitäten initiiert (siehe Abhängigkeiten der Aktivitäten in Abbildung 19). Zu Beginn des EDI-Imports werden Entkopplungsfehler durch Exceptionhandling abgefangen. In diesem Handling müssen die Monitoring-Daten zum jeweiligen Fehler erzeugt werden. Der Fehler und die Ursache sind eventgesteuert an den Monitor zu übergeben, der den Fehler anzeigt. Der Workflow ist vorerst beendet und die weitere Bearbeitung erfolgt durch die Mitarbeitergruppen. Liegt eine EDI-Datei vor und ist syntaktisch fehlerhaft, nimmt die Aktivität den Zustand Syntaxfehler ein und initiiert die Aktivität CONTRL-Ausgang. Ist die EDI-Datei syntaktisch korrekt, aber die Modellprüfung schlägt fehl, erreicht die Aktivität den Zustand Modellprüfung fehlerhaft und es werden die Folgeaktivitäten CONTRL-Ausgang (Bestätigungsnachricht) und APERAK-Ausgang (Fehlernachricht) angestoßen. Bei bestandener Syntax- und Modellprüfung hängen die Folgeaktivitäten von der Art der in der EDI-Datei enthalten Nachrichten ab. Handelt es sich um eine kontrollflussorientierte Nachricht, wird eine Aktivität des CONTRL- oder APERAK-Eingangs erzeugt. Im Fall einer oder mehrerer datenflussorientierter Nachrichten (abhängig von der Anzahl der UNH-UNT-Segmente) wird eine Aktivität CONTRL-Ausgang als positive Empfangsbestätigung und für jede enthaltene Nachricht eine Aktivität Nachrichten-Eingang initiiert. 68

69 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Über Timeoutzustände wird geprüft, ob die genannten Folgeaktivitäten gestartet werden. Ist das nicht der Fall, zeigt der Monitor den Fehler in der Aktivität des Konvertierungseingangs an. Alle Zustände des Konvertierungseingangs werden durch die Import-Aufgabe an den Monitor übertragen. Aufgrund der o.g. maximalen Bearbeitungszeit der Aufgabe kann die Maximalwartezeit der Timeouts auf 1 Minute gesetzt werden. Nachrichten-Eingang: 3 Attribute: Transconnect-ID (interner Primärschlüssel der XML-Nachricht), Notes-ID (Fremdschlüssel zu Konvertierungseingang), UNH- Referenz, IDoc-Nummer, SAP- System, SAP-Mandant, Zeitstempel der Zustände Datenobjekte: EDIFACT-XML Bearbeitungsfunktionen: Timeout (IDoc-Mapping): - Verschieben der XML-Nachricht aus Fehlerqueue in aktuelle Verarbeitungsqueue Mind. 1 DA fehlerhaft angelegt (Status 51): - Transaktion zur Bearbeitung der Stammdaten von Marktteilneh mern (SAP-TA:EEDMIDESERVPROV02) - Report zum IDoc neu einspielen 4 5 Abbildung 22: Zustandsübergangsgraph (Nachrichten-Eingang) Wie in Abbildung 22 dargestellt, beginnt der Nachrichten-Eingang mit dem Einstellen der datenflussorientierten Nachricht in die Verarbeitungsqueue der Middleware. Der Folgezustand signalisiert die Übergabe der Nachricht an den SAP-Adapter, der die Übertragung an das SAP-System durchführt. Der Timeout (IDoc-Mapping) dient der Überwachung von Übertragungsfehlern, beispielsweise Fehler im Adapter. Die Maximalwartezeit für diesen Timeout hängt von dem Datenvolumen der Transconnect-Middleware ab. Die XML-Nachrichten werden in die Verarbeitungsqueue eingestellt und sequentiell verarbeitet. Werden besonders viele Nachrichten zu einem Zeitpunkt bearbeitet, erhöht sich die Zustandsübergangszeit. Für die Definition der Maximalwartezeit ist eine genauere Untersuchung des Datenvolumens und der davon abhängigen, durchschnittlichen 69

70 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Bearbeitungsdauer des Workflows notwendig. Das Datenvolumen hängt zusätzlich von Prozessfristen ab, die zu einem erhöhten Nachrichtenverkehr an bestimmten Tagen im Monat führen. Eine dynamische Anpassung des Timeouts in Abhängigkeit dieser Fristen wäre eine geeignete Lösung. Im Rahmen dieser Arbeit wird nach Empfehlung von Mitarbeitern der Administration und der Anwendungsbetreuung der Timeout vorerst statisch auf 60 Minuten festgelegt. Unmittelbar nach Versenden der IDoc-Daten durch den SAP-Adapter wird das IDoc im SAP-System durch Ausführung eines Funktionsbausteins erstellt und erhält den internen SAP-Status 50. Der FuBa prüft die Geschäftsvorgangsart des IDocs und anschließend werden die enthaltenen DA-Aufgaben angelegt. Die Maximalwartezeiten der restlichen Timeouts werden auf 5 Minuten gesetzt. Jede DA-Aufgabe führt zur Erstellung einer Aktivität DA-Eingang. Werden alle angelegten Aktivitäten des DA-Eingangs eines IDocs erfolgreich beendet, erhält das IDoc den internen SAP-Status 53 und der Workflow ist erfolgreich beendet. Werden ein oder mehrere DA-Aufgaben nicht erfolgreich angelegt (siehe DA- Eingang), erhält das IDoc den internen Fehlerstatus 51. Das Ergebnis jeder Aktivität vom Typ DA-Eingang beeinflusst somit die Statusfortschreibung des zugehörigen Nachrichten-Eingangs. DA-Eingang: 4 5 Attribute: DA-ID (interner Primärschlüssel der DA), DA-Prozess, IDoc- Nummer (Fremdschlüssel zu Nachrichten-Eingang), Wechselbelegnummer (prozessübergreifender Schlüssel), Kundenname, Kundennummer, Zählpunkt, Status des Geschäftsvorgangs, Zeitstempel der Zustände Abbildung 23: Zustandsübergangsgraph (DA-Eingang) Während der IDoc-Verarbeitung werden die verschiedenen DA-Aufgaben angelegt und verbucht. Nach Anlegen der DA werden die relevanten Daten zu dem Geschäftsvorgang an den Monitor übertragen (Kundenname, Status des Geschäftsvorgangs etc.). Diese Daten unterstützen die Fachbereiche bei der Suche nach konkreten Vorgängen und bilden die Basis für zu entwickelnde Reportingfunktionalitäten. Wie aus Abbildung 23 hervorgeht, werden die Fehler der Kategorie DA-Aufgabe-Verbuchungsfehler zeitgesteuert erkannt, falls die Verbuchung nicht initialisiert wird, oder eventgesteuert, wenn die DA-Aufgabe aus den genannten Gründen nicht verbucht werden kann. In Abhängigkeit der Verbuchung wird der Status der aufrufenden Aktivität Nachrichteneingang verändert. Wenn die DA-Aufgabe ordnungsgemäß einem Wechselbeleg zugeordnet werden kann, so wird die Wechselbelegnummer an den Monitor übertragen. Dieses 70 Bearbeitungsfunktionen: Vorgang nicht verbucht: - Transaktion zum Customer Interaction Center (SAP-TA: CIC0) - Transaktion zur Bearbeitung der Stammdaten von Marktteilneh mern (SAP-TA: EEDMIDE SERVPROV02)

71 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Attribut dient als Schlüssel für die prozessübergreifende Darstellung der an einem Wechselprozess beteiligten Nachrichten. CONTRL- und APERAK-Ausgang: Attribute: Notes-ID der eingehenden (Fremdschlüssel zu Konvertierungseingang), Zeitstempel der Zustände Datenobjekte: CONTRL- mit Attachment Attribute: Notes-ID der eingehenden (Fremdschlüssel zu Konvertierungseingang), Zeitstempel der Zustände Datenobjekte: APERAK- mit Attachment Abbildung 24: Zustandsübergangsgraphen (CONTRL- und APERAK-Ausgang) Die Zustandsübergangsgraphen des CONTRL- und APERAK-Ausgangs sind in Abbildung 24 dargestellt. Beide Aktivitäten werden durch die Aufgabe des EDI- Imports ausgelöst. Eine wird im Postausgang des Marktpartners in Lotus Notes angelegt. Anschließend wird diese durch den Java-basierten Agenten Mailversand, der zyklisch im Abstand von 15 Minuten ausgeführt wird, versendet. Treten Fehler der Kategorie -Versendefehler auf, werden diese durch einen Timeout, der auf 20 Minuten eingestellt wird, erkannt. Als Attribut wird die Notes-ID der eingehenden genutzt, auf die sich die CONTRL- oder APERAK-Nachricht bezieht. Diese ID stellt somit die Referenz zur Aktivität des Konvertierungseingangs her. 71

72 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes CONTRL- und APERAK-Eingang: Attribute: Transconnect-ID (interner Primärschlüssel der XML-Nachricht), UCI-Segment (enthält UNB-Referenz der versendeten Nachricht und Antwortstatus), Zeitstempel der Zustände Attribute: Transconnect-ID (interner Primärschlüssel der XML-Nachricht), UCI-Segment (enthält UNB-Referenz der versendeten Nachricht und Antwortstatus), Zeitstempel der Zustände Datenobjekte: EDIFACT-XML Datenobjekte: EDIFACT-XML Abbildung 25: Zustandsübergangsgraphen (CONTRL- und APERAK-Eingang) Die in Abbildung 25 dargestellten Aktivitäten des CONTRL- und APERAK-Eingangs werden durch zwei positive Workflow-Zustände und einen negativen Zustand für die potentiellen Fehler beschrieben. Initialisiert wird die jeweilige Aktivität durch die Aufgabe des EDI-Imports, die eine XML-Nachricht in der Messagequeue der Middleware erstellt (siehe Konvertierungseingang). Anschließend werden die Informationen der Nachricht per synchronem RFC-Aufruf an das SAP-System übergeben und dem ausgehenden IDoc zugeordnet bzw. ein Status gesetzt. Treten während der Verarbeitung der XML-Nachricht Fehler auf, so werden diese durch einen Timeout an den Monitor gemeldet. Die Maximalwartezeit dieses Timeouts ist abhängig von der in der Messagequeue zu verarbeitenden Anzahl der Nachrichten und dem damit verbunden Datenvolumen. Wie bereits erwähnt wird für diesen Fall die Maximalwartezeit vorerst auf 60 Minuten eingestellt. Nach erfolgreicher Zuordnung im SAP-System wird in Abhängigkeit des Nachrichteninhalts der Zustand der zugehörigen Aktivität des Nachrichtenausgangs fortgeschrieben. CONTRL- und APERAK-Eingang unterscheiden sich lediglich in ihren an den Monitor zu übertragenden Attributen. Während beim CONTRL-Eingang nur die Information übertragen wird, ob Syntaxfehler in der versendeten Nachricht enthalten sind, werden beim APERAK-Eingang zusätzliche in der APERAK-Nachricht enthaltene Informationen zur Fehlerursache an den Monitor übermittelt. Die Zuordnung zu den versendeten Nachrichten erfolgt in beiden Aktivitäten über die UNB-Referenznummer. 72

73 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Workflow ausgehender Nachrichten DA-Ausgang: Attribute: DA-ID (interner Primärschlüssel der DA), DA-Prozess, Empfänger, IDoc-Nummer/aggregierte IDoc- Nummer+System+Mandant (Fremdschlüssel zu Nachrichten- Ausgang), Wechselbelegnummer (prozessübergreifender Schlüssel), Kundenname, Kundennummer, Zählpunkt, Status des Geschäftsvorgangs (Felder Kategorie und Transaktionsgrund des STS-Segments), Zeitstempel der Zustände 14 Bearbeitungsfunktionen: DA fehlerhaft angelegt: - Transaktion zur Workflow-Inbox (SAP-TA: CIC0) Timeout (IDoc-Übertragung): - Transaktion zum Neuversenden des IDocs (SAP-TA: BD87) Abbildung 26: Zustandsübergangsgraph (DA-Ausgang) Die Aktivität des in Abbildung 26 dargestellten DA-Ausgangs beginnt mit der Erstellung einer DA-Aufgabe durch eine vorgangsspezifische Verbuchung (Beispiel: Anlegen einer Kündigung). Im fehlerfreien Fall wird die DA-Aufgabe mit dem Status OK angelegt und ein zugehöriges IDoc erzeugt. Tritt ein Fehler beim Generieren des IDocs auf, so wird die DA-Aufgabe mit dem Status ERROR angelegt und kein IDoc erzeugt. Die beiden Zustände und die damit verbundenen Informationen zu dem jeweiligen Geschäftsvorgang werden eventgesteuert vom Monitor empfangen und angezeigt. Das erstellte IDoc wird ggf. mit anderen IDocs, die Daten zu der gleichen Geschäftsvorgangsart enthalten, zu einem aggregierten IDoc zusammengefasst 7. Diese Aggregation ist abhängig von den im System hinterlegten Parametern der Agreements zu dem jeweiligen Marktpartner, mit dem kommuniziert wird ([SAP05], S.202). Das erstellte Einzel-IDoc oder das aggregierte IDoc wird anschließend an die Middleware versendet. Nach erfolgreicher Transformation des IDocs durch den SAP-Adapter wird die IDoc- XML-Datei in die Messagequeue der Middleware gestellt und im Monitor die Aktivität Nachrichten-Ausgang initiiert. Die Verbindung zwischen den Aktivitäten des DA-Ausgangs und des Nachrichten-Ausgangs kann über die Nummer des versendeten IDocs, das zugehörige SAP-System und die Mandantennummer hergestellt werden. Fehler während der Übertragung, beispielsweise die Fehler der Kategorie RFC-Versendefehler werden mit Hilfe des Zustandes Timeout (IDoc- Übertragung) erkannt. Die Maximalwartezeit für diesen Timeout ist abhängig von dem Datenvolumen der Middleware und wird auf 60 Minuten festgelegt (vgl. Timeout für IDoc-Mapping in Aktivität des Nachrichten-Eingangs). 7 Wie bereits in erwähnt, ist die Aggregation von IDocs noch nicht implementiert, aber in Planung. Das Metamodell soll diesen Fall berücksichtigen, um die spätere Anpassung des Monitors zu erleichtern. 73

74 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Nachrichten-Ausgang: 14 Attribute: IDoc-Nummer (Primärschlüssel und Fremdschlüssel zu DA- Ausgang), EDIFACT- Nachrichtentyp, UNB- und UNH- Referenz (Fremdschlüssel zu CONTRL- und APERAK-Eingang), ILN-Nummer von Sender und Empfänger, Zeitstempel der Zustände Datenobjekte: EDIFACT-XML, mit Attachment Bearbeitungsfunktionen: Syntaxfehler: - Verschieben der IDoc-XML- Nachricht aus Fehlerqueue in aktuelle Verarbeitungsqueue Abbildung 27: Zustandsübergangsgraph (Nachrichten-Ausgang) Die Aktivität des Nachrichten-Ausgangs beginnt mit der Verarbeitung der IDoc- XML-Nachricht (siehe Abbildung 27). Schlägt die anschließende Konvertierung fehl, weil ein Syntaxfehler entdeckt wurde, zeigt der Monitor diesen eventgesteuert an. Nach erfolgreicher Durchführung der Konvertierung wird die zugehörige angelegt und in den Postkorb von Lotus Notes verschoben. Die Konvertierung und das Erstellen der erfolgt sequentiell und unmittelbar nach dem der Zustand IDoc-XML-Verarbeitung gestartet an den Monitor übertragen wurde. Aus diesem Grund wird die Maximalwartezeit der zugehörigen Timeouts auf 5 Minuten festgelegt. Das Versenden der erfolgt zeitgesteuert im Abstand von 15 Minuten durch den bereits erwähnten Mailversand-Agenten. Als Timeout für potentielle Fehler zwischen Erstellen und Versenden der wird daher ein Wert von 20 Minuten vorgeschlagen. Nach dem Versenden der wird auf die CONTRL-Antwortnachricht des Marktpartners, die laut BDEW bis zum nächsten Werktag 12:00 Uhr eingehen muss, gewartet ([BDW08_6], S.10). Wird bis zu diesem Zeitpunkt keine Antwortnachricht empfangen, löst der Monitor durch einen dynamischen Timeout den Zustand 74

75 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Keine CONTRL empfangen aus. Bei Empfang einer CONTRL-Nachricht wird die Aktivität CONTRL-Eingang im Monitor erzeugt. Kann diese CONTRL-Nachricht im SAP-System erfolgreich verbucht werden, wird in Abhängigkeit des Inhalts dieser Nachricht der Folgezustand des zugehörigen Nachrichtenausgangs erreicht. Handelt es sich um eine negative CONTRL-Nachricht wird der Fehler eventgesteuert im Monitor angezeigt. Im Fall der positiven CONTRL-Nachricht wird die Antwortfrist für eine mögliche APERAK-Nachricht, die laut BDEW bis 12:00 Uhr zum übernächsten Werktag eingegangen sein muss, durch den Monitor überprüft. Bei Erreichen der Frist und keiner eingegangenen APERAK wird der erfolgreiche Workflow-Endzustand erreicht. Bei Empfang einer APERAK- Nachricht, wird die Aktivität APERAK-Eingang im Monitor initialisiert. Nach erfolgreicher Zuordnung im SAP-System kann der Fehler eventgesteuert in der Aktivität des Nachrichten-Ausgangs angezeigt werden. Nachdem die Aktivitäten des Metamodells näher vorgestellt wurden, muss vor der Umsetzung des Modells in einer BAM-Lösung die Infrastruktur der drei Schichten Erzeugung, Verarbeitung und Darstellung geplant werden (siehe Phase 4 des BAM-Vorgehensmodells): Erzeugung der Monitoring-Daten: Die Erzeugung der Monitoring-Daten umfasst das Erfassen der genannten Aktivitäten bzw. der damit verbundenen Zustände und die Übertragung der definierten Attribute an geeigneten Punkten im Workflow. Aufgrund des geringen Realisierungsaufwandes und den anwendungsbezogenen Abstraktionsniveaus sollen Software-Sensoren für die Instrumentierung der drei Komponenten der WF Anwendung eingesetzt werden. Folgende Punkte im Workflow konnten für die Instrumentierung ermittelt werden: 1. Lotus Notes: Quellcode der Java-basierten Mail-Agenten PutInFolder und Mailversand 2. Transconnect Middleware: Quellcode der Java-basierten zeitgesteuerten Aufgaben Einrichten zusätzlicher Routingregeln, die Informationen zur Verarbeitung der XML-Nachrichten in der Messagequeue an den Monitor übertragen können 3. SAP: ABAP-Quellcode der Funktionsbausteine, die die IDoc-, DA- und Wechselbeleg-Verarbeitung für ein- und ausgehende Nachrichten durchführen Ereignistypkopplungen basierend auf Event-Action-Condition-Mapping Die Instrumentierung der Mail-Agenten, zeitgesteuerten Aufgaben und Routingregeln wird bereits in einem existierenden Monitor-Prototyp bei der ENSO eingesetzt. Der Prototyp und die verschiedenen Instrumentierungspunkte werden in Kapitel 4 näher erläutert. Als Technologie für die Übertragung der Monitor-Informationen werden Web Services empfohlen. Verschiedene Web Services, die die Aktivitäten und Zustände in eine Monitor-Datenbank schreiben, müssen im Vorfeld definiert und 75

76 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes implementiert werden. An den verschiedenen Monitorpunkten im Workflow werden diese Web Services aufgerufen und die zu übertragenden Attribute als Parameter mitgegeben. Folgende Gründe sprechen für den Einsatz von Web Services: einfache Implementierung und Einbindung in die Java-basierten Mail- Agenten und zeitgesteuerten Aufgaben vorhandene Unterstützung von Web Services in der SAP- und Transconnect-Anwendung Wiederverwendung der Web Services in zukünftig eingesetzter Middleware SAP PI ([NF+06], S.179) bisherige Verwendung in existierendem Prototyp standardisierte, weit verbreitete Technologie mit Open Source Tool- Unterstützung für Entwurf und Ausführung Die bereits erwähnten Nachteile von Web Services sind der XML-Overhead und die Performance-Verluste durch das XML-Parsing. Diese Nachteile müssen in Abhängigkeit der Anzahl der zu überwachenden Workflowinstanzen beim Entwurf des Monitors berücksichtigt werden. Ein weiterer Punkt ist die Integrität der Monitoring-Daten, die anwendungsunabhängig durch Transport Layer Security, einer Weiterentwicklung des Netzwerkprotokolls Secure Socket Layer, oder durch Mechanismen des standardisierten WS-Security-Frameworks erreicht werden kann ([Ham05], S.119f.; [Bra08_2] und [Bra08_3]). Die Nutzung des Monitoring-Tools ist nur für das Firmen-Intranet vorgesehen, womit Angriffe von außen durch bereits vorhandene Sicherheitskonzepte, wie die Internet-Firewall, abgedeckt werden. Verarbeitung und Präsentation der Monitoring-Daten: Die Verarbeitung der Monitor-Daten umfasst das Anlegen der Aktivitäten und Zustände in einer Monitor-Datenbank, basierend auf dem beschriebenen Metamodell. Jede Workflow-Instanz wird in Abhängigkeit der erzeugten Informationen abgebildet und in geeigneter Form den verschiedenen Mitarbeitergruppen angezeigt. Aufgrund der Beteiligung von drei verschiedenen Komponenten an den Workflows und der Forderung nach geringer Beeinflussung der vorhandenen Systeme sowie einer hohen Entkopplung wird eine zentrale und unabhängige Komponente für die Verarbeitung der Monitor-Informationen empfohlen. Es sollen die Vorteile eines Hybrid-Monitors genutzt werden (siehe Teilabschnitt 2.3.3). Der Erzeugung der Monitor-Daten erfolgt im Zielsystem durch Software-Sensoren (Web Service-Aufrufe) und die anschließende Weiterverarbeitung auf Basis separater Hardware-Ressourcen. Der Monitor ist somit unabhängig von den Komponenten der WF-Anwendung und die verwendete Monitor-Hardware kann bei Bedarf problemlos erweitert werden (Skalierbarkeit). 76

77 3 Prozessanalyse und Entwurf eines Monitoring-Konzeptes Aufgrund der aufgestellten Anforderungen ist der Einsatz einer Webanwendung in Form der klassischen 3-Tier-Architektur für die Umsetzung des Monitors vorteilhaft (Abbildung siehe Anhang 6.2.4). Die Datenhaltung erfolgt separat durch einen Datenbankserver (Data-Tier). Die Anwendungslogik, Seitengestaltung und Seitenerzeugung werden durch einen Webserver realisiert (Middle-Tier). Die Anwender greifen mit Hilfe eines Browsers und der URL des Webservers auf die Anwendung zu (Client-Tier). Folgende Argumente sprechen für diese Form des Monitors: kein Installationsaufwand auf Client-Seite durch Verwendung des Browsers zentrale Nutzerverwaltung zur Realisierung der Zugriffskontrolle und des Berechtigungskonzeptes auf Basis des Web-Servers GUI kann individuell durch HTML erstellt werden zentrale Verwaltung der Anwendungslogik (Beispiel: Änderungen im Metamodell) Die Voraussetzung für die Nutzung einer Webanwendung ist eine ständige und ausreichend dimensionierte Verbindung zum Webserver. Aufgrund der Nutzung des Monitors innerhalb des Firmen-Intranets ist diese Voraussetzung erfüllt. Ein oftmals negativer Aspekt von Webanwendungen ist die unterschiedliche Interpretation und Darstellung in verschiedenen Browsern oder Browserversionen. Die Programme der Workstations der ENSO-Mitarbeiter werden zentral administriert. Aus diesem Grund ist die Implementierung der Web-Anwendung auf Basis des verwendeten Standard-Browsers ausreichend. Zusammenfassung: Im zurückliegenden Abschnitt wurden die funktionalen Anforderungen, Qualitätsanforderungen und Rahmenbedingungen, die beim Entwurf des Monitoring- Konzeptes zu berücksichtigen sind, zusammengetragen. Anschließend folgte die Entwicklung des Konzeptes, das ein Metamodell zur Beschreibung der Workflows beinhaltet. Dieses Modell besteht aus Aktivitäten, die im Weiteren durch Zustandsübergangsgraphen dargestellt und beschrieben wurden. Mit Durchführung der Infrastrukturplanung, der Phase 4 des BAM-Vorgehensmodells, schließt das Kapitel 3 ab. 77

78 4 Prototypische Umsetzung 4 Prototypische Umsetzung Das folgende Kapitel beschreibt die prototypische Umsetzung des erstellten Monitoring-Konzeptes (siehe Phase 5 des BAM-Vorgehensmodells). Im Abschnitt 4.1 wird ein vorhandener Prototyp in der ENSO vorgestellt, der das aufgestellte Monitoring-Konzept bereits teilweise berücksichtigt. Der zweite Abschnitt behandelt die in dieser Arbeit durchgeführte Erweiterung des Prototyps und endet mit der Durchführung von Testszenarien. 4.1 Vorhandener Prototyp in der ENSO Im Vorfeld dieser Arbeit entwickelten die Administratoren der Middleware ein Tool, das den Nachrichtenaustausch über die Middleware und die - Anwendung überwacht. Dieses Tool wurde zunächst als Prototyp auf einer Testlandschaft implementiert und sollte als Hilfsmittel zur Fehlererkennung in den genannten Komponenten eingesetzt werden. Hauptzielgruppe des Tools waren die Administratoren selbst. Mit der Erkenntnis, dass eine allumfassende Lösung benötigt wird, die den gesamten Nachrichtenaustausch auch auf fachlicher Ebene überwacht, wurde der Prototyp um eine Teilmenge der Aktivitäten des Metamodells erweitert. Bei einer durchgeführten Untersuchung des bestehenden Prototyps wurden die Funktionalitäten verglichen, die entsprechend der aufgestellten Anforderungen erfüllt werden sollen und welche bereits im entwickelten Tool realisiert sind. Daraufhin wurde in Abstimmung mit der Anwendungsbetreuung und des Fachbereichs die Entscheidung getroffen, den Prototyp weiter zu entwickeln und die fehlenden Funktionalitäten zu ergänzen. Das Hauptargument für diese Entscheidung ist die Tatsache, dass der Prototyp bereits wichtige Aspekte des aufgestellten Monitoring-Konzeptes erfüllt und diese wieder verwendet werden können. Inhalt dieses Abschnitts ist die Beschreibung der Architektur und Funktionsweise des Prototyps und die Aufstellung der fehlenden Funktionalitäten. Abschließend wird die Priorität der zu ergänzenden Funktionalitäten analysiert und festgelegt, welches Feature im Rahmen dieser Arbeit realisiert werden soll Architektur und Funktionsweise des Prototyps Der Monitor-Prototyp ist eine Webanwendung, die auf Basis der Java Plattform, Enterprise Edition (Java EE) in der Version 5 implementiert ist. Die Anwendung besteht aus drei Tiers: Client, Web-Server und Datenbank-Server. Die Verteilung der Präsentations-, Anwendungs- und Datenhaltungslogik erfolgt entsprechend der Beschreibung im Monitoring-Konzept. Der Web-Server und der Datenbank- Server sind als Anwendungskomponenten auf einem separaten Rechnerknoten installiert und verfügen somit über eigene Hardwareressourcen. Die gesamte Server-Anwendung basiert auf dem Architekturmuster Model-View-Controller. Die drei Bestandteile erfüllen die folgenden Funktionen: Model: Das Modell enthält die Geschäftslogik und repräsentiert den aktuellen Zustand des Systems. Der Modellzustand wird durch Objektmethoden verändert. View: Der View stellt den Modellzustand dar und dient als Schnittstelle zum Benutzer. 78

79 4 Prototypische Umsetzung Controller: Der Controller realisiert die Steuerung der Interaktionen des Benutzers mit den Views und dem Model. Diese Strukturierung erleichtert die Änder- und Erweiterbarkeit der Anwendung und ermöglicht die Wiederverwendbarkeit der einzelnen Komponenten ([Ma- Ra06], S.19f.). In Abbildung 28 ist die Architektur des Prototyps dargestellt. Webserver (Tomcat) Lotus Notes SOAP over HTTP SOAP-Engine (Axis2) View+ Controller (Struts2) HTTP Client (Browser) Trans- Connect Dependency Injection (Spring) Data Access Objects SAP IS-U OR-Mapping (Hibernate) DB-Server (PostgreSQL) Beschreibung der Komponenten: Abbildung 28: Architektur des Prototyps Tomcat: Der Apache Tomcat stellt die Laufzeitumgebung zur Ausführung des Java-Codes bereit. In seinem Servlet-Container werden die Axis-Engine, die Controller-Servlets, die die HTTP-Requests der Clients verarbeiten, und die View- Servlets, die aus Java Server Pages generiert werden, ausgeführt. Der Prototyp verwendet einen Tomcat-Server in der Version 5.0. ([Tomc]) Axis2: Axis2 ist eine SOAP-Engine, die zur Erstellung von Web Services in Java und C eingesetzt wird. Mit Hilfe des integrierten Tools JAVA2WSDL können aus Java-Klassen automatisch WSDL-Dokumente erstellt werden. Axis2 kann sowohl Web Services mit SOAP-Nachrichten über HTTP aufrufen als auch SOAP- Nachrichten über HTTP empfangen. Im Prototyp werden die Web Services in die Axis2-Engine deployed und stehen zum Aufruf durch die WF Anwendung zur Verfügung. Axis2 wird in der Version 1.3 vom Prototyp verwendet. ([Axis]) Struts2: Struts2 ist ein Open-Source-Framework für die Präsentations- und Steuerungsschicht von Java-Webanwendungen. Durch einen zentralen Dispatcher (FilterDispatcher) werden die HTTP-Requests des Clients verarbeitet. Der Dispatcher ruft mit Hilfe eines Actions-Mappers und einem Action-Proxy entsprechende Action-Controller-Klassen auf, die auf JavaBeans-Klassen zugreifen und Methodenaufrufe durchführen. Die JavaBeans dienen als Container zur 79

80 4 Prototypische Umsetzung Datenübertragung. Anschließend ruft eine zugehörige Java Server Page (JSP) die Daten der JavaBeans ab und bettet sie dynamisch in HTML-Code ein, der an den Client als HTTP-Response übertragen und im Browser angezeigt wird. Die Zuordnung der JavaBeans zu den jeweiligen Controller-Action-Klassen erfolgt im Monitorprototyp mit Hilfe des Spring-Frameworks. Der Prototyp verwendet Struts2 in der Version ([Strut], [BaWi04]) Spring: Spring ist ein Open-Source-Applikationsframework für die Entwicklung von Java EE Anwendungen. Das Framework bietet eine Vielzahl von Funktionalitäten an. Im Prototyp dient Spring als Schnittstelle zwischen Axis2 bzw. Struts2 und den Java-Klassen, die den Zugriff auf die eigentlichen Datenobjekte durchführen (Entwurfsmuster: Dependency Injection). Spring übernimmt die Erzeugung und Zuweisung der benötigten Datenzugriffsobjekte (Data Access Objects = DAO) zu den Web Service-, Controller- und View-Klassen und die Zuweisung der Datenbank zur SessionFactory, sowie der SessionFactory zu den jeweiligen DAOs. Die Web Service-Zuweisung erfolgt über die Definition von JavaBeans und zugehörigen Properties in der XML-Datei applicationcontext.xml. Ein Plug-In von Struts2 überträgt die Zuweisung der DAOs zu den Controller- und View-Klassen an Spring ([Spr_1]). Der Prototyp verwendet außerdem die von Spring unterstützte Möglichkeit des Scheduling 8. Spring kommt in der Version 2.0 im Prototyp zum Einsatz. ([Spr_2], [Spr_3]) Hibernate: Hibernate ist ein Open-Source-Persistenz-Framework für Java und.net-anwendungen. Im Prototyp übernimmt es das objekt-relationale Mapping zwischen den Java-Datenobjekten und der Monitor-Datenbank durch die Bereitstellung der DAO. Es können Zustände von Objekten in die Datenbank gespeichert werden und aus Datenbankeinträgen Objekte erzeugt werden. Das Framework erleichtert die Entwicklung der Java-Anwendung, indem die DB- Zugriffe nicht explizit in SQL programmiert werden müssen. Außerdem können die Datenobjekte bzw. die zugehörigen DAOs durch ein integriertes Reverse Engineering Tool generiert werden. Die Datenobjekte sind gewöhnliche Java- Objekte, die aus Attributen und getter/setter-methoden bestehen. Relationen in der Datenbank werden auf Beziehungen zwischen den Objekten in Form von Annotations abgebildet. Hibernate wird in der Version verwendet. ([Hib_1]) PostgreSQL: PostgreSQL ist ein objekt-relationales Datenbankmanagementsystem und Open-Source-Software. Es dient als Persistenzschicht für die gesammelten Monitoring-Daten. ([PSQL]) Die View- und Controllerklassen des MVC-Musters werden durch Struts2 zur Verfügung gestellt. Die Datenobjekte und DAOs, die durch Spring und Hibernate verwaltet werden, entsprechen den Modellklassen. Funktionsweise: Erzeugung und Verarbeitung: Die PostgreSQL-Datenbank enthält verschiedene Tabellen, die mit den erzeugten Monitoring-Informationen aus der WF Anwendung gefüllt werden. Diese Tabellen speichern einerseits die Nachrichtendaten von den Datenobjekten der jeweiligen Workflowinstanz und andererseits die Aktivitätsdaten, die den Workflowverlauf beschreiben. Eingehende Nachrichten werden auf die drei Tabellen notes, transconnect und sap abgebildet. Ausgehende Nachrichten werden mittels der Tabelle 8 Scheduling = Einmaliges oder wiederholtes Abarbeiten von Programmstücken nach festen Zeitspannen oder zu einem fixen Zeitpunkt [Spr_4] 80

81 4 Prototypische Umsetzung ausgehende protokolliert. Der Workflowverlauf wird durch zwei Tabellen abgebildet: eine Tabelle für die Aktivitätsinstanzen und eine weitere Tabelle für die den Instanzen zugeordneten Zustände. Des Weiteren sind die Metadaten, die zur Beschreibung des Workflowverlaufs benötigt werden, in der Monitor-Datenbank hinterlegt. Diese Metadaten enthalten bereits einen Teil des in aufgestellten Metamodells und werden von der Server-Anwendung zum Anlegen der Aktivitätsinstanzen und Zustände verwendet. Das Befüllen der Monitor-Datenbank erfolgt durch das Aufrufen von Web Services an bestimmten Punkten in der WF Anwendung. Im Prototyp werden die folgenden Web Services über Axis2 bereitgestellt: 1. NotesService zum Anlegen und Aktualisieren von Einträgen in der Notes- Tabelle 2. TransconnectService zum Anlegen und Aktualisieren von Einträgen in der Transconnect-Tabelle 3. SAPService zum Anlegen und Aktualisieren von Einträgen in der SAP- Tabelle 4. AusgehendeService zum Anlegen und Aktualisieren von Einträgen in der Ausgehende-Tabelle 5. ProzessService zum Anlegen von Aktivitätsinstanzen 6. ProzessschrittService zum Anlegen von Zuständen Die Web Services 1 bis 4 erzeugen die Nachrichtendaten, Web Service 5 und 6 erstellen die Aktivitätsdaten. Die SOAP-Nachrichten der Web Services werden mittels HTTP zwischen WF Anwendung und dem Webserver übertragen. Die implementierten Service-Operationen entsprechen dem Request-Response- Kommunikationsmuster. Mit den Datenbanktabellen und den zugehörigen Web Services stehen alle Komponenten zur Verfügung, um die Funktionsweise für die Erzeugung und Verarbeitung der Monitor-Daten am Beispiel der Aktivität -Eingang zu beschreiben: Die Überwachung der Workflowinstanzen eingehender Nachrichten beginnt mit der Instrumentierung des Mail-Agenten PutInFolder. Für jede zu verarbeitetende wird der NotesService innerhalb der dem Agenten zugrunde liegende Java- Klasse aufgerufen. Mit Hilfe des NotesService wird eine SOAP-Nachricht an den Webserver übertragen, der die Operation createnotes() aufruft und als Eingabeparameter verschiedene Attribute der übergibt. Im Webserver injiziert Spring der Web Service-Instanz eine Bean, die das entsprechende DAO-Objekt (NotesDAO) enthält. In der Methode createnotes() wird auf Basis des DAO-Objekts ein Eintrag in der Notes-Tabelle des Monitors angelegt. Die ID des DB-Eintrages ist der Rückgabeparameter der createnotes()-methode. Der Parameter wird in eine SOAP-Nachricht geschrieben und als Antwort an den PutInFolder-Agenten zurück gesendet. Der anschließend aufgerufene ProzessService überträgt eine SOAP-Nachricht, die die Operation createprozess() mit den Eingabeparametern ID des Notes-Eintrags und einer Vorgangsnummer der anzulegenden Aktivitätsart aufruft. Ein Objekt der Klasse ProzessDAO wird dem Web Service zugeordnet, der mit Hilfe der Vorgangsnummer in den Metadaten der Monitor-DB überprüft, welche Aktivitätsart die anzulegende Aktivitätsinstanz haben soll. Daraufhin werden ein - Eingang in der Tabelle für Aktivitätsinstanzen und der Initialzustand empfangen in die Zustandstabelle aller Instanzen angelegt. Der Aktivitätsinstanz 81

82 4 Prototypische Umsetzung wird ein eindeutiger Schlüssel zugeordnet, der als Fremdschlüssel in der Zustandstabelle eingetragen ist. Dieser Schlüssel stellt die Zuordnung zwischen der einzelnen Aktivitätsinstanz und den Zuständen her. Die ID des Notes-Eintrags wird verwendet, um die Beziehung zwischen den Nachrichtendaten und den Aktivitätsdaten abzubilden. Der Eintrag in der Notes-Tabelle wird selektiert und erhält als Fremdschlüssel die ID der Aktivitätsinstanz. In der SOAP-Response- Nachricht wird diese ID als Rückgabeparameter der Methode createprozess() übertragen. Die weitere Verarbeitung der im PutInFolder-Agenten wird mit Hilfe des ProzessschrittService überwacht. Dieser Service schreibt in Abhängigkeit der Ausführung die Folgezustände, beispielsweise in Bearbeitungsordner oder aussortiert in die Zustandstabelle der Monitor-DB. Diese Zustandsfortschreibung erfolgt unter Verwendung der Metadaten, d.h. bei jedem Aufruf des ProzessschrittService werden die Aktivitätsinstanz-ID und eine Vorgangsnummer des anzulegenden Zustands übergeben. Im Webserver wird dem Service ein DAO zugeordnet, mit dem ein Eintrag in die Zustandstabelle gespeichert wird. Die Erzeugung und Verarbeitung der Monitor-Daten der weiteren Aktivitäten erfolgt äquivalent nach dem beschriebenen Prinzip und umfasst allgemein die folgenden Schritte: Anlegen der Nachrichtendaten Anlegen der Aktivitätsinstanz und des Initialzustands (Aktivitätsdaten) Aktualisieren der Nachrichtendaten (Verknüpfung zu Aktivitätsdaten) Anlegen der Zustände bis Fehlerzustand oder Aktivität abgeschlossen Die unterschiedlichen Instrumentierungspunkte in der WF Anwendung werden nachfolgend zusammengefasst: EDI-Import: Die Java-basierte zeitgesteuerte Aufgabe der Transconnect- Middleware wird auf Basis eines Web Service-Adapters instrumentiert. Transconnect bietet diesen Adapter standardgemäß an, um den Zugriff auf Web Services per SOAP zu ermöglichen. Für jeden Web Service wird in der Middleware eine Adapterkonfiguration erstellt, die die jeweilige URL des Dienstes enthält ([TCHb], S.54). Innerhalb des EDI-Imports findet die gesamte Verarbeitung der eingehenden s bis zum Einstellen der EDIFACT-XML-Nachrichten in die Messagequeue statt. Aus diesem Grund ist die zugrunde liegende Java-Klasse komplex und es muss weitaus mehr Instrumentierungscode eingefügt werden im Vergleich zu den restlichen Instrumentierungspunkten. Folgende Nachrichten- und Aktivitätsdaten des Metamodells werden durch die Instrumentierung des EDI-Imports angelegt: Anlegen des gesamten Konvertierungseingangs: Die verschiedenen Entkopplungsfehler werden durch Instrumentierung des Exceptionhandlings überwacht. Anlegen der Einträge der Transconnect-Tabelle: Die Tabelle enthält die im Metamodell genannten Attribute des Konvertierungseingangs. Anlegen des Nachrichten-Eingangs Anlegen des CONTRL- und APERAK-Eingangs Anlegen des CONTRL- und APERAK-Ausgangs 82

83 4 Prototypische Umsetzung Monitor-Routingregeln: Die ein- und ausgehenden Nachrichten in der Messagequeue der Middleware werden durch XSLT-basierte Routingregeln weiterverarbeitet. Für die Überwachung dieser Verarbeitung werden zusätzliche Routingregeln definiert, die über den Transconnect-Adapter die Services des Monitor-Prototyps aufrufen. Der Adapter verfügt über einen WSDL-Parser, der die XML-Schemas für den Aufruf und das Ergebnis der Serviceoperationen sowie XML-Masken für die XSLT-Regel generiert ([TCHb], S.55f.). Die zusätzlichen Regeln erstellen die folgenden Nachrichten- und Aktivitätsdaten: Eingehend: Anlegen des Zustands IDoc gemappt an SAP gesendet der existierenden Nachrichten-Eingänge Aktualisieren der angelegten CONTRL- und APERAK-Eingänge Ausgehend: Anlegen und Aktualisieren der Einträge der Ausgehende-Tabelle: Die Tabelle enthält die im Metamodell genannten Attribute des Nachrichten- Ausgangs. Anlegen des Nachrichtenausgangs bis einschließlich Zustand angelegt In Teilabschnitt des Anhangs ist der Aufruf eines Web Service mittels einer XSLT-basierten Routingregel an einem Beispiel beschrieben. Zeitgesteuerte Monitor-Aufgabe: Für die Statusfortschreibung des Nachrichten-Eingangs wurde für den Monitor-Prototyp eine zeitgesteuerte Aufgabe in der Middleware angelegt. Die Java-basierte Aufgabe fragt zyklisch den Status der angelegten IDocs im SAP-Backend ab, erstellt die Monitor-Einträge der SAP- Tabelle und legt die Folgezustände des Nachrichten-Eingangs an. Es wird nur der Endstatus des Nachrichten-Eingangs im Monitor angelegt ( DA erfolgreich angelegt oder Mind. 1 DA fehlerhaft angelegt ). Alle Zwischen-Zustände, die im Metamodell enthalten sind, werden durch den Prototyp nicht abgebildet. Der Zugriff auf die Web Services erfolgt äquivalent zum EDI-Import. Mailversand: Die Überwachung der zu versendenden s wird durch die Instrumentierung des Java-basierten Lotus Notes-Agenten Mailversand erreicht. Die aufgerufenen Web Services erstellen den Zustand versendet für die Aktivitäten des Nachrichten-, CONTRL- und APERAK-Ausgangs. Die aufgeführten Instrumentierungspunkte erzeugen die gesamten Monitor- Daten des Prototyps. Im Webserver werden die Daten verarbeitet und in der Monitor-DB gespeichert. Die im Metamodell beschriebenen Timeout-Fehler werden im Prototyp durch eine mittels Spring definierte Scheduler-Task ausgelöst. Diese Task ruft periodisch die run-methode in der Klasse CheckTimeout.java auf. Die Klasse prüft mit Hilfe der Metadaten und der Zeitstempel der angelegten Zustände, ob die Maximalwartezeiten überschritten werden. Ist dies der Fall, wird automatisch der entsprechende Timeout-Zustand der zugehörigen Aktivitätsinstanz in der Monitor-DB angelegt. Die Maximalwartezeiten der einzelnen Zustände sind in der Tabelle, die die Metadaten der Zustände enthält, hinterlegt. Die Scheduler-Task wird in der Spring-Konfigurationsdatei applicationcontext.xml definiert (siehe Teilabschnitt des Anhangs). 83

84 4 Prototypische Umsetzung Die Bereitstellung der Monitor-Daten für die Präsentation im Browser der Benutzer erfolgt mit Hilfe des Struts2-Frameworks und soll nachfolgend beschrieben werden. Präsentation: Die Präsentation der Monitor-Daten erfolgt auf Basis von Events, die durch eine Interaktion des Benutzers mit den Views ausgelöst werden. Der zentrale Dispatcher von Struts2 verarbeitet das jeweilige Event, indem die entsprechende Action-Controller-Klasse initialisiert wird. Mit Hilfe der zugeordneten DAOs werden die anzuzeigenden Daten aus der Monitor-DB geladen. Anschließend stößt die Action-Controller-Klasse das Rendern eines neuen Views an. Der zugehörige View ist als JSP hinterlegt und wird in der Action-Controller-Klasse referenziert. Die geladenen Monitor-Daten werden durch die JSP dynamisch in ein HTML- Dokument geschrieben, das als HTTP-Response an den Client übertragen wird. In Abbildung 29 ist der Einstiegsbildschirm des Monitor-Prototyps dargestellt. Menuleiste Abbildung 29: Einstiegsbildschirm des Monitor-Prototyps Die Menuleiste des Monitors besteht aus sieben Punkten, die jeweils mit einem zugehörigen View im Webserver verlinkt sind. Die Menupunkte realisieren die folgenden Funktionalitäten: Prozesse: Dieser Menupunkt wird beim Start der Anwendung initialisiert und listet alle laufenden Aktivitätsinstanzen der WF Anwendung in einer Baumstruktur auf. Die Instanzen sind in den verschiedenen Mandanten, den Rollen als Netzbetreiber oder Lieferant, der Aktivitätsart und dem aktuellen Zustand eingeteilt (Abbildung 30). 84

85 4 Prototypische Umsetzung Mandant und Netzbetreiber Aktivitätsinstanzen (nach Aktivitätsart) Aktivitätsinstanzen (nach Zustand) Weitere Mandanten Abbildung 30: Menupunkt-Prozesse (expandierte Baumstruktur) Der Benutzer kann sich alle oder nur die fehlerhaften Aktivitätsinstanzen anzeigen lassen. Durch Auswahl eines Zustandes per Mausklick werden alle Instanzen, die sich in diesem Zustand befinden, in tabellarischer Form aufgelistet. Wird eine konkrete Instanz ausgewählt, gelangt man in den DetailView, der die zugehörigen Nachrichtendaten und die Aktivitätsinstanzen anzeigt (Abbildung 31). Aktivitätsinstanz Abbildung 31: DetailView für Aktivitätsinstanz Nachrichten-Ausgang Per Klick auf die Aktivitätsinstanz gelangt der Benutzer in den AktivitätsView, der die einzelnen Zustände der Instanz auflistet (Abbildung 32). Abbildung 32: AktivitätsView für Aktivitätsinstanz Nachrichten-Ausgang 85

86 4 Prototypische Umsetzung Übersicht: Dieser View enthält Statistikfunktionen, die auf den gesammelten Monitor-Daten operieren. Es können derzeit nur die Anzahl der Einträge pro Tag und Monat in den Tabellen der Nutzdaten angezeigt werden. Ein weiteres Feature der Übersicht ist die Suchfunktion auf Basis der Nachrichtendaten Notes, Transconnect, SAP und Ausgehende. Es kann beispielsweise in den eingegangen s nach Inhalten im Mail-Betreff oder bei ausgehenden Nachrichten nach einer IDoc-Nummer gesucht werden. Mit Hilfe eines Zeitintervalls können alle Nachrichtendaten gefiltert werden. Notes, Transconnect, SAP, Ausgehende: Auflistung aller Einträge der Nachrichtendaten in Tabellenform. Die ID des jeweiligen Eintrages ist mit dem DetailView, der die daran beteiligten Nachrichten- und Aktivitätsdaten anzeigt, verlinkt. Administration: Die Administration dient als Hilfsmittel für die Entwicklung des Prototypen. Es werden eine Log-Datei, die die Verarbeitung des Webservers protokolliert, und die verfügbaren Web Services angezeigt. Die Menupunkte ermöglichen die Überwachung der eingehenden Nachrichten vom Start des Mailagenten bis zum Versenden des IDocs an das SAP-System. Anschließend wird mit Hilfe der zeitgesteuerten Monitoraufgabe die IDoc- Nummer und der IDoc-Status im Monitor angezeigt. Das Monitoring der ausgehenden Nachrichten erfolgt im Prototyp ab Verarbeitungsbeginn in der Middleware bis zum Versenden der Mail per Versendeagenten. Der Aufbau der Weboberfläche des Prototyps wurde speziell für die Fehlersuche der ein- und ausgehenden Nachrichten in der WF Anwendung konzipiert. Der Benutzer startet die Anwendung und erhält einen Überblick über die fehlerhaften Aktivitätsinstanzen. Mit Hilfe des Detail- und AktivitätsViews können die einzelnen Instanzen einer Analyse unterzogen werden, wann und in welchem Schritt Fehler aufgetreten sind bzw. welche Daten in den Nachrichten empfangen oder versendet werden. Der Menupunkt Übersicht unterstützt die Anwender primär bei der Suche von Nachrichten nach verschiedenen Kriterien. Dieses Feature ist für die Interaktion der Fachbereiche mit anderen Marktpartnern bzw. den Mitarbeitern der Anwendungsbetreuung vorgesehen. Die Menupunkte SAP, Transconnect, Notes und Ausgehende ermöglichen die Überwachung aus Sicht der Nachrichtendaten. Es werden die aktuellsten Nachrichten angezeigt und die Anwender können in den DetailView der einzelnen Einträge wechseln. Die Administration dient ausschließlich als Hilfsmittel für die Entwicklungsphase des Prototyps. Das Anlegen der Web Services wird über das integrierte Axis2- Framework überwacht. Auf Basis der Log-Datei kann die Ausführung der Anwendung, beispielsweise das Absetzen der Datenbankabfragen mittels Hibernate, analysiert werden. Bei Übergang in den produktiven Einsatz würde dieser Menupunkt entfallen. Der beschriebene Prototyp erfüllt bereits einen Teil der in Teilabschnitt genannten Anforderungen. Ein produktiver Einsatz des Prototyps im derzeitigen Zustand ist dennoch nicht sinnvoll, da elementare Funktionalitäten fehlen. Im Folgenden werden die fehlenden Features aufgelistet und Prioritäten für die Weiterentwicklung zugeordnet. 86

87 4 Prototypische Umsetzung Aufstellung fehlender Funktionalitäten im Prototyp Nachrichtenüberwachung und Fehlererkennung: Der Monitor-Prototyp realisiert die Überwachung des Nachrichtenverkehrs über die Middleware und die Mailanwendung. Die beschriebenen Fehlerkategorien dieser beiden Systeme werden erkannt und im Monitor angezeigt. Eine direkte Anbindung an das SAP- Backend fehlt. Die Aktivitäten DA-Eingang und DA-Ausgang des Metamodells werden nicht aufgezeichnet. Diese Aktivitäten stellen das Hauptaugenmerk der Fachbereiche und der Anwendungsbetreuung dar, da sie die einzelnen Geschäftsvorgänge und die dazu gehörigen Kundendaten enthalten. Eine Suche auf Basis dieser Daten ist somit nicht möglich. Für den eingehenden Workflow wird mit Hilfe der speziell für den Prototyp eingerichteten zeitgesteuerten Monitor-Aufgabe lediglich der IDoc-Status an den Monitor übertragen. Der Nachrichten-Eingang des Metamodells wird somit nicht vollständig abgebildet. Dieses Vorgehen hat bei aggregierten Nachrichten den Nachteil, dass nicht festgestellt werden kann, welcher Vorgang den Fehler auslöst und was die Ursache für den Fehler ist. Besonders bei großen EDIFACT- Dateien gestaltet sich die Suche nach Fehlern aufwändig 9. Die Zeitsteuerung führt des Weiteren zu einer größeren Zeitverzögerung zwischen Auftreten des Fehlers und der Anzeige im Monitor. Die Überwachung des ausgehenden Workflows erfolgt mit dem Verarbeitungsbeginn in der Middleware. Aus diesem Grund werden Fehler, die im Backend beim Anlegen der DA-Aufgabe bzw. Versenden des IDocs auftreten, nicht erkannt. Das betrifft besonders die Fehlerkategorien RFC-Versendefehler und sonstige Fehler, beispielsweise Programmierfehler und fehlerhafte Daten im Backend. Die Analyse aggregierter Nachrichten kann ebenfalls nicht auf Basis der Einzelvorgänge erfolgen, da nur das aggregierte IDoc erfasst wird. Aufgrund der fehlenden Aktivitäten der DA-Aufgaben ist es zudem nicht möglich, die Vorgänge eines Geschäftsprozesses miteinander zu verknüpfen. Eine prozessorientierte Darstellung auf Basis des Wechselbelegs ist nicht umgesetzt (siehe Punkt 7 der funktionalen Anforderungen in Teilabschnitt 3.3.1). Priorität: HOCH Suchfunktionen und Anzeige der Fehlerbehandlung: Im Monitor sind bereits Suchfunktionen vorhanden, die auf Basis der gesammelten Nachrichtenund Aktivitätsdaten operieren. Eine Suche mit Hilfe fachlicher Kriterien, die besonders die Attribute des DA-Eingangs und DA-Ausgangs betreffen, ist aufgrund der fehlenden Backend-Anbindung nicht realisiert. Die Erweiterung der Suchmaske im Menupunkt Übersicht um weitere Suchkriterien ist aufgrund der Trennung des Monitors in Model, View und Controller mit geringem Aufwand möglich. Die Kombination der Suchkriterien ist nicht umgesetzt. Eine Möglichkeit die Fehlerbehandlung zu kommentieren ist ebenfalls noch nicht implementiert. Dieses Feature kann durch Hinzufügen eines Textfelds im Detail- View eingebunden werden. Priorität: MITTEL Links auf Datenobjekte und Aufruf von Bearbeitungsfunktionen: Die beschriebenen Anforderungen sind im Prototyp nicht integriert. Es besteht lediglich die Möglichkeit Aktivitätsinstanzen manuell zu beenden, damit sie in der Überwachung nicht angezeigt werden. Diese Funktionalität operiert auf der Monitor-DB 9 EDIFACT-Nachrichten vom Typ INVOIC enthalten bis zu 1000 Vorgänge. Begrenzt wird die Anzahl durch die maximal zulässige Dateigröße, die zwischen den Marktpartnern ausgehandelt wird und im Normalfall zwischen 10 und 100 MB liegt. 87

88 4 Prototypische Umsetzung und soll für Vorgänge genutzt werden, die anderweitig, zum Beispiel durch bilaterale Einigung mit dem Marktpartner, geklärt wurden. Der Prototyp verfügt nicht über eine automatische Alarmierungsfunktion bei Auftreten von Fehlern. Im derzeitigen Zustand handelt es sich um einen passiven, nicht-steuernden Monitor. Der entfernte Zugriff auf die Dokumente und Funktionalitäten der anwendung kann mit Hilfe einer separaten Java-Klassenbibliothek, die von Lotus Notes zur Verfügung gestellt wird, erfolgen ([KP+00], S.656ff.). Die internen Transconnect-Tabellen können über JDBC angesprochen werden. Der Aufruf von SAP- Funktionen und der Zugriff auf SAP-Objekte sind mit Hilfe des SAP Java Connectors (SAP JCo) realisierbar ([SAP_1]). SAP JCo ist ein Interface zwischen den BAPIs und RFCs des SAP-Backends und externen Java-Anwendungen. Priorität: NIEDRIG Reporting-Funktionalität und Archivierung: Die Möglichkeit Statistiken zu erzeugen, ist in geringem Umfang gegeben. Die aufgelisteten Informationen stellen die Gesamtanzahl von Nachrichten in einem bestimmten Zeitraum dar. Fachliche Auswertungen, wie im Punkt 8 der funktionalen Anforderungen genannt, werden bisher nicht unterstützt. Eine Grundlage für derartige Analysen ist die Überwachung der DA-Aufgaben im SAP-System. Die übertragenen Attribute der einzelnen Geschäftsvorgänge stellen die benötigte Datenbasis dar. Die Archivierung von bearbeiteten Vorgängen ist im Prototyp bisher nicht vorgesehen. Die automatische Weiterleitung in ein Langzeitarchiv, das als Data Warehouse genutzt wird, könnte beispielsweise mit Hilfe einer zusätzlichen Scheduler-Task im Spring-Framework realisiert werden. Priorität: NIEDRIG Zugriffskontrolle und Berechtigungskonzept: Mechanismen für die Zugriffskontrolle und das beschriebene Berechtigungskonzept sind bisher nicht implementiert. Die Zuordnung der Aktivitätsinstanzen zum Mandanten bzw. der Rolle als Netzbetreiber oder Lieferant ist bereits in der Monitor-DB hinterlegt. Ein entsprechendes Konzept könnte auf diesen Informationen aufsetzen und die Definition von Berechtigungsprofilen für die Anwender realisieren. Sicherungsmaßnahmen für die Integrität der Monitor-Daten müssen noch implementiert werden. Axis2 enthält das Modul Rampart, das speziell für die Sicherung der SOAP-Nachrichten auf Basis der WS Security Spezifikationen eingerichtet wurde ([Ramp_1], [Ramp_2]). Eine Kombination von Benutzername/Passwort- Token zur Authentifizierung mittels WS Security und die Verschlüsselung der Nachrichten auf Basis der Transport Layer Security stellt eine mögliche Lösung dar. Der Nachteil der Ver- und Entschlüsselung der Nachrichten ist der entstehende Performanz-Overhead. Priorität: MITTEL Performanz: Die Performanz für die Erzeugung und Verarbeitung der Monitordaten wurde bisher durch wenige Testfälle geprüft. Unter anderem untersuchte man die Verarbeitung von ca eingehenden Test-Mails. Die Verarbeitungszeiten der Nachrichten wurden mit Hilfe von Log-Files des -Clients und des Transconnect Managers überprüft und waren laut Administratoren zufrieden stellend. Die Aussagekraft dieser Tests kann jedoch als gering eingeschätzt werden, da keine Bezugswerte für die Verarbeitung der Nachrichten ohne Monitor- Anbindung existieren. Eine Erstellung von Bezugswerten und umfassendere Testreihen sollten im Vorfeld der Produktivsetzung durchgeführt werden. Voraussetzung für diese Tests ist die Anbindung des Monitors an das 88

89 4 Prototypische Umsetzung SAP-Backend, um die vollständige Erzeugung der Monitor-Daten zu prüfen. Im Durchschnitt werden täglich ca ein- und ausgehende IDocs angelegt. Es gilt jedoch zu berücksichtigen, dass durch Festlegung der gesetzlichen Fristen an bestimmten Monatstagen ein hoher Nachrichtenverkehr zu verzeichnen ist. [BDW08_7], S.51 legt beispielsweise fest, dass UTILMD-Nachrichten, die Bestandslisten enthalten, am 16. Werktag des Monats zu versenden sind. Dies führt zu Spitzenwerten von bis zu täglich erstellten IDocs im SAP-Backend. Die Performanz für die Präsentation der Monitoring-Daten ist primär von der Datenmenge, die aus der Datenbank geladen wird, und dem Zustand der aufgerufenen Klassen abhängig. Die Antwortzeiten beim erstmaligen Starten der Anwendung sind relativ hoch, da die für jeden View benötigten Servlets initialisiert und die Daten direkt aus der Datenbank geladen werden. Hibernate bietet verschiedene Caching-Mechanismen an, die bei einer erneuten Anfrage die Daten im Framework vorhalten. Nach Initialisierung der Klassen ist ein schnelles Arbeiten mit dem Prototyp möglich. Priorität: MITTEL Fazit: Wie aus der Beschreibung der fehlenden Funktionalitäten hervorgeht, bestehen noch viele offene Punkte, die den Einsatz des Prototyps im produktiven Umfeld der WF Anwendung verhindern. Die wichtigste Voraussetzung ist die vollständige Abbildung der Workflows durch die Anbindung des Prototyps an die SAP- Anwendung. Nur mit Hilfe dieses Features ist es möglich, die Mitarbeiter der Fachbereiche und der Anwendungsbetreuung bei der Nachrichtenüberwachung und Fehlererkennung umfassend zu unterstützen. Außerdem liefert die Kopplung an das SAP-System notwendige Daten für weitere zu entwickelnde Punkte (Suchmöglichkeiten und Reportingfunktionalitäten). Das primäre Ziel ist der möglichst kurzfristige Einsatz des Prototyps zur Fehlererkennung. Mit der Möglichkeit, alle Fehler innerhalb eines Tools anzuzeigen, könnte der bisherige Aufwand der Mitarbeiter bereits erheblich gesenkt werden. Die Verlinkung der Datenobjekte und die Integration von Bearbeitungsfunktionen wurden aus diesem Grund von der Priorität niedriger eingestuft, da diese Punkte vorrangig für die anschließende Fehlerbehandlung eingesetzt werden. Die Einführung des Berechtigungskonzeptes ist besonders relevant für den Einsatz des Prototyps durch die verschiedenen Fachbereiche der Unternehmen, da diesen nur eingeschränkter Zugriff auf die Monitoring-Daten gestattet ist. Des Weiteren muss die Performanz der Anwendung, besonders für die Datenmenge im täglichen Betrieb, näher untersucht werden. Eine Verbesserung der Überwachung der Workflows im Vergleich zur bisherigen Toolunterstützung und eine große Nutzerakzeptanz des neuen Monitors kann nur durch angemessene Antwortzeiten erreicht werden. Im praktischen Teil dieser Arbeit soll aufgrund der oben aufgeführten Prioritäten eine Möglichkeit gefunden werden, die SAP-Anwendung an den Prototyp anzubinden. Die Erweiterung des Monitors wird im folgenden Abschnitt beschrieben. 4.2 Erweiterung des Prototyps Zunächst wird in Teilabschnitt auf die Erzeugung der Monitor-Daten und die Möglichkeiten der Instrumentierung in der SAP-Anwendung eingegangen. Anschließend erfolgt die Beschreibung der durchgeführten Implementierungsmaßnahmen in der Serveranwendung des Prototyps für die Verarbeitung der übertragenen Monitor-Daten (4.2.2). 89

90 4 Prototypische Umsetzung Die Anbindung der SAP-Anwendung beschränkt sich auf den ausgehenden Workflow und die damit verbundene Aktivität des DA-Augangs. Hintergrund dieser Entscheidung ist die Tatsache, dass der Prototyp in der Lage ist, Fehler in der SAP-Verarbeitung im eingehenden Workflow anzuzeigen. Die Fehlererkennung basiert zwar auf der zeitgesteuerten Monitor-Aufgabe und enthält daher die genannten Nachteile, aber die auftretenden Fehler werden zumindest angezeigt. Die Überwachung des ausgehenden Workflows beginnt erst mit der Verarbeitung der XML-Nachrichten in der Middleware. Fehler bei der Erstellung der DA- Aufgaben und den zugehörigen IDocs und RFC-Versendefehler werden vom Prototyp derzeit nicht angezeigt. Abschließend wird die Arbeitsweise der erweiterten Monitorfunktionalitäten demonstriert und auf Basis von Szenarien getestet (4.2.3) Erzeugung der Monitor-Daten in der SAP-Anwendung Die SAP-Anwendung basiert auf dem 3-Tier-Architekturmodell Präsentation- Applikation-Datenhaltung ([SAP_2]). Der zentrale SAP NetWeaver Application Server (SAP NW AS) stellt die Applikationsschicht und die Basis für alle SAP- Komponenten dar. Der Server besteht aus einem ABAP- und einem Java-Stack. Die SAP-Anwendung der ENSO verwendet das Server-Release 7.0 und setzt vollständig auf dem ABAP-Stack auf. Für die Anbindung des SAP-Systems an den Monitor-Prototyp muss eine Möglichkeit gefunden werden, Web Services aus ABAP-Programmen aufzurufen. Die konsumierenden Services müssen in der Serveranwendung des Prototyps entwickelt und für den Aufruf publiziert werden (siehe 4.2.2). Der SAP NW AS implementiert die grundlegenden Web Service-Standards XML, SOAP, WSDL und UDDI. Die ABAP-Entwicklungsumgebung stellt ein Web Service Framework zum Publizieren, Suchen und Aufrufen von Web Services bereit. Der SAP NW AS kann somit als Server für Web Services und als Web Service-Client agieren. ([SAP_3]) Der Aufruf eines Web Service erfolgt mit Hilfe einer Client-Proxy-Klasse, die auf Basis des WSDL-Dokuments des Dienstes generiert wird. Beim Erstellen der ABAP-Klasse erfolgt das Importieren der WSDL-Datei durch Angabe einer URL oder aus einer lokalen Datei. Die generierte Klasse enthält für jede beschriebene Web Service-Operation eine Methode. Die Ein- und Ausgabeparameter der Methoden werden aus der Message- und Typdeklaration im WSDL-Dokument ausgelesen und auf ABAP-Datenstrukturen und elementare ABAP-Datentypen abgebildet 10. ([SAP_4]) Für den Zugriff auf den jeweiligen Service muss für die Proxy-Klasse ein logischer Port angelegt werden, der auf den Endpunkt, der die eindeutige Adresse des Service im System des Dienstanbieters enthält, verweist. Einer Proxy-Klasse können mehrere logische Ports zugeordnet werden. Der logische Port kann automatisiert über die importierte WSDL-Datei der Proxy-Klasse angelegt werden. Die Aufrufparameter des Ports sind in den <service>- und <binding>- Elementen enthalten. ([SAP_5]) Nach Erstellung der Proxy-Klasse und mindestens einem logischen Port kann der Aufruf des Web Service an beliebiger Stelle in ABAP-Programmen eingebunden werden. Zunächst müssen die Proxy-Klasse und die Ein- und Ausgabestruktur der aufzurufenden Methode als Variablen deklariert werden. Anschließend wird die Eingabestruktur mit den Aufrufparametern befüllt. Im nächsten Schritt wird die Proxy-Klasse unter Angabe des zu verwendeten Ports initialisiert. Erfolgt die 10 Die Proxy-Generierung unterstützt nur <message>-elemente in der importierten WSDL-Datei, die genau ein <part>-element enthalten. Innerhalb des <part>-elements kann auf komplexe Datentypen, die im <types>- Element definiert sind, verwiesen werden. Der Datentyp, der in diesem <part>-element angegeben ist, wird auf exakt eine ABAP-Struktur abgebildet. ABAP-Strukturen bestehen aus einer Folge beliebiger Datentypen. 90

91 4 Prototypische Umsetzung Initialisierung ohne Angabe eines Ports, so wird der im Vorfeld definierte Standardport verwendet. Der Web Service wird durch den Methodenaufruf der Proxy- Instanz und unter Angabe der Ein- und Ausgabestruktur konsumiert. Nach dem Aufruf können die Rückgabeparameter der ausgeführten Web Service Methode aus der Ausgabestruktur ausgelesen und ausgewertet werden. ([SAP_6]) Analyse der Instrumentierungsmöglichkeiten im SAP Workflow Nachdem mit dem Web Service Framework das Werkzeug zum Aufrufen der Web Services aus ABAP-Programmen zur Verfügung steht, muss entschieden werden, an welchen Punkten die WF Anwendung instrumentiert wird. Dazu ist es zunächst notwendig einen Einblick in den SAP Business Workflow zu geben, der die GPKE/GeLi-Prozesse in den SAP-Mandanten der ENSO realisiert. Der SAP Business Workflow unterstützt die rationelle, rechnergestützte Bearbeitung von komplexen, betriebswirtschaftlichen Abläufen. Es handelt sich um eine anwendungsübergeifende, vollständig im SAP-System integrierte Lösung, die die vorhandenen, umfassenden SAP-Funktionen ergänzt. Die Architektur des Business Workflow ist in Abbildung 33 dargestellt. Mehrschrittaufgabe basiert auf: zur Laufzeit repräsentiert durch: Workflow Workflow- Definition enthält als Schritte: Mögliche Bearbeiter ist verknüpft mit: Einzelschrittaufgabe ruft Objektmethode auf: zur Laufzeit repräsentiert durch: Workitem Business Object Repository enthält: Objekttyp Methode zur Laufzeit repräsentiert durch: Objekt Abbildung 33: Architektur des SAP Business Workflow Ein Workflow wird als Mehrschrittaufgabe angelegt und enthält die Workflowdefinition, die den betriebswirtschaftlichen Prozess allgemeingültig, vollständig und unter Berücksichtigung von Ausnahme- und Entscheidungsmöglichkeiten beschreibt. Die Einzelschrittaufgaben stellen die ausführbaren Schritte dieser Definition dar und fassen die funktionalen und organisatorischen Aspekte einer betriebswirtschaftlichen Tätigkeit zusammen. Eine Einzelschrittaufgabe kann mit oder ohne Beteiligung eines Bearbeiters durchgeführt werden. Das Business Object Repository stellt die Schnittstelle zwischen dem Workflow und den auszuführenden SAP-Anwendungen dar. Es enthält die Definitionen und Methoden von Objekttypen, die die Grundlage für die objektorientierte Strukturierung des SAP-Systems schaffen. Die vorhandenen 91

92 4 Prototypische Umsetzung Standard-Funktionen des SAP-Systems und eventuell neu entwickelte Funktionen sind als Objektmethoden der Objekttypen definiert. Die Daten und Informationen der Anwendung werden als Attribute der Objekttypen angelegt und können vom Workflow verwendet werden, um weiter zu verzweigen. ([Men04], S.11ff.) Alle ein- und ausgehenden EDIFACT-Nachrichten werden in der SAP-Anwendung der ENSO nach dem beschriebenem Prinzip verarbeitet. Aufgrund der Komplexität der Geschäftsabläufe existiert eine Vielzahl stark verzweigter Workflowdefinitionen, die alle Sonderfälle der Geschäftsprozesse berücksichtigen. Eine detaillierte Betrachtung der Workflowdefinitionen übersteigt den Rahmen dieser Arbeit. Aus diesem Grund werden im Folgenden die Workflowdefinitionen für die ausgehenden DA-Aufgaben des Lieferantenwechsels zusammenfassend beschrieben (Abbildung 34). Die Beschreibung dient als Basis für die Erstellung der Aktivität des DA-Ausgangs im Monitor-Prototyp. ISUSWITCHD create() Wechselbeleg anlegen Methodenaufrufe - Daten zu Wechselbeleg ermitteln - DA-Prozesse bestimmen create() ISUTASK (Bsp. Kündigungsantwort) ISUTASK IDoc IDoc IDoc - Verarbeitung Zielsysteme (u.a. Transconnect) Abbildung 34: Vereinfachte Darstellung des Workflows für ausgehende DA-Aufgaben Durch eine vorgangsspezifische Verbuchung im SAP-System wird ein Objekt des Objekttyps ISUSWITCHD initialisiert, das den erstellten Wechselbeleg darstellt. Beispiel für eine vorgangsspezifische Verbuchung, die auch für die späteren Tests des Monitor-Prototyps verwendet wird, ist das manuelle Anlegen einer eingehenden Kündigung: Der Mitarbeiter des entsprechenden Fachbereichs ruft die Daten des Kunden, der zu einem neuen Lieferanten wechseln will, über das Kundeninformationssystem (CIC) der SAP-Anwendung auf. Auf Basis des Zählpunkts, der die Entnahmestelle 92

93 4 Prototypische Umsetzung des Kunden eindeutig und systemübergreifend identifiziert, legt der Mitarbeiter über einen Dialog einen Wechselbeleg an. In der Dialogmaske befüllt der Mitarbeiter die Felder des Wechselbelegs mit den Kündigungsdaten, u.a. Versorgungsbeginn, Versorgungsende und neuer Lieferant, und sichert den Beleg. Die SAP-Anwendung prüft, ob alle Pflichtfelder gefüllt sind, und legt anschließend das Objekt ISUSWITCHD an. Das Erstellen des Objekts stellt die erste Einzelschrittaufgabe des gestarteten Workflows dar. Über den Aufruf verschiedener Methoden werden die Daten zum Wechselbeleg ermittelt und geprüft, welche DA-Prozesse für den Geschäftsprozess erstellt werden müssen. Anschließend werden in Abhängigkeit der DA-Prozesse parallel verschiedene Objekte des Objekttyps ISUTASK, der die DA-Aufgabe definiert, erstellt. Im Fall der eingehenden Kündigung wird eine Kündigungsantwort als DA-Aufgabe erstellt. Für die Initialisierung des jeweiligen ISUTASK-Objekts wird ein initialer FuBa aufgerufen, der im DA-Prozess hinterlegt ist. Dieser FuBa sammelt die Vorgangsdaten der zu versendenden EDIFACT-Nachricht aus den zugrunde liegenden Datenbanktabellen, erzeugt ein IDoc und übergibt dieses an die IDoc-Verarbeitung. Zusätzlich prüft der FuBa die Abhängigkeiten zu anderen Objekten der SAP-Anwendung. Für jeden EDIFACT-Nachrichtentyp und für jede EDIFACT-Nachrichtentypversion existiert ein initialer FuBa, der das Anlegen der DA-Aufgabe und die genannten Folgeschritte durchführt. Innerhalb des jeweiligen FuBas werden eine Vielzahl von ABAP-Unterprogrammen und weitere FuBas aufgerufen, die die Eigenschaften des jeweiligen Geschäftsvorgangs berücksichtigen. Aus diesem Grund ist der Aufrufbaum des initialen FuBas stark verzweigt und komplex. Die Verarbeitung des initialen FuBas führt im fehlerfreien Fall zum Anlegen der DA-Aufgabe mit dem Status OK und eines zu versendenden IDocs. Das IDoc wird an die IDoc- Verarbeitung übergeben, gegebenenfalls aggregiert und versendet. Eine Instrumentierung der IDoc-Verarbeitung ist nicht erforderlich, da eine IDoc- Aggregation für den Lieferantenwechselprozess noch nicht implementiert ist und somit der Zustand IDoc aggregiert nicht im Monitor-Prototyp angezeigt werden muss. Wenn während der Verarbeitung der DA-Aufgaben Fehler auftreten, werden diese durch Exceptionhandling im FuBa abgefangen und die DA-Aufgabe mit dem Status ERROR angelegt. In diesem Fall wird kein IDoc erzeugt. Typische Beispiele für Verarbeitungsfehler sind das Fehlen von Stammdaten und fehlerhafte IDoc-Basistypkonfigurationen. Für die Aktivität des DA-Ausgangs enthält der beschriebene Erstellungsprozess die für das Monitoring relevanten Events. Eine Möglichkeit, um die im Metamodell genannten Informationen an den Monitor-Prototyp zu übertragen, ist die Instrumentierung des jeweiligen initialen FuBas, der im DA-Prozess hinterlegt ist. Diese Vorgehensweise wurde im Rahmen dieser Arbeit zunächst umgesetzt und getestet. Dabei stellte sich jedoch heraus, dass mit der Instrumentierung ein hoher Implementierungsaufwand verbunden ist. Folgende Nachteile wurden festgestellt: 1. Aufwändige Suche nach der zu instrumentierenden Codestelle aufgrund hoher Komplexität des FuBa-Aufrufs: Innerhalb des FuBas werden die Attribute der DA-Aufgabe durch die verschiedenen Unterprogramme hinzugefügt. In einem finalen Schritt wird in einem dieser Unterprogramme die vollständige DA-Aufgabe als Datenbank-Eintrag in die ABAP-Tabelle EDEXTASK angelegt. Die konkrete ID der angelegten DA-Aufgabe wird nicht an den initialen FuBa zurückgeliefert. Diese ID liefert die Grundlage, um die erforderlichen Attribute der DA-Aufgabe und die Nummer des erstellten 93

94 4 Prototypische Umsetzung IDocs zu ermitteln. Die Schwierigkeit besteht darin das entsprechende Unterprogramm und den Datenbankaufruf zu finden. 2. Notwendigkeit der Instrumentierung aller initialen FuBas, die für die Erstellung der DA-Aufgaben aufgerufen werden: Der Web Service Aufruf müsste für jeden EDIFACT-Nachrichtentyp an der korrekten Stelle des damit verbundenen FuBas eingefügt werden. Das führt zu einer Erhöhung des Implementierungsaufwands. 3. Anpassung der Instrumentierung bei EDIFACT-Versionswechsel: Eine Aktualisierung der EDIFACT-Nachrichtentypen ist mit der Anpassung bestehender FuBas und ggf. mit der Implementierung neuer ABAP-Programme in der SAP-Anwendung verbunden. Durch die Vermischung des Instrumentierungscode mit dem Anwendungscode der FuBas, muss bei jeder durchzuführenden Änderung die Abhängigkeit zum Monitor-Prototyp berücksichtigt werden. Eine Alternative zur Instrumentierung der einzelnen FuBas bietet die Ereignissteuerung der SAP-Objekttypen. Für jeden Objekttyp sind bestimmte Ereignisse definiert, die durch die konkreten Objektinstanzen ausgelöst werden können. Beispiele für Ereignisse sind das Erstellen einer Instanz, Zustandsänderungen und Fehlermeldungen. Die Ereignisse werden systemweit publiziert und bieten somit eine flexible Andockstelle für beliebige Anwendungskomponenten. Die Ereigniserzeugung basiert auf dem Publish-Subscribe-Prinzip. Dabei publiziert ein Erzeuger ein Ereignis und informiert alle Verbraucher, die sich vorher als solche eingetragen haben. Jedes Ereignis überträgt Informationen über das ereigniserzeugende Objekt. Der Ereignismanager übernimmt die Vermittlung zwischen Ereigniserzeuger und Ereignisverbraucher und arbeitet nach dem Event- Condition-Action-Paradigma. Das jeweils erzeugte Ereignis wird auf bestimmte Bedingungen hin überprüft, bevor es an den Verbraucher weitergeleitet wird. Die Ereignissteuerung enthält einige hilfreiche Werkzeuge, die den Entwickler beim Arbeiten mit Ereignissen unterstützen. Für die Protokollierung der zur Laufzeit ausgelösten Ereignisse steht der Ereignis-Trace mit der Transaktion SWEL zur Verfügung. Der Objekttyp, der Ereignisname, ein Zeitstempel und die Verbraucher werden angezeigt. Dieses Hilfsmittels ist besonders hilfreich, weil die ereignisauslösende Anwendung im Hintergrund ausgeführt wird und somit der ABAP-Debugger nicht als Standardwerkzeug zur Verfügung steht. ([Men04], S.75 und S.94) Für den Objekttyp ISUTASK sind verschiedene Ereignisse, die mit Hilfe der Transaktion SWO1 angezeigt werden können, definiert. Die Statusänderung von DA-Aufgaben ist als ISUTASK.TaskStatusChanged hinterlegt. Des Weiteren sind die Attribute des Objekttyps, die beim Auslösen des jeweiligen Ereignisses an den Verbraucher in Form eines Datencontainers übertragen werden, definiert. Für das Ereignis ISUTASK.TaskStatusChanged sind u.a. die ID der angelegten DA-Aufgabe, der Vorgängerstatus, der Folgestatus und der DA-Prozess im Container hinterlegt. Beim Erstellen einer DA-Aufgabe werden generell zwei Ereignisse publiziert, die nach der DA-Aufgabenverarbeitung ausgelöst werden. Das erste Ereignis zeigt an, dass eine DA-Aufgabe den Status IN WORK angenommen hat. Dieses Ereignis ist gleichbedeutend mit dem Anlegen der DA- Aufgabe. Das zweite Ereignis ist das für den Monitor interessante Ereignis. In Abhängigkeit der Ausführung des FuBas wird der Status ERROR oder OK gesetzt. Aufgrund der Tatsache, dass die Ereignisse nach der Erstellung der DA- Aufgabe ausgelöst werden, stehen alle benötigten Informationen der DA-Aufgabe zur Verfügung und können aus den Datenbanktabellen gelesen werden. Weitere 94

95 4 Prototypische Umsetzung Vorteile der Ereignissteuerung sind zum einen, dass alle DA-Aufgaben an einem zentralen Punkt überwacht werden können, und zum anderen, dass der bestehende Anwendungscode nicht mit Instrumentierungscode vermischt wird. Aufgrund der genannten Vorteile ist die Implementierung unter Verwendung der Ereignissteuerung die bevorzugte Vorgehensweise für die Instrumentierung der SAP-Anwendung. Im Folgenden soll die durchgeführte Instrumentierung beschrieben werden: Die Voraussetzung für die Nutzung des Ereignisses ISUTASK.TaskStatusChanged ist das Eintragen eines Verbrauchers. Die Verbindung zwischen Ereignis und Verbraucher wird über eine Typkopplung eingerichtet. Eine Typkopplung bedeutet, dass alle Instanzen eines Objekttyps mit einem Verbraucher gekoppelt werden. Verbraucher von Ereignissen sind FuBas mit fest vorgegebenem Interface. Das Interface beschreibt die Schlüsselfelder und den Datencontainer der auslösenden Objektinstanz. Über die Transaktion SWETYPV gelangt der Entwickler in die Übersicht aller Typkopplungen. Bei Anlegen eines neuen Eintrags werden der Objekttyp, das Ereignis, ein Verbraucher-FuBa und gegebenenfalls ein Check-FuBa gepflegt. Der Verbraucher-FuBa kodiert die Reaktion auf das Ereignis. Der Check-FuBa wirkt als Filter, indem er den Verbraucheraufruf für bestimmte Objektinstanzen verhindert. ([Men04], S.78f.) Für die Anbindung an den Monitor-Prototyp wurde der in Listing 3 abgebildete Check-FuBa implementiert. FUNCTION z_event_check_isutask. Schnittstellendefinition INCLUDE <cntn01>. DATA: l_systemid TYPE string, lf_oldstatus TYPE edextask-dexstatus. l_systemid = sy-sysid. swc_get_element event_container 'OldStatus' lf_oldstatus. CASE l_systemid. Prüfung System-ID WHEN 'TE1'. CASE lf_oldstatus. Prüfung Vorgängerstatus WHEN 'IN_WORK'. EXIT. " Verbraucher-FuBa wird aufgerufen WHEN OTHERS. RAISE kein_ws_aufruf. ENDCASE. WHEN OTHERS. RAISE kein_ws_aufruf. ENDCASE. ENDFUNCTION. Listing 3: Ausschnitt aus Quelltext des Check-FuBas Der dargestellte FuBa lässt den Aufruf des Verbraucher-FuBas nur bei Auslösen des zweiten Ereignisses der DA-Verarbeitung zu, da dieses Ereignis die Statusänderung auf OK oder ERROR publiziert und somit den Startzustand des DA- Ausgangs des Metamodells festlegt. Die Filterung basiert auf der Prüfung des Vorgängerstatus. Zusätzlich wird die ID des SAP-Systems ausgewertet, um den Monitor-Prototyp vorerst nur an das Testsystem der ENSO anzubinden. Der Verbraucher-FuBa enthält die gesamte Anwendungslogik, die zur Anbindung an den Prototyp erforderlich ist. Ein Ausschnitt des Quelltexts des Verbraucher- FuBas ist in Listing 4 dargestellt. 95

96 4 Prototypische Umsetzung FUNCTION z_event_consumer_isutask. Schnittstellendefinition Tabellen und Variablen Deklarationen INCLUDE <cntn01>. swc_get_element event_container 'NewStatus' lf_newstatus. swc_get_element event_container 'Process' lf_proc. Werte des Datencontainers SELECT SINGLE * FROM eideswtmsgdata WHERE dextaskid = objkey. IF eideswtmsgdata-direction = '2'. SELECT SINGLE * FROM edextask WHERE dextaskid = objkey. SELECT SINGLE * FROM edextaskidoc WHERE dextaskid = objkey. IF sy-subrc EQ 0. l_idocnum = edextaskidoc-docnum. ELSE. l_idocnum = 'NONE'. ENDIF. DB-Abfragen für Attribute der DA-Aufgabe l_switchnum = eideswtmsgdata-switchnum. SELECT SINGLE * FROM eideswtdoc WHERE switchnum = l_switchnum. l_category = eideswtmsgdata-category. l_daid = objkey. l_daproz = lf_proc. l_dastatus = lf_newstatus. l_frserv = edextask-dexservprov. l_idocnum = edextaskidoc-docnum. l_kundennummer = eideswtdoc-partner. und alle weiteren Attribute Konvertierung Datentypen proxy_request-category = l_category. proxy_request-daid = l_daid. proxy_request-daproz = l_daproz. proxy_request-dastatus = l_dastatus. proxy_request-frserv = l_frserv. proxy_request-idocnum = l_idocnum. proxy_request-kundennummer = l_kundennummer. und alle weiteren Parameter der Proxy-Methode Befüllen der Proxy-Input-Struktur TRY. CREATE OBJECT: proxy. CALL METHOD proxy->create_daidoc_ausgehend EXPORTING input = proxy_request IMPORTING output = proxy_response. Exceptionhandling Proxy-Init und Web Service Aufruf ENDTRY. ENDIF. ENDFUNCTION. Listing 4: Ausschnitt aus Quelltext des Verbraucher-FuBas 96

97 4 Prototypische Umsetzung Im Verbraucher-FuBa werden aus dem Datencontainer der neue Status und der DA-Prozess gelesen. Anschließend wird die Richtung der DA-Aufgabe geprüft. Hintergrund dieser Prüfung ist, dass das Ereignis ISUTASK.TaskStatusChanged auch für eingehende DA-Aufgaben publiziert wird, da der gleiche Objekttyp verwendet wird. Dieser Aspekt ist durchaus von Vorteil, um den DA-Eingang und damit den vollständigen Nachrichten-Eingang im Monitor abzubilden. Im Rahmen dieser Arbeit wird jedoch zunächst nur die Aktivität des DA-Ausgangs realisiert. Mit Hilfe der ID der DA-Aufgabe werden die restlichen im Metamodell beschriebenen Attribute aus verschiedenen Datenbanktabellen der SAP-Anwendung abgerufen. Unter anderem wird die Nummer des erstellten IDocs aus der Tabelle edextaskidoc selektiert. Wenn kein Eintrag existiert, da Fehler bei der Erstellung der DA-Aufgabe auftraten, wird die IDoc-Nummer auf NONE gesetzt. Anschließend erfolgt die implizite Konvertierung der weiteren Attribute der DA- Aufgabe durch Variablenzuweisung. Der Grund dieser Vorgehensweise ist das die zu befüllende Eingabe-Struktur des Web Service Proxys nur nichtleere Zeichenketten variabler Länge (ABAP-Datentyp: String) unterstützt. Die Attribute der DA-Aufgabe haben die ABAP-Datentypen CHAR und NUMC, die Zeichenketten fester Länge definieren. Beim Testen des Proxys hat sich die direkte Zuweisung der Attribute auf die Eingabe-Struktur bzw. die Zuweisung mit leeren Strings als nicht typsicher erwiesen und der Aufruf des Web Service schlug fehl. Mit den konvertierten Attributen der DA-Aufgabe wird anschließend die im Deklarationsteil definierte Eingabe-Struktur des Proxys gefüllt. Im TRY-Anweisungsblock wird der Web Service Aufruf mittels der Proxy-Klasse proxy und der Methode create_daidoc_ausgehend durchgeführt. Eine Angabe des logischen Ports ist nicht notwendig, da nur ein Port erstellt und als Standard definiert wurde. Durch den Aufruf werden die Attribute der DA-Aufgabe an den Monitor-Prototyp übergeben, der die weitere Verarbeitung übernimmt. In Abhängigkeit des übertragenen DA-Status werden bestimmte Folgeaktionen in der Serveranwendung durchgeführt. Voraussetzung für den Web Service Aufruf ist die im Vorfeld durchzuführende Generierung der Proxyklasse und des zugehörigen logischen Ports. Für die Generierung muss die WSDL-Datei des aufzurufenden Web Services bereitgestellt werden. Die Erstellung der WSDL- Datei und die damit verbundene Java-Implementierung erfolgt im nächsten Teilabschnitt Verarbeitung und Präsentation der übertragenen Daten in der Serveranwendung Dieser Teilabschnitt beschreibt die Erweiterung auf Serverseite des Monitor- Prototyps. Im ersten Teil wird auf die benötigten Veränderungen der Monitor-DB eingegangen. Anschließend folgt eine Beschreibung zur Erstellung und Anpassung der Modellklassen und der Entwicklung des darauf basierenden Web Service. Im letzten Teil wird die Erweiterung der View- und Controller-Klassen und damit die Präsentationsschicht im Prototyp vorgestellt. Folgende Entwicklungswerkzeuge wurden verwendet: pgadmin zur Bearbeitung der PostgreSQL-Datenbank Eclipse IDE for Java EE Developers als Entwicklungsumgebung für die Java-Programmierung lokale Tomcat-Installation zum Testen der Anwendung 97

98 4 Prototypische Umsetzung Erweiterung der Monitor-Datenbank: Die Voraussetzungen für das Abbilden der Aktivität des DA-Ausgangs sind das Speichern der vom Verbraucher-FuBa übertragenen Attribute (Nachrichtendaten) und die Erweiterung der Aktivitäts- und Metadaten in der Monitor-Datenbank. Für die Nachrichtendaten wird die Tabelle daidocausgehend erstellt, die alle Attribute der DA-Aufgaben enthält. Jede ausgehende DA-Aufgabe wird als Eintrag in dieser Tabelle angelegt. Neben den Attributen der DA-Aufgabe wird ein Fremdschlüsselfeld angelegt, das die Referenz auf die ID der Tabelle ausgehende herstellt. Diese Beziehung ist die Voraussetzung für die Darstellung des vollständigen ausgehenden Workflows, da die Aktivität DA-Ausgang zum entsprechenden Nachrichten-Ausgang zugeordnet werden soll. Die Erweiterung der Metadaten erfolgt über das Hinzufügen neuer Einträge in zwei Tabellen. In der Tabelle prozesstyp, die den Aktivitätsnamen und eine zugehörige ID enthält, wird der Eintrag DA-Ausgang angelegt. Die Tabelle prozessbeschreibung speichert die zur jeweiligen Aktivität gehörigen Zustände bzw. Zustandsübergänge. Für die Aktivität des DA-Ausgangs werden die in Abbildung 35 dargestellten Einträge angelegt: Abbildung 35: Ausschnitt aus Tabelle prozessbeschreibung Die Zustände bzw. Zustandsübergänge basieren auf dem im Metamodell beschriebenen Zustandsübergangsgraphen des DA-Ausgangs (siehe Teilabschnitt 3.3.2). Die Spalte prozess ist der Fremdschlüssel, der auf die ID der Aktivität verweist. Die Spalten zustand und folgezustand definieren die Zustandsübergänge. Der Fall der IDoc-Aggregation wurde hier bereits berücksichtigt, um die Erweiterung des Prototyps nach Einrichten dieser Funktionalität im SAP-Backend zu vereinfachen. Die Fehlerfälle des DA-Ausgangs werden durch die Zustände 102 und 103 repräsentiert. Alle Fehlerzustände der Metadaten werden durch Integer-Werte, die größer als 100 sind, definiert. Diese Festlegung wurde getroffen, um die fehlerhaften Aktivitätsinstanzen im Monitor-Menupunkt Prozesse anhand des aktuellen Zustands zu selektieren und anzuzeigen. Die Spalte beschreibung enthält die Zustandsbeschreibung, die im Monitor-Prototyp anzuzeigen ist. In maxtime sind die Maximalwartezeiten für die Zustandsübergänge in den Timeout-Zustand angegeben. Die Spalte folgeprozess definiert die Folgeaktivität des DA-Ausgangs. Ist der Wert identisch mit der Spalte prozess handelt es sich um einen Zustandsübergang innerhalb derselben Aktivitätsinstanz. Bei Nichtübereinstimmung, siehe letzter Eintrag, existiert eine Folgeaktivität. Der Wert 6 ist die Referenz auf die Aktivität des Nachrichten-Ausgangs. Die Erweiterung der Tabelle der Aktivitätsdaten beschränkt sich auf das Hinzufügen einer neuen Fremdschlüsselspalte in der Tabelle der überwachten Aktivitätsinstanzen. Diese Spalte enthält die ID der zugehörigen DA-Aufgabe, die 98

99 4 Prototypische Umsetzung in der Tabelle daidocausgehend gespeichert ist, und stellt somit die Beziehung zwischen den Aktivitätsinstanzen des DA-Ausgangs und den Nachrichtendaten der DA-Aufgaben her. Mit dem Anlegen der Tabelle daidocausgehend und der Erweiterung der Aktivitäts- und Metadaten ist die Voraussetzung geschaffen, um die erzeugten Monitor-Informationen zu sichern. Der Zugriff auf die Monitor-Datenbank und die Übergabe der Daten erfolgt über die Modellklassen. Erweiterung und Anpassung der Modellklassen (Erstellung des Web Service): Der vollständige Quellcode des existierenden Monitor-Prototyps, inklusive der verschiedenen Framework-Bibliotheken, wurde mit Eclipse importiert und zunächst analysiert. Die Java-Klassen sind in die vier Packages dao, services, view und timer unterteilt. Das dao-package enthält die Modellklassen, und services kapselt die Web Service Klassen. In view werden die Controller-Klassen verwaltet, die die Verbindung zu den jeweiligen JSP-Dateien herstellen. Das timer-package enthält lediglich die von der Scheduler-Task auszuführende Timer- Klasse. Im ersten Schritt werden neue Modellklassen für den Zugriff auf die Tabelle daidocausgehend angelegt: DAIDocAusgehend.java: Diese Klasse ist das Datenobjekt, das die Datenbanktabelle daidocausgehend abbildet und somit die DA-Aufgabe repräsentiert. Die Attribute entsprechen den Feldern der Tabelle. Das Mapping der Tabelle und der zugehörigen Spalten auf die Attribute erfolgt mit Hilfe von Hibernate- Annotations 11. In Listing 5 ist ein Ausschnitt aus der Klasse dargestellt, der das Mapping der Tabelle auf die Klasse und das Mapping der Spalte daproz auf das Klassenattribut = = "daidocausgehend_seq", sequencename = = "daidocausgehend", schema = "public", uniqueconstraints = {}) public class DAIDocAusgehend implements java.io.serializable { private String daproz; Mapping der Tabelle und alle weiteren Attribute und = "daproz", unique = false, nullable = true, insertable = true, updatable = true, length = 10) public String getdaproz() { return this.daproz; } public void setdaproz(string daproz) { this.daproz = daproz; } Mapping der Spalte } und alle weiteren getter- und setter-methoden Listing 5: Ausschnitt aus DAIDocAusgehend.java 11 Als Annotation wird in Zusammenhang mit der Programmiersprache Java ein Sprachelement bezeichnet, das die Einbindung von Metadaten in den Quelltext erlaubt. Eingesetzt werden Annotations unter anderem im Java EE-Umfeld, um zusätzliche Beschreibungsdateien zu Klassen automatisch zu erzeugen. ([Hib_2]) 99

100 4 Prototypische Umsetzung Über das Entity wird die gesamte Tabelle daidocausgehend auf die Klasse abgebildet. Als Parameter werden die Caching-Strategie 12, die Tabellensequenz und der Tabellenname übergeben. Das Mapping der einzelnen Spalte funktioniert unter Angabe des Spaltennamen und der verschiedenen Spaltenparameter. Über getter- und setter-methoden kann auf die verschiedenen Attribute zugegriffen werden. Mit Hilfe der Konstruktoren können neue Instanzen erzeugt werden. Die Fremdschlüsselbeziehung zwischen der Tabelle daidocausgehend und ausgehend erfolgt durch eine ManyToOne-Annotation unter Angabe der Fremdschlüsselspalte. Damit wird die m:1-beziehung zwischen den Aktivitäten DA- Ausgang und Nachrichten-Ausgang abgebildet. Somit wird auch an dieser Stelle die zukünftige IDoc-Aggregation bereits berücksichtigt. Um die bidirektionale Relation zwischen den Spalten abzubilden, muss die existierende Java-Klasse Ausgehende.java, die die Einträge der Tabelle ausgehende abbildet, durch Einfügen einer OneToMany-Annotation angepasst werden. Die Fremdschlüsselbeziehung zwischen der Tabelle für die Aktivitätsinstanzen und den DA-Aufgaben wird ebenfalls über diese Art der Annotations realisiert. Durch Anlegen der bidirektionalen Beziehungen kann über die Instanz einer DA-Aufgabe auf die zugehörige Aktivitätsinstanz (DA-Ausgang) und die Nachrichtendaten des zugehörigen Nachrichten-Ausgangs (Ausgehende.java) zugegriffen werden. Umgekehrt können die jeweiligen DA-Aufgaben über die Aktivitätsinstanz des DA-Ausgangs und die Instanz der Klasse Ausgehende.java ermittelt werden. DAIDocAusgehendDAO.java: Diese Klasse kapselt den Datenbank-Zugriff auf die Tabelle daidocausgehend. Die Abfrage der Datenbank-Einträge, die zur Laufzeit auf Instanzen der Klasse DAIDocAusgehend.java abgebildet werden, basiert auf der SQL-ähnlichen Abfragesprache Hibernate Query Language (HQL). Die Web Service und View-Klassen greifen mit Hilfe der DAO-Klasse auf die benötigten Objektinstanzen zu. Die Standard-Datenbank-Abfragen sind das Löschen und Aktualisieren einzelner Objektinstanzen, das Selektieren aller Instanzen und das Speichern einer neuen Instanz. Weitere Abfragen, die verschiedene Bedingungen abprüfen, können hinzugefügt werden. Die im Prototyp realisierten Suchoptionen basieren auf diesen zusätzlichen Abfragen. Eine Abfrage, die für die weitere Verarbeitung in der zu implementierenden Web Service Klasse benötigt wird, ist in Listing 6 abgebildet: public List<DAIDocAusgehend> findbyidocsystemmandant(long idoc, String system, String mandant) { try { String querystring = "select model from DAIDocAusgehend model WHERE idoc =? and system =? and mandt =?"; Object[] params = {idoc, system, mandant}; HibernateTemplate ht = gethibernatetemplate(); List<DAIDocAusgehend> ret = ht.find(querystring, params); } return ret; } catch (RuntimeException re) { throw re; } HQL - Abfrage Listing 6: Methode findbyidocsystemmandant 12 Read-Write: Sichert die Synchronität zwischen Cache und Datenbank bis zu einem read committed - Isolationslevel. D.h. Dirty Reads werden verhindert. Sollte vorwiegend eingesetzt werden, wenn die Daten nur selten geändert werden. 100

101 4 Prototypische Umsetzung Mit Hilfe der Methode werden in der zu entwickelnden Service-Klasse alle DA- Aufgaben zu einer bestimmten Instanz der Klasse Ausgehende.java selektiert. In der Variable querystring wird die HQL-Abfrage formuliert. Das Array params enthält die Parameter der Abfrage. Die Parameter, die alle DA-Aufgaben zu einem Eintrag in der Tabelle ausgehende eindeutig beschreiben, sind die Nummer des versendeten IDocs, die ID und der Mandant des sendenden SAP-Systems (siehe DA-Ausgang des Metamodells, S.72). Mit der Methode gethibernatetemplate() wird auf die Funktionalitäten des Hibernate-Frameworks zugegriffen. Die Voraussetzungen für den Aufruf dieser Methode sind: 1. Die DAO-Klasse muss von der Klasse HibernateDAOSupport.java, die von Spring bereitgestellt wird und u.a. für das Sessionhandling verantwortlich ist, erben. 2. Hibernate muss in Spring durch Definition einer SessionFactoryBean eingebunden werden. Diese Bean enthält die Informationen zur Datenquelle (PostgreSQL-Datenbank des Monitors), die Liste aller Datenobjektklassen und weitere Hibernate-Konfigurationsparameter. Die Definition der Bean erfolgt in der Spring-Konfigurationsdatei applicationcontext.xml, die auf der dieser Arbeit beiligenden CD enthalten ist. Anschließend erfolgt das Absetzen der Datenbankabfrage durch die Methode find unter Angabe der HQL-query und der Selektionsparameter. Aufgrund der Tatsache, dass noch keine IDoc-Aggregation implementiert ist und somit jede ausgehende DA-Aufgabe im fehlerfreien Fall genau einen Eintrag in der Tabelle ausgehende erzeugt, liefert diese Abfrage nur eine DA-Aufgabe. Die Verwendung dieser Methode wird bei der Beschreibung der Web Service Klasse erklärt. Mit der Erstellung der beiden Modellklassen für die DA-Aufgaben sowie der Erweiterung der existierenden Modellklassen sind die Voraussetzungen geschaffen die Web Service Klasse zu implementieren. DAIDocAusgehendServiceImpl.java: Mit Hilfe dieser Klasse wird der Web Service DAIDocAusgehendService implementiert. Die Attribute der DA-Aufgabe, die aus der SAP-Anwendung an den Monitor übertragen werden, werden durch den Service verarbeitet. Die Aufgaben des Service sind zum einen das Anlegen eines Eintrages in die Tabelle daidocausgehend für die erstellte DA-Aufgabe (Nachrichtendaten) und zum anderen die Erzeugung einer zugehörigen Aktivitätsinstanz des DA-Ausgangs (Aktivitätsdaten). Die Umsetzung erfolgt mit der Methode createdaidocausgehend(). Auf ABAP-Seite wurde diese Methode als create_daidoc_ausgehend im Web Service Proxy generiert und im Verbraucher- FuBa aufgerufen (siehe Listing 4, S.95). Ein Auszug der Methode createdaidocausgehend() ist in Listing 7 abgebildet: Im ersten Schritt wird eine neue Instanz der Klasse DAIDocAusgehend.java instanziiert und anschließend mit den übergebenen Attributen gefüllt. Im try- Block wird die erstellte Instanz über die save-methode des zugehörigen DAOs in die Datenbanktabelle geschrieben. Das Anlegen der Aktivitätsinstanz erfolgt per Zugriff auf die Methode createprozess() des Prozessservice. Es wird die Nummer der Aktivität des DA-Ausgangs und die Referenz auf die angelegte DA-Aufgabe als Parameter übergeben. Die Aktivitätsinstanz wird dabei mit dem Initialzustand Vorgangsspezifische Verbuchung angelegt. Das Setzen des Folgezustands erfolgt in Abhängigkeit des übertragenen DA-Status. War das Anlegen der DA-Aufgabe erfolgreich, wird der Folgezustand 2 über den Prozessschrittservice 101

102 4 Prototypische Umsetzung zur erstellten Aktivitätsinstanz erstellt. Im Fehlerfall wird der Zustand 102 angelegt. Nach Aufruf der Methode createdaidocausgehend() sind die Nachrichtendaten der DA-Aufgabe gespeichert und eine Aktivitätsinstanz wurde erstellt. public Integer createdaidocausgehend(string daproz, String dastatus, String frserv, String kundennummer, und alle weiteren Parameter ) { DAIDocAusgehend s = new DAIDocAusgehend(); s.setdaproz(daproz); s.setdastatus(dastatus); s.setfrserv(frserv); s.setkundennummer(kundennummer); und alle weiteren setter Anlegen und Befüllen der DA-Aufgabe try { daidocausgehenddao.save(s); short m = 8; Anlegen des DB-Eintrags ProzessReturn pr = prozessservice.createprozess(m, null, null, null, null, null, s.getid(), werk); Anlegen des DA-Ausgangs und Setzen des Folgezustands } if (dastatus.equals("ok")){ prozessschrittservice.createprozessschritt(pr.getid(), 2, "", null, null, null, null, s.getid()); } else { prozessschrittservice.createprozessschritt(pr.getid(), 102, "", null, null, null, null, s.getid()); } } catch Exceptionhandling Listing 7: Auszug aus Methode createdaidocausgehend Im fehlerfreien Fall folgt im Workflow auf die angelegte DA-Aufgabe das Anlegen der Nachrichtendaten zur Aktivität Nachrichten-Ausgang mit Hilfe einer Routing- Regel, die den AusgehendeService aufruft. Für die Erkennung von RFC- Versendefehlern ist es notwendig, dass bei Aufruf des AusgehendeService eine Rückmeldung an die zugehörige Aktivitätsinstanz des DA-Ausgangs erfolgt. Außerdem muss die Verknüpfung zu den Nachrichtendaten der DA-Aufgabe durch Füllen der Fremdschlüsselspalte erfolgen. Wenn die Rückmeldung nicht erfolgt, da ein RFC-Versendefehler aufgetreten ist, erzeugt die Timer-Klasse nach Ablauf der Maximalwartezeit den Zustand 103 für den zugehörigen DA-Ausgang. Die Rückmeldung wird durch Ausführen der Methode updatedaidocausgehend() unmittelbar nach Anlegen der Nachrichtendaten in der AusgehendeService-Klasse durchgeführt. Die Methode ist in der DAIDocAusgehendServiceImpl.java implementiert (siehe Listing 8, S. 103). Mit Hilfe der ID des angelegten Ausgehende-Eintrags und der ausgehendedao- Klasse wird zunächst die Instanz aus der Tabelle ausgehende geladen. Anschließend kommt die beschriebene Methode findbyidocsystemmandant der DAIDocAusgehendDAO.java zum Einsatz, um alle zugehörigen DA-Aufgaben aus der Tabelle daidocausgehend zu ermitteln. In der for-anweisung wird für jede dieser DA-Aufgaben die Referenz zum Ausgehende-Eintrag hinzugefügt und der Zustand 5 der entsprechenden Instanz des DA-Ausgangs erstellt. Mit Eintragen dieses Zustands ist die Aktivität des DA-Ausgangs erfolgreich abgeschlossen und die ausgehende Workflowinstanz wird anschließend durch die Aktivität des Nachrichten-Ausgangs im Monitor überwacht. 102

103 4 Prototypische Umsetzung public Integer updatedaidocausgehend(integer ausgehendeid, Long idoc, String system, String mandant) { Ausgehende ausgehende = ausgehendedao.findbyid(ausgehendeid); List<DAIDocAusgehend> dl = daidocausgehenddao.findbyidocsystemmandant(idoc, system, mandant); for (DAIDocAusgehend da : dl) { da.setausgehende(ausgehende); daidocausgehenddao.update(da); Set<Prozess> ps = da.getprozesse(); for (Prozess prozess : ps) { prozessschrittservice.createprozessschritt(prozess.getid(), 5, "", null, null, null, null, da.getid()); } } } return 0; Listing 8: Methode updatedaidocausgehend Die Abhängigkeiten der einzelnen Web Service Klassen zu den verschiedenen DAO- und weiteren Service-Klassen werden in der Konfigurationsdatei applicationcontext.xml definiert. Jede Service-Klasse wird als EntityBean angelegt und die Beschreibung ihrer Abhängigkeiten erfolgt mittels property-tags. Innerhalb der Service-Klasse müssen die abhängigen Objekte nicht selbst erzeugt werden, sondern bekommen diese durch Setter-Methoden injiziert (Setter-Injection siehe [Spr_5], S.41). Nachdem die Modell- und Serviceklassen implementiert sind und die Konfigurationsdatei um diese Objekte erweitert wurde, kann der Web Service im Monitor- Prototyp eingesetzt werden. Eine Voraussetzung für die Proxy-Generierung im SAP-System ist das Erstellen der zugehörigen WSDL-Datei. Die Datei wird automatisch beim Deployment des Service in die Axis2-Engine generiert. Axis2 benötigt für das Deployment ein spezielles Archivformat, das die Web Service Klasse und die Datei services.xml enthält. Die XML-Datei beschreibt den Servicenamen, die Service-Klasse, die ID der zugehörigen EntityBean und die anzulegenden Web Service Operationen. Das Axis-Archiv ist im Grunde eine normale JAR-Datei mit der XML-Datei im META-INF-Ordner. Für die automatisierte Generierung des Archivs wurde ein Ant-Skript geschrieben 13. Besonders während der Implementierung der Service-Klasse beschleunigte dieses Skript den Testprozess. Nach dem Deployment des Web Service kann auf die generierte WSDL-Datei über den Menupunkt Administration des Monitor-Prototyps zugegriffen werden. Mit der Fertigstellung des Web Service und der Bereitstellung der WSDL-Datei ist die Verarbeitung der Monitor-Daten aus dem SAP-System abgeschlossen. Der vollständige Quellcode der neu erstellten Serviceklasse und das Ant-Skript sind im Anhang unter abgebildet. Für die neu erstellten Modellklassen, alle weiteren Klassen des Monitor-Prototyps, die WSDL-Datei des DAIDocAusgehend- Service und die vollständige Konfigurationsdatei applicationcontext.xml wird auf die dieser Arbeit beiliegenden CD verwiesen. 13 Ant ist ein java-basiertes Werkzeug zur automatisierten Erstellung von Programmen und Programmarchiven. Über eine XML-Datei können in Java implementierte Tasks, beispielsweise Kopieren von Dateien und Erstellen von Ordnern, beliebig kombiniert werden ([Ant]). 103

104 4 Prototypische Umsetzung Um die verarbeiteten Informationen im Prototyp anzuzeigen, ist die im Weiteren beschriebene Erweiterung der Präsentationsschicht notwendig. Erweiterung der View-Klassen und JSPs: Der erstellte DAIDocAusgehendService nutzt die bereits vorhandene Implementierung des ProzessService, um die Aktivitätsinstanzen anzulegen. Dadurch werden die erstellten Instanzen des DA-Ausgangs ohne zusätzliche Implementierung im Menupunkt Prozesse angezeigt. Für die Anzeige der Nachrichtendaten der DA-Aufgabe und des Links auf die Aktivitätsinstanz des jeweiligen DA- Ausgangs im DetailView wurden die zugehörige Controller-Klasse und die entsprechende JSP-Datei angepasst. Durch die Anpassung kann eine ausgehende Workflowinstanz vollständig, d.h. inklusive der Nachrichtendaten der DA-Aufgabe und der Daten des Nachrichten-Ausgangs, angezeigt werden. Zusätzlich wurde ein neuer Menupunkt mit der Bezeichnung DA(ausgehend) implementiert, der alle erstellten DA-Aufgaben in Tabellenform anzeigt. Die angelegte Controller-Klasse greift über das DAIDocAusgehendDAO auf alle Einträge der Tabelle daidocausgehend zu. Die ID des jeweiligen Tabelleneintrags ist wie bei den Menupunkten Notes, Transconnect, SAP und Ausgehende mit dem DetailView verlinkt. Des Weiteren wurde im Menupunkt Übersicht ein SubView angelegt, der die Suche nach DA-Aufgaben nach bestimmten Suchkriterien realisiert (Abbildung siehe Anhang 6.3.4). Für jede dieser Suchoptionen existiert eine Methode im DAIDocAusgehendDAO, die die jeweilige Datenbank-Abfrage mittels HQL implementiert. Die Controller-Klasse des SubView greift bei Starten der Suche auf diese Methoden zu. Die Erweiterung der Suchmaske um weitere Suchkriterien ist problemlos realisierbar. Die wichtigste Suchoption ist die Suche nach der Wechselbelegnummer, die alle DA-Aufgaben eines Lieferantenwechselprozesses ausgibt. Über dieses Kriterium soll die prozessübergreifende Darstellung im Prototyp realisiert werden. Dabei ist zu berücksichtigen, dass die eingehenden DA-Aufgaben und die Aktivität des DA- Eingangs im derzeitigen Zustand noch nicht im Monitor angelegt werden. Damit sind momentan nur alle ausgehenden DA-Aufgaben eines Wechselbelegs zu sehen. Außerdem werden die selektierten DA-Aufgaben nur in einer Tabelle aufgelistet. Für den produktiven Einsatz sollte eine geeignete Darstellungsform für die graphische Benutzeroberfläche implementiert werden. Die neu erstellten Controller-Klassen und die entsprechenden JSPs sind im Anhang unter abgebildet. Für alle weiteren Controller-Klassen, JSPs und CSS- Dateien wird auf die beiliegende CD verwiesen. Mit der Implementierung der Controller-Klassen und der zugehörigen JSPs ist die Erweiterung des Prototyps abgeschlossen und die Voraussetzung geschaffen die erzeugten Monitor-Daten anzuzeigen. Um die korrekte Funktionsweise der Überwachung des DA-Ausgangs und der DA-Aufgaben zu testen, wurden verschiedene Testszenarien aufgestellt, die im folgenden Teilabschnitt beschrieben werden. 104

105 4 Prototypische Umsetzung Validierung der Prototyp-Erweiterung Für die Validierung der durchgeführten Prototyp-Erweiterung werden drei Szenarien definiert, die in Tabelle 4 beschrieben sind. Szenario 1: Keine Fehler Beschreibung Der Wechselbeleg zur Kündigung erzeugt die DA-Aufgabe der Kündigungsantwort mit dem Status OK. Das zugehörige IDoc wird angelegt und erfolgreich versendet. Die Transconnect-Middleware empfängt das IDoc und beginnt mit der weiteren Verarbeitung der IDoc-XML-Nachricht. 2: Fehler bei DA-Verarbeitung Aus dem Wechselbeleg zur Kündigung wird die DA-Aufgabe der Kündigungsantwort mit dem Status ERROR erstellt. Es wird kein IDoc erzeugt und versendet. 3: RFC-Versendefehler Der Wechselbeleg generiert die DA-Aufgabe mit dem Status OK. Das zugehörige IDoc wird angelegt, aber nicht versendet. Tabelle 4: Testszenarien In allen drei Szenarien soll der Monitor-Prototyp die Nachrichtendaten der DA- Aufgabe anzeigen und die Aktivität des DA-Ausgangs überwachen. Fehler im Workflow, siehe Szenario 2 und 3, sollen im Monitor erkannt und hervorgehoben werden. Grundlage der Validierung ist der auf S.91f. beschriebene Anlegevorgang einer eingehenden Kündigung. Die Kündigungsantwort wird als DA-Aufgabe erzeugt und schließlich als UTILMD-Nachricht in einer versendet. Die Testszenarien konzentrieren sich auf die neu angelegte Aktivität des DA-Ausgangs. Die Ergebnisse der Szenarien werden im Folgenden beschrieben. Szenario 1: Das Anlegen der DA-Aufgabe führt zum Auslösen von zwei Ereignissen des Typs ISUTASK.TaskStatusChanged, die mittels Ereignis-Trace in der SAP-Anwendung angezeigt werden können. Das erste Ereignis löst keine Folgeaktion aus, da die Bedingung im Check-FuBa nicht erfüllt ist. Das zweite Ereignis, das den Status der DA-Aufgabe von IN_WORK auf OK meldet, führt zum Aufruf des implementierten Verbraucher-FuBas. Dieser FuBa ruft die Service- Operation createdaidocausgehend des DAIDocAusgehendService des Monitors auf und überträgt die Parameter der DA-Aufgabe in der Request-SOAP-Nachricht. Die Web-Applikation des Monitors speichert einen neuen Eintrag in der Tabelle daidocausgehend und legt eine neue Aktivitätsinstanz DA-Ausgang an. Anschließend wird der DA-Status ausgewertet und der Zustand DA angelegt (IDoc erzeugt) für die erstellte Aktivitätsinstanz erstellt. Wenn keine Verarbeitungsfehler in der Service-Operation auftreten, wird der Return-Code 0 in der SOAP- Response-Nachricht an den aufrufenden Verbraucher-FuBa zurückgemeldet. Der Endzustand IDoc von Middleware empfangen wird im Folgenden durch den Aufruf des AusgehendeService in der ersten Routing-Regel der Transconnect- Middleware geschrieben. Ergebnis: Der Monitor zeigt unmittelbar nach Erstellen der DA-Aufgabe die Nachrichtendaten im Menupunkt DA(ausgehend) an. Durch Klicken auf die ID der 105

106 4 Prototypische Umsetzung DA-Aufgabe gelangt man in den DetailView, in dem die Aktivitätsinstanz des DA- Ausgangs verlinkt ist. Falls die zugehörige Aktivität des Nachrichten-Ausgangs bereits erzeugt wurde, sind die Nachrichtendaten und der Link auf die Aktivitätsinstanz in dieser Ansicht ebenfalls enthalten (Abbildung 36). Abbildung 36: DetailView für angelegte DA-Aufgabe Im AktivitätsView können die Statussätze der Aktivitätsinstanz nachvollzogen werden (Abbildung 37). Abbildung 37: AktivitätsView für angelegten DA-Ausgang Das Erstellen der DA-Aufgabe und der Empfang des IDocs durch die Middleware wurden erwartungsgemäß protokolliert. Eine weitere Überwachungsmöglichkeit ist die Auswahl der Aktivität des DA-Ausgangs im Menupunkt Prozesse. Die neu angelegte Instanz wird angezeigt und bei Bedarf kann in den DetailView gewechselt werden. Szenario 2: Um einen Verarbeitungsfehler zu simulieren, wurde der initiale FuBa, der die DA-Aufgabe und das IDoc erstellt, in der Form umprogrammiert, dass verschiedene Exceptionhandler ausgelöst werden. Auf diese Art konnte beispielsweise das Fehlen von Stammdaten bzw. Fehler in der IDoc- Basistypkonfiguration simuliert werden. In der SAP-Anwendung zeigt das zweite Ereignis des Typs ISUTASK.TaskStatusChanged die Änderung des DA-Status von IN_WORK auf ERROR an. Das Ereignis löst den Aufruf des Verbraucher-FuBas aus, der wiederum den DAIDocAusgehendService aufruft. Nach Prüfung des DA- Status wird der Zustand DA fehlerhaft angelegt (IDoc nicht erzeugt) der neu erstellten Aktivitätsinstanz des DA-Ausgangs hinzugefügt. Der AusgehendeService wird nicht aufgerufen, da kein IDoc erzeugt und an die Middleware versendet wird. Ergebnis: Der Verarbeitungsfehler wird eventgesteuert erkannt und im Monitor in zwei Perspektiven angezeigt. Der DA-Ausgang ist im ProzessView in den fehlerhaften Aktivitätsinstanzen aufgelistet. Des Weiteren wird die fehlerhafte DA-Aufgabe im Menupunkt DA(ausgehend) angezeigt und rot markiert. Bei Wechsel in den DetailView sind nur die Nachrichtendaten der DA-Aufgabe und 106

107 4 Prototypische Umsetzung der rot gefärbte Link zur Aktivitätsinstanz des DA-Ausgangs abgebildet. Der zugehörige AktivitätsView zeigt den Aktivitätsschritt an, in dem der Fehler festgestellt wurde. Damit wird dem Bearbeiter mitgeteilt, an welcher Stelle im Workflow ein Fehler aufgetreten ist. Szenario 3: Für die Simulation eines RFC-Versendefehlers wurde die Monitoring- Routingregel, die den AusgehendeService aufruft, deaktiviert. In diesem Fall wird der Endzustand des DA-Ausgangs nicht geschrieben und kein Nachrichten- Ausgang angelegt. Der Monitor sollte nach Ablauf der definierten Maximalwartezeit einen Timeout-Fehler anzeigen. Mit Hilfe dieses Szenarios wird die Funktionsweise der beschriebenen Timerklasse geprüft. Ergebnis: Der Timer wird nach Ablauf der Maximalwartezeit ausgelöst und legt den Zustand Timeout (IDoc-Übertragung) für die erstellte Aktivitätsinstanz des DA-Ausgangs an. Das Auslösen der Timer-Klasse wird im Menupunkt Administration in der Log-Datei der Anwendung protokolliert. Äquivalent zu Szenario 2 wird der Fehler über den ProzessView und im Menupunkt DA(ausgehend) angezeigt. Fazit: Die Erweiterung des Prototyps auf Basis der Ereignistypkopplungen im SAP konnte erfolgreich implementiert werden. In der bestehenden Webanwendung wurden die Aktivität des DA-Ausgangs und die damit verbundenen Attribute der DA- Aufgabe in der Monitor-Datenbank bzw. den Modellklassen abgebildet. Der zugehörige Web Service, der die Ereignisse und Attribute verarbeitet, konnte erstellt werden. Für die Anzeige im Browser wurde der DA-Ausgang in die bestehenden Aktivitätsdaten integriert und ein zusätzlicher Menupunkt bzw. eine Suchmaske mit ausgewählten Suchattributen für die Nachrichtendaten der DA-Aufgabe angelegt. Abschließend wurde die Funktionalität der durchgeführten Implementierung mit drei Szenarien getestet. Die Testszenarien ergaben, dass die auf dem aufgestellten Metamodell basierende Nachrichtenüberwachung des DA-Ausgangs und die Fehlererkennung korrekt funktionieren. Die von den Benutzergruppen benötigten fachlichen Informationen werden gesammelt und angezeigt. Mit der Möglichkeit alle DA-Aufgaben eines Wechselbelegs zu suchen ist die Grundlage für die prozessübergreifende Darstellung geschaffen. 107

108 5 Zusammenfassung und Ausblick 5 Zusammenfassung und Ausblick Zu Beginn dieser Arbeit wurden verschiedene Einsatzgebiete von Monitoring in verteilten Systemen vorgestellt und bestehende Ansätze analysiert, inwiefern diese für die Erstellung des Monitoring-Konzeptes in der ENSO wieder verwendet werden können. Besonders auf Business Activity Monitoring (BAM), ein noch junges und wachsendes Anwendunsgebiet des Geschäftsprozess-Monitorings, wurde näher eingegangen und verschiedene Lösungen genannt. Das von [Rei08] erstellte Vorgehensmodell zur Einführung einer BAM-Lösung in Unternehmen wurde beschrieben und stellte den Leitfaden für die Erstellung des Monitor- Konzeptes und den daraus resultierenden Prototyp dar. Nach einer allgemeinen Beschreibung der Geschäftsprozesse des Energiemarktes wurde der Lieferantenwechsel als Pilotprozess ausgewählt und genauer vorgestellt. Weiterhin wurden das für die Prozesse verwendete Datenaustauschformat EDIFACT und die Systemlandschaft der ENSO, die zur automatisierten Umsetzung der Geschäftsprozesse eingesetzt wird, beschrieben. In einer anschließenden Analyse konnten die Schwachstellen der aktuell eingesetzten Monitoring-Tools zur Unterstützung der verschiedenen Mitarbeitergruppen bei der Fehlersuche ermittelt werden. Das Ergebnis dieser Analyse war die Erkenntnis, dass eine einheitliche prozessorientierte Lösung benötigt wird, um die Mitarbeiter bei der Prozessbetreuung optimal zu unterstützen. Als Voraussetzung für die Erstellung dieser Lösung wurden die verschiedenen Fehler in den Workflows der Anwendung kategorisiert und diesbezüglich Regeln aufgestellt, wie diese in einem Monitor anzuzeigen sind. Hier stellte sich heraus, dass die Fehler aufgrund der Komplexität der Prozesse und der Systemlandschaft vielfältig sind, d.h. nachrichtenbedingt als auch systemseitig verursacht werden. Im Anschluss wurde ein Anforderungskatalog erstellt, der die benötigten funktionalen und qualitativen Aspekte des Monitors und zu beachtende Randbedingungen enthält. Auf Basis dieses Katalogs wurde ein Monitoring-Konzept entwickelt, das insbesondere auf die umfassende Überwachung des EDIFACT-Nachrichtenverkehrs und die automatische Fehlererkennung ausgerichtet ist. Die im Anforderungskatalog aufgestellten Bearbeitungsfunktionen sowie die Attribute der zu überwachenden Workflows wurden in einem Metamodell integriert. Dieses Modell teilt die Workflows in Aktivitäten ein, die jeweils durch ein Zustandsübergangsgraphen genauer beschrieben werden. Die Einteilung basiert auf dem Datenmodell und den Verarbeitungsschritten der Workflows. Innerhalb dieser Graphen werden die Events spezifiziert, die durch den Monitor zu überwachen sind. Das Konzept schließt mit der Infrastrukturplanung für die zu entwickelnde Anwendung ab. Ein wichtiger Punkt der Infrastruktur ist die Festlegung auf Web Services als Technologie zur Erzeugung der Monitordaten in der Workflow Anwendung der ENSO. Hintergrund dieser Entscheidung ist die vorhandene Unterstützung in den Systemen der überwachten Anwendung bzw. der mittelfristig eingesetzten Middleware SAP PI und der derzeitige Einsatz von Web Services in einem existierenden Prototyp. Dieser Prototyp ist eine Java EE- Webanwendung, die bereits einen Teil der Workflows überwachen kann. Im praktischen Teil dieser Arbeit wurde der bestehende Prototyp analysiert und die Festlegung getroffen diesen weiterzuentwickeln, da bereits wesentliche Bestandteile des Monitoring-Konzeptes enthalten sind und wieder verwendet werden können. Die Analyse ergab, dass der Prototyp die Workflows im SAP- Backend, das die betriebswirtschaftlichen Daten der Geschäftsprozesse verwaltet, nicht überwacht. Besonders diese Workflow enthalten die für die Mitarbeiter 108

109 5 Zusammenfassung und Ausblick relevanten Attribute bei der Nachrichtenüberwachung und Fehlersuche. Aus diesem Grund wurde die Anbindung des Prototyps an das SAP-System im Rahmen dieser Arbeit realisiert. Die SAP-Anwendung wurde analysiert, inwiefern die Erzeugung der Monitor-Daten am geeignetsten implementiert werden könnte. Nach einem ersten Versuch den Monitorcode direkt in den Anwendungscode einzubetten, wurde die Möglichkeit der Ereignistypkopplung entdeckt und als effizienter eingestuft. Mittels dieser Technologie ist die zentrale Anbindung an die SAP-Workflows möglich und der eigentliche Anwendungscode wird nicht mit Monitorquellcode vermischt. Die Erzeugung der Monitor-Daten erfolgt mit Hilfe eines Web Service Aufrufs, der den Status der SAP-Workflows und die Daten der EDIFACT-Nachrichten an den Prototyp überträgt. Der Prototyp speichert unter Nutzung verschiedener Java-Frameworks die Nachrichtendaten in einer PostgreSQL-Datenbank und legt basierend auf dem Metamodell die Aktivitäten der Workflows an. Für die Anzeige der gesammelten Daten wurden auf Basis von Servlet- und JSP-Technologie die bestehenden Views des Prototyps angepasst, ein neuer Menupunkt für die SAP-Daten erstellt und eine darauf zugeschnittene Suchmaske, mit der u.a. alle Nachrichten eines Wechselprozesses gesucht werden können, angelegt. Die Nachrichtenüberwachung und Fehlererkennung der durchgeführten Erweiterung des Prototyps wurde mit Hilfe von drei Testszenarien erfolgreich validiert. Durch die Erweiterung des Prototyps wurde die Grundlage geschaffen, den Geschäftsprozess des Lieferantenwechsels in der SAP-Anwendung der Enso zu überwachen. Dennoch bestehen noch offene Punkte, die vor dem produktiven Einsatz des Prototyps geklärt werden müssen. Die durchgeführte Implementierung im Rahmen dieser Arbeit bezog sich nur auf den ausgehenden Workflow und damit auf die Überwachung der Aktivität des Datenaustausch-Ausgangs. Für die vollständige Prozessüberwachung und damit abschließenden Realisierung einer BAM-Lösung ist es notwendig den eingehenden SAP-Workflow an den Prototyp anzubinden. Die zu überwachenden Ereignisse und Attribute des eingehenden SAP-Workflows sind im Meta-Modell beschrieben. Die Implementierung könnte ebenfalls auf Basis der Ereignistypkopplungen erfolgen. Des Weiteren besteht Optimierungsbedarf bei der Gestaltung der Web-Oberfläche, um die prozessorientierte Sicht zu verbessern. Weiterhin ist die Durchführung von umfassenden Performancetests notwendig, um den sinnvollen Einsatz in der Prozessbetreuung zu gewährleisten. Ein Ausfall des Monitor-Prototyps bzw. einer seiner Komponenten würde dazu führen, dass alle Workflowinstanzen in der Zeit des Ausfalls nicht überwacht werden und auch im Nachhinein nicht neu eingespielt werden könnten. Um die Wahrscheinlichkeit des Eintretens dieser Situation möglichst gering zu halten, ist auch die Überwachung der Monitor-Anwendung und der zugrundeliegenden Hardware notwendig. Der Ausfall des Monitor-Datenbankservers könnte beispielsweise durch Backupserver, die im Problemfall alternativ verwendet und nach Problembehebung synchronisert werden, kompensiert werden. Ein weiterer wichtiger Punkt ist die Implementierung der Zugriffskontrolle und des Berechtigungskonzeptes sowie die Einführung von Maßnahmen zur Sicherung der Integrität der Monitor-Daten, die in der Arbeit angesprochen wurden. Der Prototyp im derzeitigen Zustand ist ein nicht-steuernder, passiver Monitor. In der Arbeit wurden Möglichkeiten genannt, auf Bearbeitungsfunktionen und Dokumente der verschiedenen Systeme der Workflow Anwendung zuzugreifen. Außerdem wäre eine Alarmierungsfunktion im Fehlerfall eine durchaus sinnvolle Erweiterung. 109

110 5 Zusammenfassung und Ausblick Die Fortführung dieser Arbeit könnte darin bestehen sich den genannten offenen Punkten anzunehmen und den Prototyp zu einer umfassenden BAM-Lösung weiterzuentwickeln. Außerdem wurde im Laufe der Arbeit die strategische Entscheidung getroffen SAP PI als zentrale Middleware-Plattform für die Unternehmensprozesse einzuführen. Aufgrund der gewählten Web Service Technologie zur Erzeugung der Monitor-Daten ist die Wiederverwendbarkeit des Prototyps gesichert. Die Anbindung des Monitors an die neue Middleware stellt damit eine weitere Herausforderung dar. Außerdem könnte die Prozessüberwachung auf andere Unternehmensprozesse ausgedehnt werden. Auch hier bietet die Web Service Technologie viele Vorteile, da sie den Anschluss weiterer IT-Systeme erleichtert. Es existieren somit interessante Ansatzpunkte und Möglichkeiten für weiterführende Untersuchungen und Arbeiten bezüglich der Weiterentwicklung der Monitor-Anwendung. 110

111 6 Anhang 6 Anhang 6.1 Ergänzungen zu den Grundlagen Infrastruktur kommunikationsorientierter Middleware Die Infrastruktur einer kommunikationsorientierten Middleware stellt einer verteilten Anwendung ein Kommunikationsprotokoll, Techniken zur Datentransformation und Fehlerbehandlungsmechanismen zur Verfügung. Eine Datentransformation ist notwendig, um die Heterogenität bezüglich Hardware, Betriebssystem und der verwendeten Programmiersprache zwischen den Komponenten zu überwinden und somit eine einheitlichen Darstellung der Daten innerhalb der verteilten Anwendung zu schaffen. Zur Lösung dieser Aufgabe wird meist ein übergeordnetes Datenformat durch die Middleware verwendet. Dieses kann middleware-spezifisch sein, beispielsweise die CDR (Common Data Representation) der CORBA-Middleware, oder middleware-unabhängig, wie das heute weitestgehend verwendete XML-Format ([Ham05], S.36). Die Fehlerbehandlung bezieht sich auf die korrekte und zuverlässige Übertragung von Informationen zwischen den einzelnen Komponenten. Typischerweise können die Informationen während der Übertragung verfälscht werden oder es fallen ganze Komponenten aus. Mit Hilfe von Prüfsummenchecks, Bestätigungsnachrichten und Neusenden von Nachrichten werden die Fehler durch die Middleware und das verteilte System automatisch behandelt Erweiterungen nachrichtenorientierter Middleware Eine anwendungsorientierte Middleware erweitert die genannten Funktionalitäten einer kommunikationsorientierten Middleware um eine Laufzeitumgebung, weitere Dienste und ein Komponentenmodell. Die Laufzeitumgebung setzt direkt auf den Betriebssystemfunktionalitäten der Knoten des verteilten Systems auf und erweitert diese, um die Anforderungen verteilter Anwendungen erfüllen zu können. [Ham05], S.46ff. beschreiben verschiedene Aufgaben der erweiterten Laufzeitumgebung. Unter anderem werden die Ressourcenverwaltung zur Verbesserung der Anwendungsperformanz, die Erhöhung der Verfügbarkeit durch Replikation von Komponenten und Sicherheitskonzepte wie Datenverschlüsselung und Signaturen beschrieben. Weitere Dienste, wie beispielsweise ein Namensdienst für die Veröffentlichung von verfügbaren Ressourcen und eine Transaktionsverwaltung zur Erhaltung der Datenkonsistenz, werden implizit über die Laufzeitumgebung angeboten. Mit Hilfe des Komponentenmodells der Middleware kann die komponentenbasierte Entwicklung von verteilten Anwendungen durchgeführt werden. Die Entwicklung der Komponenten als Erweiterung des objektorientierten Programmierparadigma wird unter Verwendung von integrierten Softwarewerkzeugen im gesamten Software-Lebenszyklus unterstützt. Des Weiteren wird eine Komponentenlaufzeitumgebung bereitgestellt, die die aktiven Komponenten von der Initialisierung bis zur Löschung verwaltet. Im Wesentlichen existieren zwei Standards für Komponentenmodelle: das Enterprise JavaBeans-Modell und das COM- Modell der.net-plattform ([ScSp07], S.210). 111

112 6 Anhang Aufbau eines WSDL-Dokuments (Version 1.1) <definitions> <types> </types> <message > </message> <porttype> </porttype> <binding> </binding > </definitions> <service > </service > Abbildung 38: Aufbau eines WSDL-Dokuments Ein WSDL-Dokument in der Version 1.1 besteht aus sechs Hauptelementen, die nachfolgend beschrieben werden (vgl. [Ham05], S.116f. und [Bra08_1]): <definitions> ist das Wurzelelement eines WSDL-Dokuments. In diesem Teil werden Namen und Namensräume des Services und des verwendeten Standards definiert. <types> beschreibt alle Datentypen und Typdefinitionen, die für den Service- Aufruf benötigt werden. <message> legt fest, welche Parameter für die eingehenden und die ausgehenden SOAP-Nachrichten erwartet werden. Die definierten Datentypen können zu Gruppen zusammengefasst und von mehreren Operationen genutzt werden. <porttype> definiert die Operationen durch Kombination der zuvor beschriebenen Nachrichten. Ein porttype-element kann mehrere Operationen enthalten. Es werden die vier folgenden Kommunikationsmuster unterstützt: One way: Ein Client schickt einem Service eine Nachricht, der nicht antwortet. Notification: Der Service schickt dem Client eine Nachricht und erhält keine Antwort. Request response: Ein Client fragt beim Server an und dieser antwortet ihm. Solicit response: Der Server fragt beim Client nach und erhält eine Antwort. 112

113 6 Anhang <binding> definiert die Nachrichtenformate und das Transportprotokoll, die zur Übertragung der Aufrufe verwendet werden (oftmals: SOAP-Binding). <service> beschreibt die für den Service-Zugriff notwendigen Informationen wie Netzwerkadresse und Portnummer. 6.2 Ergänzungen zur Prozessanalyse und Entwurf des Monitoring- Konzeptes Darstellung des Lieferantenwechselprozesses als Sequenzdiagramm und in Form von eepks Abbildung 39: Lieferantenwechselprozess - Sequenzdiagramm 113

114 6 Anhang Abbildung 40: Hauptprozess Lieferantenwechsel als eepk Abbildung 41: Teilprozess Kündigungsprüfung als eepk 114

115 6 Anhang Abbildung 42: Teilprozess Wechselprüfung als eepk Zuordnung DA-Prozesse zum Wechselbeleg in Abhängigkeit der Rolle Rolle Neulieferant Altlieferant Netzbetreiber DA-Prozesse - ausgehende Kündigung - ausgehende Anmeldung - eingehende Kündigungsantwort - eingehende Anmeldungsantwort - eingehende Kündigung - ausgehende Kündigungsantwort - ausgehende Abmeldung - eingehende Abmeldungsantwort - eingehende Anmeldung - eingehende Abmeldung - ausgehende Anmeldungsantwort - ausgehende Abmeldungsantwort Tabelle 5: Teilprozess Wechselprüfung als eepk 115

116 6 Anhang Legende für Zustandsübergangsgraphen des Metamodells Workflow-Zustände: Initial-Zustand Endzustand: Fehler behandelt Endzustand: Workflow erfolgreich beendet Workflow ok Workflow fehlerhaft, manuelle Bearbeitung erforderlich Workflow fehlerhaft, keine manuelle Bearbeitung Sonstige: XOR-Verknüpfung Zeitgesteuerter Zustandsübergang Eventgesteuerter Zustandsübergang Aktivitäts-Schnittstelle Abbildung 43: Legende für Zustandsübergangsgraphen Klassische 3-Tier-Architektur einer Webanwendung Client-Tier Middle-Tier Data-Tier Request Response Präsentation Workstation-Mitarbeiter Anwendung Webserver Datenhaltung Datenbank Abbildung 44: Klassische 3-Tier-Architektur einer Webanwendung 116