Oracle Workflow im Einsatz beim Order Management System von T-Online

Transkript

1 Oracle Workflow im Einsatz beim Order Management System von T-Online Thomas Müller von der Bank T-Online International AG Darmstadt Matthias Gries its-people Hochtaunus GmbH Oberursel Schlüsselworte: Oracle Workflow 2.6.2, Oracle 9i Rel. 2, Erfahrungsbericht Einleitung Workflow Management Systeme (WMS) waren ursprünglich dazu gedacht, starre und immer wiederkehrende Geschäftsabläufe zu automatisieren und zu verbessern. Ein klassisches Beispiel hier ist die Genehmigung von Urlaubsanträgen oder die Bestellung von Büromaterial. Mittlerweile finden Workflow Management Systeme aber auch Verwendung in anderen Unternehmensbereichen, wie z.b. Datawarehouse und Enterprise Application Integration (EAI). Oracle Workflow ist eines von vielen Workflow Management Systemen, die es derzeit auf dem Markt gibt. Hierbei kann Oracle Workflow auf eine langjährige Existenz sowohl als allein stehendes Produkt als auch integriert in Oracle Applications bzw. die Oracle E- Business Suite zurückblicken. Allerdings ist es vielen Firmen gar nicht bekannt, dass es Oracle Workflow gibt. Noch weniger wissen die meisten, dass sie, wenn sie eine Oracle Datenbank oder den Application Server von Oracle einsetzen, bereits Oracle Workflow kostenlos im Haus haben. Dabei bietet Oracle Workflow all das, was man von einem modernen Workflow Management System erwarten kann: Modellierung und Visualisierung der Geschäftsprozesse Unterstützung von sowohl traditionellen, anwendungsbasierten sowie von nachrichtenbasierten Geschäftsprozessen Einbeziehung der Anwender durch Versenden von Benachrichtigungen (Web- Notifications oder ) Performanz, Verfügbarkeit und Skalierbarkeit durch Einbettung in die Oracle Datenbank Administrierbarkeit über den Workflow Monitor und den Oracle Workflow Manager

2 Oracle Workflow wird nunmehr seit 2 Jahren produktiv beim Order Management von T- Online eingesetzt. Dieser Erfahrungsbericht soll einen Überblick über die dabei gesammelten Erkenntnisse bzgl. des Einsatzes von Oracle Workflow hinsichtlich einer großen Anzahl lang laufender Geschäftsprozesse sowie der technischen Besonderheiten geben. Oracle Workflow Hauptkomponenten von Oracle Workflow sind: Workflow Builder: Windows basiertes Entwicklungswerkzeug zum graphischen Modellieren von Geschäftsprozessen per Drag and Drop. Unterstützt werden u.a. Subprozesse, Parallelverarbeitung, Und- und Oder-Verknüpfungen, Schleifen, Timeouts. Workflow Engine: überwacht und koordiniert die Steuerung von Prozessen, unter Benutzung einer PL/SQL oder Java API. Hierbei können die Prozessschritte entweder sofort oder verzögert durch die so genannte Background Engine ausgeführt werden. Workflow Definitions Loader: Utility Programm um Workflow Definitionen zwischen der Datenbank und dem File System zu bewegen, auch im Workflow Builder integriert. Benachrichtigungssystem: einzelne Benutzer oder Benutzergruppen können per E- Mail oder Web-Benachrichtigungen in Aktivitäten einbezogen werden, die nicht automatisiert werden können. Business Event System: ermöglicht die Kommunikation zwischen verschiedensten Systemen innerhalb und außerhalb des Unternehmens, basierend auf Oracle Advanced Queuing. Monitoring und Administration: Graphische Darstellung des Workflow Fortschritts im Workflow Monitor. T-Online Order Management System Über das Order Management System (OMS) werden alle Geschäftsprozesse im Auftragsmanagement von T-Online abgewickelt, u.a. Neukundenaufträge, Produktbuchungen, Produkt- und Tarifwechsel, Stammdaten- und Anschlussdatenänderungen. Hierbei sind die betroffenen Geschäftsprozesse durchgängig mit Oracle Workflow umgesetzt. Dies gewährleistet die Nachvollziehbarkeit und Transparenz von Prozessen. Zudem kann schnell auf Änderungen der Geschäftsprozesse reagiert werden. OMS unterstützt außerdem die Geschäftsprozesse des Customer Care Managements. OMS ist Eingangskanal für Kundenaufträge von Partnern und Endkunden. Hierbei stehen den Partnern verschiedenste Möglichkeiten offen: Frontend für den Vertrieb Anbindung über Webservices Dateiaustausch

3 An OMS sind verschiedenste Backendsysteme sowohl von T-Online, des Telekom-Konzerns als auch anderer Partner angebunden, entweder direkt per Webservice oder indirekt per Oracle Advanced Queuing oder Dateiexport/Dateiimport. Mengengerüst In OMS gehen pro Tag im Durchschnitt ca neue Aufträge ein. Durchschnittlich sind ca. 1,5 Millionen Aufträge aktuell in Bearbeitung. Hierbei kann ein Auftrag auch Tage und Wochen laufen, abhängig davon, ob eine manuelle Bearbeitung notwendig ist oder der Auftrag in einem Warteschritt geparkt wird. Unterstützt werden ca. 30 verschiedene Geschäftsprozesse. Um dieses hohe Aufkommen an Aufträgen zu bewältigen, wird ein SUN-Server mit 48 Prozessoren eingesetzt. Hierauf ist Oracle 9i Release 2 mit den aktuellsten Patchsets installiert sowie Oracle Workflow standalone. Zudem wird das Lastaufkommen auf zwei RAC- Knoten verteilt. Skalierung wird erreicht durch das zusätzliche Starten von Workflow Background Engines. Es laufen im Durchschnitt ca. 50 Background Engines, teilweise bis zu 7 für einen Prozesstyp. Anforderungen aus Workflow Sicht Zwischen Workflow und der eigentlichen Business Logik muss es eine generische Schnittstelle geben. Hierzu wurde der so genannte Workflow-Wrapper in PL/SQL entwickelt, der über Metadaten die eigentliche Business Logik ermittelt und aufruft. Der Workflow- Wrapper ist gemäß des Standard-API von Oracle Workflow bzgl. PL/SQL-Prozeduren implementiert: procedure <procedure name> ( itemtype in varchar2, itemkey in varchar2, actid in number, funcmode in varchar2, resultout out varchar2 ) is <local declarations> begin if (funcmode = RUN ) then <your RUN executable statements> resultout := COMPLETE:<result> ; return; end if;... end; Die vom Workflow-Wrapper aufgerufenen Business Logiken haben eine einheitliche Signatur, ähnlich der PL/SQL-Schnittstelle von Oracle Workflow. Hierdurch ist eine Trennung von Workflow und Business Logik gewährleistet. Oracle Workflow ist für die Ablaufsteuerung zuständig und per se nicht für die Fachlichkeit. Diese obliegt, wie der Name schon sagt, den Business Logiken.

4 Weitere Anforderungen waren: Nutzdaten (z.b. über Item Attribute) werden aus Performance-Gründen nicht im Workflow Repository vorgehalten, sondern nur Kontextdaten (Prozesstyp, Vorgangsnummer). Transaktionen werden durch die Workflow Engine gesteuert und nicht durch die Business Logik. Jede Business Logik muss wegen der Sichtbarkeit in der Statusbearbeitung unabhängig von anderen ausgeführt werden können (so genannte Deferred Activities, die durch den regelmäßigen Aufruf der Workflow Background Engine WF_ENGINE.BACKGROUND abgearbeitet werden müssen). Bei asynchronen Zugriffen auf Fremdsysteme (i.d.r. über Oracle Advanced Queuing) wird über das API WF_NOTIFICATION.SEND eine interne Workflow Notification erzeugt, die durch das Fremdsystem beantwortet werden muss (via API WF_NOTIFICATION.RESPOND). U.a. aus diesen Anforderungen resultieren die folgenden Anwendungsschichten und Kommunikationswege, siehe Abbildungen 1 und 2: Client (Browser, WS, File) DB-API Respond Prozesssteuerung (Workflow) Wrapper Controller Business Logik Controller Fassade Kommunikation Fassade CRM- Adapter Fuzzy- Adapter WS- Adapter sonst. Adapter Abb. 1: Kommunikation zwischen den einzelnen Anwendungsschichten von OMS Über eine in PL/SQL realisierte Submit-Prozedur wird ein Auftrag vom Client an das OMS- Backend übermittelt. Hierdurch wird in OMS ein Auftrag mit allen relevanten Daten (z.b. Kunden- und Produktdaten) und ein zugehöriger Workflowprozess (über die API s

5 WF_ENGINE.CREATEPROCESS und WF_ENGINE.STARTPROCESS) angelegt und gestartet. Über die Workflow Background Engine werden die zugehörigen Prozessschritte nacheinander ausgeführt. Hierbei wird abgesehen von einigen Standardfunktionalitäten wie z.b. Warteschritten und Schleifenzähler immer der generische Workflow-Wrapper aufgerufen. Dieser ermittelt anhand von Metadaten die im aktuell abzuarbeitenden Schritt auszuführende Business Logik und die Art und Weise der Ausführung (synchron oder asynchron). Der Workflow-Wrapper ruft anschließend den so genannten Business Logik Controller mit den ermittelten Metadaten auf. Dieser führt dann die Business Logik über EXECUTE IMMEDIATE entweder synchron oder asynchron aus und liefert das Ergebnis an den Workflow-Wrapper zurück, welcher dieses wiederum an die Workflow Engine zurück gibt. WF-Wrapper Aufrufmodus BL-Name,... Metadaten Audit Status Audit BL-Controller Vorgangs- und Kundendaten Business Logik Insert, Update Delete, Select Abb. 2: Kommunikation zwischen Workflow und Business Logik Tuning-Maßnahmen Oracle beschreibt in dem White Paper Oracle Workflow Performance and Sizing Concepts, Release im Wesentlichen zwei Maßnahmen, um die Performance der Workflow Background Engine zu steigern, wenn große Datenmengen, wie dies bei T-Online der Fall ist, erwartet werden: Die erste Maßnahme ist die Partitionierung des Workflow Repositories durch das Ausführen des Skripts wfupart.sql. Hauptkriterium für die Partitionierung sind die Itemtypes der im Repository existierenden Workflow Definitionen.

6 Die zweite Maßnahme ist das regelmäßige Purging (Löschen) obsoleter Laufzeitdaten, da beendete Workflowprozesse nicht automatisch aus dem Workflow Repository entfernt werden. Hierzu kann das PL/SQL API WF_PURGE verwendet werden. Für OMS haben wir auf Basis dieses API s eigene Funktionalität entwickelt, da zum einen ein Workflowprozess erst dann aus dem Workflow Repository gelöscht werden darf, wenn der zugehörige OMS- Vorgang beendet und archiviert ist, und da wir zum anderen Einfluss darauf haben wollten, wie viele Prozesse mit einem Purge-Durchgang gelöscht werden sollten, um so zu lang laufende Transaktionen zu vermeiden. Weitere Erweiterungen Im Laufe des Produktivbetriebs von OMS wurden folgende Erweiterungen notwendig: Anpassung der Workflow Background Engine und Steuerung über die MAESTRO- Jobsteuerung: Bis vor kurzem war es ausreichend, für jede benötigte Background Engine von Oracle Workflow einen Datenbankjob anzulegen, welcher die entsprechende Background Engine regelmäßig alle 15 Sekunden aufgerufen hat. Der Nachteil hierbei war aber, dass die zugehörigen SQL-Sessions nicht normal beendet werden konnten, wenn z.b. viele Prozessschritte zu verarbeiten waren. Dies war insbesondere bei Deployments ein Problem, bei denen eine Downtime der Datenbank erforderlich war. Zudem ließ die Standard Background Engine keinen Rückschluss auf ihren tatsächlichen Durchsatz zu (z.b. wie viele Prozessschritte wurden in der letzten Stunde verarbeitet). Dadurch war keine lastabhängige Steuerung möglich. Aus diesem Grund haben wir auf Basis der Background Engine von Oracle Workflow eine eigene Background Engine entwickelt, die von außen über das Setzen von Parametern in einer Metadatentabelle gestartet und gestoppt werden kann und die eine rudimentäre lastabhängige Steuerung bietet. Diese Background Engine ist in die MAESTRO- Jobsteuerung von T-Online eingebunden. Metadaten gesteuerte Breakpoint-Funktionalität: Diese Funktionalität erlaubt es, einen Workflowprozess an jeder beliebigen Stelle vor Ausführung der nächsten Business Logik anzuhalten, ohne die Modellierung des Prozesses ändern zu müssen. Die Prüfung, ob für den aktuell auszuführenden Prozessschritt ein Breakpoint existiert, erfolgt durch den Workflow-Wrapper. Existiert ein Breakpoint, wird der Prozess in den Status NOTIFIED gesetzt. Über das API WF_ENGINE.HANDLEERROR können die so angehaltenen Prozesse wieder über den Breakpoint gehoben werden. Die Breakpoint-Funktionalität ist insbesondere im Rahmen der Wartung hilfreich, wenn z.b. aufgrund geänderter Anforderungen Workflowprozesse von einer älteren in eine neuere Version migriert werden müssen. Konfigurierbare Wiederaufsetzpunkte: Im Rahmen der manuellen Statusbearbeitung ist es möglich, Prozesse aus einem so genannten Sichtprüfungsstatus (d.h. ein Agent überprüft z.b. fehlende Auftragsdaten und ergänzt diese unter Umständen nach Rücksprache mit dem Kunden) auf vordefinierte Zielschritte zu setzen und den Prozess dort weiterlaufen zu lassen. Auch hierbei machen wir uns das API WF_ENGINE.HANDLEERROR zu nutze. Eigene Warte- und Timeoutfunktionalität: Da Prozesse in OMS mitunter sehr lange angehalten werden (teilweise mehrere Wochen, um Kunden oder Partnern eine

7 qualifizierte Rückantwort zu Anfragen zu ermöglichen), wurde zur Entlastung der internen Workflow Deferred Queue, in der normalerweise neben den Deferred Activities auch alle Waits und Timeouts landen, eigene Funktionalität entwickelt. Waits und Timeouts werden in einer separaten Tabelle protokolliert und über einen Datenbankjob abgearbeitet. Mittels WF_ENGINE.HANDLEERROR werden Prozesse, bei denen ein Wait oder ein Timeout erreicht wurde, auf den nächsten Prozessschritt weitergesetzt. Aktuelle Herausforderung Bei einem Füllstand von über 2 Millionen offenen Prozessen und bis zu Nachrichten in der internen Workflow Deferred Queue scheint Oracle Workflow bzgl. der Abarbeitung asynchroner Prozessschritte an seine Grenzen zu gelangen. Um hier die Workflow Deferred Queue zu entlasten und eine gute Performance von Oracle Workflow zu gewährleisten, wurden zwei Maßnahmen in die Wege geleitet: Zum einen wurde die Entscheidung, dass jeder Workflowschritt über die Background Engine als Deferred Activity ausgeführt werden soll, revidiert. Zur Entlastung der Queue werden alle Workflowprozesse, da wo möglich, nach und nach auf teilsynchrone Abarbeitung umgestellt. Zum anderen haben wir beobachtet, dass die Ladeprozesse von Flat Files, bei denen aufgrund der Schnittstellenvereinbarungen mit den Partnern große Datenmengen in nur einer Transaktion in OMS eingelesen werden ( ganz oder gar nicht ), einen negativen Einfluss auf die Performance der Background Engine haben, insbesondere wenn als Teil dieser Transaktion mit einem Mal mehrere Workflowprozesse erzeugt werden. Hier werden wir das Einlesen der Daten in OMS und das Starten der Workflowprozesse entkoppeln. Das Starten der Workflowprozesse wird in mehreren separaten Transaktionen durchgeführt werden. Fazit In den zwei Jahren, in denen OMS nun produktiv im Einsatz ist, sind die Erfahrungen mit Oracle Workflow durchweg positiv, insbesondere auch in Hinblick auf die Verarbeitung von großen Datenmengen. Trotz der aktuellen Herausforderungen würden wir Oracle Workflow jederzeit wieder einsetzen. Referenzen Oracle Workflow User's Guide (Part No. B12162) Oracle Workflow Developer's Guide (Part No. B12161) Oracle Workflow API Reference (Part No. B12163) Oracle Workflow Administrator's Guide (Part No. B12160) Oracle Workflow Performance and Sizing Concepts, Release

8 Kontaktadresse: Thomas Müller von der Bank T-Online International AG T-Online Allee 1 D Darmstadt Telefon: +49 (0)6151/ t.mueller_von_der_bank@t-online.net Internet: Matthias Gries its-people Hochtaunus GmbH Nassauer Str. 60 D Oberursel Telefon: +49(0)173/ matthias.gries@its-people.de Internet: