DE19955718A1

DE19955718A1 - Paralleler Datenbank-Support für Workflow-Management-Systeme

Info

Publication number: DE19955718A1
Application number: DE19955718A
Authority: DE
Inventors: Frank Leymann; Dieter Roller
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1998-11-17
Filing date: 1999-11-04
Publication date: 2000-05-31
Also published as: US6415297B1

Abstract

Die vorliegende Erfindung bezieht sich auf ein Mittel, um den parallelen Datenbank-Support in einem Workflow-Management-System (WFMS) bereitzustellen. DOLLAR A Die Erfindung empfiehlt Mittel, um einen Teil der zentralen System-Datenbank von einem Workflow-Management-System (WFMS) oder einem System mit vergleichbarer Funktionalität so zu definieren, daß dieser von einem Datenbankverwaltungssystem (DBMS) in einer parallelen Datenbank gehalten wird. Das WFMS enthält wenigstens ein Prozeßmodell. Es wird außerdem empfohlen, daß die Definitionsmittel zur Definition, welche Teile der zentralen System-Datenbank in der parallelen Datenbank gespeichert werden, in den WFMS-Konfigurationsspezifikationen enthalten sind, wie beispielsweise in diesem Prozeßmodell.

Description

1. Hintergrund der Erfindung 1.1 Bereich der Erfindung

Die vorliegende Erfindung bezieht sich auf Workflow-Manage ment-Systeme (WFMS).

Die Erfindung bezieht sich insbesondere auf Mittel zur Bereitstellung eines verbesserten Datenbank-Supports in einem Workflow-Management-System (WFMS).

1.2 Beschreibung und Nachteile des Stands der Technik

Ein neuer Technologiebereich von zunehmender Bedeutung ist der Bereich der Workflow-Management-Systeme (WFMS). WFMS unterstützen die Modellierung und Ausführung von Geschäftsprozessen. Geschäftsprozesse steuern, welcher Teil der Arbeit aus einem Netzwerk mit Teilen von Arbeit von wem durchgeführt wird und welche Betriebsmittel für diese Arbeit benutzt werden. So beschreibt beispielsweise ein Geschäftsprozeß, wie ein Unternehmen seine Geschäftsziele erreichen wird. Die einzelnen Teile der Arbeit könnten durch eine Vielzahl von verschiedenen Computersystemen verteilt werden, die über irgendeine Art von Netzwerk miteinander verbunden sind.

Der Prozeß, ein neues Produkt zu konzipieren, zu entwickeln und herzustellen und der Prozeß, ein vorhandenes Produkt zu ändern oder anzupassen, bietet für Produktmanager und Ingenieure viele Herausforderungen, da sie das Produkt in gleichbleibender Qualität oder besser noch in besserer Qualität zu niedrigsten Kosten und termingerecht auf den Markt bringen müssen. Viele Unternehmen sind sich darüber im klaren, daß der konventionelle Produktdesign-Prozeß nicht ausreicht, um diese Anforderungen zu erfüllen. Sie verlangen frühe Einbindung von Herstellungs-Engineering, Kosten- Engineering, Logistikplanung, Beschaffung, Herstellung, Kundendienst, und sie verlangen Unterstützung beim Design. Sie verlangen außerdem die Planung und Kontrolle der Produktdaten während der Entwicklung, der Freigabe und der Herstellung.

Die korrekte und wirksame Ausführung von Geschäftsprozessen innerhalb eines Unternehmens, beispielsweise die Entwicklungs- oder Produktionsprozesse, ist für ein Unternehmen von größter Wichtigkeit und hat wesentlichen Einfluß auf den Gesamterfolg des Unternehmens am Markt. Deshalb müssen diese Prozesse ähnlich wie Technologieprozesse betrachtet werden und getestet, optimiert und überwacht werden. Die Verwaltung von solchen Prozessen wird für gewöhnlich von einem computergestützten Prozeß oder Workflow-Management-System durchgeführt und unterstützt.

In D. J. Spoon: "Project Management Environment", IBM Technical Disclosure Bulletin, Vol. 32, No. 9A, February 1990, Seiten 250 bis 254, wird eine Prozeßverwaltungsumgebung beschrieben, die eine Betriebsumgebung, Datenelemente und Anwendungsfunktionen sowie Anwendungsprozesse enthält.

In R. T. Marshak: "IBM's FlowMark, Object-Oriented Workflow for Mission-Critical Applications", Workgroup Computing Report (USA), Vol. 17, No. 5, 1994, Seiten 3 bis 13, ist der Objektcharakter der IBM FlowMark als ein Client-/Server- Produkt, das auf einem echten Objektmodell aufgebaut ist, das auf die aufgabenkritische Entwicklung und den Einsatz der Produktionsprozeßanwendung abzielt, beschrieben.

In H. A. Inniss und J. H. Sheridan: "Workflow Management Based on an Object-Oriented Paradigm", IBM Technical Disclosure Bulletin, Vol. 37, No. 3, March 1994, Seite 185, sind weitere Aspekte der objektorientierten Modellierung, die an den Kunden angepaßt wird und Änderungen beschrieben.

In F. Leymann und D. Roller: "Business Process Management with Flowmark", Digest of papers, Cat. No. 94CH3414-0, Spring COMPCON 94, 1994, Seiten 230 bis 234 ist das Computer Process Management Tool aus dem Stand der Technik, IBM FlowMark, beschrieben. Das Meta-Modell von IBM FlowMark wird ebenso wie die Implementierung von IBM FlowMark vorgestellt. Die Möglichkeiten von IBM FlowMark, Geschäftsprozesse zu modellieren, werden ebenso wie ihre Ausführung erörtert. Das Produkt IBM FlowMark ist für verschiedene Computerplattformen lieferbar, und die Dokumentation für IBM FlowMark ist in jeder IBM-Filiale erhältlich.

In F. Leymann: "A meta model to support the modeling and execution of processes", Proceedings of the 11th European Meeting on Cybernetics and System Research EMCR92, Vienna, Austria, April 21 to 24, 1992, World Scientific 1992, Seiten 287 bis 294 wird ein Meta-Modell zur Steuerung von Geschäftsprozessen vorgestellt und ausführlich erörtert.

Das "IBM FlowMark for OS/2", Dokumentennummer GH 19-8215-01, IBM Corporation, 1994, das bei jeder IBM-Vertriebsstelle er hältlich ist, stellt ein typisches, modernes, hochentwickeltes und leistungsfähiges Workflow-Management- System dar. Es unterstützt die Modellierung von Geschäftsprozessen als ein Netz von Aktivitäten; siehe beispielsweise "Modeling Workflow", Dokumentennummer SH 19- 8241, IBM Corporation, 1996. Als eine weitere Information zu Workflow Management Systems, die in IBM-Vertriebsstellen erhältlich sind, ist eine noch besonders zu erwähnen: IBM MQSeries Concepts and Architecture, Dokumentennummer GH 12- 6285; IBM MQSeries Getting Started with Buildtime, Dokumentennummer SH 12-6286; IBM MQSeries Getting Started with Runtime, Dokumentennummer SH 12-6287. Dieses Netz von Aktivitäten, das Prozeßmodell, wird als gerichteter, azyk lischer, gewichteter, kolorierter Graph erstellt. Die Knoten des Graphen stellen die Aktivitäten oder Arbeitspositionen dar, die durchgeführt werden. Die Ränder des Graphen, die Steuersteckverbinder, beschreiben die potentielle Ausführungssequenz der Aktivitäten. Die Definition des Prozeßgraphen erfolgt über die IBM FlowMark Definition Language (FDL) oder den integrierten Grafikeditor. Die Laufzeitkomponente des Workflow Managers interpretiert den Prozeßgraphen und verteilt die Ausführung der Aktivitäten an die richtige Person am richtigen Ort, indem beispielsweise Aufgaben entsprechend der jeweiligen Person einer Arbeitsliste zugeordnet werden, wobei diese Arbeitsliste als digitale Daten innerhalb des Workflow- oder Prozeß- Management-Computersystem gespeichert ist.

In F. Leymann und W. Altenhuber: "Managing business processes as an information resource", IBM Systems Journal, Vol. 32 (2), 1994, ist die mathematische Theorie, die dem IBM FlowMark Produkt zugrunde liegt, beschrieben.

In D. Roller: "Verifikation von Workflows in IBM FlowMark", in J. Becker und G. Vossen (Hrsg.): "Geschaeftsprozessmodellierung und Workflows", International Thompson Publishing, 1995, ist die Bedingung und die Möglichkeit für die Verifikation von Workflows beschrieben. Des weiteren wird die Funktion der grafischen Animation zur Verifikation der Prozeßlogik vorgestellt wie sie im IBM FlowMark Produkt beschrieben ist.

Um ein computergestütztes Prozeß-Management-System zu imple mentieren, müssen zuerst die Geschäftsprozesse analysiert werden und dann ist als Ergebnis dieser Analyse ein Prozeßmodell als ein Netz von Aktivitäten zu erstellen, die dem Geschäftsprozeß entsprechen. Im IBM FlowMark Produkt werden die Prozeßmodelle nicht in ein ablauffähiges umgewandelt. Mit Laufzeit wird eine Instanz des Prozesses von dem Prozeßmodell erstellt, die sogenannte Prozeßinstanz. Diese Prozeßinstanz wird dann dynamisch von dem IBM FlowMark Produkt interpretiert.

Normalerweise führt ein Benutzer mit dem Workflow- Management-System über eine grafische Benutzerschnittstelle, die die von dem Benutzer durchzuführenden Aufgaben als Symbole darstellt, einen Dialog. Die Arbeit für eine bestimmte Aufgabe startet der Benutzer durch Doppelklicken auf das entsprechende Symbol, das seinerseits die Programmimplementierung der Aktivität startet.

Ein weiterer Technologiebereich ist die Technologie der Datenbankverwaltung. Die meisten Workflow-Systeme benutzen eine relationale Datenbank, um Informationen mit der Build- Time-Information zu verwalten, wie ihre Prozeßmodelle oder die Laufzeitinformation, wie der Status der Geschäftsprozesse. WFMSs nehmen deutlich an Komplexität und verwalteten Daten zu: immer mehr Geschäftsprozesse sind in WFMSs zu implementieren, was in einer deutlich größeren Anzahl von Prozeßmodellen resultiert, die von WFMSs zu bearbeiten sind; auch die Anzahl der kooperierenden WFMSs, d. h. der Grad der Verteilung verzeichnet einen dramatischen Anstieg usw. Um diesen neuen Anforderungen gerecht zu werden, muß die Interoperation von WFMS und des zugrundeliegenden Datenbankverwaltungssystems (Database Management System) (DBMS) verbessert werden. Spezifische Fragen sind die Fragen nach Gleichzeitigkeit, Parallelität und Verfügbarkeit.

Es müssen Techniken wie Hotpooling und Application-Server- Clustering angeboten werden, um Leistung und Verfügbarkeit zu verbessern. Es wurde jedoch noch kein Verfahren vorgeschlagen, um die Leistung über die Interoperation der WFMSs und der zugrundeliegenden Datenbankverwaltungssysteme (DBMS) zu verbessern. Außerdem sind die WFMSs aus dem Stand der Technik nicht in der Lage, den Konflikt zwischen dem verteilten Verfahren dieser WFMSs selbst und der zentralen Annäherung der DBMS zu reduzieren. Dieser Konflikt spitzt sich mit zunehmender Datenbankgröße immer mehr zu.

1.3 Ziel der Erfindung

Ziel der Erfindung ist es, die Zusammenarbeit der WFMSs und der zugrundeliegenden DBMS zu verbessern.

2. Zusammenfassung und Vorteile der Erfindung

Die Ziele der Erfindung werden durch Anspruch 1 gelöst.

Die Erfindung bezieht sich auf Mittel, um einen Teil der zentralen Systemdatenbank (system-repository) eines Workflow-Management-Systems (WFMS) oder eines Systems mit vergleichbarer Funktionalität, das von einem Datenbankverwaltungssystem (DBMS) in einer Datenbank gehalten werden muß, zu definieren. Das WFMS enthält ein oder eine Vielzahl von WFMS Instanzen, die in einem oder in einer Vielzahl von Computersystemen ausgeführt werden. Das WFMS enthält wenigstens ein Prozeßmodell. Die aktuelle Lehre empfiehlt, den Teil der zentralen Systemdatenbank zu definieren, der in einer parallelen Datenbank gehalten werden muß. Es wird außerdem empfohlen, daß die zur Durchführung notwendigen Definitionsmittel in den WFMS Konfigurationsspezifikationen, wie beispielsweise in diesem Prozeßmodell, enthalten sind.

Die Einführung der parallelen Datenbanktechnologie in die Workflow-Management-Systeme erlaubt letzteren, den steigenden Anforderungen und Erwartungen zu entsprechen. Die Speicherung von Teilen dieser zentralen System-Datenbank in parallelen Datenbanken führt zu deutlichen Verbesserungen in bezug auf Parallelität, Gleichzeitigkeit und Verfügbarkeit. Parallele Datenbanken ermöglichen es, gleichzeitig an Teilen von Daten zu arbeiten, und die Zeit, die für die Operation benötigt wird, auf eine verwaltbare Größe zuzuschneiden. Unterteilte Tabellen ermöglichen es einem Programm, gleichzeitig an Teilen mit Daten zu arbeiten, während der gleichzeitige Zugriff auf sonstige Programme in anderen Plattenspeicherbereichen erlaubt wird. Daten, auf die häufiger zugegriffen wird, können von den restlichen Daten getrennt und in einem eigenen Plattenspeicherbereich abgelegt werden und einen anderen Gerätetyp benutzen. Durch eine einzelne Abfrage in einer unterteilten Datenbank können mehrere parallele Operationen ausgelöst werden. Diese kleineren Abfragen laufen gleichzeitig in mehreren Pro zessoren ab, die parallel auf die Daten zugreifen. Dadurch reduziert sich die abgelaufene Zeit für eine Abfrage.

Da die Definitionsmittel im Prozeßmodell enthalten sind, wird eine sehr hohe Empfindlichkeit erreicht. Auf der Basis von individuellen Prozeßmodellen und einzelnen Tabellen kann mit der aktuelle Lehre festgelegt werden, ob die Tabellen der zentralen System-Datenbank zu parallelisieren sind oder nicht.

Insbesondere die Einführung der parallelen, relationalen Inter-Partition-Datenbanktechnologie, gemäß einem weiteren Ausführungsbeispiel der aktuellen Erfindung, bietet in bezug auf Parallelität, Gleichzeitigkeit und Verfügbarkeit die größten Vorteile. Diese Art der parallelen Datenbanktechnologie erlaubt eine optimale Nutzung von parallelen Prozessoren. Außerdem kann diese einfach mit allen anderen Arten parallelen Verarbeitungsverfahren wie Multi-Taskbetrieb und intra-parallele Datenbanktechnologie kombiniert werden.

Gemäß einem weiteren Ausführungsbeispiel der aktuellen Erfindung enthält dieser Teil der zentralen System-Datenbank wenigstens eine Tabelle mit einer Sequenz von Attributen, wobei die Tabelle einen oder mehrere Datensätze mit Sequenzen von Attributwerten behält. In dieser Umgebung enthalten die Definitionsmittel erste Definitionsmittel, um wenigstens eines dieser Attribute als Partitionierungscode von dieser Tabelle anzugeben, der von DBMS benutzt wird, um dieser Datensatz in einer Partition zu behalten, die von dem Attributwert dieses Partitionierungscodes für parallelen Datenbankzugriff gekennzeichnet wird. Zusätzlich oder anstatt enthalten diese Definitionsmittel zweite Definitionsmittel, um wenigstens ein zusätzliches Attribut als Partitionierungscode von dieser Tabelle anzugeben.

Basierend auf diesem zusätzlichen Funktionsmerkmal wird es möglich, ein bereits vorhandenes Tabellenattribut als Parti tionierungscode zu benutzen oder ein zusätzliches Attribut zu Partitionierungszwecken zu benutzen.

Weitere Vorteile werden erreicht, indem die Systemidentifikation dieser WFMS Instanzen als Partitionierungscode oder die Erstellungszeit von diesem Datensatz als Partitionierungscode benutzt wird.

Diese Attribute resultieren in idealen Partitionierungscodes, da dieselbe WFMS Systemidentifikation oder ähnliche Zeitwerte ein inhärentes Verhältnis zwischen den Einträgen angeben, mit denen es möglich ist, unabhängige Aktivitäten in bezug auf den Datenbankzugriff zu trennen, der in optimaler Parallelität resultiert.

Gemäß einem weiteren Ausführungsbeispiel der aktuellen Erfindung wird empfohlen, einen Partitionierungscode für eine oder mehrere Tabellen anzugeben, die dieses Prozeßmodell enthalten bzw. für eine oder mehrere Tabellen, die Ausführungsinstanzen von diesem Prozeßmodell enthalten bzw. für eine oder mehrere Tabellen, die eine Prüfspur (audit-trail) von diesem Prozeßmodell enthalten bzw. für eine oder mehrere Tabellen, die Arbeitspositionen bezogen auf Ausführungsinstanzen von diesem Prozeßmodell enthalten. Alle diese Tabellen sind Ziele von sehr starken Zugriffen. Deshalb verbessern parallelisierte Zugriffsfähigkeiten bezogen auf diese Tabellen die Vorteile der aktuellen Erfindung.

Die Ziele der Erfindung werden durch Anspruch 9 gelöst. Die Erfindung bezieht sich auf ein Workflow-Management-System (WFMS) oder auf ein System von vergleichbarer Funktionalität, das einen Teil der zentralen System- Datenbank von diesem WFMS in einer Datenbank mittels eines Datenbankverwaltungssystems (DBMS) behält. Gemäß der Erfindung enthält dieses WFMS ein oder eine Vielzahl von WFMS-Instanzen in einem oder in einer Vielzahl von Computersystemen. Dieses WFMS enthält wenigstens ein Prozeßmodell und behält diesen Teil der zentralen System- Datenbank in einer parallelen Datenbank.

Die oben erwähnten Vorteile finden ebenfalls auf dieses wei tere Ausführungsbeispiel Anwendung.

3. Kurzbeschreibung der Zeichnungen

Fig. 1 zeigt eine vereinfachte Struktur von einem solchen WFMS, das eine Vielzahl von WFMS Instanzen und ihre Interoperation mit einer DBMS enthält, die die zentrale System-Datenbank des WFNS in einer Datenbank speichert.

Fig. 2 zeigt eine einzelne logische Tabelle, die als Satz partitionierter Tabellen gespeichert wird.

Fig. 3 zeigt die Konzeptionsstruktur eines Datenbankverwaltungssystems, das parallele Datenbanken benutzt, die verschiedenen Clients den Eindruck eines einzelnen logischen Datenbankverwaltungssystem geben.

Fig. 4 faßt ein WFMS gemäß der aktuellen Erfindung zusam men, das Teile der Tabellen speichert, die die zentrale System-Datenbank in einer parallelen Datenbank bilden, die die logische Ansicht eines einzelnen Datenbankverwaltungssystem mit Bezug auf die verschiedenen WFMS Instanzen bietet. Durch die Nutzung der inter-parallelen Datenbanktechnologie werden die parallelisierten Teile der System- Datenbank in physisch unterschiedlichen Partitionen gespeichert, die ein Maximum an Parallelität, Gleichzeitigkeit und Verfügbarkeit bieten.

4. Beschreibung des bevorzugten Ausführungsbeispiels

Die aktuelle Erfindung ist auf dem Workflow-Management- System FlowMark von IBM aufgebaut. Selbstverständlich kann statt dessen ein anderes WFMS benutzt werden. Die aktuelle Lehre kann auch auf eine andere Systemart angewendet werden, die WFMS Funktionalitäten nicht als separates WFMS bietet sondern innerhalb einer anderen Systemart.

4.1 Einführung in die Workflow-Management-Systeme (WFMS)

Es folgt eine kurze Ausführung zu den Basiskonzepten eines Workflow-Management-Systems, das auf dem WFMS FlowMark von IBM basiert.

Vom Gesichtspunkt eines Unternehmens aus wird die Verwaltung von Geschäftsprozessen zunehmend wichtiger: Geschäftsprozesse oder der Geschäftsprozeß zur kurzen Kontrolle, welches Teil der Arbeit von wem durchgeführt wird, und welche Betriebsmittel für diese Arbeit eingesetzt werden, d. h. ein Geschäftsprozeß beschreibt, wie ein Unternehmen seine Geschäftsziele erreichen wird. Ein WFMS kann beides unterstützen, das Modellieren der Geschäftsprozesse und ihre Ausführung.

Die Modellierung eines Geschäftsprozesses als syntaktische Einheit auf eine Art und Weise, die direkt von einem Softwaresystem unterstützt wird, ist ausgesprochen wünschenswert. Das Software-System kann außerdem auch als Interpreter arbeiten, der hauptsächlich als Input eines solchen Modells dient. Das Modell, ein Prozeß- oder Workflow-Modell, kann dann die Instanz bilden, und die einzelne Sequenz der Arbeitsschritte, die von dem Kontext der Instanzbildung (instantiation) des Modells abhängen, können festgelegt werden. Ein solches Modell eines Geschäftsprozesses kann als Schablone für eine Kategorie ähnlicher Prozesse erkannt werden, die innerhalb eines Unternehmens ausgeführt werden. Es ist ein Schema, das alle möglichen Ausführungsvarianten einer bestimmten Art von Geschäftsprozeß beschreibt. Eine Instanz eines solchen Modells und seine Interpretation stellt einen individuellen Prozeß dar, d. h. eine konkrete, kontextabhängige Ausführung von einer Variante, die von dem Modell vorgeschrieben wird. Ein WFMS erleichtert die Verwaltung von Geschäftsprozessen. Es liefert ein Mittel, um Modelle der Geschäftsprozesse zu beschreiben (Erstellungszeit), und es steuert Geschäftsprozesse, die auf einem zugehörigen Modell (Laufzeit) basieren. Das Meta-Modell von dem WFMS FlowMark von IBM, beispielsweise die syntaktischen Elemente, die zur Beschreibung der Geschäftsprozeßmodelle bereitgestellt werden und die Bedeutung und Interpretation dieser syntaktischen Elemente ist nachstehend beschrieben.

Ein Prozeßmodell ist eine komplette Darstellung eines Prozesses, der ein Prozeßdiagramm und die Einstellungen enthält, die die Logik hinter den Komponenten des Diagramms definieren. Mittels verschiedener Dienste, die von FlowMark bereitgestellt werden, werden diese Erstellungszeit- Definitionen von den Prozeßmodellen in Prozeßschablonen umgewandelt, die von FlowMark mit Laufzeit genutzt werden. Zu den wichtigen Komponenten eines FlowMark Prozeßmodells gehören:

Prozesse
Aktivitäten
Blöcke
Control Flows
Konnektoren
Daten-Container
Datenstrukturen
Bedingungen
Programme
Personal

Es werden im folgenden nicht alle diese Elemente beschrieben.

Unter diesem Hintergrund ist ein Prozeß, der von einem Prozeßmodell innerhalb FlowMark modelliert wird, eine Sequenz von Aktivitäten, die abgeschlossen werden müssen, damit die Aufgabe erfüllt wird. Der Prozeß ist das Element in der höchsten Ebene eines FlowMark Workflow-Modells. In einem FlowMark Prozeß kann folgendes definiert werden:

- Wie die Arbeit von Aktivität zu Aktivität abgearbeitet wird.
- Welche Personen führen Aktivitäten aus und welche Pro gramme benutzen sie.
- Ob irgendwelche andere Prozesse, sogenannte Unterpro zesse, in dem Prozeß verschachtelt sind.

Aktivitäten sind die fundamentalen Elemente des Meta- Modells. Eine Aktivität stellt eine Geschäftsaktion dar, die unter einem bestimmten Gesichtspunkt eine eigenständige semantische Entität darstellt. Bei dem Modell des Geschäftsprozesses kann es eine Feinstruktur geben, die dann ihrerseits über ein Modell dargestellt wird, oder ihre Einzelheiten sind von einem Modellierungsgesichtspunkt eines Geschäftsprozesses aus gesehen, überhaupt nicht von Interesse. Die Verfeinerung von Aktivitäten über Prozeßmodelle ermöglichen sowohl das Modellieren von Ge schäftsprozessen von unten nach oben als auch von oben nach unten. Aktivitäten, die ein Schritt in einem Prozeß sind, stellen einen Teil der Arbeit dar, die die zugewiesene Person abschließen kann, indem sie ein Programm oder einen anderen Prozeß startet. In einem Prozeßmodell gehört die folgende Information zu jeder Aktivität:

- Welche Bedingungen müssen erfüllt werden, bevor die Aktivität beginnen kann.
- Ob die Aktivität manuell von einem Benutzer gestartet werden muß oder automatisch starten kann.
- Welche Bedingung angibt, daß die Aktivität abgeschlossen ist.
- Ob die Steuerung die Aktivität automatisch verlassen kann, oder ob die Aktivität zuerst als abgeschlossen von einem Benutzer bestätigt werden muß.
- Wieviel Zeit für den Abschluß der Aktivität gewährt wird.
- Wer für den Abschluß der Aktivität verantwortlich ist.
- Welches Programm oder welcher Prozeß benutzt wird, um die Aktivität abzuschließen.
- Welche Daten als Input in die Aktivität und als Output von der Aktivität benötigt werden.

Ein FlowMark Prozeßmodell besteht aus folgenden Aktivitätsarten:
Programmaktivität: Hat ein Programm, das zur Ausführung zugewiesen wurde. Das Programm wird aufgerufen, wenn die Aktivität startet. In einem vollautomatisierten Workflow führt das Programm die Aktivität aus, ohne daß der Eingriff eines Benutzers erforderlich ist. Andernfalls muß der Benutzer die Aktivität starten, indem er diese aus einer Laufzeit-Arbeitsliste auswählt. Der Output von Programm kann in der Ausgangsbedingung (Exit) für die Programmaktivität und für die Übergangsbedingungen in andere Aktivitäten benutzt werden.
Prozeßaktivität: Hat ein (Unter-)Prozeß, der zur Ausführung zugewiesen wurde. Der Prozeß wird aufgerufen, wenn die Aktivität startet. Eine Prozeßaktivität stellt einen Weg dar, um einen Satz Aktivitäten wiederzuverwenden, der den verschiedenen Prozessen gemein ist. Der Output von dem Prozeß kann in der Ausgangsbedingung für die Prozeßaktivität und für die Übergangsbedingungen in andere Aktivitäten benutzt werden.

Der Flow of Control, d. h. der Control Flow durch einen ablaufenden Prozeß bestimmt die Sequenz, in der Aktivitäten ausgeführt werden. Der FlowMark Workflow-Manager navigiert einen Pfad durch den Prozeß, der von der Bewertung in wahren Start-, Ausgangs- und Übergangsbedingungen bestimmt wird.

Die Ergebnisse, die im allgemeinen von der Arbeit erzeugt werden, die von einer Aktivität dargestellt wird, werden in einem Output-Container plaziert, der zu jeder Aktivität gehört. Da es eine Aktivität im allgemeinen erforderlich macht, auf Output-Container von anderen Aktivitäten zuzugreifen, gehört jede Aktivität ebenfalls zu einem Input- Container. Mit Laufzeit stellen die aktuellen Werte für die formellen Parameter, die den Input-Container einer Aktivität bilden, den aktuellen Kontext von einer Instanz der Aktivität dar. Jeder Daten-Container wird von einer Datenstruktur definiert. Eine Datenstruktur ist eine geordnete Liste von Variablen, Mitglieder genannt, die einen Namen und einen Datentyp haben. Die Datenkonnektoren repräsentieren die Übertragung von Daten von Output- Containern an Input-Container. Wenn ein Datenkonnektor auf einen Output-Container trifft, und die Datenstrukturen der beiden Container genau übereinstimmen, stellt der FlowMark Workflow-Manager die Daten automatisch dar.

Konnektoren verknüpfen die Aktivitäten in einem Prozeßmodell. Mit den Konnektoren definiert man die Sequenz der Aktivitäten und die Übertragung von Daten zwischen den Aktivitäten. Da die Aktivitäten nicht beliebig ausgeführt werden können, werden sie über Kontrollkonnektoren miteinander verbunden. Ein Kontrollkonnektor kann eine gerichtete Kante zwischen zwei Aktivitäten sein. Die Aktivität am Endpunkt des Steckverbinders kann nicht starten, bevor die Aktivität am Startpunkt des Konnektors beendet ist (erfolgreich). Kontrollkonnektoren modellieren somit den potentiellen Flow of Control in einem Geschäftsprozeßmodell. Standard-Konnektoren geben an, wo der Flow of Control sein sollte, wenn die Übergangsbedingung von keinem anderen Kontrollkonnektor eine mit wahr bewertete Aktivität verläßt. Standard-Konnektoren ermöglichen es dem Workflow-Modell, mit den außergewöhnlichen Ereignissen fertig zu werden.

Datenkonnektoren geben den Datenfluß in einem Workflow- Modell an. Ein Datenkonnektor stammt von einer Aktivität oder einem Block und hat als Ziel eine Aktivität oder einen Block. Man kann angeben, daß Output-Daten in ein Ziel oder in eine Vielzahl von Zielen gehen müssen. Ein Ziel kann mehr als einen ankommenden Datenkonnektor haben.

Bedingungen sind Mittel, mit denen der Flow of Control in einem Prozeß angegeben werden kann. In FlowMark Prozeßmodellen können logische Ausdrücke definiert werden, die von FlowMark mit Laufzeit definiert werden, um zu bestimmen, ob eine Aktivität starten oder enden kann, und ob die Steuerung zur nächsten Aktivität übergehen kann.

Neben der Beschreibung des potentiellen Flow of Control und der Daten zwischen Aktivitäten kann ein Geschäftsprozeßmodell auch die Beschreibung des Aktivitätenflusses an sich zwischen "Betriebsmitteln" berücksichtigen, die normalerweise die Teile der Arbeit ausführen, die von jeder Aktivität dargestellt werden. Ein Betriebsmittel kann als ein bestimmtes Programm, eine Person, eine Rolle oder eine Organisationseinheit angegeben werden. Mit Laufzeit werden Aufgaben in Anforderungen an be stimmte Personen aufgelöst, um die bestimmten Aktivitäten auszuführen, die in den Arbeitspositionen für diese Person resultieren. Personalzuordnungen sind Mittel, um Aktivitäten an die richtigen Leute in der Sequenz zu verteilen, die von dem Control-Flow-Aspekt eines Geschäftsprozeßmodells vorgeschrieben wird. Jede Aktivität in einem Prozeß wird einem oder mehreren Mitgliedern des Personals, die in der FlowMark Datenbank definiert sind, zugewiesen. Ob eine Aktivität manuell vom Benutzer oder automatisch vom FlowMark Workflow-Manager gestartet wird, ob der Dialog mit dem Benutzer erforderlich ist, um den Vorgang automatisch abzuschließen, es muß in jedem Fall ein Mitglied des Personals dieser Arbeit zugewiesen werden. FlowMark Personaldefinitionen erfordern mehr, als die Leute in Ihrem Unternehmen in der FlowMark Datenbank zu kennzeichnen. Jeder definierten Person können Sie eine Ebene, eine Abteilung und mehrere Rollen zuweisen. Diese Attribute können mit Laufzeit benutzt werden, um Aktivitäten Leuten mit passenden Attributen zuzuordnen.

Die Prozeßdefinition enthält die Modellierung von Aktivitäten, Kontrollkonnektoren zwischen den Aktivitäten, Input-/Output-Container und Datenkonnektoren. Ein Prozeß wird als ein gerichteter, azyklischer Graph mit den Aktivitäten als Knoten und den Kontroll-/Datenkonnektoren als Kanten des Graphen dargestellt. Der Graph wird über einen integrierten, Ereignis-gesteuerten CUA-kompatiblen Grafikeditor manipuliert. Die Daten-Container werden als bezeichnete Datenstrukturen angegeben. Diese Datenstrukturen selbst werden über die DataStructure Definitionseinrichtung angegeben.

Alle Datenstrukturen, die als Schablonen für die Container mit Aktivitäten und Prozessen genutzt werden, sind über die DataStructure Definitionsstruktur definiert. Datenstrukturen sind Namen und sind als elementare Datentypen, wie beispielsweise Gleitkomma, Ganzzahl oder Zeichenkette, und als Referenzen auf vorhandene Datenstrukturen definiert. Das Verwalten von Datenstrukturen als separate Entitäten hat den Vorteil, daß alle Schnittstellen von Aktivitäten und ihre Implementierungen durchweg an einer Stelle verwaltet werden (ähnlich Header-Dateien in Programmiersprachen).

Alle Programme, die Programmaktivitäten implementieren, werden über die Program-Registration-Einrichtung definiert. Für jedes Programm ist der Name des Programms, seine Speicherstelle und die Zeichenkette zu seinem Aufruf registriert. Die Aufruf-Zeichenkette besteht aus dem Programmnamen und der Befehlskette, die an das Programm übertragen wird.

Bevor die Prozeßinstanzen erstellt werden können, muß das Prozeßmodell übersetzt werden, um die Korrektheit und die Vollständigkeit des Prozeßmodells sicherzustellen. Die übersetzte Version des Modells wird als Schablone benutzt, wenn eine Prozeßinstanz erstellt wird. Dies ermöglicht es, Änderungen am Prozeßmodell vorzunehmen, ohne daß die in Ausführung begriffenen Prozeßinstanzen beeinflußt werden. Eine Prozeßinstanz wird entweder über die graphische Schnittstelle oder über die aufrufbare Anwendungsprogrammierschnittstelle des Prozesses gestartet. Wenn ein Prozeß gestartet wird, sind die Startaktivitäten fixiert, die richtigen Leute festgelegt, und die Aktivitäten werden als Arbeitspositionen in die Arbeitsliste der ausgewählten Leute gesetzt. Wählt ein Benutzer die Arbeitsposition aus, d. h. die Aktivität, wird die Aktivität ausgeführt und aus der Arbeitsliste eines anderen Benutzers entfernt, dem die Aktivität zugeteilt wurde. Nachdem eine Aktivität ausgeführt wurde, wird ihre Ausgangsbedingung bewertet. Wird diese nicht erfüllt, wird die Ausführung der Aktivität neu geplant. Andernfalls werden alle ausgehenden Kontrollkonnektoren und die zugehörigen Übergangsbedingungen bewertet. Ein Kontrollkonnektor wird ausgewählt, wenn die Bedingung TRUE bewertet. Dann werden die Zielaktivitäten der ausgewählten Kontrollkonnektoren bewertet. Wenn ihre Startbedingungen wahr sind, werden sie in die Arbeitsliste der ausgewählten Leute gesetzt. Ein Prozeß wird als abgeschlossen betrachtet, wenn alle Endaktivitäten abgeschlossen wurden. Um sicherzustellen, daß alle Endaktivitäten beendet sind, wird eine Dead-Path-Elimination durchgeführt. Dabei werden alle Kanten im Prozeßgraphen ent fernt, die niemals erreicht werden können, da die Übergangsbedingungen versagt haben. Alle Informationen über den aktuellen Status eines Prozesses werden in der Datenbank gespeichert, die von dem Server gehalten wird. Dies erlaubt die Vorwärts-Wiederherstellung im Fall von Systemabstürzen.

Normalerweise schreibt das Workflow-Management-System einen Audit-Trail. Dieser Audit-Trail enthält für jedes wichtige Ereignis einen Datensatz, beispielsweise den Start oder den Abschluß eines Prozesses oder einer Aktivität. Hauptzweck des Audit-Trails ist es, die Historie von der Ausführung einer Prozeßinstanz zu erfassen. Somit stellt ein Audit- Trail eine Art Ausführungsprotokoll der Prozeßmodelle dar, die von WFMS ausgeführt werden. Die meisten Workflow- Management-Systeme speichern den Audit-Trail direkt in einer relationalen Datenbank.

Nachfolgend fassen wir einige der Felder zusammen, die in einem solchen Audit-Trail vorhanden sind. Die WFMSs schreiben für jedes eingetretene Ereignis einen solchen Audit-Trail.

Timestamp
Datum und Uhrzeit, an dem das Ereignis stattfand.

Ereignis
Art des Ereignisses, das dazu geführt hat, daß der Audit-Trail geschrieben wurde. Zu den typischen Ereignissen gehören der Start eines Prozesses, der Abschluß eines Prozesses, der Start einer Aktivität oder der Abschluß einer Aktivität. Auch irgendwelche Ereignisse, die während der Ausführung einer bestimmten Aktivität auftreten, sind Kandidaten für den Audit- Trail. In einem solchen Fall würde die Aktivität selbst einen Audit-Trail erzeugen. Es ist daher für die aktuelle Erfindung nicht wichtig, welche Komponente das Ereignis erzeugt und somit den Audit-Trail-Datensatz auslöst. Dies kann von dem WFMS selbst oder einem anderen Programm ausgeführt werden.

Benutzer
Identifikation des Benutzers, der das Ereignis ausgeführt oder aufgerufen hat.

Prozeßmodell-Name
Name des Prozeßmodells. Jedes Prozeßmodell wird nur durch diesen Namen identifiziert.

Prozeßinstanz-Name
Identifikation der Prozeßinstanz. Jeder Prozeß wird nur durch diesen Namen identifiziert.

Aktivitätsname
Name der Aktivität. Jede Aktivität innerhalb eines Prozeßmodells wird nur durch den Namen identifiziert. Dieses Feld wird ausgefüllt, wenn das Ereignis mit einer Aktivität verbunden wird.

Zugehöriger Objektkennzeichner
Kennzeichnet nur das Objekt, das zu dem Ereignis gehört. Es könnte der Kennzeichner einer Arbeitsposition, einer aktiven Instanz oder der Prozeßinstanz sein. Dieser Kennzeichner kann benutzt werden, um mittels der Anwendungs programmierschnittstelle des Workflow-Managements auf das Objekt zuzugreifen.

Benutzerfeld
Enthält den Wert des Benutzerfelds. Benutzerfelder stellen einen Mechanismus bereit, um Import- Benutzerdaten, die zu einer Prozeßinstanz im Audit- Trail gehören, zu speichern. Ein typisches Beispiel ist eine Kundennummer oder der Betrag eines Kredits.

4.2 Die Rolle der Datenbankverwaltungssysteme in den WFMSs

Der MQSeries Workflow ist ein Workflow-System, das auf einer relationalen Datenbanktechnologie und dem Einreihen in die Nachrichtenwarteschlange basiert. Die relationale Datenbank wird benutzt, um alle Daten, die dauerhaft sein sollen, wie beispielsweise Geschäftsprozesse, zu speichern.

Fig. 1 zeigt eine vereinfachte Struktur eines solchen Work flow-Systems und seine Interoperation mit einem DBMS. Die aktuelle Spezifikation folgt der Struktur wie implementiert mittels MQSeries Workflow, obwohl dieser nur ein Beispiel sein soll und nicht den Bereich der aktuellen Erfindung begrenzen soll. Wie abgebildet, besteht das Workflow-System aus einem Satz individueller Systeme, den verschiedenen WFMS-Instanzen, die mit den Clients (101 bis 103) verbunden sind. Für einen Endbenutzer scheint dieses Netzwerk von kooperierenden WFMS Instanzen ein einzelnes logisches WFMS zu sein. Ein bestimmter Prozessor (110) oder (120) kann eines oder mehrere Workflow-Systeme (111 bis 113) oder (121 bis 123) halten. Jedes System besteht aus einem Hotpool mit einem oder mehreren zustandlosen Servern, die die verschiedenen Anforderungen verarbeiten, zum Beispiel das Starten eines Prozesses oder das Ausführen einer Aktivität. Jeder Server ist mit dem relationalen Datenbankver waltungssystem (130) verbunden, das die zentrale Datenbank des Workflow-Systems verwaltet. MQSeries Workflow nennt diese Kombination aus multiplen Systemen, die dieselbe Datenbank gemeinsam benutzen, eine Systemgruppe. Wie aus dieser Systemstruktur bereits ersichtlich ist, kann das Halten der zentralen Datenbank, zum Engpaß in bezug auf Gleichzeitigkeit, Parallelität und Verfügbarkeit werden, da die zentrale System-Datenbank der Brennpunkt des gesamten Datenverkehrs ist; dieser Konflikt ist eine Folge des verteilten Verfahren von diesem WFMS auf der einen Seite und dem zentralen Verfahren des DBMS auf der anderen Seite.

Die zentrale Datenbank des Workflow-Systems enthält nicht nur die Build-Time-Information, zum Beispiel Prozeßmodelle, Organisationsdaten und Merkmale der aufzurufenden Programme, sondern auch Laufzeitinformationen, zum Beispiel Prozeßinstanzen, Audit-Trail und die Arbeitspositionen, die den einzelnen Benutzern des Workflow-Systems zugeordnet wurden. Die meisten der Daten in der zentralen Datenbank sind Laufzeitinformationen; die Größe der Build-Time- Information kann fast vernachlässigt werden, wobei die Erstellung der Laufzeitinformation, insbesondere des Audit- Trails zum Haupt-Engpaß wird. Die Größe der Laufzeitinformation hängt von mehreren Faktoren ab: der Anzahl der Prozeßinstanzen, der Umfang der Audit-Trail- Information, die geschrieben wurde, und der Anzahl der Arbeitspositionen, die die Benutzer behalten, selbst nachdem sie diese verarbeitet haben, tragen wesentlich zur Gesamtgröße bei.

Die zentrale Datenbank besteht aus einem Satz Tabellen (falls ein relationales Datenbanksystem benutzt wird). Das Layout der Tabellen reflektiert die Struktur der Informationen, die sie behalten.

Die Prozeßinformation wird beispielsweise in mehreren Tabellen behalten, die die Struktur des Meta-Modell- Prozesses widerspiegeln. Es gibt beispielsweise eine Tabelle, die für jede Prozeßinstanz einen Eintrag behält, und eine Tabelle, die für jede Aktivität einen Eintrag behält. Alle Konstrukte, zum Beispiel Aktivitäten und Prozesse, werden durch einen einzigartigen Objektkennzeichner identifiziert, der von dem Workflow- System erzeugt wird. Diese Objektkennzeichner werden benutzt, um die Tupels in den einzelnen Tabellen zu verknüpfen. Das ist die Art und Weise, auf die beispielsweise die Tupels in der Aktivitätstabelle mit den Tupels in der Prozeßtabelle verknüpft werden.

Der Audit-Trail auf der anderen Seite ist eine einfache Ta belle, in der die einzelnen Einträge geschrieben werden.

Alle Informationen über einen Prozeß müssen wenigstens so lange behalten werden, bis der Prozeß beendet ist. Es kann jedoch notwendig sein, die Information über einen längeren Zeitraum zu behalten. Laut den gesetzlichen Vorschriften müssen diese Informationen manchmal über mehrere Jahre aufbewahrt werden. Dadurch wächst die zentrale Datenbank des Workflow-Systems an, wodurch die Leistung erheblich beeinträchtigt wird. Diese Leistungsbeeinträchtigung kann beispielsweise minimiert werden, indem das Workflow-System ältere, abgeschlossene Prozeßinstanzen und Audit-Trails archiviert oder aufteilt. Doch dann müssen diese Archive vom Workflow-System so verwaltet werden, daß das Workflow-System in der Lage ist, Anfragen zu beantworten, die in den archivierten Informationen enthalten sind. Im Fall einer solchen Anfrage muß das Workflow-System mehrere Anfragen ausgeben: eine an die zentrale Datenbank und eine oder mehrere an die Archive und dann die Anfrageergebnisse in einem einzelnen Anfrageergebnis zusammenfassen, anstatt, daß die Gesamtaktivität solcher Verfahren zu einem weiteren Anstieg führen würde. Abgesehen davon, daß die Implementierung der Archivierung nicht unbedeutend ist, ist die Leistung im allgemeinen nur tolerierbar, wenn diese Anfragen nur gelegentlich auftreten.

Die aktuelle Erfindung versucht daher, die Leistung von parallelen Datenbanken zu nutzen, um selbst große, zentrale Datenbanken des Workflow-Systems zu verwalten, und die Ansicht einer einzelnen logischen Datenbank bereitzustellen und parallele und gleichzeitige Zugriffe auf die verschiedenen Teile der zentralen System-Datenbank eines WFMS vorzusehen.

4.3 Parallele Datenbanken

Moderne relationale Datenbankverwaltungssysteme, zum Beispiel DB2 Universal Database Version 5 von IBM (siehe beispielsweise D. Chamberlin, A Complete Guide to DB2 Universal Database, Morgan Kaufmann Publishers, 1998), bieten die Fähigkeit, parallele Datenbanken zu unterstützen. Eine parallele Datenbank ist eine Datenbank, in der mehrere Aktionen gleichzeitig stattfinden können.

Die Parallelität ist seit vielen Jahren in relationalen Datenbanken vorhanden. Diese erlaubten, daß viele Benutzer mit mehreren Datenbanken verbunden sind, wobei jedoch jeder Benutzer meint, er sei der einzige, der mit relationalen Datenbankverwaltungssystem arbeitet. Dies wird durch Standardtechniken des Time-Sharing erreicht; d. h. jedem Benutzer einen bestimmten Anteil der Prozessorzeit zu geben, damit diese bzw. dieser seine Arbeit tun kann. Jeder Benutzer ist einem Betriebssystemprozeß zugeordnet, d. h. höchstens ein Prozessor kann mit der Durchführung einer Arbeit für eine bestimmte Person belegt sein. Zur Unterscheidung wird ein solches Datenbanksystem als serielles System bezeichnet, und die Parallelität wird durch den Multitask-Betrieb eingeführt.

In einem parallelen System kann eine Datenbank in mehrere separate Teile aufgeteilt werden, sogenannte Partitionen oder Knoten. Jede Tabelle in einer Datenbank kann in Partitionen aufgeteilt werden. Jede Partition kann in einem separaten Gerät ausgeführt werden. Sie hat ihr eigenes Protokoll und ihren eigenen Satz Indexe.

Es können zwei Arten von Parallelitäten unterschieden und auf die Verarbeitung eines SQL-Befehls angewendet werden. Die Intra-Partitions-Parallelität bezieht sich auf gleichzeitige Prozesse in einer einzelnen Partition, während sich die Inter-Partitions-Parallelität auf gleichzeitige Prozesse in mehreren Partitionen bezieht. Beide Arten der Parallelität verhalten sich orthogonal zueinander, d. h. beide Techniken können miteinander kombiniert und parallel angewendet werden.

Die Intra-Partitions-Parallelität wird normalerweise in symmetrischen Multiprozessoren (SMP) verwendet, in denen mehrere Prozessoren Speicher und Platten gemeinsam benutzen. Die Inter-Partitions-Parallelität wird komplett vom Datenbankverwaltungssystem verwaltet und erfordert keine besondere Aktion auf der Benutzerseite mit Ausnahme, daß dem Datenbankverwaltungssystem gesagt werden muß, daß es die Intra-Partitions-Parallelität benutzen muß.

Die Inter-Partitions-Parallelität arbeitet mit einem Satz Prozessoren, von denen jeder seinen eigenen Speicher und seine eigenen Platten hat. Die einzelnen Prozessoren benutzen nichts gemeinsam. Diese Hardware-Konfiguration wird als Shared-Nothing-System bezeichnet. Einige oder alle Prozessoren können selbst symmetrische Multiprozessoren sein, die dann die Intra-Partitions-Parallelität benutzen können. Somit können Intra-Partitions-Parallelität und Inter-Partitions-Parallelität als orthogonale Konzepte kombiniert werden. Ein typisches Gerät, das diese Architektur enthält, ist der IBM RS6000 SP2. Die verschiedenen Knotenprozessoren kommunizieren untereinander über das interne Hochgeschwindigkeitsnetz des Clusters.

Jede der verschiedenen Partitionen, die DB2 UDB einen Knoten nennt, wird einem einzigartigen Kennzeichner zugeordnet. Bei DB2 UDB ist dies eine Ganzzahl, die mit 0 beginnt. Jeder Knoten wird dann dem Prozessor zugeordnet, der die Partition behält. Die Tabellen, die den verschiedenen Partitionen zugeordnet werden (sogenannte partitionierte Tabellen), müssen jeweils einen Partitionierungscode haben, der bestimmt, welche Reihen der Tabelle unter den Partitionen verteilt werden. Die Werte des Partitionierungscodes werden dann mittels einer Hash-Funktion in dem Partitionssatz dargestellt. Diese Hash-Funktion wird von dem Datenbankverwaltungssystem geliefert.

Eine solche Situation ist in Fig. 2 dargestellt. Eine einzelne Logiktabelle (200) ist als ein Satz partitionierter Tabellen (201) und (202) gespeichert. Die Partitionierungscodes der einzelnen Datensätze werden benutzt, um festzulegen, welcher Datensatz, in welcher Partitionstabelle zu speichern ist. Im Beispiel von Fig. 2 sind Datensätze mit Partitionierungscodes im Bereich von 1 bis 10 (siehe 205 bis 206) in der Partition des Knotens 0 (201) gespeichert, während Datensätze mit Partitionierungscodes im Bereich von 71 bis 99 (siehe 207 bis 208) in der Partition des Knotens 1 (202) gespeichert sind. Der Zugriff auf die Logiktabelle (200) resultiert in inter-parallelem Zugriff auf die einzelnen Partitionen (201) bis (202).

Ein Datenbank-Client läßt sich mit einem der Knoten verbinden. Dieser Knoten, der Koordinator-Knoten, ist für alle Client-Anforderungen verantwortlich und verteilt diese Anforderungen an die einzelnen Knoten. Aus der Sicht eines Benutzers besteht daher kein Unterschied, ob ein SQL-Abruf von einer seriellen oder von einer parallelen Datenbank verarbeitet wird.

Fig. 3 zeigt die konzeptionelle Struktur eines solchen Datenbankverwaltungssystems, das parallele Datenbanken benutzt. Ein einzelnes, logisches Datenbankverwaltungssystem (301) bietet Zugriff auf verschiedene Datenbank-Clients (305) bis (307). Das Datenbankverwaltungssystem besteht derzeit aus einem Satz Knoten (302 bis 304) mit entsprechenden partitionierten Tabellen. Der Datenbank- Client (305) greift beispielsweise auf Knoten 1 (302) zu, während der Koordinator-Knoten für den Datenbank-Client den Ausdruck eines einzelnen logischen Datenbank verwaltungssystem erstellt.

4.4 Paralleler Datenbank-Support in WFMSs

Der Zweck der aktuellen Lehre ist es, den Inter- Parallelität-Support der parallelen Datenbanken für die WFMSs bereitzustellen (die zusätzliche Nutzung des orthogonalen Konzepts der Intra-Parallelität ist ohne Änderung der aktuellen Lehre möglich).

Die aktuelle Erfindung empfiehlt, den parallelen Datenbank- Support zu nutzen, indem die Tabellen der gesamten zentralen Datenbank des WFMS vorbereitet werden, d. h. die Laufzeit tabellen bzw. die Built-Time-Tabellen so zu nutzen, daß sie in mehrere Teile aufgeteilt werden können, die von dem zugrundeliegenden Datenbankverwaltungssystem als Partitionen behandelt werden können. Dies kann erreicht werden, indem zu allen relevanten Tabellen Spalten hinzugefügt und dann im Datenbankverwaltungssystem als Partitionierungscodes definiert werden, die zur Aufteilung der Tabellen dienen. Alle Tabellen, die Entitäten bilden, z. B. Prozesse, müssen diese hinzugefügte Spalte haben.

Durch die Benutzung des parallelen Supports des Datenbankverwaltungssystems wird die Leistung aufgrund der reduzierten Datenbankgröße, des reduzierten Konkurrenzbetriebs und der besseren Nutzung von CPUs verbessert. Die besten Leistungen werden erzielt, wenn eine Anforderung, die durch das Workflow-System erfolgt, das sich nur auf einen Knoten bezieht, genau auf diesen Knoten trifft. Die aktuelle Erfindung erreicht dieses Ziel, indem der Partitionierungscode enthalten ist, d. h. die Spalte, die in der WHERE-Klause der SQL-Befehle benutzt wurde, um die Tabelle in verschiedene Partitionen aufzuteilen.

Wie bereits erwähnt, sind die Prozeßinstanzen, der Audit- Trail und die Arbeitsliste der Benutzer ideale Kandidaten für die Nutzung des parallelen Datenbank-Supports. Diese Liste ist bei weitem nicht vollständig: es gibt sicherlich noch andere Kandidaten. Dies hängt von dem Meta-Modell ab, welches das Workflow-System implementiert. Es besteht auch kein Bedarf, die parallelen Datenbanken für alle Kandidaten zu nutzen. Sie sollten gerade für die Audit-Trail-Tabelle benutzt werden, eine Tabelle, die häufig genutzt wird. Die aktuelle Lehre stellt deshalb große Selektivität bereit, um zu entscheiden, welche der Tabellen zu parallelisieren sind.

Die aktuelle Erfindung führt zwei Verfahren ein, um die Spalten zu definieren, die helfen, die Aufteilung zu erreichen. In einem ersten Verfahren werden die internen Eigenschaften von den Tabellen der WFMS für die Erstellung von Partitionen benutzt. In einem zweiten Verfahren basiert die Erstellung von Partitionen auf den externen Eigenschaften. Interne Eigenschaften sind Eigenschaften, die im Workflow-System vorhanden sind und sich im allgemeinen auf Definitionen des WFMS als solches beziehen, wie beispielsweise Topologiedefinitionen. Deshalb enthalten die internen Eigenschaften mehr globale Definitionen, welche die Ausführung der Vielzahl von allen Prozeßmodellen steuern (sofern die Definitionen nicht von Spezifikationen in den einzelnen Prozeßmodellen aufgehoben werden). Externe Eigenschaften brauchen die Extradefinition vom Benutzer und sorgen so gegenüber der Verteilung unter den verschiedenen Partitionen/Knoten für eine bessere Steuerung. Die externen Eigenschaften enthalten somit alle Definitionen, die in dem einzelnen Prozeßmodell enthalten sein können, und die nur für ein spezifisches Prozeßmodell signifikant sind.

Unabhängig von dem derzeit ausgewählten Verfahren ist die fundamentale Idee der aktuellen Erfindung, die Definitionen, die für die Partitionierung der WFMS-Tabellen erforderlich sind, bereits in die einzelnen Prozeßmodelle aufzunehmen.

4.4.1 Interne Eigenschaften

Das Verfahren, die internen Eigenschaften von den Tabellen der WFMS zu benutzen, basiert auf der Tabellenstruktur in ihrer bisherigen Form, bei der die WFMS aus einer globalen Perspektive unabhängig von den einzelnen Prozeßmodellen, die vom WFMS ausgeführt werden, geführt und gesteuert werden. Dieses Verfahren wählt bereits verfügbare Tabellenattribute als Partitionierungscodes für die Parallelisierung aus.

Typische interne Eigenschaften sind die Erstellungs- /Startzeit eines Prozesses oder der Kennzeichner des Systems, das einen Prozeß erstellt hat. Andere könnten ebenfalls benutzt werden. Diese Eigenschaften sind genau des Prototyp der internen Eigenschaften. Trotzdem werden bestimmte Vorteile erreicht, indem genau diese Tabellenattribute als Partitionierungscode benutzt werden.

4.4.1.1 Startzeit

Jeder Prozeß ist mit einer Erstellungszeit/Startzeiteigen schaft verbunden, die, wenn der Prozeß erstellt/gestartet wird, in einen Tabelleneintrag geschrieben wird. Durch diese Eigenschaft können die Tabellen in Zeitrahmen aufgeteilt werden, beispielsweise Tage, Wochen, Monate usw. Die Benutzung eines Zeitattributs für Partitionierungszwecke basierend auf dem Zeitwert ist für Partitionstabellendatensätze geeignet, da ähnliche Zeitwerte auf ein inhärentes Verhältnis zwischen den Einträgen hinweisen.

4.4.1.2. System-Kennzeichner

In Fig. 1 ist die Systemstruktur des MQSeries Workflow und ihr Verhältnis zu den zugrundeliegenden Datenbankverwaltungssystemen abgebildet. In dieser Struktur wird jedes WFMS-System von einem WFMS-System-Kennzeichner identifiziert, der nur die WFMS-Instanzen angibt. Die aktuelle Lehre empfiehlt, diese Eigenschaft zu nutzen, um die Tabellen durch den System-Kennzeichner aufzuteilen. Diese Eigenschaft ist aus vielerlei Gründen eine ideale Eigenschaft, um die parallelen Datenbanken zu nutzen:

- Dem System, das einen Prozeß erstellt, ist dieser Prozeß eigen, bis der Prozeß beendet ist. Es gibt somit keinen Konkurrenzbetrieb in den Tabellen, die verschiedene Systeme gemeinsam benutzen; somit kann die Parallelisierung maximiert werden. Dies ist besonders für den Audit-Trail interessant, das es für jedes der Systeme eine eigene Partition geben wird.
- Jedes System kennt seinen Namen, d. h. den System-Kenn zeichner, ohne auf eine Datenbank zuzugreifen und kann deshalb den Namen in allen Zugriffen auf die Datenbank enthalten; d. h. in die WHERE-Klauseln der SQL-Befehle.
- Ein besonderes System könnte mit dem Knoten verbunden werden, der alle Laufzeitdaten dieses Systems behält.

4.4.1.3 Definitionen in den Topologiespezifikationen

Das folgende neue Konstrukt für die Spezifikation des parallelen Datenbank-Supports basierend auf den internen Eigenschaften ist eine Abbildung, wie der Support für parallele Datenbanken möglicherweise in der Flow- Definitionssprache des MQSeries Workflow ausgedrückt werden könnte.

Das Konstrukt definiert für die Systemgruppe "Stuttgart", d. h. eine Sammlung von WFMS-Systeminstanzen in einer Gruppe kombiniert und in einer Gruppe adressierbar, daß einige Tabellen aufgeteilt werden sollten und definiert für zwei Bereiche, wie dies erfolgen sollte. Die zweite Zeile zeigt ein Definitionskonstrukt, mit dem das WFMS informiert wird, daß die folgenden Tabellen in Partitionen aufgeteilt werden müssen. Die dritte und vierte Zeile reflektiert die Definitionskonstrukts, die im ersten Feld die Tabelle nennen, die zu partitionieren ist (d. h. zu parallelisieren ist); das zweite Feld definiert das Attribut von dem Wert, der sowohl von dem WFMS als auch von dem DBMS als Partitionierungscode benutzt wird. Mit Bezug auf das aktuelle Beispiel wird der Audit-Trail (AUDIT TRAIL) von der Systemidentifikation (SYSTEM ID) aufgeteilt (d. h. parti tioniert), d. h. daß Workflow-System behält und benutzt die Identifikationsspalte des WFMS-Systems im Audit-Trail. Die Tabellen, welche die Prozeßinformation (PROCESSES) halten, werden durch die Erstellungszeit (CREATION TIME) der Prozesse aufgeteilt. Somit muß das Workflow-System behalten werden und in jeder der Tabellen eine Spalte benutzen, welche die Erstellungszeit behält.

Aufgrund von der allgemeinen Art der Spezifikationen von den internen Eigenschaften steuern diese Definitionen die entsprechenden Tabellen von allen Prozeßmodellen, wenn diese nicht durch neue Spezifikationen in den einzelnen Prozeßmodellen außer Kraft gesetzt werden.

Basierend auf der aktuellen Lehre und mit Bezug auf das obengenannte Beispiel würde das WFMS den Partitionierungscode in jeder WHERE-Klausel der SQL-Befehle enthalten, die auf die Datenbanken zugreifen; der SELECT- Befehl für einen Audit-Trail-Zugriff würde somit wie folgt aussehen:

SELECT <attribute_list< FROM AUDIT_TRAIL WHERE SYSTEM_ID = 'SYS1'

Ein solches Verfahren resultiert in deutlichen Leistungsver besserungen, da die Optimizer der DBMS in der Lage sind, den Datenbankzugriff nur mit der Systemidentifikation "SYS1" zum adressierten System zu steuern.

4.4.2 Externe Eigenschaften

Externe Eigenschaften werden insbesondere von dem Benutzer definiert und mit den Konstrukts im Meta-Modell des Prozeßmodells verbunden. Im Fall der externen Eigenschaften weisen neue Definitionskonstrukts das WFMS und das DBMS an, weitere Attribute in eine Tabelle einzufügen, die als Partitionierungscode dienen. Außerdem können in einer weiteren Erweiterung der Lehre bestimmte Werte innerhalb des Prozeßmodells als Partitionierungscode zugeordnet werden, der angibt, in welchem Teil der Tabelle die entsprechende Datensatzinstanz gespeichert werden sollte. Das Workflow- System verwaltet dann eine bestimmte Spalte in den entsprechenden Tabellen.

Externe Eigenschaften setzen aufgrund ihrer lokalen Bedeutung (d. h. sind nur für das Prozeßmodell von Bedeutung, das die Spezifikationen enthält) die entsprechenden Spezifikationen der internen Eigenschaften außer Kraft (sind von allgemeiner Art).

Die folgende Tabelle zeigt, wie dieser Support für die parallelen Datenbanken möglicherweise in der Flow- Definitionssprache des MQSeries Workflow ausgedrückt werden könnte.

Mit Bezug auf das vorstehende Beispiel spiegelt die Spezifikation die Definition von folgenden Aspekten wider:

- Sie definiert, daß die Aufteilung von dem Benutzer mit einer externen Eigenschaft definiert wird (Zeilen 3 und 4). Dadurch fügt das Workflow-System eine bestimmte Spalte ein und behält diese (ähnlich der Systemidentifikationsspalte), d. h. ein bestimmtes Tabellenattribut, in der Audit-Trail-Tabelle und den Prozeßinstanztabellen zu Partitionierungszwecken. Die Werte des neuen Attributs werden als Partitionierungscode verwendet. Wenn dieses Beispiel als eine Erweiterung des Beispiels angesehen wird, das in bezug auf die internen Eigenschaften erwähnt wurde, dann werden die Definitionen der Systemgruppe "Stuttgart" außer Kraft gesetzt, falls die Tabellen der Prozeßmodelle von "Loan" und "TravelExpense" betroffen sind.
- Definitionen für den "Loan" Prozeß geben an, daß der Audit-Trail in "Node1" und die Prozeßtabellen in "Node2" (Zeilen 3 und 4) verwaltet werden sollten. Wann immer das Workflow-System mit einer Instanz des "loan" Prozesses arbeitet, wird es den entsprechenden Spaltenwert in der Audit-Trail-Tabelle auf "Node1" setzen, und die entsprechende Spalte in den Tabellen, die zu den Prozessen gehört, auf "Node2". Diese Definitionen weisen das WFMS im wesentlichen darauf hin, einen bestimmten Wert, nämlich "Node1" und "Node2", ausdrücklich als Partitionierungscode zuzuordnen. Ähnliche Definitionen sind in bezug auf das Datenbankverwaltungssystem für die Erstellung der ent sprechenden Datenbanktabellen verantwortlich. Das Work flow-System sollte sicherlich die entsprechenden Tabellen automatisch erstellen.
- Ähnliche Einträge für den "TravelExpense" Prozeß sind in den Zeilen 8 und 9 des vorstehenden Beispiels wiedergegeben.

4.4.3 Weitere Einstellungen

Die Einstellung des Workflow-Systems und des Datenbankverwaltungssystems könnte weitere Benutzeraktionen erforderlich machen, wie dies nachstehend erklärt werden wird.

Der Benutzer könnte einen speziellen Hash-Mechanismus bereitstellen, wenn der/die vom Datenbanksystem gelieferte/n Hash-Mechanismus/-Mechanismen nicht geeignet sind. Ein zufälliger Hash-Mechanismus würde beispielsweise nicht helfen, wenn jemand die Erstellungsdaten benutzen möchte, um die Tabellen durch die Erstellung von Datum-/Zeitrahmen zu partitionieren. Für solche Zwecke kann ein zusätzliches Definitionskonstrukt eingeführt werden (nicht in den obengenannten Figuren abgebildet), mit dem ein Benutzer eine Hash-Funktion angeben kann, die es einem Datenbankverwaltungssystem erlaubt, die verschiedenen Bereiche der Partitionierungscode-Werte auf Partitionie rungsnummern abzubilden.

Es kann vorkommen, daß der Benutzer angeben muß, wie das Workflow-System mit dem Datenbanksystem zu verbinden ist. Eine Option ist, daß alle Systeme mit einem Knoten verbunden sind und dieser Knoten alle Built-Time-Informationen behält, während die Laufzeitinformationen auf die anderen Knoten aufgeteilt sind. Eine weitere Option ist es, jedes System mit dem Knoten zu verbinden, der die meisten Daten behält. Ein Verfahren, das besonders hilfreich ist, wenn der Systemkennzeichner als Partitionierungscode benutzt wird.

4.4.4 Zusammenfassender Überblick

Fig. 4 zeigt einen zusammenfassenden Überblick über alle WFMS mit parallelem Datenbank-Support gemäß der aktuellen Erfindung. Im Gegensatz zu Fig. 1 speichert das WFSM gemäß dieser Lehre Teile der Tabelle, die die zentrale System- Datenbank in einer parallelen Datenbank bildet, und die logische Ansicht eines einzelnen (401) Datenbankverwaltungssystems in bezug auf die verschiedenen WFMS-Instanzen (401, 403) bietet. Durch die Nutzung der inter-parallelen Datenbanktechnologie sind die parallelisierten Teile (404, 405) der zentralen System- Datenbank derzeit in physisch unterschiedlichen Partitionen gespeichert, die für ein Maximum an Parallelität, Gleichzeitigkeit und Verfügbarkeit sorgen.

Claims

1. Definitionsmittel, um einen Teil der zentralen System- Datenbank von einem Workflow-Management-System (WFMS) oder einem System mit vergleichbarer Funktionalität zu definieren, der von einem Datenbankverwaltungssystem (DBMS) in einer Datenbank gehalten wird,
wobei das WFMS eine oder eine Vielzahl von WFMS- Instanzen in einem oder in einer Vielzahl von Computersystemen enthält;
wobei das WFMS wenigstens ein Prozeßmodell enthält;
wobei die Definitionsmittel dadurch gekennzeichnet sind, daß
dieser Teil der zentralen System-Datenbank definiert wird, um in einer parallelen Datenbank gehalten zu wer den; und
wobei die Definitionsmittel in den Konfigurationsspezifikationen des WFMS enthalten sind, wie beispielsweise in diesem Prozeßmodell.

2. Definitionsmittel gemäß Anspruch 1, wobei die parallele Datenbank eine parallele, relationale Inter-Partitions-Datenbank ist.

3. Definitionsmittel gemäß Anspruch 2,
wobei dieser Teil der zentralen System-Datenbank wenig stens eine Tabelle mit einer Sequenz von Attributen enthält, und diese Tabelle eine oder mehrere Datensätze mit einer Sequenz von den Attributwerten behält,
wobei diese Definitionsmittel erste Definitionsmittel enthalten, um wenigstens eines dieser Attribute als Partitionierungscode von dieser Tabelle anzugeben,
wobei dieser Code von der DBMS benutzt wird, um den Datensatz in einer Partition zu halten, die von dem Attributwert dieses Partitionierungscodes für parallelen Datenbankzugriff identifiziert wird; und/oder
wobei diese Definitionsmittel zweite Definitionsmittel enthalten, um wenigstens ein zusätzliches Attribut als Partitionierungscode von dieser Tabelle anzugeben.

4. Definitionsmittel gemäß Anspruch 3,
wobei die ersten Definitionsmittel die Systemidentifikation von diesen WFMS-Instanzen als Partitionierungscode angeben; oder
wobei die ersten Definitionsmittel die Erstellungszeit des Datensatzes als Partitionierungscode angeben.

5. Definitionsmittel gemäß Anspruch 3, wobei die zweiten Definitionsmittel die Zuordnung eines bestimmten Werts zu diesem Partitionierungscode unter stützen.

6. Definitionsmittel gemäß Anspruch 2 oder 3, wobei die Definitionsmittel dritte Definitionsmittel enthalten, um anzugeben, daß eine Hash-Funktion von diesem DBMS benutzt werden kann, um den Attributwert von diesem Partitionierungscode in einem begrenzten Satz der Partitionierungscode-Werte abzubilden.

7. Definitionsmittel gemäß Anspruch 3,
wobei die ersten bzw. die zweiten Definitionsmittel einen Partitionierungscode für eine oder mehrere Tabellen, die dieses Prozeßmodell enthalten, nennen; bzw.
wobei die ersten bzw. die zweiten Definitionsmittel einen Partitionierungscode für eine oder mehrere Tabellen, welche die Ausführungsinstanzen von diesem Prozeßmodell enthalten, nennen; bzw.
wobei die ersten bzw. zweiten Definitionsmittel einen Partitionierungscode für eine oder mehrere Tabellen, die einen Audit-Trail von diesem Prozeßmodell enthalten, nennen; bzw.
wobei die ersten bzw. zweiten Definitionsmittel einen Partitionierungscode für eine oder mehrere Tabellen mit Arbeitspositionen, die zu den Ausführungsinstanzen von diesem Prozeßmodell gehören, nennen.

8. Definitionsmittel gemäß Anspruch 3, wobei das WFMS, das diese Attributwerte von diesem Partitionierungscode in der WHERE-Klausel des SQL- Befehls benutzt, auf die parallele Datenbank zur weiteren Optimierung durch diese DBMS zugreift.

9. Ein Workflow-Management-System (WFMS) oder ein System mit vergleichbarer Funktionalität, das einen Teil der zentralen System-Datenbank von diesem WFMS mittels eines Datenbankverwaltungssystems (DBMS) in einer Datenbank behält,
wobei das WFMS eine oder eine Vielzahl von WFMS- Instanzen in einem oder in einer Vielzahl von Computersystemen enthält;
wobei das WFMS wenigstens ein Prozeßmodell enthält;
wobei das WFMS dadurch gekennzeichnet ist, daß
dieser Teil der zentralen System-Datenbank in einer parallelen Datenbank behalten wird.

10. Ein WFMS gemäß Anspruch 9, das außerdem gekennzeichnet wird durch Definitionsmittel gemäß irgendeinem Anspruch 1 bis 8, die in diesen WFMS-Konfigurationsspezifikationen enthalten sind, beispielsweise in diesem Prozeßmodell.

11. Ein WFMS gemäß Anspruch 9, wobei die parallele Datenbank eine parallele, relationale Inter-Partitions-Datenbank ist.

12. Ein WFMS gemäß Anspruch 10,
wobei dieser Teil der zentralen System-Datenbank wenig stens eine Tabelle mit einer Sequenz von Attributen enthält und die Tabelle einen oder mehrere Datensätze mit einer Sequenz von Attributwerten behält, und
wobei das WFMS wenigstens eines dieser Attribute als Partitionscode von dieser Tabelle benutzt, die von dem DBMS benutzt wird, um diesen Datensatz in einer Parti tion zu behalten, die von dem Attributwert von diesem Partitionierungscode für den parallelen Datenbankzugriff identifiziert wird.

13. Ein WFMS gemäß Anspruch 10,
wobei die Systemidentifikation von diesen WFMS- Instanzen als Partitionierungscode benutzt wird; oder
wobei die Erstellungszeit von diesem Datensatz als Par titionierungscode benutzt wird.

14. Ein WFMS gemäß Anspruch 10, wobei dieses WFMS, das diese Attributwerte von diesem Partitionierungscode in der WHERE-Klausel des SQL- Befehls benutzt, auf die parallele Datenbank zwecks weiterer Optimierung durch diese DBMS zugreift.