23. Ein Workflow-Managementsystem auf der Basis aktiver

17 Pages·2004·0.26 MB·German

(cid:0)(cid:1)(cid:2) Ein Work(cid:3)ow(cid:4)Managementsystem auf der
Basis aktiver Datenbanken
Johann Eder(cid:0) Herbert Groiss
Abstract
Dieses Kapitel stellt eine Architektur fu(cid:0)r die Realisierung von
Work(cid:1)ow(cid:2)Managementsystemen vor(cid:3) die auf der Verwendung
von aktiven Datenbanksystemen basiert(cid:4) Bei diesem Ansatz
werden alle Informationen u(cid:0)ber das Work(cid:1)owsystem(cid:3) das sind
Proze(cid:5)strukturen(cid:3) Benutzer bzw(cid:4) Rolleninformation(cid:3)Metadaten
sowieBeziehungenzwischenProzessenundDaten(cid:3)alsauchs(cid:0)amt(cid:2)
liche Informationenu(cid:0)berdiedynamische Proze(cid:5)durchfu(cid:0)hrung in
der Datenbank verwaltet(cid:4) Die Work(cid:1)owde(cid:6)nitionen werden auf
Trigger u(cid:0)bersetzt(cid:3) die die Proze(cid:5)durchfu(cid:0)hrung ereignisorientiert
steuern(cid:4) Als Beispiel wird der Protoyp Panta Rhei vorgestellt(cid:3)
dem diese Architektur erfolgreich zugrundegelegt wurde(cid:4)
(cid:0)(cid:1)(cid:2)(cid:5) Einleitung
Work(cid:1)ow(cid:2)Systeme unterstu(cid:0)tzen die Durchfu(cid:0)hrung von Gesch(cid:0)aftsprozessen
mit informationstechnischen Mitteln(cid:4) Gesch(cid:0)aftsprozesse bzw(cid:4) Vorg(cid:0)ange
werden mit den dafu(cid:0)r entwickelten Modellierungswerkzeugen konzeptuell
modelliert(cid:4) Diese konzeptuellen Proze(cid:5)modelle k(cid:0)onnen dann auf Work(cid:1)ow(cid:2)
de(cid:6)nitionen(cid:3)dieProze(cid:5)schemata(cid:3) abgebildetwerden(cid:4) Esgibtdafu(cid:0)rnatu(cid:0)rlich
verschiedenste Ans(cid:0)atze (cid:7)(cid:8)HEA(cid:9)(cid:10)(cid:3) LCS(cid:11)(cid:12)(cid:3) ML(cid:9)(cid:13)(cid:3) TLF(cid:11)(cid:11)(cid:3) Zlo(cid:11)(cid:12)(cid:3) EB(cid:11)(cid:12)(cid:14)(cid:15) mit
recht unterschiedlicher M(cid:0)achtigkeit oder Flexibilit(cid:0)at(cid:4) Im wesentlichen spe(cid:2)
zi(cid:6)zieren Work(cid:1)owde(cid:6)nitionen folgendes(cid:16)
(cid:0)
Welche Aufgaben (cid:7)Tasks(cid:15) ausgefu(cid:0)hrt werden sollen(cid:4)
(cid:0)
InwelcherReihenfolgedieAufgabenausgefu(cid:0)hrtwerden(cid:7)meistabh(cid:0)angig
von Entscheidungen(cid:3) die ebenfalls Teil des Prozesses sind(cid:15)(cid:4)
(cid:0)
Wer die Aufgaben ausfu(cid:0)hren soll (cid:2) insbesondere(cid:3) ob die Aufgabe ma(cid:2)
schinell (cid:7)durch ein Anwendungsprogramm(cid:15) oder durch einen Mensch(cid:2)
Maschinen(cid:2)Dialog ausgefu(cid:0)hrt werden soll(cid:4)
(cid:0)
Welche RandbedingungeninbezugaufZeit(cid:3) Qualit(cid:0)atundRessourcen(cid:2)
verbrauch eingehalten werden mu(cid:0)ssen(cid:4)
(cid:13)
Work(cid:1)ow(cid:2)Managementsysteme haben die Aufgabe(cid:3) Work(cid:1)owde(cid:6)nitio(cid:2)
nen entgegenzunehmen und in ausfu(cid:0)hrbare Prozesse zu transformieren(cid:4) Sie
steuern die Durchfu(cid:0)hrung dieser Prozesse und gew(cid:0)ahrleisten die Sicherheit
und Zuverl(cid:0)assigkeit der Proze(cid:5)durchfu(cid:0)hrung auch bei Hard(cid:2) und Software(cid:2)
fehlern(cid:4) Au(cid:5)erdem verwalten sie Benutzerdaten und Berechtigungen(cid:3) doku(cid:2)
mentieren die Proze(cid:5)durchfu(cid:0)hrung und generieren Daten fu(cid:0)r das Manage(cid:2)
ment der Gesch(cid:0)aftsprozesse(cid:4)
Wir k(cid:0)onnen die Aufgaben eines Work(cid:1)ow(cid:2)Managementsystems deshalb
auf drei Ebenen betrachten(cid:4) Die erste Ebene verwaltet die Metadaten(cid:3) das
sind die De(cid:6)nitionen von Work(cid:1)ows und ihrer zugeh(cid:0)origen Prozesse(cid:3) Akti(cid:2)
vit(cid:0)aten(cid:3) Tasks(cid:3) die von diesen verwendeten Daten(cid:3) sowie die Beziehung zwi(cid:2)
schen Prozessen und Daten(cid:4) Die zweite Ebene umfa(cid:5)t die Verwaltung der
Instanzen(cid:3) das sindProze(cid:5)instanzen(cid:3) Dateninstanzen(cid:3) Benutzer undRollen(cid:2)
informationen sowie die Beziehungen zwischen Benutzern(cid:3) Dateninstanzen
und Proze(cid:5)instanzen(cid:4) Die dritte Ebene beinhaltet die Proze(cid:5)steuerung(cid:3) d(cid:4)h
das Ansto(cid:5)en von Prozessen (cid:7)Aktivit(cid:0)aten(cid:3) Tasks(cid:15)(cid:3) die Weiterleitung von
Dateninstanzen(cid:3) der automatische Start von Programmen(cid:3) etc(cid:4)
In diesem Kapitel wird ein neuer Ansatz fu(cid:0)r die Realisierung von Work(cid:2)
(cid:1)ow(cid:2)Managementsystemen beschrieben(cid:4) Die Grundidee ist die Verwendung
einer aktiven Datenbank fu(cid:0)r die Verwaltung s(cid:0)amtlicher Daten sowie fu(cid:0)r die
Steuerung der Proze(cid:5)instanzen(cid:4) Aktive Datenbanken erweitern herk(cid:0)omm(cid:2)
liche (cid:7)passive(cid:15) Datenbanken durch eine dynamische Komponente in Form
von Produktionsregeln bzw(cid:4) Trigger(cid:3) mit der sie auf Ereignisse wie A(cid:0)nde(cid:2)
rungen des Datenbankinhaltes automatisch reagieren k(cid:0)onnen(cid:4) Sie sind des(cid:2)
halb vorzu(cid:0)glich fu(cid:0)r Applikationen geeignet(cid:3) die (cid:2) wie Work(cid:1)ow(cid:2)Systeme (cid:2)
inh(cid:0)arent daten(cid:2) und ereignisgesteuert sind(cid:4)
Fu(cid:0)r die Verwaltung der Daten und Metadaten werden in Work(cid:1)ow(cid:2)
Managementsystemen h(cid:0)au(cid:6)g Datenbanken herangezogen(cid:4) In unserem An(cid:2)
satz wird auch die dynamische Statusinformation der Proze(cid:5)instanzen in
den Datenraum abgebildet(cid:4) Fu(cid:0)r jede Proze(cid:5)instanz wird in der Datenbank
eineDateninstanz angelegt(cid:3) dieunteranderem denaktuellenStand derPro(cid:2)
ze(cid:5)instanz enth(cid:0)alt(cid:4) Aus dieser Proze(cid:5)beschreibung kann insbesondere abge(cid:2)
lesen werden(cid:3) welche Tasks bereits absolviert sind und welche Tasks fu(cid:0)r die
Durchfu(cid:0)hrung bereit stehen(cid:4) Diese Statusinformation ist persistent(cid:3) da sie
von einer Datenbank verwaltet wird(cid:4) A(cid:0)nderungen an dieser Statusinforma(cid:2)
tion ist der Transaktionsverwaltung des Datenbanksystems unterworfen(cid:4)
Fu(cid:0)r die dynamische Proze(cid:5)durchfu(cid:0)hrung wird ebenfalls die Datenbank(cid:3)
und zwar die Trigger der aktiven Datenbank(cid:3) herangezogen(cid:4) Damit wird ei(cid:2)
nehochintegrierteArchitekturrealisiert(cid:3)die auf einemeinzigenBasissystem
beruht(cid:4) Gleichzeitig bietet diese Architektur eine gr(cid:0)o(cid:5)tm(cid:0)ogliche O(cid:17)enheit(cid:3)
da die aktive Datenbank beliebige externe Prozesse starten kann und u(cid:0)ber
die Verwendung der Datenbank als KommunikationsvehikelDaten zwischen
Programmenausgetauschtwerdenk(cid:0)onnen(cid:4) Damitk(cid:0)onnenineinenWork(cid:1)ow
beliebige Anwenderprogramme(cid:3) insbesondere bereits bestehende(cid:3) eingebun(cid:2)
(cid:12)
den werden(cid:4) Au(cid:5)erdem kann die Vielzahl der Schnittstellen und Werkzeu(cid:2)
ge moderner Datenbanksysteme direkt fu(cid:0)r das Work(cid:1)owsystem verwendet
werden(cid:4) Eine Besonderheit bietet dieses Konzept auch fu(cid:0)r die Ausl(cid:0)osung
von Work(cid:1)owprozessen(cid:4) So kann das Work(cid:1)owsystem in bestehende(cid:3) auf
Datenbanken basierende Informationssysteme integriert werden(cid:3) so da(cid:5) auf
bestimmte Situationen(cid:3) die durch bestehende Applikationen in die Daten(cid:2)
bank abgebildet werden(cid:3) u(cid:0)ber Trigger automatisch ein Work(cid:1)ow gestartet
wird(cid:4) Dafu(cid:0)r braucht die bestehende Applikation in keiner Weise ge(cid:0)andert
werden(cid:4)
Die hier vorgestellte Architektur ist auch dadurch charakterisiert(cid:3) da(cid:5)
m(cid:0)oglichst viel der vom aktiven Datenbanksystem zur Verfu(cid:0)gung gestellten
Funktionalit(cid:0)at direkt genutzt wird(cid:4) So wird zum Beispiel fu(cid:0)r die Steuerung
der Nebenl(cid:0)au(cid:6)gkeit direkt das Transaktionssystem der Datenbank verwen(cid:2)
det(cid:4) Weiters wird die erforderliche Sicherheit durch den Zugri(cid:17)sschutz der
Datenbank direktgew(cid:0)ahrleistet(cid:4) Das Recovery(cid:2)System derDatenbank sorgt
fu(cid:0)r die Wiederherstellung eines konsistenten Zustandes der Datenbank und
damit auch des Work(cid:1)owsystems im Falle eines Systemausfalls mit Prim(cid:0)ar(cid:2)
oderSekund(cid:0)arspeicherverlust(cid:4) DabeiwerdennichtnurdieDaten wiederher(cid:2)
gestellt(cid:3)sondernauchalleProzessewerdenaufdenletztenbest(cid:0)atigtenStand
gesetzt (cid:2) ohne jeglichen zus(cid:0)atzlichen Implementierungsaufwand(cid:4) Diese Ar(cid:2)
chitektur zeichnet sich daher auch durch vergleichsweise niedrigen Aufwand
fu(cid:0)r die Realisierung eines Work(cid:1)ow(cid:2)Managementsystems aus(cid:4)
Imn(cid:0)achstenAbschnittgebenwireinekurzeEinfu(cid:0)hrungindieFunktions(cid:2)
weise von aktiven Datenbanken(cid:3) danach wird die Abbildung von Work(cid:1)ow(cid:2)
Beschreibungen in Regeln aktiver Datenbanken beschrieben(cid:3) Abschnitt (cid:12)(cid:18)(cid:4)(cid:19)
zeigtdieArchitekturunseresPrototypenPantaRhei(cid:7)Heraklit(cid:16) Alles(cid:1)ie(cid:5)t(cid:21)(cid:15)
(cid:20)
und Abschnitt (cid:12)(cid:18)(cid:4)(cid:22) bringt eine Zusammenfassung und Bewertung unseres
Ansatzes(cid:4)
(cid:0)(cid:1)(cid:2)(cid:0) Aktive Datenbanken
Konventionelle Datenbanken sind passiv(cid:3) das hei(cid:5)t(cid:3) Anfragen und Ver(cid:0)ande(cid:2)
rungen werden nur durch explizite Aktionen eines Benutzers oder Anwen(cid:2)
dungsprogramms durchgefu(cid:0)hrt(cid:4) Aktive Datenbanken (cid:7)fu(cid:0)r eine Einfu(cid:0)hrung
siehe (cid:8)Day(cid:11)(cid:11)(cid:14)(cid:3) (cid:8)Cha(cid:9)(cid:12)(cid:14)(cid:15) hingegen erlauben die Spezi(cid:6)kation von Aktionen(cid:3)
die automatisch ausgefu(cid:0)hrt werden(cid:3) wenn bestimmte Ereignisse eintreten(cid:4)
Diegrunds(cid:0)atzlichenElementederArchitekturvonaktivenDatenbankensind
in Abbildung (cid:12)(cid:18)(cid:4)(cid:13) dargestellt(cid:4)
DasDatenbank(cid:2)ManagementsystemeineraktivenDatenbankenth(cid:0)alteinen
Mechanismus zum Erkennen von Ereignissen(cid:3)zum Pru(cid:0)fenvon Bedingungen
undzumDurchfu(cid:0)hrenbzw(cid:4) Ansto(cid:5)envonAktionen(cid:4) BeiallenAbfragenund
Ver(cid:0)anderungen(cid:3)dieinderDatenbank eintre(cid:17)en(cid:3)wirdu(cid:0)berpru(cid:0)ft(cid:3)obeineAk(cid:2)
tion durchgefu(cid:0)hrt werden soll(cid:23) diese Aktion kann wieder Ver(cid:0)anderungen in
(cid:18)
Spezifikation von Ereignissen
und Bedingungen
Passives DBMS +
..
Anfragen/Veranderungen
Anwendungsprogramme Ereigniserkennung + Aktionen
Condition Monitoring
Daten Daten
Abbildung (cid:12)(cid:18)(cid:4)(cid:13)(cid:16) Prinzip einer aktiven Datenbank
der Datenbank ausl(cid:0)osen oder eine Aktion au(cid:5)erhalb der Datenbasis ansto(cid:2)
(cid:5)en(cid:4)
Die Spezi(cid:6)kation von Ereignis(cid:3) Bedingungen und Aktionen erfolgt de(cid:2)
klarativ in Form von Event(cid:2)Condition(cid:2)Action (cid:7)ECA(cid:15) Regeln(cid:4)
Jeder Zugri(cid:17) auf die Datenbank durch einen Benutzer oder ein Anwen(cid:2)
dungsprogramm wird als Ereignis aufgefa(cid:5)t(cid:3) das eine Regelanwendung an(cid:2)
sto(cid:5)en kann(cid:4) Bei Triggerung einer Regel durch ein Ereignis werden die
Bedingungen dieser Regel u(cid:0)berpru(cid:0)ft(cid:4) Sind sie erfu(cid:0)llt(cid:3) werden die Aktionen
der Regel ausgefu(cid:0)hrt(cid:4)
Bedingungen sind dabei Beschreibungen von Zust(cid:0)anden in der Daten(cid:2)
bank(cid:4) Aktionen k(cid:0)onnen wiederum Ver(cid:0)anderungen in der Datenbank sein(cid:3)
aber auch Aufrufe von externen Prozeduren(cid:4)
Im folgenden wird fu(cid:0)r Beispiele die Syntax von SQL(cid:18) (cid:8)IA(cid:9)(cid:18)(cid:14) verwendet(cid:3)
der (cid:2) etwas vereinfachte (cid:2) Aufbau einer Regel sieht folgenderma(cid:5)en aus(cid:16)
create trigger name
after event on table
when condition
action
Mit create trigger wird eine Regel name de(cid:6)niert(cid:3) die auf Ver(cid:0)ande(cid:2)
rungen der Tabelle table reagiert(cid:4) Das die Regel triggernde Ereignis wird
nach dem Schlu(cid:0)sselwort after spezi(cid:6)ziert(cid:3) der Bedingungsteil nach dem
Schlu(cid:0)sselwort when enth(cid:0)alt eine quanti(cid:6)zierte SQL(cid:2)Abfrage(cid:3) die einen Boo(cid:2)
(cid:19)
leschen Wert retouniert(cid:4) Als Aktionen sind in SQL formulierte Datenban(cid:2)
kaktionen zul(cid:0)assig(cid:4)
Beispiel (cid:0)(cid:1)(cid:2)(cid:3) Bei Ver(cid:0)anderung des Lagerbestandes unter einen festgesetz(cid:2)
ten Wert soll automatisch eine Bestellung generiert werden(cid:4) Dazu wirdeine
Regel formuliert(cid:3) die bei Ver(cid:0)anderungen der Best(cid:0)ande getriggert wird und
beim Unterschreiten des Schwellwertes den Teil in eine Bestelliste eintr(cid:0)agt(cid:4)
create trigger store(cid:0)control
after update of quantity on store
when new(cid:1)quantity (cid:2) (cid:3)
insert into order(cid:0)list values (cid:4)new(cid:1)art(cid:0)no(cid:5) (cid:1)(cid:1)(cid:1)(cid:6)(cid:7)
Diese Regel reagiert auf Ver(cid:0)anderungen in der Tabelle store(cid:3) das triggern(cid:2)
de Ereignis ist eine Ver(cid:0)anderung des Attributs quantity bei einem Tupel
dieser Tabelle(cid:4) Die Bedingung ist eine SQL(cid:2)Abfrage(cid:3) die u(cid:0)berpru(cid:0)ft(cid:3) ob die
neue quantity kleiner (cid:3) ist(cid:4) Tri(cid:17)t dies zu(cid:3) wird ein Eintrag in die Tabelle
order(cid:0)list durchgefu(cid:0)hrt(cid:4)
Den Vorteilen von aktiven Datenbanken stehen natu(cid:0)rlich auch gewis(cid:2)
se Nachteile gegenu(cid:0)ber(cid:4) Zum einen ist die Verarbeitung der Regeln eine
zus(cid:0)atzliche Belastung fu(cid:0)r den Datenbankserver(cid:4) Aktive Datenbanken stel(cid:2)
len daher gr(cid:0)o(cid:5)ere Anforderungen an die Rechnerleistung der Server(cid:4) Zum
anderen ist die Strukturierungsehr gro(cid:5)er Regelmengen noch nicht wirklich
zufriedenstellend gel(cid:0)ost(cid:4)
(cid:0)(cid:1)(cid:2)(cid:1) Abbildung von Work(cid:3)ow(cid:4)Modellen auf akti(cid:4)
ve Datenbanken
(cid:0)(cid:1)(cid:2)(cid:1)(cid:2)(cid:3) Referenzmodell einer Proze(cid:4)beschreibung
Bisweilen gibt es kein allgemein akzeptiertes Metamodell zur Beschreibung
von Work(cid:1)ows (cid:7)obwohl Versuche in diese Richtung gehen(cid:3) siehe (cid:8)WMC(cid:9)(cid:19)b(cid:14)(cid:3)
(cid:8)EL(cid:9)(cid:22)(cid:14)(cid:15)(cid:4) Abb(cid:4) (cid:12)(cid:18)(cid:4)(cid:12) stellt das Schema eines einfachen Modells dar(cid:16)
Work(cid:0)ows sind zusammengesetze Aktivit(cid:0)aten(cid:3) die die Ausfu(cid:0)hrung meh(cid:2)
rererTasksdurchverschiedeneAkteurebeschreiben(cid:4) EinAkteuristentweder
durch einen konkreten Benutzer oder ein Programm(cid:3) das die Datenmanipu(cid:2)
lation ausfu(cid:0)hrt(cid:3) oder eine Rolle stellvertretend fu(cid:0)r eine Menge von Akteu(cid:2)
ren(cid:3) spezi(cid:6)ziert(cid:4) Forms sind die Datencontainer(cid:3) die die Applikations(cid:2) und
Proze(cid:5)daten zwischen den Aktivit(cid:0)aten weiterreichen(cid:4) Die Wege der Forms
werden mittels Flows spezi(cid:6)ziert(cid:4)
Zur Darstellung von Work(cid:1)ows verwenden wir im folgenden die von uns
entwickelte Work(cid:1)ow(cid:2)Beschreibungssprache WDL(cid:4)
(cid:22)
0 or 1 0 or many
WORKFLOW 1 1+ 1 or many
ISA Part of
input
Form Flow Task Akteur
exekutiert
output
Benutzer Programm Rolle
Abbildung (cid:12)(cid:18)(cid:4)(cid:12)(cid:16) Work(cid:4)ow Metamodell
(cid:0)(cid:1)(cid:2)(cid:1)(cid:2)(cid:0) Die Work(cid:5)ow(cid:6)Beschreibungssprache WDL
WDL ist im wesentlichen ein Darstellungskonzept fu(cid:0)r die obenbeschriebene
Modellierung (cid:7)Abb(cid:4) (cid:12)(cid:18)(cid:4)(cid:12)(cid:15) von Prozessen(cid:4) Die wichtigsten Designkriteri(cid:2)
en fu(cid:0)r diese Sprache waren(cid:16) einen einfach zu verwendenden Formalismus
zu scha(cid:17)en(cid:3) der es erm(cid:0)oglicht eine breite Palette von Gesch(cid:0)aftsprozessen zu
modellieren(cid:3)sowieguteAbbilddbarkeitaufeineImplementierungzugew(cid:0)ahr(cid:2)
leisten(cid:4)
Die wesentlichen Elemente eines Work(cid:1)ows lassen sich graphisch mittels
des WDL Proze(cid:5)diagramms darstellen(cid:4) Abb(cid:4) (cid:12)(cid:18)(cid:4)(cid:18) zeigt ein solches fu(cid:0)r den
Antrag einer Dienstreise(cid:4)
Dieser Proze(cid:5) erfordert die Interaktion verschiedener Personen und Ab(cid:2)
teilungen(cid:4) Ein Antragssteller(cid:3) der eine Reise plant(cid:3) braucht die Genehmi(cid:2)
gungvonInstitutsvorstandundDekan(cid:4) NachderReisebekommterdasGeld
von der Personalabteilung(cid:4) Die Tasks werden durch rechteckige K(cid:0)astchen
repr(cid:0)asentiert(cid:3) in denen der Name des Tasks sowie (cid:2) in eckigen Klammern (cid:2)
der Ausfu(cid:0)hrende eingetragen wird(cid:4) Fu(cid:0)r letzteren wird entweder direkt der
Benutzer oder eine Rolle spezi(cid:6)ziert (cid:7)z(cid:4)B(cid:4) Dekan(cid:15)(cid:4) Fu(cid:0)r Tasks(cid:3) die automa(cid:2)
tisch(cid:3) d(cid:4)h(cid:4) ohne Benutzer(cid:2)Interaktion ablaufen(cid:3) wird der Pseudo(cid:2)Benutzer
SYSTEM spezi(cid:6)ziert(cid:4) Dies erlaubt die Integration von beliebigen Program(cid:2)
men(cid:3) die die Daten manipulieren(cid:4) In obigem Beispiel kann ein Vorschlag
automatisch generiert werden(cid:3) der z(cid:4)B(cid:4) die Summe des noch vorhandenen
(cid:24)
Antrag Gehnemig. Gehnemig. Geld
stellen IV Dekan auszahlen
[Antragsteller] [IV] [Dekan] [Pers.abt]
Vorschlag
Bestätigung Geld
[System] anfordern
[Antragsteller]
[Antragsteller]
Abbildung (cid:12)(cid:18)(cid:4)(cid:18)(cid:16) Dienstreise
Geldes abfragt und entsprechende Aktionen setzt(cid:4) Au(cid:5)erdem kann der Be(cid:2)
nutzer als DYNAMIC spezi(cid:6)ziert werden(cid:23) in diesem Fall liest das System
den Benutzer aus einem Feld in einem der bearbeiteten Forms aus(cid:4)
DerKontroll(cid:1)u(cid:5)wirddurchdiePfeilerepr(cid:0)asentiert(cid:4) EinTaskkanneinen
odermehrereEingangs(cid:1)owssowieeinenodermehrereAusgangs(cid:1)owshaben(cid:3)
die verschieden verknu(cid:0)pft werden k(cid:0)onnen(cid:16)
Eingangsseite des Tasks(cid:16)
(cid:0)
mehrere Flows mu(cid:0)nden in einen Task(cid:16) dies bedeutet(cid:3) da(cid:5) der Task
aktiviert wird(cid:3) wenn eine der Forms den Task erreicht(cid:4)
(cid:0)
mehrere Input(cid:1)ows sind logisch verknu(cid:0)pft(cid:16) Der Task wird aktiviert(cid:3)
wenn die Boolesche Verknu(cid:0)pfung zwischen den Eingangs(cid:1)ows erfu(cid:0)llt
ist(cid:4) z(cid:4)B(cid:4)(cid:16) f(cid:13)UND (cid:7)f(cid:12)ODER f(cid:18)(cid:15) bedeutet(cid:3) da(cid:5) der Task aktiviertwird(cid:3)
wenn die Form f(cid:13) und entweder f(cid:12) oder f(cid:18) eingetro(cid:17)en sind(cid:4)
(cid:0)
Synchronisationpunkt(cid:16) Wenn ein Form zur parallelen Bearbeitung
an verschiedene Tasks weitergeleitet wird(cid:3) mu(cid:5) am Ende der Paral(cid:2)
lelfu(cid:0)hrung ein Synchronisationspunkt liegen(cid:4) Der nachfolgende Task
wird nur ausgefu(cid:0)hrt(cid:3) wenn alle parallelen Teilpfade abgearbeitet wor(cid:2)
den sind(cid:4)
Ausgangsseite des Tasks(cid:16)
(cid:0)
keine Verknu(cid:0)pfung(cid:16) Alle Forms werden den entsprechenden Nachfol(cid:2)
getasks geschickt(cid:4)
(cid:0)
UND Verknu(cid:0)pfung(cid:16) Die Form wirdan zwei Tasks zur parallelen Bear(cid:2)
beitung weitergereicht(cid:4)
(cid:0)
ODER(cid:16) Je nachdem(cid:3) welche Flow(cid:2)Bedingung erfu(cid:0)lltist(cid:3) wirddieForm
zu einem der beiden Nachfolgetasks weitergeschickt(cid:4)
(cid:25)
Zus(cid:0)atzlich zur De(cid:6)nition des Proze(cid:5)diagramms ist es notwendig(cid:3) einige
Informationen zum Proze(cid:5) anzugeben(cid:16)
(cid:0)
generelle Informationen zum Work(cid:1)ow(cid:16) De(cid:6)nition aller Benutzer und
Rollen(cid:3) die im Work(cid:1)ow vorkommen(cid:4)
(cid:0)
Struktur der involvierten Forms(cid:16) Das Proze(cid:5)diagramm zeigt nur den
Flu(cid:5) von Forms an(cid:3) nicht deren innere Struktur(cid:4)
zus(cid:0)atzliche Informationen zum Task(cid:16)
(cid:0)
Postconditions(cid:16) DurchdieDe(cid:6)nitionvonPostconditionserreicht man(cid:3)
da(cid:5) am Ende eines Tasks de(cid:6)nierte Zust(cid:0)ande herrschen(cid:4)
(cid:0)
Prozeduren(cid:16) Eine before(cid:2)procedure und eine after(cid:2)procedure k(cid:0)onnen
zur Ausfu(cid:0)hrung bevor bzw(cid:4) nach der Ausfu(cid:0)hrung eines Tasks spezi(cid:6)(cid:2)
ziert werden(cid:4)
(cid:0)
Benutzerauswahl(cid:16) Wenn eine Rolle als Akteur bei einem Task spe(cid:2)
zi(cid:6)ziert wird(cid:3) erfordert dies die De(cid:6)nition eines Selektionskriteriums(cid:3)
umdenkonkreten Benutzer zum Ausfu(cid:0)hrungszeitpunktbestimmenzu
k(cid:0)onnen(cid:4) M(cid:0)ogliche Auswahlkriterien sind(cid:16) W(cid:0)ahle Benutzer mit der
kleinsten workload(cid:3) zuf(cid:0)allige Auswahl(cid:3) o(cid:4)(cid:0)a(cid:4)
(cid:0)
Zugri(cid:17)sarten(cid:16) Der Zugri(cid:17) der Tasks auf die einzelnen Forms mu(cid:5) spe(cid:2)
zi(cid:6)ziert werden(cid:3) so ist es m(cid:0)oglich(cid:3) da(cid:5) auf einige Felder der Form
u(cid:0)berhaupt kein Zugri(cid:17) besteht(cid:3) auf andere Lesezugri(cid:17) oder Lese(cid:2) und
Schreibm(cid:0)oglichkeit(cid:4)
Fu(cid:0)r dieProzeduren(cid:3) Pre(cid:2) undPostconditionswurde keineexakte Syntax
de(cid:6)niert(cid:3) da diese von der Implementierung abh(cid:0)angt(cid:4) In unserer Imple(cid:2)
mentierung auf der Basis einer SQL(cid:2)Datenbank sind diese Prozeduren und
Ausdru(cid:0)cke jeweils SQL Konstrukte(cid:3) somit ist eine weitestgehende Portier(cid:2)
barkeit gew(cid:0)ahrleistet(cid:4) In Abschnitt (cid:12)(cid:18)(cid:4)(cid:19)(cid:4)(cid:12) wird ein Designeditor fu(cid:0)r WDL
beschrieben(cid:4)
(cid:0)(cid:1)(cid:2)(cid:1)(cid:2)(cid:1) Ausfu(cid:7)hrungsmodell
Ein WDL(cid:2)Proze(cid:5)diagramm de(cid:6)niert Abl(cid:0)aufe als den Weg von Forms zwi(cid:2)
schen Tasks(cid:4) Die Datenmanipulationen innerhalb der Tasks werden nicht
betrachtet(cid:4) Das Ausfu(cid:0)hrungsmodellfu(cid:0)rWDL kann daher mit den einzelnen
Schritten(cid:3) die zwischen der Beendigung eines Tasks und dem Starten eines
anderen vor sich gehen(cid:3) beschrieben werden(cid:4)
Nach dem Abschlu(cid:5) eines Tasks (cid:2) u(cid:0)blicherweise eine Manipulation von
Dokumenten oder Formularen (cid:2) geht die Kontrolle an den Work(cid:1)ow(cid:2)Server(cid:3)
der die folgenden Schritte ausfu(cid:0)hrt(cid:16)
(cid:11)
(cid:13)(cid:4) Die (cid:2) optionale (cid:2) Post(cid:2)Prozedur wird ausgefu(cid:0)hrt(cid:4)
(cid:12)(cid:4) Die Bedingungen(cid:3) die nach der Task(cid:2)Ausfu(cid:0)hrung gelten mu(cid:0)ssen(cid:3) wer(cid:2)
den u(cid:0)berpru(cid:0)ft(cid:4) Wenn sie erfu(cid:0)llt sind(cid:3) gilt diese Aktivit(cid:0)at als abge(cid:2)
schlossen(cid:3) im anderen Fall erh(cid:0)alt der Task eine Nachricht(cid:3) da(cid:5) eine
Weiterbearbeitung notwendig ist(cid:4)
(cid:18)(cid:4) Entsprechend der De(cid:6)nition der Abl(cid:0)aufe werden die bearbeiteten Do(cid:2)
kumente an die Nachfolger(cid:2)Aktivit(cid:0)aten geschickt(cid:4)
(cid:19)(cid:4) Die Vorbedingungen der Tasks werden u(cid:0)berpru(cid:0)ft(cid:4)
(cid:22)(cid:4) Falls die Vorbedingungen zur Ausfu(cid:0)hrung einer Aktivit(cid:0)at erfu(cid:0)llt sind(cid:3)
wirdsieeinembestimmtenBenutzer(cid:7)odereinerMaschine(cid:15)zugeordnet(cid:4)
(cid:24)(cid:4) Eine den Task vorbereitende Prozedur wird ausgefu(cid:0)hrt(cid:4)
(cid:25)(cid:4) Der Benutzer (cid:7)das Client(cid:2)Programm(cid:15) erh(cid:0)alt ein Signal(cid:3) da(cid:5) eine Ak(cid:2)
tivit(cid:0)at zur Bearbeitung ansteht(cid:4)
Fu(cid:0)r die Abbildung dieses Ablaufs in die Datenbank ist es notwendig(cid:3)
die Statusinformationen zu den laufenden Prozessen in Tabellen abzule(cid:2)
gen(cid:4) Beim Initiieren eines Prozesses wird fu(cid:0)r die neue Proze(cid:5)instanz eine
Identi(cid:6)kation und ein Eintrag in eine entsprechende Tabelle generiert(cid:4) Der
Gro(cid:5)teil der Informationen zu einem laufenden Proze(cid:5) wird mit den Task(cid:2)
Instanzen gespeichert(cid:16) eine Identi(cid:6)kation(cid:3) der zugeh(cid:0)orige Proze(cid:5) und Task(cid:3)
die Proze(cid:5)instanz(cid:3) der Benutzer(cid:3) ein Zeitstempel(cid:3) sowie der Status der Be(cid:2)
arbeitung entsprechend des obigen Ablaufmodells(cid:4) Au(cid:5)erdem werden alle
Form(cid:2)Instanzen mitzugeh(cid:0)origer Proze(cid:5)instanz(cid:3) demTypder Formundeine
Referenz zu den Daten(cid:3) sowie dem Task(cid:3) von dem die Form derzeit bearbei(cid:2)
tet wird(cid:3) in einer Tabelle verwaltet(cid:4) Eine Form(cid:2)Instanz entsteht(cid:3) wenn in
einemTaskeineneueFormgeneriertwird(cid:4) IneinerImplementierungmitak(cid:2)
tiven Datenbanken werden die A(cid:0)nderungen der Proze(cid:5)statusinformationen
in diesen Tabellen zur Triggerung der Regeln verwendet(cid:4)
(cid:0)(cid:1)(cid:2)(cid:1)(cid:2)(cid:8) U(cid:7)bersetzung in Datenbank(cid:6)Trigger
In diesem Abschnitt wird die Realisierung des oben beschriebenen Ablauf(cid:2)
modells mit aktiven Datenbanken dargestellt(cid:4) Analog zu dem im vorigen
Abschnitt beschriebenen Ausfu(cid:0)hrungsmodell gibt es fu(cid:0)r jeden der Schritte
eine Gruppevon Regeln(cid:3) dieaus der Work(cid:1)ow(cid:2)Beschreibung generiert wird(cid:4)
Fu(cid:0)r jeden Flow wird eine Regel generiert(cid:3) die den Transport(cid:21) der Forms
(cid:20)
von einem Task zum n(cid:0)achsten durchfu(cid:0)hrt(cid:4) Diese Regel triggert nach erfolg(cid:2)
reicher Pru(cid:0)fung der Postcondition eines Tasks(cid:4) Dies entspricht dem dritten
Schritt in obigem Ausfu(cid:0)hrungsmodell(cid:4) Die folgende Regel spezi(cid:6)ziert einen
Flow einer Form des Typs form i von task A nach task B(cid:3) wobei die Form
gesendet wird(cid:3) wenn die Bedingung (cid:0)ow(cid:1)condition erfu(cid:0)llt ist(cid:4)
(cid:9)
create trigger (cid:0)ow n step(cid:8)
after update of status on form i
when new(cid:1)status(cid:9)(cid:10)finished(cid:10)
and new(cid:1)type(cid:9)form j and new(cid:1)task (cid:9) task A and (cid:0)ow(cid:1)condition
update new set task (cid:9) task B(cid:7)
DieRegelfeuert(cid:3)wennsichdasStatusfeldinderTabelleform iver(cid:0)andert(cid:4)
Die Bedingung ist erfu(cid:0)llt(cid:3) wenn der neue Wert des status (cid:26)(cid:6)nished(cid:26) ist(cid:23) in
diesem Fall wird das task(cid:2)Feld der Form auf den Nachfolgetask gesetzt(cid:4)
S(cid:0)amtliche Regeln k(cid:0)onnen wie diese aus (cid:6)xen Schablonen aufgebaut wer(cid:2)
den(cid:3) das Fu(cid:0)llen u(cid:0)bernimmt ein Compiler(cid:3) der die Regeln aus der De(cid:6)nition
des Work(cid:1)ows erzeugt(cid:4)
De folgenden Regeln werden aus den einzelnen Taskbeschreibungen er(cid:2)
zeugt(cid:16)
post(cid:5)task rule(cid:6) DieseRegeltriggert(cid:3) wennderTaskabgeschlossenist(cid:3)und
fu(cid:0)hrt die after(cid:2)procedure aus (cid:7)Schritt (cid:13) des Ausfu(cid:0)hrungsmodells(cid:15)(cid:4)
postcondition rule(cid:6) Diese Regel testet die postconditions (cid:7)Schritt (cid:12)(cid:15)(cid:4)
precondition rule(cid:6) Diese Regel pru(cid:0)ft die Vorbedingungen fu(cid:0)r einen Task(cid:4)
Dies ist notwendig(cid:3) wenn der Task mehrere Eingangs(cid:1)ows besitzt(cid:4) Bei
jedemEintre(cid:17)eneinerFormwirddieseRegelgetriggert undu(cid:0)berpru(cid:0)ft(cid:3)
ob bereitsalle Voraussetzungen zurBearbeitung des Tasks erfu(cid:0)lltsind
(cid:7)Schritt (cid:19)(cid:15)(cid:4)
dispatch rule(cid:6) DieseRegelexistiert(cid:3)wennfu(cid:0)rdenTasknichteinkonkreter
Benutzer(cid:3) sondern eine Rolle mit einem Auswahlkriterium spezi(cid:6)ziert
wurde (cid:7)Schritt (cid:22)(cid:15)(cid:4)
Wenn das user(cid:2)Feld des Tasks ausgefu(cid:0)llt wird(cid:3) triggert die n(cid:0)achste
Regel(cid:16)
pre(cid:5)task rule(cid:6) Diese Regel fu(cid:0)hrt die before(cid:2)procedure aus(cid:4) Nach Beendi(cid:2)
gung dieser Regel wird ein Signal an das Client(cid:2)Programm (cid:7)entweder
das Benutzerinterface oder ein den Task ausfu(cid:0)hrendes Programm(cid:15) ge(cid:2)
schickt(cid:4)
Hervorzuheben ist(cid:3) da(cid:5) der Work(cid:1)owmanager nur aus all den Regeln(cid:3)
die aus der Proze(cid:5)beschreibung generiert wurden(cid:3) besteht(cid:4) Alle anderen
notwendigen Funktionen stellt die Datenbank zur Verfu(cid:0)gung(cid:4)
Mit konventionellen Programmen (cid:2) d(cid:4)h(cid:4) ohne Verwendung von aktiven
Datenbanken (cid:2) lassen sich diese Funktionalit(cid:0)aten ebenfalls implementieren(cid:3)
es stehen dabei grunds(cid:0)atzlich zwei M(cid:0)oglichkeiten mit jeweils bedeutenden
Nachteilen zur Auswahl(cid:16)
(cid:13)(cid:10)