DE10003015A1 - Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus Prozessmodellen - Google Patents
Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus ProzessmodellenInfo
- Publication number
- DE10003015A1 DE10003015A1 DE10003015A DE10003015A DE10003015A1 DE 10003015 A1 DE10003015 A1 DE 10003015A1 DE 10003015 A DE10003015 A DE 10003015A DE 10003015 A DE10003015 A DE 10003015A DE 10003015 A1 DE10003015 A1 DE 10003015A1
- Authority
- DE
- Germany
- Prior art keywords
- trigger
- activity
- condition
- process model
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Development Economics (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Stored Programmes (AREA)
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
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.
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.
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.
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.
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.
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.
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.
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(p1, . . ., pn) [∼ Ereignis]
IF c(q1, . . ., qk) [∼ Bedingung]
DO a(r1, . . ., rm) [∼ Aktion]
ON e(p1, . . ., pn) [∼ Ereignis]
IF c(q1, . . ., qk) [∼ Bedingung]
DO a(r1, . . ., rm) [∼ Aktion]
Hier bezeichnet {p1, . . ., pn} die Parameter, die in das System
übertragen werden, wenn das Ereignis mit dem Namen e eintritt,
{q1, . . ., qk} ⊆ {p1, . . ., pn} sind die Parameter, die notwendig sind, um
die Bedingung mit dem Namen c auszuwerten, und {r1, . . ., rm} ⊆
{p1, . . ., pn} 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.
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:
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.
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:
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.
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.
Die vorliegende Erfindung kann auch Datenflüsse behandeln, so
wie sie in Geschäftsprozessen festgelegt sind: Die Parameter
{p1, . . ., pn} 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
{q1
, . . ., qk
} der Triggerbedingung enthalten alle Parameter aller
Übergangsbedingungen von Kanten, die zu T zeigen, d. h.
Die Parameter {r1, . . ., rm} der Aktion START(T) enthalten den
Eingabecontainer von T, d. h. {r1, . . ., rm} = 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 {p1, . . ., pn} 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.
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.
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 (9)
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.
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.
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.
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.
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.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP99102337 | 1999-02-06 |
Publications (1)
Publication Number | Publication Date |
---|---|
DE10003015A1 true DE10003015A1 (de) | 2000-08-17 |
Family
ID=8237517
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10003015A Ceased DE10003015A1 (de) | 1999-02-06 | 2000-01-25 | Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus Prozessmodellen |
Country Status (2)
Country | Link |
---|---|
US (1) | US6826579B1 (de) |
DE (1) | DE10003015A1 (de) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1577811A1 (de) * | 2004-03-15 | 2005-09-21 | Ramco Systems Limited | System und Verfahren zum Nachweis von Unternehmensdaten |
US8121877B2 (en) * | 2007-07-18 | 2012-02-21 | International Business Machines Corporation | Dynamic evolution of business performance management solutions using declarative evolution policies |
CN112668795A (zh) * | 2020-12-31 | 2021-04-16 | 盐城师范学院 | 一种环锭纺纱信息物理生产系统建模方法 |
Families Citing this family (56)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7979382B2 (en) | 1999-05-04 | 2011-07-12 | Accenture Global Services Limited | Component based information linking during claim processing |
US7277863B1 (en) * | 2000-06-13 | 2007-10-02 | I2 Technologies Us, Inc. | Electronic marketplace communication system |
US7739325B1 (en) * | 2000-04-24 | 2010-06-15 | Aspect Software, Inc. | Apparatus and method for extensible real-time workflows |
JP2001356907A (ja) * | 2000-06-09 | 2001-12-26 | Ibm Japan Ltd | 処理コード情報を有するデータベース・システムおよび情報処理システム |
US7925527B1 (en) * | 2000-08-16 | 2011-04-12 | Sparta Systems, Inc. | Process control system utilizing a database system to monitor a project's progress and enforce a workflow of activities within the project |
US7020869B2 (en) * | 2000-12-01 | 2006-03-28 | Corticon Technologies, Inc. | Business rules user interface for development of adaptable enterprise applications |
GB2376094A (en) * | 2001-05-30 | 2002-12-04 | Ibm | Flexible navigation of a workflow graph in a data processing system |
GB2376311B (en) * | 2001-06-04 | 2005-06-08 | Hewlett Packard Co | A method of managing workflow in a computer-based system |
US7577554B2 (en) * | 2001-07-03 | 2009-08-18 | I2 Technologies Us, Inc. | Workflow modeling using an acyclic directed graph data structure |
WO2003015000A1 (en) * | 2001-08-08 | 2003-02-20 | Trivium Systems Inc. | Workflow engine for automating business processes in scalable multiprocessor computer platforms |
JP2003067185A (ja) * | 2001-08-14 | 2003-03-07 | Internatl Business Mach Corp <Ibm> | アプリケーション編集装置、データ処理方法及びプログラム |
US7703077B2 (en) * | 2002-04-30 | 2010-04-20 | Microsoft Corporation | Programming model to detect deadlocks in concurrent programs |
US7203924B2 (en) * | 2002-04-30 | 2007-04-10 | Microsoft Corporation | Behavioral analysis for message-passing application programs |
US7127467B2 (en) * | 2002-05-10 | 2006-10-24 | Oracle International Corporation | Managing expressions in a database system |
US7565379B2 (en) | 2002-08-01 | 2009-07-21 | Edwina Lu | Preventing change cycling using rules and redo tags in a redo log |
US8005802B2 (en) | 2002-08-01 | 2011-08-23 | Oracle International Corporation | Partial evaluation of rule sets |
US8126742B2 (en) | 2003-05-09 | 2012-02-28 | Accenture Global Services Limited | Automated assignment of insurable events |
JP4150965B2 (ja) * | 2003-05-12 | 2008-09-17 | オムロン株式会社 | 端末装置、業務指示方法、コンテンツ提供装置、コンテンツ提供方法、記録媒体、プログラム、業務管理システム、および業務管理方法 |
US8365193B2 (en) | 2003-08-14 | 2013-01-29 | Oracle International Corporation | Recoverable asynchronous message driven processing in a multi-node system |
US7444314B2 (en) * | 2003-12-01 | 2008-10-28 | International Business Machines Corporation | Methods and apparatus for business rules authoring and operation employing a customizable vocabulary |
US7797669B1 (en) | 2004-02-13 | 2010-09-14 | Microsoft Corporation | Analysis of distributed software systems via specification substitution |
US20050222996A1 (en) * | 2004-03-30 | 2005-10-06 | Oracle International Corporation | Managing event-condition-action rules in a database system |
US7567975B2 (en) * | 2005-03-16 | 2009-07-28 | Oracle International Corporation | Incremental evaluation of complex event-condition-action rules in a database system |
US8965949B2 (en) * | 2005-04-29 | 2015-02-24 | Xerox Corporation | System and method for applying computational knowledge to device data |
US7693586B2 (en) * | 2005-09-02 | 2010-04-06 | Sap Ag | Process model transformation for event-based coordination of composite applications |
US7873422B2 (en) * | 2005-09-02 | 2011-01-18 | Sap Ag | Event-based coordination of process-oriented composite applications |
US7933786B2 (en) | 2005-11-01 | 2011-04-26 | Accenture Global Services Limited | Collaborative intelligent task processor for insurance claims |
US8312420B1 (en) | 2005-11-18 | 2012-11-13 | The Mathworks, Inc. | System and method for performing structural templatization |
US8364840B2 (en) * | 2005-12-02 | 2013-01-29 | Sap Ag | Dynamic message routing |
US20070129980A1 (en) * | 2005-12-02 | 2007-06-07 | Barros Alistair P | Transactional atomicity in service interactions of business processes |
US7565373B2 (en) * | 2005-12-07 | 2009-07-21 | Teradata Us, Inc. | Automating business events |
US20070156487A1 (en) * | 2005-12-29 | 2007-07-05 | Microsoft Corporation | Object model on workflow |
US20070156486A1 (en) * | 2005-12-29 | 2007-07-05 | Microsoft Corporation | Multiple concurrent workflow persistence schemes |
US8849691B2 (en) * | 2005-12-29 | 2014-09-30 | Microsoft Corporation | Modeling user input and interaction in workflow based applications |
US8626557B2 (en) * | 2006-09-26 | 2014-01-07 | International Business Machines Corporation | System and method of providing snapshot to support approval of workflow changes |
US9691038B2 (en) * | 2006-11-03 | 2017-06-27 | International Business Machines Corporation | Method and apparatus for examining workflow processes |
GB0702822D0 (en) * | 2007-02-14 | 2007-03-28 | Salamander Organization The Lt | Organisation representational system |
US9027025B2 (en) | 2007-04-17 | 2015-05-05 | Oracle International Corporation | Real-time database exception monitoring tool using instance eviction data |
US7912804B1 (en) | 2007-04-24 | 2011-03-22 | Hewlett-Packard Development Company, L.P. | Change management in a distributed system based on triggered policy rules |
US8321841B2 (en) * | 2008-01-08 | 2012-11-27 | International Business Machines Corporation | Validation framework for service oriented architecture (SOA) application adoption |
US8478769B2 (en) | 2008-02-22 | 2013-07-02 | Accenture Global Services Limited | Conversational question generation system adapted for an insurance claim processing system |
US8515786B2 (en) | 2008-02-22 | 2013-08-20 | Accenture Global Services Gmbh | Rule generation system adapted for an insurance claim processing system |
EP2199956A1 (de) * | 2008-12-18 | 2010-06-23 | Siemens Aktiengesellschaft | Verfahren und System zum Verwalten von Ergebnissen eines Analyseverfahrens an Gegenständen, die entlang einer technischen Verfahrenslinie gehandhabt werden |
US9354847B2 (en) | 2008-12-29 | 2016-05-31 | Microsoft Technology Licensing, Llc | Interface infrastructure for a continuation based runtime |
US9128895B2 (en) | 2009-02-19 | 2015-09-08 | Oracle International Corporation | Intelligent flood control management |
US8635331B2 (en) * | 2009-08-05 | 2014-01-21 | Microsoft Corporation | Distributed workflow framework |
US20110153519A1 (en) * | 2009-12-22 | 2011-06-23 | Sap Ag | Systems and methods for generating trigger networks corresponding to event-condition-action rules |
US9165086B2 (en) | 2010-01-20 | 2015-10-20 | Oracle International Corporation | Hybrid binary XML storage model for efficient XML processing |
US8458530B2 (en) | 2010-09-21 | 2013-06-04 | Oracle International Corporation | Continuous system health indicator for managing computer system alerts |
US8566784B2 (en) | 2011-09-22 | 2013-10-22 | Sap Ag | Business process change controller |
US9536264B2 (en) | 2011-11-14 | 2017-01-03 | Microsoft Technology Licensing, Llc | Host agnostic messaging in a continuation based runtime |
US10346422B2 (en) | 2012-10-18 | 2019-07-09 | International Business Machines Corporation | Use of proxy objects for integration between a content management system and a case management system |
US20140114864A1 (en) * | 2012-10-22 | 2014-04-24 | International Business Machines Corporation | Case management integration with external content repositories |
US9354860B2 (en) | 2014-07-15 | 2016-05-31 | Sap Se | Optimizing software change processes using real-time analysis and rule-based hinting |
US9946983B1 (en) * | 2015-06-10 | 2018-04-17 | Amazon Technologies, Inc. | Rule-based electronic workflow processing |
US11543930B2 (en) * | 2020-11-10 | 2023-01-03 | RealFar Ltd | Augmenting web applications with optimized workflows supporting user interaction |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1995003586A1 (en) * | 1993-07-21 | 1995-02-02 | Persistence Software, Inc. | Method and apparatus for generation of code for mapping relational data to objects |
US5734837A (en) * | 1994-01-14 | 1998-03-31 | Action Technologies, Inc. | Method and apparatus for building business process applications in terms of its workflows |
DE19705955A1 (de) * | 1996-03-29 | 1997-10-02 | Ibm | Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung |
US5802527A (en) * | 1996-12-31 | 1998-09-01 | Mci Communications Corporation | Data enhancement engine |
US6212672B1 (en) * | 1997-03-07 | 2001-04-03 | Dynamics Research Corporation | Software development system with an executable working model in an interpretable intermediate modeling language |
US6182274B1 (en) * | 1997-05-01 | 2001-01-30 | International Business Machines Corporation | Reusing code in object-oriented program development |
US5926819A (en) * | 1997-05-30 | 1999-07-20 | Oracle Corporation | In-line triggers |
US5937410A (en) * | 1997-10-16 | 1999-08-10 | Johnson Controls Technology Company | Method of transforming graphical object diagrams to product data manager schema |
US6199195B1 (en) * | 1999-07-08 | 2001-03-06 | Science Application International Corporation | Automatically generated objects within extensible object frameworks and links to enterprise resources |
-
2000
- 2000-01-25 DE DE10003015A patent/DE10003015A1/de not_active Ceased
- 2000-02-04 US US09/498,835 patent/US6826579B1/en not_active Expired - Fee Related
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1577811A1 (de) * | 2004-03-15 | 2005-09-21 | Ramco Systems Limited | System und Verfahren zum Nachweis von Unternehmensdaten |
US7774305B2 (en) | 2004-03-15 | 2010-08-10 | Ramco Systems Limited | System and method for auditing enterprise data |
US8121877B2 (en) * | 2007-07-18 | 2012-02-21 | International Business Machines Corporation | Dynamic evolution of business performance management solutions using declarative evolution policies |
CN112668795A (zh) * | 2020-12-31 | 2021-04-16 | 盐城师范学院 | 一种环锭纺纱信息物理生产系统建模方法 |
CN112668795B (zh) * | 2020-12-31 | 2023-06-30 | 盐城师范学院 | 一种环锭纺纱信息物理生产系统建模方法 |
Also Published As
Publication number | Publication date |
---|---|
US6826579B1 (en) | 2004-11-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE10003015A1 (de) | Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus Prozessmodellen | |
DE69802437T2 (de) | Feinkörniger übereinstimmungsmechanismus für optimistische parallelsteuerung mit verriegelungsgruppen | |
DE69811790T2 (de) | Ableitung von Prozessmodellen aus Rechnungsprüfvorgängen für Systeme zur Verwaltung von Arbeitsflüssen | |
DE69736748T2 (de) | Editierumgebung für objektmodelle und verfahren zu deren anwendung | |
DE69415917T2 (de) | System und Verfahren zum Optimieren vom Nachrichtenaustausch zwischen Agenten in verteilten Systemen | |
DE19705955A1 (de) | Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung | |
DE69719269T2 (de) | Absicherung der Unteilbarkeit für eine Ansammlung von transaktionellen Arbeitsschritten in einem Arbeitsflussverwaltungssystem | |
DE69523939T2 (de) | Verfahren zur erzeugung von objektstrukturen für den zugriff auf konventionelle, nicht objekt-orientierte geschäftsanwendungen | |
DE19955718A1 (de) | Paralleler Datenbank-Support für Workflow-Management-Systeme | |
DE19712946A1 (de) | Methode zum Generieren einer Implementierung wiederverwendbarer Teile von Containern eines Workflow-Prozessmodells | |
DE69628374T2 (de) | Datenverwaltungssystem | |
DE10040987B4 (de) | Verfahren und Vorrichtung für übereinstimmende Aktualisierungen von redundanten Daten in relationalen Datenbanken | |
DE19948028A1 (de) | Verfahren und System zum Optimieren des Anforderungsschickens in Workflow Management Systemen | |
DE10128883A1 (de) | Verfahren und System für die Verteilung von Anwendungsdaten auf verteilte Datenbanken mit verschiedenen Formaten | |
EP1758051A1 (de) | System, Verfahren und Computerprogrammprodukt zur arbeitsflussbasierten Datenverarbeitung | |
DE69522713T2 (de) | Verfahren zum assoziieren von datentragenden objekten mit objekten der benutzerschnittstelle | |
DE69814697T2 (de) | Vorrichtung, methode und computer programm produkt für client/server rechner mit vom client auswählbarer lokalisierung von transaktionsobjekten | |
EP2648094B1 (de) | Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses | |
DE19960048A1 (de) | Zeitgesteuerte Startbedingungen für Aktivitäten in Workflow-Management-Systemen | |
DE112018005049T5 (de) | Transformieren einer spezifikation in ein dauerhaftes computerprogramm | |
DE10125956A1 (de) | Archivierung in Arbeitsablaufverwaltungssystemen | |
EP3776257B1 (de) | Objektdatenbank zur geschäftsmodellierung mit verbesserter datensicherheit | |
EP1285315B1 (de) | Informationsverarbeitungssystem und verfahren zu dessen betrieb | |
EP1187001A2 (de) | Integriertes Wissens-Technologiesystem | |
DE60315030T2 (de) | Vermeiden von datenverlusten beim aktualisieren eines data warehouse |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8131 | Rejection |