DE60203117T2

DE60203117T2 - Signalisierung von ereignissen in arbeitsfluss-verwaltungssystemen

Info

Publication number: DE60203117T2
Application number: DE60203117T
Authority: DE
Inventors: Frank Leymann; Dieter Roller
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2001-05-12
Filing date: 2002-04-17
Publication date: 2006-05-24
Anticipated expiration: 2022-04-18
Also published as: CN1531701A; US20040177074A1; ATE290240T1; DE60203117D1; WO2002093437A2; WO2002093437A3; US7174338B2; EP1402436B1; EP1402436A2; CN1316408C

Description

1. HINTERGRUND DER ERFINDUNG
1.1 GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft ein Mittel und ein Verfahren zur Verbesserung der Robustheit und zur Erleichterung des Umgangs mit Arbeitsflussverwaltungssystemen oder einem Computersystem mit vergleichbarer Funktionalität (work flow management system, WFMS) zur Signalisierung von Ereignissen.
1.2 BESCHREIBUNG UND NACHTEILE DES STANDES DER TECHNIK
Der Bereich der Arbeitsflussverwaltungssysteme (WFMS) stellt ein neues technologisches Gebiet mit zunehmender Bedeutung dar. Die WFMS unterstützen die Modellierung und die Ausführung von Geschäftsprozessen. In einer WFMS-Umgebung ausgeführte Geschäftsprozesse legen fest, wer in einem Netzwerk von Arbeitsobjekten ein Arbeitsobjekt bearbeitet und welche Ressourcen hierfür genutzt werden. Die einzelnen Arbeitsobjekte können über eine Vielzahl verschiedener Computersysteme verteilt sein, die durch einen bestimmten Netzwerktyp miteinander verbunden sind.
Das Softwareprodukt „IBM MWSeries Workflow" (zuvor unter der Bezeichnung IBM FlowMark) stellt ein solches typisches modernes, anspruchsvolles und leistungsfähiges Arbeitsflussverwaltungssystem dar. Es unterstützt die Modellierung von Geschäftsprozessen als Aktivitätennetzwerk. Dieses Aktivitätennetzwerk, das Prozessmodell, ist als gerichteter, azyklischer, gewichteter und farbiger Graph dargestellt. Die Knoten des Graphen stellen die durchgeführten Aktivitäten dar. Die Linien des Graphen, welche die Steuerungswege darstellen, beschreiben die potenzielle Abfolge der Aktivitäten. Die Definition des Prozessgraphen erfolgt über die Flow-Definition-Sprache (Flow Definition Language, FDL) von IBM MQSeries Workflow oder über den integrierten Grafikeditor.
Die Laufzeitkomponente des Arbeitsflussverwaltungssystems benutzt dieses Prozessmodell als Vorlage zur Erzeugung von Prozessobjekten. Jedem Prozessobjekt ist ein Satz von Variablen zugeordnet, die üblicherweise als Kontext bezeichnet werden. Diese Werte werden entweder von demjenigen bereitgestellt, der das Prozessobjekt über die entsprechende Anforderung anfordert, oder sie werden durch Programme abgerufen, welche die verschiedenen Aktivitäten realisieren, oder sie ergeben sich aus der Vorgeschichte eines bestimmten Prozessobjekts. Der Kontext für ein bestimmtes Prozessobjekt ist eindeutig. Eine bestimmte wichtige Information innerhalb dieses Kontextes stellt die Prozessobjektkennung dar, welche ein Prozessobjekt eindeutig kennzeichnet. Hierbei ist anzumerken, dass Prozessobjektkennungen normalerweise nur innerhalb des Satzes von Prozessobjekten eindeutig sind, die von einem bestimmten Prozessmodell abgeleitet werden.
Ereignisaktivitäten sind besonders wichtige Aktivitätstypen. Eine Ereignisaktivität ermöglicht es, ein Prozessobjekt bis zur Signalisierung warten zu lassen. Das Signal, oder anders gesagt das Ereignis, kann zwar im WFMS erzeugt werden, jedoch liegt seine Quelle normalerweise außerhalb des Arbeitsflussverwaltungssystems. Nach dem Empfangen dieses Signals speichert das Arbeitsflussverwaltungssystem die erhaltene Information als Kontextinformation (in diesem Fall im Ausgangsspeicher der Ereignisaktivität) und fährt mit der Navigation fort.
Die Signalisierung des Ereignisses erfolgt durch eine entsprechende Signalanforderung an das Arbeitsflussverwaltungssystem. Diese Signalanforderung kann durch ein Programm erzeugt werden, welches die durch das Arbeitsflussverwaltungssystem bereitgestellte Anwendungsprogrammierschnittstelle verwendet, oder durch das Senden einer vom Arbeitsflussverwaltungssystem definierten Nachricht an das Arbeitsflussverwaltungssystem, mit welcher eine solche Signalanforderung üblicherweise transportiert werden kann. Die Signalisierungsanforderung muss unabhängig davon, wie die Signalisierung erfolgt, die entsprechende Prozessobjektkennung desjenigen Prozessobjekts, in welchem das Ereignis wartet, sowie die Ereigniskennung enthalten. Diese Information ist dafür erforderlich, dass das Arbeitsflussverwaltungssystem das richtige Prozessobjekt und das richtige Ereignis innerhalb des Prozessmodells finden kann. Wenn der Absender der Signalanforderung nicht die Ereigniskennung und möglicherweise sogar nicht einmal die Prozessobjektkennung kennt, muss der Absender diese Information erhalten. Zu diesem Zweck stellt die Arbeitsflussverwaltung Abfragemittel bereit, mittels derer der Absender im Eingabespeicher nach der Ereignisaktivität suchen kann. Der Ersteller des Prozessmodells hat dafür zu sorgen, dass der Eingabespeicher der Ereignisaktivität die entsprechenden Werte enthält, von denen die Prozessobjektkennung abgeleitet werden kann.
Cugola, G. et al. beschreiben in „Exploiting an event-based infrastructure to develop complex distributed systems", IEEE Comput. Soc., Los Alamitos, Kalifornien, USA, S. 261 bis 270, ISBN 0-8186-8386-6 eine ereignisbasierte Infrastruktur für ein komplexes verteiltes System, insbesondere die zur Realisierung des OPSS-Arbeitsflussverwaltungssystems benutzte ereignisbasierte verteilte Java-Infrastruktur (Java Eventbased Distributed Infrastructure, JEDI). Ereignisse enthalten keine Informationen über ihre Empfänger, und die Ermittlung der Empfänger erfolgt dynamisch durch einen Ereignisverteiler (event dispatcher).
Dieser Ansatz nach dem Stand der Technik weist mehrere Nachteile auf, insbesondere, wenn ein Ereignis durch Senden einer Nachricht an das Arbeitsflussverwaltungssystem signalisiert wird:

• Der Signalisierer des Ereignisses muss dem Arbeitsflussverwaltungssystem anzeigen, dass die Anforderung zur Signalisierung eines Ereignisses dient; das bedeutet, dass der Anfordernde die durch das Arbeitsflussverwaltungssystem definierte Struktur der Nachricht beachten muss. Diese Struktur erfordert normalerweise bestimmte Indikatoren wie beispielsweise den Befehl, welchen die Nachricht darstellt, an bestimmten Stellen der Nachricht; zum Beispiel das Zeichenfolgesignal im ersten Feld der Nachricht. Dazu ist es erforderlich, dass ein vorhandenes nachrichtenorientiertes Programm des Signalisierenden dafür eingerichtet sein muss, wenn das Signal nun durch ein Arbeitsflussverwaltungssystem verarbeitet werden soll; ein solcher Ansatz lässt sich nicht immer realisieren. Ein anderer Ansatz zur Lösung dieses Problems besteht in der Verwendung eines Übersetzungsprogramms, welches die Originalnachricht des Signalisierenden in die spezielle Nachricht für die Arbeitsflussverwaltung umsetzt; mit diesem Ansatz nimmt nicht nur die Komplexität des Gesamtsystems zu (wodurch die Wartung und die Verwaltung des Systems komplizierter werden), sondern es wird auch die Erzeugung eines Signals erschwert.
• Der Signalisierer muss über die Prozessobjektkennung des Zielprozessobjekts verfügen. Falls dies nicht möglich sein sollte, muss der Signalisierende die entsprechende Information (Daten im Eingangsspeicher des Ereignisses) vom Arbeitsflussverwaltungssystem erhalten. Hierfür muss der Signalisierer den Ereignisnamen kennen, damit er die entsprechende Abfrage für das Arbeitsflussverwaltungssystem formulieren kann. Das ist insofern nachteilig, als jede an dem Modell vorgenommene Änderung wie z.B. die Änderung des Ereignisnamens Programmänderungen am Signalisiererteil bedingen (z.B. die Übernahme des neuen Ereignisnamens).
• Der Signalisierer muss den Ereignisnamen (gemäß der WFMS-Nomenklatur) auch dann kennen, wenn er die Prozessobjektkennung kennt. Die Kenntnis des Namens beinhaltet auch eine gewisse Kenntnis der Struktur des Prozessmodells; zum Beispiel kann das Prozessmodell ein und denselben Namen im Rahmen desselben Prozessmodells mehrmals verwenden, wenn beispielsweise aus mehreren einfacheren Prozessmodellen komplexere Prozessmodelle erstellt werden.

Die oben aufgeführten Mängel zeigen deutlich, dass beim gegenwärtigen Stand der Technik eine enge Kopplung zwischen dem Signalisierer eines Ereignisses und dem Arbeitsflussverwaltungssystem bestehen muss, was sich darin äußert, dass der Signalisierer über die Information Bescheid wissen muss, über welche das Arbeitsflussverwaltungssystem verfügt. Aus den oben angeführten Gründen ist diese Situation nicht erwünscht. Es müsste möglich sein, im Arbeitsflussverwaltungssystem alle Informationen anzugeben, die zur Verarbeitung einer nahezu beliebigen Nachricht für das Signalisieren eines Ereignisses erforderlich sind. Ferner müsste es möglich sein, Signalisierungsereignisse für eine beliebige Ereignissignalisierung zum WFMS zu senden, ohne dass dieses Signal die WFMS-Anforderungen erfüllt. Es sollte möglich sein, dass ein beliebiger Signalisierer nicht die konkrete Art des Empfängers (das heißt, des Adressaten) der Signalisierungsanforderungen zu kennen braucht. Dann kann man den Signalisierer unabhängig vom Empfänger entwickeln.
Die Schwächen der Ansätze nach dem Stand der Technik in diesem Problembereich kommen noch stärker zu Tage, wenn es um typische Internetszenarien geht, die üblicherweise als C2B-(Consumer-to-Business) oder B2B-(Business-to-Business)Geschäftsprozesse bezeichnet werden. Es ist klar, dass in diesen Szenarien die enge Kopplung zwischen dem Signalisierer und dem Arbeitsflussverwaltungssystem überhaupt nicht wünschenswert ist.
1.2 ZIELSETZUNGEN DER ERFINDUNG
Die Erfindung geht von der Zielsetzung aus, dass die Ereignissignalisierer nicht mehr über die Information verfügen müssen, die zum Auffinden des entsprechenden auf den Aufruf wartenden Ereignisses im entsprechenden Prozessobjekt erforderlich ist.
2. ÜBERBLICK ÜBER DIE ERFINDUNG UND DEREN VORTEILE
Die gesetzten Ziele der Erfindung werden durch die Hauptansprüche erreicht. Weitere vorteilhafte Anordnungen und Ausführungsarten der Erfindung sind in den entsprechenden Unteransprüchen dargelegt.
Die vorliegende Erfindung stellt ein computergestütztes Verfahren zur Ermittlung eines Adressaten einer Signalisierungsanforderung in einem Arbeitsflussverwaltungssystem oder einem Computersystem mit einer vergleichbaren Funktionalität (WFMS) bereit.
Nach dem Empfangen einer Signalisierungsanforderung, welche einen Satz von Signaldatenelementen bereitstellt, verhindert die vorliegende Erfindung, dass die Signaldatenelemente eine genaue Bezeichnung eines Adressaten dieser Signalisierungsanforderung umfassen müssen.
Um zu ermitteln, ob eine bestimmte Ereignisaktivität eines Prozessobjekts, welches das Objekt eines Prozessmodells eines Geschäftsprozesses ist, der potenzielle Adressat der zu ermittelnden Signalisierungsanforderung ist, wird vorgeschlagen zu ermitteln, ob das Prozessmodell die Spezifikation einer Ereigniskennung umfasst. Diese Ereigniskennungsspezifikation gemäß der vorliegenden Erfindung umfasst eine Untergruppe der Signaldatenelemente. Anhand der Bewertung der Ereigniskennungsspezifikation lässt sich indirekt entscheiden, ob es sich bei der Ereignisaktivität um den Adressaten der Signalisierungsanforderung handelt.
Die vorgeschlagene Lehre beseitigt alle oben erwähnten Mängel. Daraus, dass der Sender einer Signalisierungsanforderung aufgrund des vorgeschlagenen Ansatzes keinen bestimmten Adressaten mehr angeben muss, ergibt sich der weitere Vorteil, dass es für eine einzige Signalisierungsnachricht mehrere Adressaten geben kann.
3. KURZBESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein Beispiel eines durch einen Prozessgraphen dargestellten Prozessmodells.
2 stellt eine Ausführungsform der Signaturen von Aktivitäten als Eingangs- und Ausgangsspeicher und den Weg der Daten von einer Aktivität über Datenwege zu einer anderen Aktivität dar.
3 veranschaulicht die Struktur einer aktivierten Ereignisaktivität, die auf eine zu verarbeitende Nachricht wartet.
4 stellt die Definition einer Nachricht dar, welche den Inhalt der Nachricht mittels einer XML-Schema-Definition beschreibt und so ein Ereignis signalisiert.
5 veranschaulicht die Einzelheiten der erforderlichen Spezifikationen, die mittels der Flow Definition Language (Arbeitsflussdefinitionssprache) des Programms MQSeries Workflow beschrieben werden.
6 veranschaulicht ein weiteres Verfahren zur Ermittlung der Struktur einer Nachricht, welche ein Ereignis signalisiert.
7 veranschaulicht ein weiteres Verfahren zur Erkennung desjenigen Ereignisses, welches das Ziel einer Signalisierungsnachricht ist.
4. BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSART
In den Zeichnungen und in der Beschreibung wird eine bevorzugte Ausführungsart der Erfindung dargelegt, bei der die verwendete Terminologie nur als allgemeingültige Beschreibung und nicht als Einschränkung zu verstehen ist, obwohl spezielle Begriffe verwendet werden.
Die vorliegende Erfindung kann in Form von Hardware, Software oder einer Kombination von Hardware und Software realisiert werden. Hierfür ist jede Art von Computersystem bzw. jede andere zum Ausführen der hier beschriebenen Verfahren eingerichtete Vorrichtung geeignet. Eine typische Kombination von Hardware und Software könnte ein Universalcomputersystem mit einem Computerprogramm sein, welches in das System geladen und ausgeführt wird und das Computersystem so steuert, dass dieses die hier beschriebenen Verfahren ausführt. Die vorliegende Erfindung kann auch in ein Computerprogrammprodukt integriert werden, welches alle Merkmale umfasst, die es zur Realisierung der hier beschriebenen Verfahren befähigen, und welches nach dem Laden in ein Computersystem in der Lage ist, diese Verfahren auszuführen.
Unter dem Computerprogrammmittel oder Computerprogramm ist im vorliegenden Zusammenhang jeder Ausdruck in einer beliebigen Sprache, Code oder Notation eines Satzes von Anweisungen zu verstehen, welche ein System zur Datenverarbeitung und so zur Ausführung einer bestimmten Funktion befähigen, entweder direkt oder nach einer bzw. beiden der folgenden Aktivitäten:

a) Umwandlung in eine andere Sprache, Code oder Notation;
b) Darstellung in einer anderen materiellen Form.

Die vorliegende Erfindung wird auf der Grundlage des Arbeitsflussverwaltungssystems „MQSeries Workflow" von IBM dargestellt. Stattdessen kann natürlich jedes andere WFMS verwendet werden. Die vorliegende Lehre bezieht sich außerdem auf jegliche andere Art von Systemen, welche WFMS-Funktionalitäten nicht als getrenntes WFMS, sondern im Rahmen eines anderen Systems bereitstellen.
Gemäß der vorliegenden Lehre ist es von Vorteil, wenn die WFMS-Einheit als Verarbeitungseinheit zur Ermittlung des/der Adressaten einer Signalisierungsanforderung aufgrund der vom Signalisierenden bereitgestellten Datenelemente dient. Die vorliegende Erfindung kann jedoch auch in anderen Szenarien eingesetzt werden, bei denen nicht die WFMS-Einheit selbst, sondern eine andere Einheit zur Verarbeitung der Anforderung zur Signalisierung eines Ereignisses dient.
4.1 EINLEITUNG
Im Folgenden werden anhand des WFMS „MQSeries Workflow" von IBM kurz die Grundprinzipien eines Arbeitsflussverwaltungssystems beschrieben:
Aus Sicht eines Unternehmens gewinnt die Verwaltung von Geschäftsprozessen immer mehr an Bedeutung: Durch Geschäftsprozesse oder kurz Prozesse wird gesteuert, durch wen und unter Nutzung welcher Ressourcen ein bestimmtes Arbeitsobjekt bearbeitet wird, d.h., wie ein Unternehmen seine unternehmerischen Ziele erreicht. Ein WFMS kann sowohl die Modellierung von Geschäftsprozessen als auch deren Ausführung unterstützen.
Die Modellierung eines Geschäftsprozesses als syntaktische Einheit, die direkt durch ein Softwaresystem unterstützt wird, ist äußerst wünschenswert. Darüber hinaus kann das Softwaresystem auch als Übersetzungsprogramm (Interpreter) fungieren, in den ein solches Modell eingegeben wird: Das auch als Prozessmodell oder Arbeitsflussmodell bezeichnete Modell kann dann dargestellt werden, sodass je nach der Darstellung des Modells die Folge der einzelnen Arbeitsschritte festgelegt werden kann. Ein solches Modell eines Geschäftsprozesses kann als Muster für eine Klasse in einem Unternehmen auszuführender gleichartiger Prozesse aufgefasst werden; es stellt ein Schema dar, dass alle möglichen Ausführungsvarianten einer bestimmten Art von Geschäftsprozess beschreibt. Ein Objekt eines solchen Modells und dessen Beschreibung stellen einen individuellen Prozess dar, d.h. eine konkrete situationsabhängige Ausführung einer durch das Modell beschriebenen Variante. Ein WFMS erleichtert die Verwaltung von Geschäftsprozessen. Es stellt ein Mittel zur Beschreibung von Modellen von Geschäftsprozessen (Erstellungszeit) dar und steuert auf der Grundlage eines entsprechenden Modells die Geschäftsprozesse (Laufzeit). Im Folgenden werden das Metamodell des WFMS „MQSeries Workflow" von IBM sowie die Bedeutung und die Beschreibung dieser syntaktischen Elemente beschrieben.
Ein Prozessmodell ist eine vollständige Darstellung eines Prozesses und umfasst ein Prozessdiagramm und die Einstellungen, welche die den Diagrammkomponenten zugrunde liegende Logik definieren. Ein Prozessmodell in „MQSeries Workflow" enthält folgende wichtige Komponenten:

• Prozesse
• Aktivitäten
• Blöcke
• Steuerungsabläufe
• Steuerungswege
• Datenspeicher
• Datenstrukturen
• Bedingungen
• Programme
• Personal

Im Folgenden werden nicht alle der aufgeführten Elemente beschrieben.
Aktivitäten stellen die grundlegenden Elemente des Metamodells dar. Eine Aktivität stellt einen Geschäftsvorgang dar, der in gewisser Hinsicht eine eigene semantische Einheit darstellt.
Im WFMS „MQSeries Workflow" besteht ein Prozessmodell aus den folgenden verschiedenen Aktivitäten:
Programmaktivität: Zu ihr gehört ein Programm zur Ausführung der Aktivität. Das Programm wird aufgerufen, wenn die Aktivität gestartet wird. Bei einem vollautomatischen Arbeitsfluss führt das Programm die Aktivität ohne menschliches Eingreifen aus. Ansonsten muss der Benutzer die Aktivität starten, indem er sie aus einer Laufzeitarbeitsliste auswählt. Das durch das Programm ermittelte Ergebnis kann als Bedingung zum Verlassen der Programmaktivität oder als Bedingung zum Fortsetzen weiterer Aktivitäten dienen.
Prozessaktivität: Zu ihr gehört ein (Teil-)Prozess zur Ausführung der Aktivität. Der Prozess wird aufgerufen, wenn die Aktivität gestartet wird. Eine Prozessaktivität stellt eine Möglichkeit dar, einen Satz von Aktivitäten mehrfach zu verwenden, die in verschiedenen Prozessen auftreten. Das durch den Prozess ermittelte Ergebnis kann als Bedingung zum Verlassen der Prozessaktivität oder als Bedingungen zum Fortsetzen weiterer Aktivitäten dienen.
Die Abfolge der Steuerungsvorgänge, d.h. der Steuerungsablauf im Verlauf eines laufenden Prozesses, legt die Abfolge der auszuführenden Aktivitäten fest. Das Arbeitsflussverwaltungsprogramm von „MQSeries Workflow" folgt einem Pfad durch den Prozess, wenn das Ergebnis der Prüfung der Startbedingungen, der Beendigungsbedingungen und der Fortsetzungsbedingungen WAHR lautet.
Steuerungswege verbinden Aktivitäten in einem Prozessmodell miteinander. Über die Steuerungswege wird die Abfolge der Aktivitäten und die Datenübertragung zwischen den Aktivitäten definiert. Da Aktivitäten nicht einfach willkürlich ausgeführt werden können, sind sie über die Steuerungswege miteinander verbunden. Ein Steuerungsweg ist als gerichtete Verbindungslinie zwischen zwei Aktivitäten aufzufassen; die Aktivität am Endpunkt des Steuerungsweges kann erst dann beginnen, wenn die Aktivität am Startpunkt des Steuerungsweges (erfolgreich) beendet worden ist. Die Steuerungswege modellieren somit den potenziellen Steuerungsablauf im Geschäftsprozessmodell. Standardsteuerungswege geben den weiteren Steuerungsablauf an, wenn die Prüfung der Fortsetzungsbedingung keines der eine Aktivität verlassenden Steuerungswege den Wert WAHR ergibt. Durch Standardsteuerungswege ist das Arbeitsflussmodell in der Lage, mit außergewöhnlichen Ereignissen fertig zu werden. Datenwege zeigen den Datenfluss in einem Arbeitsflussmodell an. Ein Datenweg beginnt bei einer Aktivität bzw. einem Block und führt zu einer Aktivität bzw. einem Block als Ziel. Es kann angegeben werden, dass Ergebnisdaten zu einem oder zu mehreren Zielen weitergeleitet werden sollen. Ein Ziel kann über mehr als einen Datenweg verfügen.
Die Prozessdefinition beinhaltet die Modellierung von Aktivitäten, Steuerungswegen zwischen den Aktivitäten, Eingangs-/Ausgangsspeichern und Datenwegen. Ein Prozess wird als gerichteter azyklischer Graph dargestellt, dessen Knoten die Aktivitäten und dessen Verbindungslinien die Steuerungs-/Datenwege bedeuten. Der Graph wird über einen integrierten Grafikeditor erstellt. Die Datenspeicher werden in Form von Datenstrukturen mit Namen bezeichnet. Diese Datenstrukturen wiederum werden durch die Funktion DataStructureDefinition benannt. Programmaktivitäten werden mittels Programmen realisiert. Die Programme werden durch die Funktion Program Definition registriert. Blöcke sind genauso wie Prozesse aufgebaut, z.B. wie Aktivitäten, Steuerungswege usw. Sie tragen jedoch keine Namen und weisen eine eigene Beendigungsbedingung auf. Wenn die Beendigungsbedingung nicht erfüllt ist, wird der Block noch einmal gestartet. Der Block führt somit eine DO-UNTIL-Funktion aus. Prozessaktivitäten werden als Prozesse ausgeführt. Diese Teilprozesse sind getrennt als normale, mit Namen benannte Prozesse mit allen ihren normalen Eigenschaften definiert. Prozessaktivitäten bieten bei der Definition von Prozessen eine große Flexibilität. Dadurch kann ein Prozess nicht nur durch eine ständig verfeinerte Aufgliederung von Aktivitäten in Programm- und Prozessaktivitäten aufgebaut (von oben nach unten – top-down) werden, sondern auch aus einer Reihe vorhandener Prozesse zusammengesetzt (von unten nach oben – bottom-up) werden.
Alle Programme, in denen Programmaktivitäten laufen, werden durch die Programmregistrierungsfunktion definiert. Für jedes Programm werden der Name des Programms, seine Positionsadresse und seine Aufrufzeichenfolge registriert. Die Aufrufzeichenfolge setzt sich aus dem Programmnamen und der zum Programm übermittelten Befehlszeichenfolge zusammen.
1 zeigt als Beispiel für ein solches Prozessmodell schematisch die Struktur eines solchen Prozessgraphen. Die Aktivitäten (A1 bis A5) sind in Kreisen dargestellt, wobei deren Name üblicherweise den Zweck der Aktivität beschreibt. Aktivitäten adressieren die unterschiedlichen durch sie zu bearbeitenden Aufgaben auf vielfältige Weise. Sie können diese verschiedenen Anforderungen durch unterschiedliche Ausführungsformen ausführen. Programmaktivitäten werden durch ein ihnen zugeordnetes Programm ausgeführt; Programmaktivitäten wie beispielsweise das Objekt 100 werden durch einen anderen Prozess 101 ausgeführt, und Blöcke wie beispielsweise das Objekt 102 werden durch ein Makro mit einer integrierten DO-UNTIL-Schleife ausgeführt. Die Steuerungswege p12, p13, p24, p35 und p45 werden durch Pfeile dargestellt; die Spitze des Pfeils beschreibt die Richtung, in welcher die Steuerung durch den Prozess fortschreitet. Diejenige Aktivität, bei welcher der Steuerungsweg beginnt, heißt Quellenaktivität; die Aktivität, bei welcher er endet, heißt Zielaktivität. Wenn von einer Aktivität mehrere Steuerungswege abgehen, kann dies parallele Bearbeitung bedeuten.
4.2 SPEICHER UND DATENWEGE
2 zeigt die beiden Aktivitäten A 200 und B 210, welche Teil eines komplexeren Prozessmodells sein können. Jeder der beiden Aktivitäten A 200 und B 210 ist ein Eingangsspeicher 220 bzw. 240 zugeordnet; der Aktivität A 200 ist außerdem noch ein Ausgangsspeicher 230 zugeordnet. Bei einer grundlegenden Variante der vorliegenden Erfindung kann der Eingangs- und Ausgangsspeicher einer Aktivität prinzipiell als Signatur der Aktivität angesehen werden. Die Aktivität erhält die zu ihrer Ausführung erforderlichen Daten vom Eingangsspeicher und schreibt die von ihr selbst erzeugten Daten, die von anderen Aktivitäten benötigt werden, in den Ausgangsspeicher. Die Speicher stehen, wie das auch bei Signaturen üblich ist, nur der betreffenden Aktivität, d.h. nur lokal, zur Verfügung. Zum Beispiel stehen der Eingangsspeicher 220 und der Ausgangsspeicher 230 nur der zugehörigen Aktivität A 200 zur Verfügung. Wenn also die Aktivität B 210 zum Beispiel Daten aus dem Ausgangsspeicher 230 der Aktivität A 200 benötigt, müssen diese Daten aus dem Ausgangsspeicher 230 der Aktivität A 200 in den Eingangsspeicher 240 der Aktivität B 210 gespeichert werden.
Zum Kopieren der Daten von einer Aktivität zu einer anderen gibt es einen Datenweg 260, der in 2 durch einen gestrichelten Pfeil dargestellt ist. Der Datenweg 260 von 2 zeigt an, dass aus dem Ausgangsspeicher 230 der Aktivität A 200 alle oder ein Teil der Daten in den Eingangsspeicher 240 der Aktivität B 210 kopiert werden sollen.
Der Ausgangsspeicher einer Aktivität und der Eingangsspeicher einer anderen Aktivität weisen jedoch im Allgemeinen unterschiedliche Datenstrukturen auf, da sie zum Beispiel unterschiedliche Datenfelder enthalten. Daher wird in 2 eine Speichertabelle 250 bereitgestellt, die definiert, welche Datenfelder des Ausgangsspeichers 230 der Aktivität A 200 in welche Datenfelder des Eingangsspeichers 240 der Aktivität B 210 kopiert werden sollen. In der Speicherliste 250 ist auch verzeichnet, ob die Daten vor dem Kopieren z.B. in den Eingangsspeicher 240 der Aktivität B 210 durch das Arbeitsflussverwaltungssystem transformiert werden müssen.
4.3 EREIGNISAKTIVITÄTEN
Ereignisaktivitäten stellen einen anderen Aktivitätstyp dar, der durch Arbeitsflussverwaltungssysteme unterstützt wird. Durch sie kann ein Prozessobjekt so lange in Wartestellung gehalten werden, bis das Ereignis durch ein Signal beispielsweise von außerhalb des Arbeitsflussverwaltungssystems angekündigt wird. Nach dem Empfangen des Signals verarbeitet das Arbeitsflussverwaltungssystem die Anforderung und fährt mit der Navigation fort. Eine Ereignisaktivität weist die meisten Eigenschaften der Programm- und Prozessaktivitäten auf. Sie ist mit einem Eingangs- und einem Ausgangsspeicher verbunden. Sowohl für die Steuerungswege als auch für die Datenwege kann sie Quelle und Ziel sein. Die Ereignisaktivität weist eine Startbedingung auf, und es kann für sie eine Gültigkeitsdauer festgelegt werden.
Dies ist in 3 durch den Ausschnitt 301 aus einem komplexeren Prozessmodell schematisch dargestellt. Eine Ereignisaktivität 300 geht in den Wartezustand über, sobald der Steuerungsweg 360 die Ereignisaktivität erreicht. wenn bei der Ausführung eines Prozessmodells noch kein Steuerungsweg zur Ereignisaktivität führt, geht diese sofort in den Wartezustand über, nachdem das Prozessobjekt erzeugt worden ist. Die Ereignisaktivität verbleibt so lange in diesem Zustand, bis das Ereignis signalisiert wird. Ein Client 310 sendet eine entsprechende Anforderung 350 zum Arbeitsflussverwaltungssystem und signalisiert das Ereignis, auf welches die Aktivität 300 wartet. Diese Anforderung muss (1) im jeweiligen Prozessobjekt als Adressat das entsprechende Ereignis (2) benennen. Außerdem kann das Ereignissignal Daten liefern, die im Ausgangsspeicher 320 gespeichert sind, sodass die vom Ereignissignalisierer bereitgestellten Daten dem Prozessobjekt zur Verfügung gestellt werden können. wenn das Ereignis korrekt signalisiert wurde, wird die Navigation fortgeführt. Weitere Einzelheiten zu Ereignisaktivitäten sind zu finden in Leymann/Roller, Production Workflow: Concepts and Techniques, Prentice Hall, New Jersey, ISBN, und in der US-Patentschrift US 6 065 009 mit dem Titel „Events as Activities in Process Models of Workflow Management Systems".
4.4 DEFINIEREN VON NACHRICHTEN MITTELS XML
4 zeigt die Definition einer Nachricht mittels der XML-Schema-Definition (Einzelheiten zu XML und XML-Schema siehe http://www.w3.org). Die Aufgabe der Nachricht besteht darin, der in 5 definierten Ereignisaktivität ein Ereignis zu signalisieren. Die Definition einer benutzerdefinierten XML-Struktur beginnt mit dem Schlüsselwort complexType 400. Der Name der Struktur ist SignalMessage 410. Die Struktur setzt sich aus einer Menge von Elementen 420, einem Elementnamen 430 und einem Datentyp 440 des Elements zusammen.
4.5 VERARBEITUNG DER SIGNALISIERUNG EINES EREIGNISSES
5 zeigt, wie die vorliegende Erfindung mittels der Flow Definition Language (FDL) von MQSeries Workflow realisiert/bezeichnet werden kann, welches ein Arbeitsflussverwaltungssystem nach dem Stand der Technik ist, das vom Einreicher der vorliegenden Patentanmeldung vertrieben wird. FDL dient hier nur als Beispiel; stattdessen kann die Signalisierung von Ereignissen auch auf jede andere Art dargestellt werden. Auch das zugrunde liegende Metamodell dient nur der Veranschaulichung; stattdessen können auch andere Metamodelle verwendet werden.
Der Kern der vorliegenden Erfindung besteht darin, eine Technologie bereitzustellen, bei der ein beliebiger Signalisierer eines Ereignisses den Adressaten einer Signalisierungsanforderung, das auf das Ereignis wartende konkrete Prozessobjekt, überhaupt nicht zu kennen braucht. Dadurch braucht der Signalisierer die Prozessobjektkennung des auf das Ereignis wartenden konkreten Prozessobjekts und die Kennung der Ereignisaktivität innerhalb des entsprechenden Prozessmodells nicht zu speichern.
Eine grundlegende Erkenntnis der vorliegenden Erfindung besteht darin, dass die vom Signalisierer innerhalb der Signalisierungsanforderung bereitgestellten Datenelemente oder eine Teilmenge davon durch das WFMS selbst genutzt werden können, um das konkrete Prozessobjekt (oder die Prozessobjekte) und/oder die konkrete Ereignisaktivität (oder Ereignisaktivitäten), die als Adressat(en) des Ereignisses in Frage kommen, eindeutig zu kennzeichnen.
Um das WFMS zur Ausführung dieser Kennzeichnungsaufgabe in die Lage zu versetzen, wird vorgeschlagen, das eine Ereignisaktivität umfassende Prozessmodell um Spezifikationen zu erweitern, welche die von der Signalisierungsanforderung bereitgestellte Menge von (einem oder mehreren) Datenelementen definieren, die zum Kennzeichnen eines bestimmten Prozessobjekts des Prozessmodells und dieser Ereignisaktivität als Adressat dienen. Nach dem Empfangen der Signalisierungsanforderung durch das WFMS ist das WFMS in Kenntnis gesetzt, dass das Prozessmodell diese vordefinierten Ereigniskennungsspezifikationen und die zusammen mit der Signalisierungsanforderung bereitgestellten konkreten Datenelemente dazu verwenden wird, den konkreten Adressaten des Ereignisses zu ermitteln.
Das Beispiel zeigt die Definition einer Ereignisaktivität, welche die vorliegende Erfindung anwendet.
Die Definition DATENSTRUCTURE 500 kennzeichnet eine Datenstruktur durch den Namen SignalMessage 501. Die Datenstruktur nimmt (über das Schlüsselwort XML) 502 Bezug auf ein XML-Schema SignalMessage 503 (das in 4 definiert wurde). Diese Datenstruktur definiert die Struktur der Nachricht, welche als Signal zur Übermittlung der Ereignisaktivität 520 dient.
Die Definition DATASTRUCTURE 510 kennzeichnet eine Datenstruktur durch den Namen EventOutput. Die Datenstruktur enthält ein Feld AmountOffered vom Typ INTEGER 512. Diese Datenstruktur wird als Ausgangsspeicher der Ereignisaktivität 520 verwendet; das Feld AmountOffered dient als Ziel für das entsprechende in der Signalisierungsnachricht übertragene Feld.
Die Ereignisaktivität wird durch das Schlüsselwort EVENT_ACTIVITY 520 definiert; der Name der Ereignisaktivität ist ReceiveOffer 522. Der Ausgangsspeicher der Ereignisaktivität wird durch das Schlüsselwort OUTPUT definiert, welches die Datenstruktur EventOutput 524 als Struktur für den Ausgangsspeicher kennzeichnet.
Das Schlüsselwort SIGNAL 540 kennzeichnet alle mit der Signalisierung des Ereignisses zusammenhängenden Eigenschaften; insbesondere umfasst dieser Abschnitt die durch die vorliegende Erfindung vorgeschlagenen Ereigniskennungsspezifikationen. Beim vorliegenden Beispiel zeigt das Schlüsselwort an, dass die Datenstruktur SignalMessage 526 die Struktur der das Ereignis signalisierenden Nachricht darstellt.
Das Schlüsselwort MESSAGE_IDENTIFICATION 536 zeigt dem Arbeitsflussverwaltungssystem an, wie die Struktur, d.h. das Layout, der Nachricht ermittelt werden muss. Der Parameter XML_SCHEMA 528 zeigt an, dass der durch die Nachricht vorgegebene Name des XML-Schemas verwendet werden soll (dies ist für XML-Nachrichten typisch, damit die Verwendung eines XML-Parsers zum Analysieren der Nachricht ermöglicht wird). Weitere mögliche Werte des Parameters MESSAGE_IDENTIFICATION werden im Folgenden erörtert. Wenn die Signalisierungsnachricht das angegebene XML-Schema aufweist, verwendet das Arbeitsflussverwaltungssystem diese Nachricht als potenzielle Signalisierungsnachricht für diese Aktivität ReceiveOffer. Das bedeutet, dass die Signalisierungsnachricht möglicherweise als Signalisierungsnachricht für die Ereignisaktivität ReceiveOffer 522 in Frage kommt, wenn sie das SML-Schema SignalMessage aufweist.
Das Schlüsselwort PROCESS_INSTANCE 542 kennzeichnet die Felder in der Signalisierungsnachricht, die zur Kennzeichnung des Prozessobjekts verwendet werden sollen. Im vorliegenden Beispiel dient hierzu das Feld ContractId 530 aus der XML-Nachricht. Allgemein kann das Prozessobjekt durch einen beliebigen komplexen Boole'schen Ausdruck gekennzeichnet werden, in welchem Werte von Datenelementen innerhalb der Signalisierungsnachricht und der Datenelemente aus dem Umfeld des Prozessobjekts enthalten sind.
Das Schlüsselwort TARGET_IDENTIFICATION 544 definiert einen Ausdruck 532; wenn eine Prüfung dieses Ausdruck das Ergebnis WAHR liefert, ist die Signalisierungsnachricht für die Ereignisaktivität bestimmt. Somit ermöglicht dieses Schlüsselwort die Kennzeichnung der konkreten Aktivität innerhalb des Prozessmodells, dessen Ereignis durch das WFMS signalisiert werden soll. Der Ausdruck setzt sich aus einem oder mehreren Feldern in der Signalisierungsnachricht zusammen. Beim vorliegenden Beispiel ist die Signalisierungsnachricht für diese Aktivität bestimmt, wenn das Feld ActionId in der Signalisierungsnachricht die Zeichenfolge ReceiveOffer enthält.
Das Schlüsselwort MAP 546 sorgt dafür, dass Felder aus der Signalisierungsnachricht im Ausgangsspeicher der Aktivität in eine Tabelle eingetragen werden. Im vorliegenden Beispiel wird das Feld AmountOffered aus der Signalisierungsnachricht in den Ausgangsspeicher kopiert. Andere Möglichkeiten bestehen darin, die Felder der Signalisierungsnachricht in einen globalen bzw. Hauptspeicher zu kopieren (Einzelheiten hierzu siehe Leymann/Roller: Production Workflow: Concepts and Techniques, Prentice Hall, 2000).
Eine weitere Möglichkeit zur Kennzeichnung der Struktur einer Signalisierungsnachricht ist in 6 dargestellt. Wenn das Ergebnis der Prüfung des durch sie definierten Ausdrucks WAHR lautet, weist die Signalisierungsnachricht die Struktur auf, die der Spezifikation der Struktur der Signalisierungsnachricht entspricht. Das bedeutet, wenn das Feld messageId 610 den Wert 512 enthält, weist die Signalisierungsnachricht die für sie definierte Struktur auf und kommt als mögliche Signalisierungsnachricht für die Ereignisaktivität ReceiveOffer in Frage.
6 schlägt eine Lösung für ein weiteres Problem vor. In bestimmten Umgebungen sind potenzielle Adressaten nur innerhalb bestimmter Domänen eindeutig. Beispiele hierfür sind Prozessobjektkennungen, die nur innerhalb einer Gruppe von Prozessobjekten eindeutig sind, die von einem gemeinsamen Prozessmodell abgeleitet wurden.
Um mit solchen Situationen fertig zu werden, wird vorgeschlagen, dass die Ereigniskennungsspezifikation solche Spezifikationen umfasst, die nach Prüfung den Umfang an möglichen Adressaten einzuschränken erlaubt, welche Prozessobjekte eines gemeinsamen Prozessmodells bearbeiten sollen. Die besondere Ausführungsart 620 in 6 ermöglicht, eine Kennung eines Prozessmodells aus einem oder mehreren Datenelementen der Signalisierungsnachricht (im vorliegenden Beispiel der Parameter businessProcessID, siehe 4) zu erstellen. Demzufolge werden nur solche Prozessobjekte als potenzielle Adressaten angesehen, die von Prozessmodellen mit dieser erstellten Kennung stammen; natürlich werden die konkreten Adressaten durch die anderen Spezifikationen innerhalb der Ereigniskennungsspezifikationen noch genauer gekennzeichnet.
Ein Ereignis innerhalb eines Prozessobjektes wird durch eine Aktivitätsobjektkennung eindeutig gekennzeichnet. Damit liegt ein alternativer Ansatz für die Spezifikation des Ziels einer Signalisierungsnachricht vor. Diese Spezifikation ist lediglich eine Kombination der Spezifikationen PROCESS_INSTANCE und TARGET_IDENTIFICATION. 7 zeigt, wie eine solche Spezifikation aussehen könnte. Das Schlüsselwort ACTIVITY_IDENTIFICATION 710 kennzeichnet ein oder mehrere Felder innerhalb der Signalisierungsnachricht zur Erstellung (auch durch einen komplexeren Ausdruck) der Kennung eines Ereignisaktivität, die als Adressat für das signalisierte Ereignis in Frage kommt. Beim vorliegenden Beispiel wird das Feld EventId 720, das Bestandteil der Signalisierungsnachricht ist, direkt zu Erstellung der Ereignisaktivitätskennung verwendet, welche diesen Adressaten darstellt.
Während der Laufzeit werden die obigen Spezifikationen durch das WFMS wie folgt verwendet:
Zuerst ermittelt das WFMS die Struktur der Signalisierungsnachricht. Hierzu müssen alle MESSAGE_DEFINITIONSs für alle Ereignisaktivitäten in allen Prozessmodellen untersucht werden. Wenn die Struktur der Signalisierungsnachricht nicht ermittelt werden kann, geht das WFMS davon aus, dass es sich bei der Nachricht nicht um eine Ereignissignalisierungsnachricht handelt, und ergreift andere erforderliche Maßnahmen.
Zweitens ermittelt das WFMS dasjenige Prozessobjekt, das Ziel der Signalisierungsnachricht ist.
Drittens ermittelt das WFMS dasjenige Aktivitätsobjekt innerhalb des Prozessobjekts, das Ziel der Signalisierungsnachricht ist.
Viertens kopiert das WFMS Felder aus der Signalisierungsnachricht in den Kontext des Prozessobjekts.

Claims

Computergestütztes Verfahren zum Ermitteln eines Empfängers einer Signalisierungsanforderung in einem Arbeitsflussverwaltungssystem (Workflow Management System, WFMS) oder einem Computersystem mit vergleichbarer Funktionalität, wobei das WFMS ein Prozessobjekt verwaltet, das ein Objekt eines Prozessmodells (301) eines Geschäftsprozesses darstellt, und wobei das Verfahren ferner gekennzeichnet ist durch das Prozessmodell, welches mindestens eine Ereignisaktivität (300) umfasst, und bei welchem das WFMS in einem ersten Schritt eine Signalisierungsanforderung empfängt (350), wobei die Signalisierungsanforderung eine Gruppe von Signaldatenelementen (430) bereitstellt; und die Signaldatenelemente keine explizite Beschreibung zur Kennzeichnung des Prozessobjektes oder der Ereignisaktivität als Empfänger der Signalisierungsanforderung umfasst; und bei welchem das WFMS in einem zweiten Schritt ermittelt, ob das Prozessmodell eine Beschreibung der Ereigniskennzeichnung umfasst, welche eine Untergruppe der Signaldatenelemente beinhaltet; und, wenn dies der Fall ist, die Beschreibung der Ereigniskennzeichnung bewertet, um indirekt zu entscheiden, ob es sich bei dieser Ereignisaktivität um einen Empfänger der Signalisierungsanforderung handelt; und bei welchem das WFMS in einem dritten Schritt die Signalisierungsanforderung der Ereignisaktivität als Empfänger bereitstellt.
Computergestütztes Verfahren zum Ermitteln eines Empfängers einer Signalisierungsanforderung nach Anspruch 1, bei welchem die Beschreibung der Ereigniskennzeichnung eine erste Beschreibung (542) umfasst, welche anhand einer Bewertung entscheidet, ob es sich bei dem Prozessobjekt um den Empfänger der Signalisierungsanforderung handelt.
Computergestütztes Verfahren zum Ermitteln eines Empfängers einer Signalisierungsanforderung nach Anspruch 2, bei welchem die Beschreibung der Ereigniskennzeichnung eine zweite Beschreibung (544, 720) umfasst, welche anhand einer Bewertung entscheidet, ob es sich bei der Ereignisaktivität des Prozessobjekts um den Empfänger der Signalisierungsanforderung handelt.
Computergestütztes Verfahren zum Ermitteln eines Empfängers einer Signalisierungsanforderung nach Anspruch 3, bei welchem die erste und/oder zweite Beschreibung ein Boole'sches Prädikat umfasst, das ferner Datenelemente eines Kontextes des Prozessobjekts beinhaltet.
Computergestütztes Verfahren zum Ermitteln eines Empfängers einer Signalisierungsanforderung nach Anspruch 3, bei welchem die zweite Beschreibung (720) aus der ersten Untergruppe der Signaldatenelemente eine erste Kennung ableitet, die mit einer die Ereignisaktivität kennzeichnenden zweiten Kennung verglichen wird, um zu entscheiden, ob es sich bei der Ereignisaktivität des Prozessobjekts um den Empfänger der Signalisierungsanforderung handelt.
Computergestütztes Verfahren zum Ermitteln eines Empfängers einer Signalisierungsanforderung nach Anspruch 2, bei welchem die Beschreibung der Ereigniskennzeichnung eine vierte Beschreibung (620) umfasst, welche durch Bewertung den Umfang der potenziellen Empfänger auf Prozessobjekte des Prozessmodells beschränkt.
Computergestütztes Verfahren zum Ermitteln eines Empfängers einer Signalisierungsanforderung nach Anspruch 3, bei welchem die Beschreibung der Ereigniskennzeichnung eine dritte Beschreibung (536) umfasst, die anhand der Art der Signalisierungsanforderung entscheidet, ob es sich bei dem Prozessobjekt um den Empfänger der Signalisierungsanforderung handelt.
System, welches geeignete Mittel zum Ausführen der Schritte des Verfahrens nach einem der obigen Ansprüche 1 bis 7 umfasst.
Datenverarbeitungsprogramm zum Ausführen in einem Datenverarbeitungssystem, wobei das Datenverarbeitungsprogramm Teile eines Softwarecodes zum Durchführen des Verfahrens nach einem der vorigen Ansprüche 1 bis 7 umfasst, wenn das Programm in dem Computer läuft.
Computerprogrammprodukt, das in einem computerlesbaren Medium gespeichert ist und computerlesbare Programmmittel umfasst, mittels derer ein Computer veranlasst wird, ein Verfahren nach einem der vorigen Ansprüche 1 bis 7 durchzuführen, wenn das Programm in dem Computer läuft.