DE10003015A1

DE10003015A1 - Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus Prozessmodellen

Info

Publication number: DE10003015A1
Application number: DE10003015A
Authority: DE
Inventors: Frank Leymann; Dieter Roller
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-02-06
Filing date: 2000-01-25
Publication date: 2000-08-17
Also published as: US6826579B1

Abstract

Die Erfindung bezieht sich auf ein computergestütztes Verfahren zur automatischen Transformation des Prozessmodells eines Arbeitsablaufs-Management-Systems in Trigger-Festlegungen, die innerhalb eines Triggersystems ausführbar sind. Das Prozessmodell enthält wenigstens eine Quellaktivität S, eine Zielaktivität T und einen Steuerverbinder, der einen möglichen Steuerfluss von der Quellaktivität zur Zielaktivität definiert, der mit einer Übergangsbedingung P verbunden ist. Entsprechend der vorgeschlagenen Methodik wird die Quellaktivität S in ein Triggerereignis transformiert. Wenn das Triggerereignis zur Laufzeit ausgelöst wird, zeigt es dem Triggersystem an, dass eine Instanz der Quellaktivität beendet wurde. Darüber hinaus wird der Steuerverbinder in eine Triggerbedingung transformiert, was das Triggersystem zur Laufzeit veranlasst, den Wahrheitswert der Übergangsbedingung auszuwerten, falls das Triggerereignis ausgelöst wurde. Weiterhin wird die Zielaktivität in eine Triggeraktion transformiert, die das Triggersystem zur Laufzeit veranlasst, eine Instanz der Zielaktivität zu starten, falls die Triggeraktivität zu TRUE ausgewertet wird.

Description

1 Hintergrund der Erfindung 1.1 Bereich der Erfindung

Die vorliegende Erfindung bezieht sich auf eine Methode, das Prozessmodell eines Arbeitsablaufs- (workflow) Verwaltungs- Systems automatisch in Trigger-Festlegungen umzuwandeln, die innerhalb eines Triggersystems ausführbar sind.

1.2 Beschreibung und Nachteile des Standes der Technik

Ein neues Gebiet der Technologie mit zunehmender Bedeutung ist der Bereich der Arbeitsablaufs-Verwaltungs-Systeme (WFMS). WMFS unterstützen die Modellierung und Ausführung von Geschäftsabläufen. Geschäftsabläufe, die innerhalb einer WFMS- Umgebung ausgeführt werden, steuern, welcher Arbeitsgang eines Netzwerkes von Arbeitsgängen von wem ausgeführt wird und welche Hilfsmittel für diese Arbeit verwendet werden. Die einzelnen Arbeitsgänge können über eine Vielzahl verschiedener Computersysteme verteilt sein, die durch ein Netzwerk beliebiger Art verbunden sind.

Das Produkt "IBM MQSeries Workflow" (auch FlowMark genannt) stellt ein solches typisches modernes, intelligentes und leistungsfähiges Arbeitsablaufs-Verwaltungs-System dar. Es unterstützt die Modellierung von Geschäftsprozessen als ein Netzwerk von Aktivitäten. Dieses Netzwerk von Aktivitäten, das Prozessmodell, wird als ein gerichteter, azyklischer, gewichteter, gefärbter Graph konstruiert. Die Knoten des Graphen stellen die Aktivitäten oder Arbeitsschritte (workitems) dar, die ausgeführt werden. Die Kanten des Graphen, die Steuerverbinder (control connectors), beschreiben die potentielle Ausführungsfolge der Aktivitäten. Die Definition des Prozessgraphen geschieht über die IBM MQSeries Workflow Definition Language (Arbeitsablaufs-Definitionssprache) (FDL) oder den eingebauten graphischen Editor. Die Laufzeit- Komponente des Arbeitsablauf-Managers interpretiert den Prozessgraphen und verteilt die Ausführung von Aktivitäten an die richtige Person am richtigen Platz, zum Beispiel durch Zuweisen von Aufgaben an eine Tätigkeitsliste entsprechend der jeweiligen Person, wobei die Tätigkeitsliste als digitale Daten innerhalb des Arbeitsablauf- oder Prozessverwaltungs- Computersystems gespeichert sind.

Ein anderer Technologiebereich sind die Triggersysteme. Das Paradigma für die Ausführung von Aktivitäten innerhalb dieser Systeme beruht auf dem eines Triggers. Ein Trigger ist eine Regel, die für das Triggersystem definiert ist und angibt, dass eine bestimmte Aktion (action) vom Triggersystem gestartet werden soll, falls ein Ereignis (event) eingetreten ist und falls eine zugeordnete Bedingung (condition) zu TRUE (wahr) ausgewertet würde. Das Triggersystem umfasst eine Gruppe solcher Trigger. Es überwacht ständig eingetretene Ereignisse und bestimmt die entsprechenden Trigger, die dann ausgeführt ("gefeuert") werden und zur Einleitung einer Triggeraktion führen können. Eine Aktion kann während ihrer Ausführung weitere Ereignisse auslösen, was eine weitere Aktivität hervorruft. Auf der Grundlage dieses Schemas wird durch ein Triggersystem eine effektive Tätigkeit realisiert.

Trigger können so verstanden werden, dass sie oft Geschäftsregeln widerspiegeln, und Geschäftsabläufe können als Sammlungen von Geschäftsregeln angesehen werden. Entsprechend dieser Methode sind Geschäftsabläufe Mengen von Triggern.

Trigger wurden beispielsweise eingeführt, um bei der Verwaltung der Konsistenz in Datenbanksystemen zu helfen. Ursprünglich wurden sie beschrieben als eine Abstraktion (innerer) Dienste, die von einem Datenbank-Verwaltungssystem (DBMS) zu realisieren sind, um die Konsistenz von Datenbank-Manipulationen bei Transaktionen zu sichern. Aber dieser Bereich wurde erweitert, um lange laufende Transaktionen in nicht-traditionellen Anwendungen von DBMS zu verwalten (siehe beispielsweise A. Kotz, Triggermechanismen in Datenbanken, Springer, 1989); DBMS, die allgemeine Triggerumgebungen bereitstellen, werden oft als aktive DBMS bezeichnet. Ein Beispiel einer aktiven Datenbank ist DB2 Universal Database (UDB) von IBM. Heute stellen die meisten kommerziellen relationalen DBMS eingeschränkte Trigger- Varianten zur Verfügung, um die Durchsetzung von Geschäftsregeln innerhalb von Transaktionen zu erlauben, und demzufolge sind Trigger für die SQL3-Standardisierung vorgesehen. Obwohl Triggersysteme eine leistungsfähige; Umsetzungsumgebung in vielen Anwendungsfeldern zur Verfügung stellen, sind sie von einem globalen Standpunkt aus mit Unzulänglichkeiten bezüglich ihrer Klarheit verbunden - mit einer wachsenden Anzahl von Triggern nehmen die Schwierigkeiten zu, die Wechselbeziehung der verschiedenen Aktionen zu verstehen, die auf Triggerereignisse reagieren können. Auf der anderen Seite können Prozessmodelle von WFMS genau dieses globale Bild liefern, indem sie präzise definieren und zeigen, welche Aktivität welcher anderen Aktivität unter welchen Bedingungen folgt.

Es wäre wünschenswert, Geschäftsprozesse vollständig auf der Grundlage und mit den Mitteln der WFMS-Technologie zu modellieren und zu definieren, aber andererseits die Option zu eröffnen, die Technologie der Triggersysteme als eine reine Umsetzungsumgebung zu nutzen.

1.3 Ziel der Erfindung

Die Erfindung beruht auf dem Ziel, die Prozessmodelle eines Arbeitsablaufs-Verwaltungs-Systems (WFMS) automatisch in Trigger-Festlegungen umzuwandeln, die automatisch eine ausführbare Realisierung der Geschäftsprozesse erzeugen, die durch die Prozessmodelle modelliert wurden.

2 Zusammenfassung und Vorteile der Erfindung

Die Ziele der Erfindung werden erreicht durch die unabhängigen Ansprüche. Weitere vorteilhafte Anordnungen und Ausführungsformen der Erfindung werden in den jeweiligen Unteransprüchen bekanntgemacht.

Die Erfindung bezieht sich auf eine computergestützte Methode zur automatischen Transformation des Prozessmodells eines Arbeitsablauf-Verwaltungs-Systems in Trigger-Festlegungen, die innerhalb eines Triggersystems ausführbar sind. Das Prozessmodell enthält wenigstens eine Quellaktivität S und eine Zielaktivität T sowie einen Steuerverbinder, der einen potentiellen Steuerfluss von der Quellaktivität zur Zielaktivität definiert, in Verbindung mit einer Übergangsbedingung P. Entsprechend der vorgeschlagenen Methode wird die Quellaktivität S in ein Triggerereignis transformiert. Wenn das Triggerereignis zur Laufzeit ausgelöst wird, zeigt es dem Triggersystem an, dass eine Instanz der Quellaktivität beendet wurde. Darüber hinaus wird der Steuerverbinder in eine Triggerbedingung transformiert, die das Triggersystem zur Laufzeit veranlasst, den Wahrheitswert der Übergangsbedingung zu berechnen, nachdem das Triggerereignis einmal ausgelöst wurde. Weiterhin wird die Zielaktivität in eine Triggeraktion umgewandelt, die bewirkt, dass das Triggersystem zur Laufzeit eine Instanz der Zielaktivität startet, falls die Triggerbedingung zu TRUE ausgewertet wurde.

Die vorliegende Erfindung liefert eine Kombination der WFMS- Technologie und der Triggertechnologie. Die vorliegende Erfindung lehrt, wie Steuerflüsse von Geschäftsprozess-Modellen auf ECA-Regeln abzubilden sind. Die Interpretation der erzeugten ECA-Regeln selbst kann auf unterschiedliche Arten realisiert werden, zum Beispiel in aktiven Datenbanksystemen, Agentensystemen oder in Veröffentlichungs-Bestätigungs- Umgebungen (publish/subscribe environment). Demzufolge kann unsere Erfindung für die Realisierung eines Arbeitsablaufsystems angewandt werden, das auf einer Vielzahl von verschiedenen Technologien beruht. Die Erfindung lehrte eine Methode, Geschäftsprozesse vollständig mit Mitteln und auf der Grundlage der WMFS-Technologie zu modellieren und zu definieren, aber andererseits die Option zu eröffnen, die Technologie der Triggersysteme als eine reine Umsetzungsumgebung zu nutzen, indem automatisch Trigger- Festlegungen erzeugt werden, die durch das Triggersystem direkt ausgeführt werden können.

3 Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Diagramm, das die grundlegende Transformationsmethodik widerspiegelt, die jedes einzelne Konstruktionselement, das aus einer Quellaktivität, einer Zielaktivität und einem Steuerverbinder besteht, der diese Aktivitäten verbindet, in einen gesonderten Trigger umwandelt.

Fig. 2 ist ein Diagramm, das die verbesserte Transformationsmethodik widerspiegelt, die sich mit dem Problem der Synchronisation paralleler Arbeitsabläufe in einem Prozessmodell beschäftigt.

Fig. 3 veranschaulicht eine Ausführungsform des Transformationsprozesses, in der die Triggeraktion zusätzlich zur START()-Aktion auch eine weitere Aktion (SIGNALTERMINATION( )) enthält, die die Beendigung der Zielaktivität mitteilt.

Fig. 4 zeigt die erzeugte Trigger-Festlegung für das Beispiel von Fig. 3, entsprechend der DB2-UDB-Syntax für eine bestimmte Ausführungsform entsprechend der vorliegenden Erfindung.

4 Beschreibung der bevorzugten Ausführungsform

Die vorliegende Erfindung wird auf der Grundlage des Arbeitsablaufs-Verwaltungs-Systems MQSeries Workflow von IBM veranschaulicht. Natürlich könnte statt dessen auch irgendein anderes WFMS benutzt werden. Weiterhin ist die vorliegende Methodik auch auf eine beliebige andere Art von System anwendbar, das WFMS-Funktionalitäten nicht als ein separates WFMS, sondern innerhalb einer anderen Art von System zur Verfügung stellt.

Darüber hinaus könnte die bevorzugte Ausführungsform, die auf der DB2-Triggertechnologie beruht, problemlos innerhalb anderer aktiver Datenbanken oder anderer Triggersysteme realisiert werden, ohne von den Grundgedanken der Erfindung abzuweichen.

4.1. Einleitung

Nachstehend folgt ein kürzer Überblick über die grundlegenden Konzepte eines Arbeitsablaufs-Verwaltungs-Systems, das auf MQSeries Workflow von IBM beruht: Von einem unternehmerischen Standpunkt aus wird die Verwaltung von Geschäftsprozessen zunehmend wichtig: Geschäftsprozesse, oder der Kürze halber ein Prozess, steuern, welcher Arbeitsgang von wem ausgeführt wird und welche Hilfsmittel für diese Arbeit verwendet werden, d. h., ein Geschäftsprozess beschreibt, wie ein Unternehmen seine Geschäftsziele erreichen will. Ein WFMS kann beides unterstützen, die Modellierung der Geschäftsprozesse und ihre Ausführung.

Die Modellierung eines Geschäftsprozesses als eine syntaktische Einheit auf eine Art und Weise, die direkt durch ein Softwaresystem unterstützt wird, ist außerordentlich wünschenswert. Darüber hinaus kann das Softwaresystem auch als ein Interpreter arbeiten, der im wesentlichen ein solches Modell als Eingabe erhält: Das Modell, als Prozessmodell oder Arbeitsablaufmodell bezeichnet, kann dann instantiiert werden, und die jeweilige Folge von Arbeitsschritten kann in Abhängigkeit vom Kontext der Instantiierung des Modells festgelegt werden. Ein solches Modell eines Geschäftsprozesses kann als eine Schablone für eine Klasse ähnlicher Prozesse angesehen werden, die innerhalb eines Unternehmens ausgeführt werden; es ist ein Schema, das alle möglichen Ausführungsvarianten einer bestimmten Art eines Geschäftsprozesses beschreibt. Eine Instanz eines solchen Modells und ihre Interpretation repräsentieren einen einzelnen Prozess, d. h., eine konkrete, kontextabhängige Ausführung einer durch das Modell vorgeschriebenen Variante. Ein WFMS erleichtert die Verwaltung von Geschäftsprozessen. Es stellt ein Mittel zur Verfügung, um Modelle von Geschäftsprozessen zu beschreiben (Entwurfsphase), und es steuert Geschäftsprozesse, die auf einem zugeordneten Modell beruhen (Ausführungsphase). Das Metamodell des WMFS MQSeries Workflow von IBM, d. h. die syntaktischen Elemente, die für die Beschreibung der Geschäftsprozessmodelle zur Verfügung stehen, sowie die Bedeutung und Interpretation dieser syntaktischen Elemente wird als Nächstes beschrieben.

Ein Prozessmodell ist eine vollständige Darstellung eines Prozesses, die ein Prozessdiagramm und die Einstellungen umfasst, die die Logik hinter den Komponenten des Diagramms festlegen. Wichtige Komponenten eines MQSeries Workflow-Prozessmodells sind:

- Prozesse
- Aktivitäten
- Blöcke
- Steuerflüsse
- Verbinder
- Datencontainer
- Datenstrukturen
- Bedingungen
- Programme
- Personal

Nicht alle diese Elemente werden nachstehend beschrieben.

Aktivitäten sind die grundlegenden Elemente des Metamodells. Eine Aktivität stellt eine Geschäftsaktion dar, die unter einem bestimmten Blickwinkel für sich genommen eine semantische Einheit ist.

Ein MQSeries Workflow-Prozessmodell besteht aus den folgenden Aktivitätenarten:
Programmaktivität: Ihr ist ein Programm zur Ausführung zugeordnet. Das Programm wird aufgerufen, wenn die Aktivität gestartet wird. In einem vollständig automatisierten Arbeitsablauf führt das Programm die Aktivität ohne menschlichen Eingriff aus. Ansonsten muss der Nutzer die Aktivität starten, indem er sie aus einer Ausführung- Arbeitsgangliste auswählt. Die Ausgabe des Programms kann in der Exit-(Ausgangs-)Bedingung der Programmaktivität und für die Übergangsbedingungen zu anderen Aktivitäten benutzt werden.

Prozessaktivität: Ihr ist ein (Sub-)Prozess zur Ausführung zugeordnet. Der Prozess wird aufgerufen, wenn die Aktivität gestartet wird. Eine Prozessaktivität stellt einen Weg dar, eine Menge von Aktivitäten, die in verschiedenen Prozessen gleich sind, wieder zu benutzen. Die Ausgabe des Prozesses kann in der Exit-(Ausgangs-)Bedingung der Prozessaktivität und für die Übergangsbedingungen zu anderen Aktivitäten benutzt werden.

Der Fluss der Steuerung, d. h. der Steuerfluss durch einen laufenden Prozess, bestimmt die Folge, in der Aktivitäten ausgeführt werden. Der MQSeries Workflow Arbeitsablauf-Manager steuert einen Weg durch den Prozess, durch die Bewertung der Startbedingungen, der Ausgangsbedingungen und der Übergangsbedingungen als TRUE bestimmt wird.

Die Ergebnisse, die im Allgemeinen durch die Arbeit erzeugt werden, die durch eine Aktivität dargestellt wird, werden in einen Ausgabecontainer gebracht, der jeder Aktivität zugeordnet ist. Da eine Aktivität im Allgemeinen erfordert, auf die Ausgabecontainer anderer Aktivitäten zuzugreifen, ist jeder Aktivität zusätzlich auch ein Eingabecontainer zugeordnet. Zur Laufzeit stellen die tatsächlichen Werte für die formalen Parameter, die den Eingabecontainer einer Aktivität aufbauen, den eigentlichen Kontext einer Instanz der Aktivität dar. Jeder Datencontainer ist durch eine Datenstruktur definiert. Eine Datenstruktur ist eine geordnete Liste von Variablen, die als Elemente (members) bezeichnet werden und einen Namen und einen Datentyp besitzen. Datenverbinder stellen die Übertragung von Daten aus Ausgabecontainern in Eingabecontainer dar. Wenn ein Datenverbinder einen Ausgabecontainer mit einem Eingabecontainer verbindet und die Datenstrukturen der beiden Container genau übereinstimmen, bildet der MQSeries Workflow- Arbeitsablauf-Manager die Daten automatisch ab.

Verbinder verbinden Aktivitäten in einem Prozessmodell. Bei Benutzung von Verbindern definiert man die Folge von Aktivitäten und die Übertragung von Daten zwischen Aktivitäten. Da Aktivitäten nicht willkürlich ausgeführt werden sollen, werden sie über Steuerverbinder verbunden. Ein Steuerverbinder könnte als eine gerichtete Kante zwischen zwei Aktivitäten angesehen werden; die Aktivität am Endpunkt des Verbinders kann nicht starten, bevor die Aktivität am Startpunkt des Verbinders (erfolgreich) beendet wurde. Steuerverbinder modellieren demzufolge den möglichen Steuerfluss innerhalb eines Geschäftsprozessmodells. Standardverbinder geben an, wohin die Steuerung fließen sollte, wenn die Übergangsbedingung keines anderen Steuerverbinders, der eine Aktivität verlässt, zu TRUE bewertet wird. Standardverbinder erlauben es dem Arbeitsablaufmodell, mit Ausnahmeereignissen fertig zu werden. Datenverbinder geben den Datenfluss in einem Arbeitsablaufmodell an. Ein Datenverbinder geht von einer Aktivität oder einem Block aus und hat eine Aktivität oder einen Block als sein Ziel. Man kann festlegen, dass Ausgabedaten zu einem Ziel oder zu mehreren Zielen gehen sollen. Ein Ziel kann mehr als einen ankommenden Datenverbinder haben.

Bedingungen (conditions) sind das Mittel, durch welches es möglich ist, den Steuerfluss in einem Prozess anzugeben. In MQSeries Workflow-Prozessmodellen können logische Ausdrücke definiert werden, die von MQSeries Workflow zur Laufzeit ausgewertet werden, um zu bestimmen, wann eine Aktivität starten, enden und die Steuerung an die nächste Aktivität übergeben kann. Startbedingungen sind Bedingungen, die bestimmen, wann eine Aktivität mit ankommenden Steuerverbindern starten kann. Diese Startbedingung kann festlegen, dass alle ankommenden Steuerverbinder zu TRUE ausgewertet werden, oder sie kann angeben, dass wenigstens eine von ihnen zu TRUE ausgewertet wird. Gleichgültig, welche Startbedingung vorliegt, alle ankommenden Verbinder müssen ausgewertet werden, bevor die Aktivität starten kann. Wenn eine Aktivität keine ankommenden Steuerverbinder besitzt, wird sie fertig, wenn der sie enthaltende Prozess oder Block startet. Zusätzlich ist jedem Steuerverbinder ein Boolescher Ausdruck, als Übergangsbedingung (transition condition) bezeichnet, zugeordnet. Parameter von Ausgabecontainern von Aktivitäten, die bereits ihre Ergebnisse erzeugt haben, werden als Parameter angesehen, auf die in Übergangsbedingungen Bezug genommen wird. Wenn zur Laufzeit eine Aktivität erfolgreich endet, werden alle Steuerverbinder, die diese Aktivität verlassen, ermittelt, und der Wahrheitswert der zugeordneten Übergangsbedingungen wird auf der Grundlage der aktuellen Werte ihrer Parameter berechnet. Nur die Endpunkte von Steuerverbindern, deren Übergangsbedingungen zu TRUE ausgewertet wurden, werden als Aktivitäten angesehen, die auf der Grundlage des eigentlichen Kontextes des Geschäftsprozesses ausgeführt werden könnten. Übergangsbedingungen modellieren also den kontextabhängigen tatsächlichen Steuerfluss innerhalb eines Geschäftsprozesses (d. h. einer Instanz eines Modells). Geschäftsprozesse schließen im allgemeinen lange laufende Aktivitäten ein; man muss erlauben, dass eine solche Aktivität unterbrochen wird. Somit zeigt die Beendigung einer Aktivität nicht notwendigerweise an, dass die zugehörige Aufgabe erfolgreich beendet wurde. Um die Messung des Erfolges der von einer Aktivität ausgeführten Arbeit zu erlauben, ist jeder Aktivität ein Boolescher Ausdruck zugeordnet, der als Ausgangsbedingung (exit condition) bezeichnet wird. Genau die Aktivitäten, deren Ausgangsbedingung in dem eigentlichen Kontext zu TRUE ausgewertet wurden, werden als erfolgreich abgeschlossen behandelt. Zur Bestimmung des, tatsächlichen Steuerflusses werden genau die erfolgreich beendeten Aktivitäten betrachtet. Somit muss der logische Ausdruck einer Ausgangsbedingung, falls er festgelegt ist, zu TRUE ausgewertet werden, damit die Steuerung von einer Aktivität oder einem Block weiterläuft.

Die Prozessdefinition beinhaltet die Modellierung von Aktivitäten, Steuerverbindern zwischen den Aktivitäten, Eingabe-/Ausgabe-Containern und Datenverbindern. Ein Prozess wird als ein gerichteter azyklischer Graph mit den Aktivitäten als Knoten und den Steuer-/Daten-Verbindern als Kanten des Graphen dargestellt. Der Graph wird mit einem eingebauten graphischen Editor behandelt. Die Datencontainer werden als benannte Datenstrukturen angegeben. Diese Datenstrukturen selbst werden über die Einrichtung zur Datenstruktur-Definition (DataStructureDefinition) festgelegt. Programmaktivitäten werden durch Programme ausgeführt. Die Programme werden über die Einrichtung zur Programm-Definition (Program Definition) registriert. Blöcke enthalten die gleichen Konstruktionselemente wie Prozesse, zum Beispiel Aktivitäten, Steuerverbindern usw. Sie sind jedoch nicht benannt und haben ihre eigene Ausgangsbedingung. Wenn die Ausgangsbedingung nicht erfüllt ist, wird der Block wieder gestartet. Der Block realisiert somit ein Do...Until-Element. Prozessaktivitäten werden als Prozesse ausgeführt. Diese Subprozesse werden getrennt als reguläre, benannte Prozesse mit all ihren üblichen Eigenschaften definiert. Prozessaktivitäten bieten eine große Flexibilität für die Prozessdefinition. Sie erlauben nicht nur, einen Prozess durch ständige Verfeinerung der Aktivitäten zu Programm- und Prozess-Aktivitäten (von oben nach unten) zu konstruieren; sondern auch, einen Prozess aus einer Menge von vorhandenen Prozessen aufzubauen (von unten nach oben).

Alle Datenstrukturen, die als Schablonen für die Container von Aktivitäten und Prozessen benutzt werden, werden über die Einrichtung zur Datenstruktur-Definition definiert. Datenstrukturen sind Namen und werden mit Hilfe von elementaren Datentypen, zum Beispiel reellen Zahlen (float), ganzen Zahlen (integer) oder Zeichenketten (string) gebildet und beziehen sich auf vorhandene Datenstrukturen. Die Verwaltung von Datenstrukturen als gesonderte Einheiten hat den Vorteil, dass alle Schnittstellen von Aktivitäten und ihren Ausführungen einheitlich an einer Stelle verwaltet werden (ähnlich zu Header Files in Programmiersprachen).

Alle Programme, die Programmaktivitäten ausführen, werden über die Einrichtung zur Programm-Registratur (Program Registration Facility) definiert. Für jedes Programm wird der Name des Programms, sein Ort und die Aufruf-Zeichenkette registriert. Die Aufrufzeichenkette besteht aus dem Programmnamen und der Befehlszeichenkette, die dem Programm übergeben wird.

Ein Trigger ist ein Software-Werkzeug, das einem Softwaresystem erlaubt, dynamisch auf Stimuli zu reagieren, die von den Herstellern des Softwaresystems nicht vorgesehen sind. Ein Trigger besteht im Wesentlichen aus drei Komponenten, nämlich einem Ereignis, einer Bedingung und einer Aktion. Diese drei Komponenten werden als eine Regel interpretiert, eine sogenannte Ereignis-Bedingungs-Aktions-Regel, oder der Kürze halber ECA-Regel. Ein Ereignis ist die Beschreibung der Stimuli, die Bedingung ist ein Prädikat, das den Kontext einschränkt, in dem die Stimuli relevant sind, und die Aktion ist die Vorschrift einer Reaktion auf relevante Stimuli. Die "Erfindung" von Triggern wird oft mit der Forschung am System/R von IBM in Zusammenhang gebracht.

Eine ECA-Regel hat die folgende Semantik: Immer wenn dem Softwaresystem das Auftreten eines Ereignisses mitgeteilt wird, wird die zugeordnete Bedingung ausgewertet, und, wenn sie erfüllt ist, wird die entsprechende Aktion ausgeführt; das bedeutet, dass, falls das Ereignis eintritt und die Bedingung zu TRUE ausgewertet wird, der Trigger die Aktion "feuert". Ereignisse, Bedingungen und Aktionen haben Parameter, die ihnen zugeordnet sind, wobei die Ereignisparameter hauptsächlich dazu benutzt werden, die Parameter bereitzustellen, die notwendig sind, um die Bedingung auszuwerten und die Daten zur Aktion weiterzuleiten. Das Auftreten des Ereignisses umfasst die Bereitstellung dieser Daten.

Wir übernehmen eine einfache Notation, um Trigger zu definieren:

TRIGGER t =
ON e(p₁, . . ., p_n) [∼ Ereignis]
IF c(q₁, . . ., q_k) [∼ Bedingung]
DO a(r₁, . . ., r_m) [∼ Aktion]

Hier bezeichnet {p₁, . . ., p_n} die Parameter, die in das System übertragen werden, wenn das Ereignis mit dem Namen e eintritt, {q₁, . . ., q_k} ⊆ {p₁, . . ., p_n} sind die Parameter, die notwendig sind, um die Bedingung mit dem Namen c auszuwerten, und {r₁, . . ., r_m} ⊆ {p₁, . . ., p_n} sind die Parameter, die zur Aktion mit dem Namen a weitergegeben werden. Trigger werden oft der Kürze halber durch t = (e, c, a) bezeichnet.

Die heutigen kommerziellen Arbeitsablauf-Steuersysteme (workflow engine) in der Produktion werden nicht oberhalb eines Triggersystems realisiert. Ein wichtiger Grund dafür ist die Komplexität der entstehenden Prozessmodelle, d. h. die Komplexität der Menge von Triggern, die das Verhalten des Triggersystems steuern, Die vorliegende Erfindung beschäftigt sich genau mit diesem Problem. Zur Verbesserung und Beschleunigung der Ausführung eines WFMS, das auf einem Triggersystem beruht und innerhalb dieses Systems ausgeführt ist, schlägt die vorliegende Methodik die Verwendung von Prozessmodellen vor, die aus heutigen Produktions- Arbeitsablaufs-Steuersystemen bekannt sind, sowie die automatische Erzeugung von Triggern aus solchen Prozessmodellen heraus, die diese Prozessmodelle ausführen. Das Problem der Komplexität (im Sinne der Verständlichkeit) wird auf das der entsprechenden Prozessmodelle zurückgeführt, und die entsprechende Umsetzung innerhalb eines Triggersystems kann automatisch erzeugt werden.

Die meisten (Produktions-)Arbeitsablauf-Steuersysteme unterstützen heute ein Metamodell, das auf gerichteten Graphen beruht. Der Standard "interface 1" der Arbeitsablaufs- Verwaltungs-Vereinigung WfMC widerspiegelt das. Kommerziell verfügbare Produkte wie MQSeries Workflow von IBM realisieren diese. Standards wenigstens teilweise. Im folgenden wird beschrieben, wie solche Graphen in ECA-Regeln transformiert werden.

Zu diesem Zweck wird zuerst eine "grundlegendere' Lösung angegeben, die Kanten unabhängig voneinander auf Trigger abbildet; dies ignoriert eine mögliche Semantik bezüglich der Synchronisation der Arbeit. Zum Zweiten wird eine Transformation beschrieben, die zusätzlich Synchronisationsprobleme betrachtet. Da nur wenige WFMS die Synchronisation der Arbeit explizit behandeln, sind alle beide Abbildungen von uns interessant.

4.2. Die grundlegende Transformation - das Ignorieren von Synchronisation

Die grundlegende Transformationsmethodik ist dargestellt unter Bezugnahme auf Fig. 1. Die Grundidee besteht darin, jedes einzelne Konstruktionselement, das aus einer Quellaktivität, einer Zielaktivität und einem Steuerverbinder besteht, der diese Aktivitäten verbindet, in einen gesonderten Trigger zu transformieren. Die linke Seite von Fig. 1 widerspiegelt einen Teil des Prozessmodells, das in einen Trigger transformiert werden soll. Es sei (S, p, T) eine Kante für den Instanzverbinder (102) eines gerichteten Graphen, der den Steuerfluss zwischen der Quellaktivität S für den Instanzknoten A (101) und der Zielaktivität T für den Instanzknoten B (103) angibt, wobei p die Bedingung bezeichnet, unter der der durch die Kante vorgeschriebene Übergang stattfindet (zum Beispiel die Übergangsbedingung p1 (102) in Fig. 1). Die zentrale Idee besteht darin, diese Kante entsprechend der folgenden Regel in einen Trigger umzuwandeln:

1. Die Quellaktivität S entspricht dem Beendigungsereignis dieser Aktivität. Dieses Ereignis wird durch TERMINATE(S) bezeichnet.
2. Die Zielaktivität T entspricht der Startaktion dieser Aktivität. Diese Aktivität wird durch START(T) bezeichnet.
3. Die Übergangsbedingung p wird in die Bedingung des Triggers transformiert.

Die abstrakte Beschreibung der grundlegenden Transformation ist wie folgt:
Es sei G = (N, E) ein gerichteter Graph, der den Steuerfluss eines Geschäftsprozesses beschreibt. N ist die Menge der Aktivitäten, E ⊆ NxNxC ist die Menge der Steuerverbinder zwischen den Aktivitäten, und C ist die Menge der Prädikate (z. B. Übergangsbedingungen) (x bezeichnet das Kartesische Produkt). Dann wird ein Element (S. p, T) ∈ E in den folgenden Trigger transformiert:

TRIGGER S_p_T =	ON TERMINATE(S)
IF p
DO START(T)

In Fig. 1 wird die Kante (A, p1, B) (101, 102, 103) auf der Grundlage der fundamentalen Transformation in den Trigger A_p1_B = (TERMINATE(A), p1, START(B)) transformiert, der auf der rechten Seite von Fig. 1 dargestellt ist.

4.3. Die verbesserte Transformation - Berücksichtigung der Synchronisation

Einige Arbeitsablauf-Steuersysteme behandeln das Problem der Synchronisation paralleler Arbeitswege in einem Prozessmodell. Zu diesem Zweck wird spezielles Verhalten angenommen für Knoten, die mehr als einen ankommenden Steuerverbinder besitzen und als Verbindungsknoten bezeichnet werden: Ein solcher Knoten kann gestartet werden, wenn alle ankommenden Steuerverbindern durchlaufen wurden und seine Startbedingung erfüllt ist. Die Startbedingung ist eine Boolesche Bedingung in den Übergangsbedingungen der ankommenden Steuerverbinder. Typischerweise können zwei Situationen auftreten: entweder kann die Zielaktivität, die durch den Verbindungsknoten dargestellt wird, gestartet werden, falls eine der Übergangsbedingungen der ankommenden Steuerverbinder zu TRUE ausgewertet wird, oder die Zielaktivität kann gestartet werden, falls alle Übergangsbedingungen der Steuerverbinder TRUE sind. Durch Verbesserung von Schritt (3) der obigen Fundamentaltransformation kann dieses Verhalten widergespiegelt werden.

Die Methode der verbesserten Transformation wird unter Bezugnahme auf Fig. 2 dargestellt. Die zusätzliche Idee besteht darin, den Fall eines Verbindungsknotens als Zielaktivität durch eine verbesserte Transformation zu behandeln: wenn ein (Quellenknoten-, Steuerverbinder- Zielaktivitäts-) Konstruktionselement übersetzt wird, schließt die erzeugte Triggerbedingung nicht nur die Übergangsbedingungen des bestimmten Steuerverbinders ein, sondern enthält auch alle Übergangsbedingungen weiterer Steuerverbinder, die in diese bestimmte Zielaktivität eintreten. Die linke Seite von Fig. 2 widerspiegelt einen Teil eines Prozessmodells, das in einen Trigger transformiert werden soll, das einen solchen Verbindungsknoten (203) umfasst, der das Ziel des Quellknotens (201) ist, der mit dem Steuerverbinder (202) verbunden ist und mit ihm gemeinsam das bestimmte Konstruktionselement bildet, das in einen erzeugten Trigger transformiert werden soll. Wir wollen deshalb weiterhin annehmen, dass die Zielaktivität das Ziel mehrerer Steuerverbinder ist, die der gleichen oder verschiedenen Quellaktivitäten entstammen. Es sei (S, p, T) eine Kante, zum Beispiel ein Verbinder (202), eines gerichteten Graphen, der den Steuerfluss zwischen der Quellaktivität S, zum Beispiel der Aktivität (201), und der Zielaktivität T, zum Beispiel der Aktivität (203) festgelegt, wobei p die Bedingung bezeichnet, unter der der durch die Kante vorgeschriebene Übergang stattfinden soll. Die zentrale Idee besteht darin, diese Kante wie folgt in einen Trigger zu transformieren:

1. Die Quellaktivität S entspricht dem Beendigungsereignis dieser Aktivität. Dieses Ereignis wird durch TERMINATE(S) bezeichnet.
2. Die Zielaktivität T entspricht der Startaktion dieser Aktivität. Diese Aktivität wird durch START(T) bezeichnet.
3. Die Startbedingung J der Zielaktivität T wird in die Bedingung des Triggers transformiert, die die Übergangsbedingungen aller ankommenden Kanten als Parameter hat, beispielsweise:
- a) Wenn die Zielaktivität kein Verbindungsknoten ist (siehe Fig. 1), dann ist die Bedingung des Triggers einfach identisch mit der Übergangsbedingung dieser bestimmten Kante.
- b) Wenn die Zielaktivität ein Verbindungsknoten ist (siehe Fig. 2), dann ist die Bedingung des Triggers beispielsweise (P3 OR P4) oder (P3 AND P4) - oder s (p2, p3) in einer abstrakteren Notation.

Die abstrakte Beschreibung der verbesserten Transformation ist wie folgt:
Es sei G = (N, E, Φ) ein gerichteter Graph, der den Steuerfluss eines Geschäftsprozesses beschreibt. N ist die Menge der Aktivitäten, E ⊆ NxNxC ist die Menge der Steuerverbinder zwischen den Aktivitäten, C ist die Menge der Prädikate (z. B. Übergangsbedingungen), und Φ:N→C ist die Abbildung, die jeder Aktivität ihre Verbindungsbedingung zuordnet. Dann wird ein Element (S, p, T) ⊆ E in den folgenden Trigger transformiert:

TRIGGER S_p_T =	ON TERMINATE(S)
IF Φ(T) (T^←)
DO START(T)

wobei T^←

die Menge der Übergangsbedingungen aller Kanten bezeichnet, die zu T zeigen, d. h.

und Φ(T)(T^←) bezeichnet die konkreten Bedingungen für die Zielaktivität T auf der Grundlage der Menge T^← aller Steuerverbinder, die zu T zeigen.

In Fig. 2 ist der Knoten D (203,) ein Verbindungsknoten mit D^← = {p3, p4}, und wir wollen annehmen, dass die Verbindungsbedingung von D gleich p3 OR p4 ist. Dann sind die erzeugten Trigger B_p3_D = (TERMINATE(B), p3 OR p4, START(D)) und C_p4_D = (TERNINATE(C), P3 or P4, START (D)), was auf der rechten Seite von Fig. 2 veranschaulicht ist. Es ist wichtig zu bemerken, dass nicht nur die Bedingung (203), sondern auch alle weiteren Bedingungen zusätzlich ankommender Steuerverbinder, Steuerverbinder (204) im vorliegenden Fall, miteinander verbunden werden und ein logisches Gesamtprädikat bilden, das die Triggerbedingung (205) des erzeugten Triggers darstellt.

4.3.1. Die Speicherung von Wahrheitswerten für Verbindungsbedingungen

Die verbesserte Transformation erfordert mehr Intelligenz auf der Umsetzungsebene, weil Verbindungsknoten typischerweise Parallelarbeit synchronisieren. Deshalb werden die Quellaktivitäten von Kanten, die zu einer Zielaktivität zeigen, die ein Verbindungsknoten ist, zu verschiedenen Zeitpunkten beendet werden, d. h., die entsprechenden TERMINATE( ) - Ereignisse werden nicht, zur gleichen Zeit signalisiert. Infolgedessen wird die Bedingung eines Triggers, der einem Verbindungsknoten zugeordnet ist, im Allgemeinen nicht zu TRUE ausgewertet werden, weil zu einem bestimmten (Signalisierungs-) Zeitpunkt nur der Wahrheitswert einer ankommenden Transitionsbedingung verfügbar sein wird, und die anderen Übergangsbedingungen sind "unbekannt" (weil sie bereits "vergessen" worden sind oder weil sie noch nicht berechnet wurden).

Demzufolge muss die Gesamtumgebung imstande sein, historische Information über Ereignisse bzw. Wahrheitswerte von Bedingungen aufzubewahren. Der natürliche Weg, dies zu erreichen, besteht darin, die Ausführung der Routine, die die Bedingung der Trigger auswertet, zu verbessern: Diese Routine wird daran angepasst, Information über bereits signalisierte Ereignisse (beispielsweise hauptsächlich die Parameter des Ereignisses) aufzubewahren. Immer wenn die Auswertungsroutine eine zusammengesetzte Bedingung auszuwerten hat, greift sie auf diese Information zu, falls es notwendig ist (d. h., wenn der Wahrheitswert nicht auf der Grundlage der Parameter des tatsächlich signalisierten Ereignisses bestimmt werden kann) und benutzt ihn als Grundlage für die Auswertung der Triggerbedingung.

Das Gesamtergebnis besteht darin, dass die Transformation das Synchronisationsverhalten, so wie es in der operationalen Semantik der Arbeitsablauf-Steuersysteme vorgeschrieben ist, beibehält.

4.3.2. Die Berücksichtigung der Datenflüsse

Die vorliegende Erfindung kann auch Datenflüsse behandeln, so wie sie in Geschäftsprozessen festgelegt sind: Die Parameter {p₁, . . ., p_n} des Ereignisses TERMINATE(S) enthalten

- alle Parameter aller Übergangsbedingungen von Kanten, die zur Zielaktivität T zeigen,
- sowie den Eingabecontainer der Zielaktivität T, d. h.

wobei ^t(X)

den Eingangsbehälter von X bezeichnet. Die Parameter {q₁

, . . ., q_k

} der Triggerbedingung enthalten alle Parameter aller Übergangsbedingungen von Kanten, die zu T zeigen, d. h.

Die Parameter {r₁, . . ., r_m} der Aktion START(T) enthalten den Eingabecontainer von T, d. h. {r₁, . . ., r_m} = ^t(T). Demzufolge führt die verbesserte Transformation, die auch Datenflüsse berücksichtigt, zur Erzeugung des folgenden Triggers:

Dem Stand der Technik entsprechende Standardmethoden können angewendet werden, um tatsächlich die erforderlichen Parameter an die Triggerumgebung zu liefern. Eine vorteilhafte Methode ist beispielsweise die folgende:

- Die Systemkomponente der Gesamtumgebung, die das Ereignis TERMINATE(S) signalisiert, erzeugt alle Parameter {p₁, . . ., p_n} und gibt sie an die Triggerumgebung. Das Triggersystem kann dann auf diese Datenelemente durch ein gewisses Zugriffsprogramm (handle) oder einen API-Ruf oder andere Zugriffsmittel zugreifen.
- Die Aufgabe der Erzeugung aller erforderlichen Parameter wird aufgeteilt:
- - Die Auswertungsroutine der Triggerbedingungen erzeugt die Eingabedaten für diese Bedingungen selbst.
- - Die Transformation wird modifiziert, um für den Zielknoten eine zusammengesetzte Aktion zu erzeugen: Die erste Komponente der zusammengesetzten Aktion ist MATERIALIZE(T), was den Eingabecontainer von T erzeugt und ihn an die richtige START(T)-Aktion weitergibt, die die zweite Komponente der zusammengesetzten Aktion ist. Die allgemeine MATERIALIZE(T)-Ausführung kann als Teil der Umgebung bereitgestellt werden.

Es muss beachtet werden, dass einige Arbeitsablauf- Steuersysteme die Erzeugung der Eingabecontainer als Teil des START(S)-Service bereitstellen: Somit ist letztere Modifikation nicht notwendig, wenn eine Ausführungsform unserer Erfindung vorhandene APIs von Arbeitsablaufsystemen aus der Triggerumgebung benutzen.

4.3.3 Weitere Eigenschaften der Ausführungsform auf der Grundlage der DB2 UDB Active Database

Als Beispiel für eine Ausführungsform der Triggerumgebung können die aktiven Datenbankeigenschaften von DB2 UDB verwendet werden. In einer solchen Ausführungsform möge die erzeugte Aktion eine zusammengesetzte Aktion sein, die insbesondere aus der START( )-Aktion besteht, um die Zielaktivität zu starten, sowie einer neuen Aktion, die die Beendigung der Zielaktivität (SIGNALTERMINATION( )) (301) signalisiert, so wie in Fig. 3 dargestellt. Die Ausführung dieser Aufforderung zur Beendigung durch die Triggerumgebung würde zu einem Tupel führen, das in eine Systemtabelle T1, (302) eingefügt wird, was die Beendigung der Zielaktivität (303) anzeigt. Die Tabelle T1 kann als ein Verzeichnis beendeter Aktivitäten angesehen werden, die auf weitere Steuerung warten.

Tabelle T1 wird durch ein spezielles Programm PGM X (304) in einer Schleife verarbeitet: PGM X entfernt zu einem Zeitpunkt ein Tupel aus Tabelle T1 und erzeugt ein entsprechendes neues Tupel in einer zweiten Systemtabelle T2 (305) (d. h., in einer einzigen Transaktion entfernt PGM X ein Tupel aus T1 und fügt ein Tupel in T2 ein). Das in die Tabelle T2 eingefügte Tupel stellt das korrekte Signal der Beendigung einer Aktivität dar (d. h. das Ereignis TERMINATE( )) und löst die vorher skizzierte Verarbeitung aus, d. h., die Entstehung des Signals, dass die Zielaktivität B (303) beendet wurde, würde das Triggersystem . veranlassen, nach einem weiteren Trigger zu suchen, der diesem Ereignis entspricht, der dann durch das Triggersystem als nächster Schritt verarbeitet würde. PGM X könnte alle erforderlichen Parameter des Ereignisses berechnen und sie in eine Spalte von Tabelle T2 eintragen. Aber die Berechnung dieser Parameter könnte auch innerhalb der Triggeraktion geschehen, indem eine gesonderte MATERIALIZE( )-Komponente zu der erzeugten Aktion hinzugefügt wird. In ähnlicher Weise muss dann die Funktion, die die Triggerbedingung auswertet (siehe unten), erweitert werden, um alle erforderlichen Parameter zu erzeugen.

Konzeptionell können die Tabellen T1 und T2 auch zu einer einzigen Tabelle zusammengefügt werden, und ein Tabellenkennzeichen könnte verwendet werden, um Datensätze in Tabellen zu unterscheiden, die einen Datensatzzustand angeben, der gerade die Beendigung einer Aktivität anzeigt, und einen Datensatzzustand, der das endgültige Abschlussereignis und die Bereitschaft zum Versenden signalisiert (zum Beispiel nach der Beendigung der Verarbeitung der gesamten Erzeugung, die die erzeugten Daten in der Tabelle verfügbar macht). Es ist nur von Wichtigkeit, dass PGM X alle erforderlichen Parameter ermittelt, einen Tabellendatensatz in die Tabelle T2 einfügt, der alle Parameter für ein Beendigungssignal enthält, das durch das Triggersystem verschickt werden kann.

Die erzeugte Triggerangabe für das Beispiel von Fig. 3, die der Syntax von DB2 UDB und der obigen bestimmten Ausführungsform folgt, ist in Fig. 4 dargestellt.

Die verschiedenen Klauseln der Triggerdefinition sollten klar auf dem vorher Gesagten beruhen. Die Verarbeitung des ausgelösten Triggerereignisses wird gestartet, wenn das Beendigungsereignis in Tabelle T2 eingefügt wird (401), was auch alle erzeugten Parameter bereitstellt. Im nächsten Schritt der Triggerverarbeitung wird die Triggerbedingung ausgewertet (402). Die VALUE-Klausel wird verwendet, um eine benutzerdefinierte Funktion für Auswertungszwecke aufzurufen: Beispielsweise hat die Funktion EVALUATE( ) wenigstens die beiden Parameter P (d. h. die Übergangsbedingung) und N.parms (unter der Voraussetzung, dass T2 eine Spalte mit dem Namen PARMS besitzt mit allen für die Triggerbedingung erforderlichen Parametern und PARMS als eine Behandlungsroutine für den Datenzugriff dient). Die nächsten Schritte innerhalb der Triggerverarbeitung werden nur ausgeführt, wenn die Übergangsbedingung (402) zu TRUE ausgewertet wird (403). Wiederum auf der Grundlage der VALUE-Klausel wird die entsprechende Zielaktivität START (B) vom Triggersystem aufgerufen. Nach ihrem Abschluss fügt die Beendigungsanforderung (405) ein entsprechendes Abschlusssatz- Tupel in die Systemtabelle T1 ein, was die Beendigung der Aktivität sowie das Warten auf Steuerung anzeigt, was schließlich zur Signalisierung eines neuen Ereignisses führt - im Wesentlichen ist die Beendigungsanforderung (405) eine spezifische Ausführung der Vorgehensweise, die oben auf der Grundlage des Rufes SIGNAL/TERMINATION( ) erläutert wurde.

5 Vorteile der Erfindung

Die vorliegende Erfindung ist eine Kombination aus WFMS- Technologie und Triggertechnologie. Die vorliegende Erfindung lehrt, wie die Steuerflüsse von Geschäftsprozess-Modellen auf ECA-Regeln abzubilden sind. Die Interpretation der erzeugten ECA-Regeln selbst kann auf verschiedene Arten realisiert werden, z. B. in aktiven Datenbanksystemen, Agentensystemen oder Veröffentlichungs-/Bestätigungs-Umgebungen. Folglich kann unsere Erfindung für die Umsetzung eines Arbeitsablaufsystems verwendet werden, das auf einer Vielzahl verschiedener Technologien beruht. Die Erfindung lehrte eine Methode, Geschäftsprozesse vollständig mit Mitteln und auf der Grundlage der WFMS zu modellieren und zu definieren, aber auf der anderen Seite die Option zu eröffnen, die Technologie der Triggersysteme als eine reine Umsetzungsumgebung zu nutzen, indem automatisch Trigger-Festlegungen erzeugt werden, die durch das Triggersystem direkt ausführbar sind.

Darüber hinaus ist die vorliegende Erfindung durch den Vorschlag einer verbesserten Transformationsmethodik auch imstande, das Synchronisationsproblem paralleler Steuerpfade im Prozessmodell automatisch zu lösen. Damit wird die Anwendbarkeit der vorgeschlagenen Methodik bedeutend erhöht, da die meisten Prozessmodelle, die einen realen Geschäftsprozess modellieren, parallele Steuerpfade behandeln müssen.

Die vorgeschlagene Methodik ist auch imstande, den speziellen Datenfluss in den automatisierten Transformations- und Erzeugungsprozess der Trigger-Festlegungen einzuschließen, der vom Steuerfluss begleitet wird, beispielsweise über Eingabe- und Ausgabecontainer.

Weiterhin ist es durch eine zusätzliche Beendigungsanforderung, die auch während des Transformationsprozesses als Teil der Trigger-Festlegungen erzeugt wird, möglich geworden, das nächste Triggerereignis auf dem Triggersystem transparente Weise zu signalisieren. Eine eventuelle Notwendigkeit, das Triggersystem an die Auslösung des nächsten Ereignisses anzupassen, wurde vollständig vermieden.

Die tatsächliche Realisierung der ausgelösten Ereignisse als Datensätze in einer Tabelle (beispielsweise einer Datenbank) erlaubt eine effektive Methodik der Realisierung der Erzeugungs-Logik. Es wird ermöglicht, dass die Erzeugung unabhängig von den Trigger-Festlegungen im Hintergrund arbeitet und für die korrekte Erzeugung der Übergangsbedingungs- Parameter und der Eingabe- und Ausgabe-Container sorgt. Zusätzlich wird die Dauerhaftigkeit des Status der verschiedenen Ereignisse ohne weitere Vorkehrungen garantiert.

Claims

1. Computergestütztes Verfahren zur automatischen Transformation des Prozessmodells eines Arbeitsablaufs- Verwaltungs-Systems in Trigger-Festlegungen, die innerhalb eines Triggersystems ausführbar sind, wobei das Prozessmodell wenigstens eine Quellaktivität S und eine Zielaktivität T sowie einen Steuerverbinder umfasst, der einen möglichen Steuerfluss von der Quellaktivität zur Zielaktivität definiert und dem eine Übergangsbedingung P zugeordnet ist,
wobei das Verfahren gekennzeichnet wird
durch Transformation der Quellaktivität S in das Triggerereignis TERMINATE(S), wobei das Triggerereignis, wenn es zur Laufzeit ausgelöst wird, dem Triggersystem anzeigt, dass eine Instanz der Quellaktivität beendet wurde, und
durch Transformation des Steuerverbinders in eine Triggerbedingung, welche das Triggersystem zur Laufzeit veranlasst, wenn das Triggerereignis ausgelöst wurde, den Wahrheitswert der Übergangsbedingung zu berechnen; und
durch Transformation der Zielaktivität T in eine Triggeraktion START(T), die das Triggersystem zur Laufzeit veranlasst, falls die Triggerbedingung zu TRUE ausgewertet wird, eine Instanz der Zielaktivität zu starten.

2. Computergestütztes Verfahren zur automatischen Transformation eines Prozessmodells nach Anspruch 1,
wobei die Zielaktivität in dem Prozessmodell eine Verbindungsaktivität (join activity) ist, die das Ziel von wenigstens einem weiteren Steuerverbinder ist, dem eine weitere Übergangsbedingung P2 zugeordnet ist,
und das Verfahren gekennzeichnet ist
durch Transformation des Steuerverbinders in eine Triggerbedingung durch eine logische ODER-Verknüpfung der Übergangsbedingung mit der weiteren Übergangsbedingung (P OR P2), falls das Arbeitsablauf-Management-System definiert, dass die Zielaktivität gestartet werden soll, wenn eine der beiden Übergangsbedingungen zu TRUE ausgewertet wird, oder
durch Transformation des Steuerverbinders in eine Triggerbedingung durch eine logische AND-Verknüpfung der Übergangsbedingung mit der weiteren Übergangsbedingung (P AND P2), falls das Arbeitsablauf-Management-System definiert, dass die Zielaktivität gestartet werden soll, wenn alle Übergangsbedingungen zu TRUE ausgewertet werden.

3. Computergestütztes Verfahren zur automatischen Transformation eines Prozessmodells nach Anspruch 1 oder 2,
wobei jede Aktivität innerhalb des Prozessmodells einen Eingabecontainer und einen Ausgabecontainer umfasst
und das Verfahren gekennzeichnet ist durch
Einbeziehung von Zugriffsmitteln in die Trigger- Festlegung, was es dem Triggersystem zur Laufzeit erlaubt, auf die Parameter aller Übergangsbedingungen und Eingabecontainer und Ausgabecontainer der Quellaktivität und der Zielaktivität zuzugreifen.

4. Computergestütztes Verfahren zur automatischen Transformation eines Prozessmodells nach Anspruch 3, das eine Beendigungsanforderung SIGNALTERMINATION(T) in die Triggeraktion einschließt und das Triggersystem auf die Beendigungsanforderung zur Laufzeit reagiert, indem ein neues Ereignis TERMINATE(T) ausgelöst wird, falls die Instanz der Zielaktivität beendet wurde.

5. Computergestütztes Verfahren zur automatischen Transformation eines Prozessmodells nach Anspruch 4, wobei die Beendigungsanforderung eine Anforderung umfasst, zur Laufzeit einen Beendigungsdatensatz in eine Tabelle zu speichern, was die Beendigung der Instanz der Zielaktivität anzeigt, wobei die Tabelle zur Laufzeit durch das Triggersystem dazu verwendbar ist, die ausgelösten Triggerereignisse zu bestimmen.

6. Computergestütztes Verfahren zur automatischen Transformation eines Prozessmodells nach Anspruch 1,
wobei die Zielaktivität in dem Prozessmodell eine Verbindungsaktivität ist, die das Ziel von einem oder mehreren weiteren Steuerverbindern ist, denen weitere Übergangsbedingungen Pi zugeordnet sind, und das Prozessmodell definiert, dass die Zielaktivität gestartet werden soll, falls ein Boolescher Ausdruck B (P1, . . ., Pi, . . .), der auf den Übergangsbedingungen beruht, zu TRUE ausgewertet wird, und
das Verfahren gekennzeichnet wird
durch Transformation des Steuerverbinders in eine Triggerbedingung, die den Booleschen Ausdruck B (P, . . ., P1, . . .) darstellt.

7. System, das Mittel umfasst, die geeignet sind zur Ausführung der Schritte des Verfahrens nach einem beliebigen der Ansprüche 1 bis 6.

8. Datenverarbeitungsprogramm zur Ausführung in einem Datenverarbeitungssystem, das Softwarecode-Elemente zur Ausführung eines Verfahrens nach einem der vorhergehenden Ansprüche 1 bis 6 umfasst.

9. Computerprogrammprodukt, das auf einem durch einen Computer nutzbaren Medium gespeichert ist und vom Computer lesbare Programm-Mittel enthält, um einen Computer zu veranlassen, ein Verfahren nach einem der vorhergehenden Ansprüche 1 bis 6 auszuführen.