Oracle Workflow im Einsatz beim Order Management System von T-Online
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
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 E-Mail)
Performanz, Verfügbarkeit und Skalierbarkeit durch Einbettung in die Oracle
Datenbank
Administrierbarkeit über den Workflow Monitor und den Oracle Workflow ManagerOracle 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
DateiaustauschAn 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. 100.000 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 2.6.2 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 ( itemtype in varchar2
, itemkey in varchar2
, actid in number
, funcmode in varchar2
, resultout out varchar2
)
is
begin
if (funcmode = ‘RUN’) then
resultout := ‘COMPLETE:‘;
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.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- Fuzzy- WS- sonst.
Adapter Adapter Adapter 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’sWF_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.
Metadaten
WF-Wrapper Aufrufmodus
BL-Name,...
Au
Sta dit Audit
tus
BL-Controller
Vorgangs- und
Kundendaten
Insert, Update
Business Logik 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 2.6.2 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.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 einequalifizierte 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 200.000 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 10.000 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 2.6.2
http://www.oracle.com/technology/products/ias/workflow/index.htmlKontaktadresse: Thomas Müller – von der Bank T-Online International AG T-Online Allee 1 D- 64295 Darmstadt Telefon: +49 (0)6151/680-2525 E-Mail t.mueller_von_der_bank@t-online.net Internet: www.t-online.de Matthias Gries its-people Hochtaunus GmbH Nassauer Str. 60 D-61440 Oberursel Telefon: +49(0)173/2752573 E-Mail matthias.gries@its-people.de Internet: www.its-people.de
Sie können auch lesen
