DE19955004A1 - Ableitung und Ausführung von Workload-Manager-Enklaven aus Workflows - Google Patents
Ableitung und Ausführung von Workload-Manager-Enklaven aus WorkflowsInfo
- Publication number
- DE19955004A1 DE19955004A1 DE19955004A DE19955004A DE19955004A1 DE 19955004 A1 DE19955004 A1 DE 19955004A1 DE 19955004 A DE19955004 A DE 19955004A DE 19955004 A DE19955004 A DE 19955004A DE 19955004 A1 DE19955004 A1 DE 19955004A1
- Authority
- DE
- Germany
- Prior art keywords
- enclave
- graph
- activities
- workload management
- wfms
- 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/10—Office automation; Time management
-
- 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
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06316—Sequencing of tasks or work
Landscapes
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Engineering & Computer Science (AREA)
- Entrepreneurship & Innovation (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Tourism & Hospitality (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Game Theory and Decision Science (AREA)
- Development Economics (AREA)
- Educational Administration (AREA)
- Data Mining & Analysis (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Die vorliegende Erfindung betrifft ein Verfahren für das Workload-Management in einem Workflow-Management-System (WFMS). DOLLAR A Die Erfindung schlägt ein erstes Verfahren vor, das automatisch mindestens einen Einklave-Graphen in einem Prozeßmodell eines Workflow-Management-Systems (WFMS) bestimmt. DOLLAR A Die Erfindung schlägt ein zweites Verfahren zur Ausführung der Enklave-Graphen vor. Das Verfahren enthält einen Enklave-Erstellungsschritt, in dem das WFMS, wenn der Kontrollfluß zum ersten Mal in den Enklave-Graphen eintritt, im WLM eine Workload-Management-Enklave für die Aktivitäten, die Bestandteile des Enklave-Graphen sind, erzeugt. Entsprechend enthält das Verfahren auch einen Enklave-Verbindungs-Schritt, indem das WFMS eine Aktivität des Enklave-Graphen im Namen der Aktivität mit der Workload-Management-Enklave im WLM verbindet. Außerdem enthält das Verfahren einen Enklave-Lösch-Schritt, in dem die Workload-Management-Enklave im Namen der Aktivitäten gelöscht wird.
Description
Die vorliegende Erfindung betrifft das Gebiet des Workload-
/Leistungs-Management. Speziell geht es um ein Verfahren für
das Workflow-Management in einem Workflow-Management-System
(WFMS).
Ein neuer Technologiebereich, der zunehmend an Bedeutung
gewinnt, ist das Gebiet der Workflow-Management-Systeme
(WFMS). WFMS unterstützen die Modellierung und Ausführung von
Geschäftsprozessen. Geschäftsprozesse steuern, welche
Arbeitseinheit aus einem Netzwerk von Arbeitsaufträgen von wem
ausgeführt werden, und welche Ressourcen für diese Arbeit
genutzt werden; d. h. ein Geschäftsablauf beschreibt, wie ein
Unternehmen seine Unternehmensziele erreichen will. Die
einzelnen Arbeitsaufträge können auf viele verschiedene
Computersysteme verteilt sein, die durch ein Netzwerk
miteinander verbunden sind.
Der Prozeß der Planung, Entwicklung und Herstellung eines
neuen Produktes und der Prozeß der Änderung oder Anpassung
eines vorhandenen Produktes konfrontiert Produktmanager und
-ingenieure mit vielen Herausforderungen, um das Produkt zu den
geringsten Kosten und innerhalb des Zeitplans auf den Markt zu
bringen, und dabei gleichzeitig die Produktqualität
beizubehalten oder sogar zu verbessern. Viele Unternehmen
erkennen inzwischen, daß der traditionelle
Produktplanungsprozeß diesen Bedürfnissen nicht gerecht wird.
Sie fordern eine frühzeitige Beteiligung der
Produktionsplanungs-, Kostenplanungs-, Logistikplanungs-,
Einkaufs-, Produktions-, Service- und Support-Abteilung an der
Planung. Außerdem ist eine Planung und Kontrolle von
Produktdaten während der Planungs-, Markteinführungs- und
Produktionsphase erforderlich.
Die korrekte und effiziente Durchführung von
Geschäftsprozessen wie z. B. Entwicklungs- oder
Produktionsprozessen in einem Unternehmen ist von größter
Wichtigkeit für ein Unternehmen und hat einen wesentlichen
Einfluß auf den Gesamterfolg des Unternehmens auf dem Markt.
Diese Prozesse müssen deshalb in ähnlicher Weise wie
Technologieprozesse betrachtet werden, und müssen getestet,
optimiert und überwacht werden. Die Verwaltung solcher
Prozesse wird in der Regel von einem computergestützten Prozeß
oder einem Workflow-Management-System ausgeführt und
unterstützt.
In D. J. Spoon: "Project Management Environment", IBM
Technical Disclosure Bulletin, Bd. 32, Nr. 9A, Februar 1990,
S. 250-254, wird eine Prozeßmanagement-Umgebung beschrieben,
die aus einer Betriebsumgebung, Datenelementen sowie
Anwendungsfunktionen und -prozessen besteht.
In R. T. Marshak: "IBMs FlowMark, Object-Oriented Workflow
for Mission-Critical Applications", Workgroup Computing Report
(USA), Bd. 17, Nr. S. 1994, S. 3-13, wird der
Objektcharakter von IBM FlowMark als Client/Server-Produkt auf
der Basis eines echten Objektmodells für eine
missionskritische Produktionsprozeßanwendungs-Entwicklung und
-Weiterentwicklung beschrieben.
In H. A. Inniss and J. H. Sheridan: "Workflow Management Based
on an Object-Oriented Paradigm", IHM Technical Disclosure
Bulletin, Bd. 37, Nr. 3, März 1994, S. 185, werden andere
Aspekte der objektorientierten Modellierung von
kundenspezifischer Anpassung und Änderungen beschrieben.
In F. Leymann and D. Roller: "Business Process Management with
FlowMark", Digest of papers, Cat. No. 94CH3414-0, Spring
COMPCON 94, 1994, S. 230-234, wird der Stand der Technik auf
dem Gebiet des Prozeßmanagement-Computerprogramms IBM FlowMark
beschrieben. Das Metamodell von IBM FlowMark wird ebenso
vorgestellt wie die Implementierung von IBM FlowMark. Hier
werden die Möglichkeiten, die IBM FlowMark für die
Modellierung von Geschäftsprozessen bietet, und ihre
Ausführung erläutert. Das Software-Produkt IBM FlowMark steht
für verschiedene Computerplattformen zur Verfügung, und
Dokumentation zu IBM FlowMark ist in jeder IBM-Zweigstelle
erhältlich.
In F. Leymann: "A meta model to support the modeling and
execution of processes", Proceedings of the 11th European
Meeting on Cybernetics and System Research EMCR92, Wien,
Österreich, 21.-24. April 1992, World Scientific 1992, S. 287-294,
wird ein Metamodell zur Steuerung von Geschäftsprozessen
vorgestellt und ausführlich erläutert.
"IBM FIowMark for OS/2", Dokument Nummer GH 19-8215-01, IBM
Corporation, 1994, das in jeder IBM Verkaufsstelle erhältlich
ist, ist ein typisches modernes, ausgereiftes und leistungs
fähiges Prozeßmanagementsystem. Es unterstützt die
Modellierung von Geschäftsprozessen als Netzwerk von
Aktivitäten; siehe beispielsweise " "Modeling Workflow",
Dokument Nummer SH 19-8241, IBM Corporation, 1996. Als weitere
Information zu Prozeßmanagementsystemen, die in IBM Verkaufs
stellen erworben werden können seien folgende genannt: IBM
MQSeries Concepts and Architecture, Dokument Nummer
GH 12-6285; IBM MQSeries Getting Started with Buildtime, Dokument
Nummer SH 12-6286; IBM MQSeries Getting Started with Runtime,
Dokument Nummer SH 12-6287. Dieses Netzwerk von Aktivitäten,
das Prozeßmodell, wird, als gerichteter, azyklischer,
gewichteter, farbiger Graph erstellt. Die Knotenpunkte des
Graphen stellen die ausgeführten Aktivitäten oder
Arbeitseinheiten dar. Die Kanten des Graphen, die
Steuerverbindungen, beschreiben die mögliche
Ausführungsreihenfolge der Aktivitäten. Die Definition des
Prozeßgraphen erfolgt in der IBM FlowMark Definition Language
(FDL) oder mit dem integrierten Grafikeditor. Die
Laufzeitkomponente des Prozeßmanagers interpretiert den
Prozeßgraphen und verteilt die Ausführung von Aktivitäten auf
die richtigen Personen an der richtigen Stelle, z. B. indem
Aufgaben einer Arbeitsliste für die betreffende Person
zugeordnet werden, wobei die Arbeitsliste in Form digitaler
Daten innerhalb des Workflow-Management-Computersystems
gespeichert wird.
In F. Leymann and W. Altenhuber: "Managing business processes
as an information resource", IBM Systems Journal, Bd. 32(2),
1994, wird die mathematische Theorie, die dem Produkt IBM
FlowMark zugrunde liegt, beschrieben.
In D. Roller: "Verifikation von Workflows in IBM FlowMark", in
J. Becker und G. Vossen (Hrsg.):
"Geschäftsprozeßmodellierung und Workflows", International Thompson Publishing, 1995, wird die Notwendigkeit und Möglichkeit der Verifikation von Workflows beschrieben. Außerdem wird die grafische Animationsfunktion für die Verifikation der Prozeßlogik so wie sie in IBM FlowMark implementiert ist beschrieben.
"Geschäftsprozeßmodellierung und Workflows", International Thompson Publishing, 1995, wird die Notwendigkeit und Möglichkeit der Verifikation von Workflows beschrieben. Außerdem wird die grafische Animationsfunktion für die Verifikation der Prozeßlogik so wie sie in IBM FlowMark implementiert ist beschrieben.
Für die Implementierung eines computerbasierten Workflow-
Management-Systems müssen zuerst die Geschäftsprozesse
analysiert werden, und als Resultat dieser Analyse muß ein
Prozeßmodell als Netzwerk von Aktivitäten erstellt werden, das
dem Geschäftsprozeß entspricht. In IBM FlowMark werden die
Prozeßmodelle nicht in eine ausführbare Form umgewandelt. Bei
der Ausführung wird aus dem Prozeßmodell eine einzelne
Ausprägung des Prozesses erstellt, eine sogenannte
Prozeßausprägung. Diese Prozeßausprägung wird dann von IBM
FlowMark dynamisch interpretiert.
Ein Benutzer interagiert mit einem Prozeßmanagementsystem
typischerweise über eine grafische Benutzerschnittstelle, die
die vom Benutzer auszuführenden Aufgaben als Piktogramme
darstellt. Die Arbeit für eine bestimmte Aufgabe wird vom
Benutzer durch einen Doppelklick auf das entsprechende
Piktogramm gestartet, das seinerseits das Programm startet,
das die Aktivität implementiert.
Ein anderer Technologiebereich ist das Leistungs- oder Work
load-Management. Das Workload-Management versucht, die
Verwendung der Prozessorressourcen von einem globalen
Gesichtspunkt aus zu optimieren: Viele verschiedene Services
(d. h. Programminstanzen) in einem System (entweder einem
Einprozessorsystem oder einem Mehrprozessorsystem wie z. B.
einem Sysplex) konkurrieren um Prozessorressourcen. Das
Workload-Management ermöglicht die Angabe von Leistungszielen
für jede Service-Klasse (einer Abstraktion von Services der
gleichen Art) und für Gruppen von Serviceklassen (sog.
Enklaven). Es können Prioritäten von Serviceklassen und
Enklaven angegeben werden, um ihre relative Wichtigkeit aus
der Sicht des Unternehmens zu definieren. Der Workload-Manager
macht Verarbeitungsressourcen verfügbar, damit Services und
Enklaven ihre Ziele erreichen können. Außerdem entzieht oder
reduziert der Workload-Manager den Services und Enklaven
Ressourcen, wenn klar wird, daß ein Service oder eine Enklave
das vorgesehene Ziel nicht erreicht, daß aber ein anderer
Service oder eine andere Enklave das vorgesehene Ziel
erreichen kann, wenn ihr mehr Ressourcen zur Verfügung stehen,
oder wenn ein Service oder eine Enklave mit höherer Priorität
Gefahr läuft, wegen mangelnder Ressourcen das Ziel nicht zu
erreichen. Deshalb verwaltet in jedem System das Workload-
Management die Systemressourcen. Das Workload-Management
koordiniert und verteilt die Leistungsinformation im System.
Wie gut es ein System verwaltet hängt davon ab, wie gut die
anderen Systeme ihre Ziele erreichen. Wenn es eine Konkurrenz
um die Ressourcen gibt, schließt das Workload-Management die
geeigneten Kompromisse anhand der Wichtigkeit der Arbeit und
dem Abschneiden in bezug auf das Erreichen der Ziele.
Eine Enklave kann als eine Gruppe von Services betrachtet
werden, die aus Unternehmenssicht zusammengehören, d. h. sie
ist eine Arbeitseinheit, deren Bestandteile gemeinsam ein
Leistungsziel erreichen müssen. Ein Beispiel hierfür wäre
eine Gruppe von Anwendungsschritten, die ein Mitarbeiter
ausführen muß, während ein Kunde auf eine Antwort wartet.
Nach dem Stand der Technik verfügen missionskritische
Umgebungen über Workload-Manager (WLM). So besitzt
beispielsweise MVS über einen eingebauten Workload-Manager mit
dem Namen WLM/MVS. Weitere Informationen über diesen
prominenten Vertreter eines Workload-Managers sind zum
Beispiel der Veröffentlichung "03/390 MVS Planning: Workload
Management, Dokument Nummer GC28-1761-02" zu entnehmen, die in
den IBM Zweigstellen erhältlich ist.
Derzeit ist der Prozeß, der einem Programm die Teilnahme an
einer Workload-Management-Umgebung ermöglicht, mühsam. Für
einen WLM muß das Verwaltungspersonal beides angeben, Enklaven
ebenso wie Leistungsziele für Services und Enklaven.
Anwendungsprogrammierer müssen WLM APIs verwenden, um bei der
Ausführung ihrer Anwendungen dem WLM alle nötigen
Informationen zur Verfügung zu stellen, damit er die
Prozessorressourcen richtig verwalten kann.
Die Ableitung von Enklaven ist in nichttrivialen Fällen
schwierig und mühsam, weil Informationen über die Beziehung
zwischen Anwendungsfunktionen fehlen: Diese Informationen sind
meist in speziellen Anwendungsprogrammen verborgen, oder die
Beziehung ändert sich aufgrund neuer Anforderungen, weil
Anwendungen zum Zweck der Interoperabilität auf neue Weise
integriert werden. Je mehr verschiedene Anwendungen am
Workload-Management teilhaben, desto komplexer wird die
Situation. Noch schlimmer sieht es bei der Integration
verschiedener Anwendungen aus, insbesondere wenn die
Anwendungen ursprünglich nicht für eine Zusammenarbeit
entwickelt wurden.
Jede einzelne Anwendung muß mit zusätzlichen Instruktionen
ausgestattet werden, die mit dem WLM interagiert, sonst kann
sie nicht am Workload-Management-Prozeß teilnehmen. Zum
Beispiel müssen Anwendungsprogrammierer ihren Code über die
API mit Instruktionen zum Erstellen, Verbinden und Beenden von
Enklaven versehen. Dabei muß für jede der verschiedenen
Anwendungsfunktionen überlegt werden, ob sie sich einer
bestehende Enklave anschließen muß, und ggf. welcher Enklave,
usw.
Die vorliegende Erfindung basiert auf dem Ziel, Anwendungen
besser am Workload-Management teilhaben zu lassen.
Die Aufgaben der Erfindung werden durch Anspruch 1 erfüllt.
Die Erfindung betrifft ein auf mindestens einem Computersystem
ausgeführten Verfahren zur Bereitstellung eines Workload-
Managements in einem Workflow-Management-System (WFMS) durch
ein Workload-Management-System (WLM). Das WFMS enthält ein
Prozeßmodell, das eine oder mehrere Aktivitäten umfaßt, die
die Knotenpunkte eines beliebigen Enklave-Graphen bilden, und
in dem gerichtete Kanten des Enklave-Graphen einen möglichen
Kontrollfluß innerhalb des Prozeßmodells definieren. In dem
Verfahren müssen die Aktivitäten des Enklave-Graphen als
Workload-Management-Enklave ausgeführt werden. Das Verfahren
umfaßt einen Enklave-Erstellungsschritt, in dem das WFMS, wenn
der Kontrollfluß zum ersten Mal in den Enklave-Graphen
eintritt, im WLM eine Workload-Management-Enklave für die
Aktivitäten erzeugt.
Mit der Erfindung ist die Festlegung und Ableitung von
Enklaven wesentlich einfacher als nach dem Stand der Technik.
Die Komplexität beim Schreiben von Anwendungsfunktionen, die
vom WLM verwaltet und in Workload-Management-Einheiten (d. h.
Enklaven) höherer Ebenen aufgenommen werden, wird drastisch
reduziert. Zudem wird das WFMS um eine Workload-Management-
Funktionalität erweitert.
Nach dem Stand der Technik nehmen WLM an, daß die verwaltete
Anwendung eine selbstinstrumentierte Komponente ist. Dies
bedeutet normalerweise, daß die Anwendung selber die WLM API
verwenden muß, um Informationen mit der WLM-Umgebung
auszutauschen. Dazu wären also invasive Änderungen vorhandener
Anwendungen oder eine explizite Einfügung von Code in neu
geschriebene Anwendungen erforderlich. Wegen diesem
zusätzlichen Aufwand wäre der Einsatzbereich von WLM
eingeschränkt. Schlimmer noch, die Instrumentierung ist nicht
immer möglich; der Quellcode gehört vielleicht einer anderen
Organisation oder ist nicht mehr vorhanden usw. Die
vorliegende Erfindung macht es möglich, daß Anwendungen an
WLM-Umgebungen teilhaben können, ohne daß sie speziell dafür
instrumentiert werden müssen. Mit der vorliegenden Erfindung
kann eine Anwendung in WLM-Umgebungen aufgenommen werden, ohne
daß sie speziell dafür instrumentiert werden muß.
Die Grundidee der vorliegenden Erfindung besteht darin, die
Anwendungsaktivitäten, die durch die Aktivitäten des
Prozeßmodells repräsentiert werden, nicht zu instrumentieren.
Die vorliegenden Erfindungen schlagen vor, die Workload-
Manager-Enklave für die Aktivität im WLM vom WFMS erstellen zu
lassen. Diese Lösung ermöglicht ein Workload-Management ohne
jegliche Änderung der verwalteten Aktivität oder Anwendung.
Deshalb muß kein zusätzlicher Code in neue oder bestehende
Anwendungen aufgenommen werden, damit sie für ein Workload-
Management geeignet sind. Das WFMS selber erteilt die
geeigneten WLM-Aufrufe, um das Workload-Management für die
Anwendung durchzuführen.
Auf dem Markt sind verschiedene, nicht miteinander kompatible
WLM-Produkte erhältlich. Ohne die vorliegende Erfindung muß
der Hersteller der Anwendung entscheiden, an welche der
Systemverwaltungsumgebungen er sich halten soll; im
schlimmsten Fall kann dies bedeuten, daß er alle
berücksichtigen muß. Bei der vorliegenden Erfindung kann diese
Entscheidung auf der Anwendungsintegrationsebene getroffen
werden, d. h. auf der Ebene des Prozeßmodells. Da das WFMS
darüber informiert ist, welche Anwendung es starten muß, ist
die vorliegende Erfindung außerdem flexibel genug, die
Entscheidung darüber, welches WLM-Produkt verwendet werden
soll, auf der Basis jeder einzelnen Anwendung zu treffen. Nach
der Lehre der Erfindung ist eine Anwendung also (bis zu einem
gewissem Grad) vom speziellen WLM-Produkt losgelöst.
Aber nicht nur Anwendungen innerhalb eines Prozeßmodells
profitieren von der vorliegenden Erfindung. Da es so viel
einfacher wird, Aktivitäten für ein Workload-Management bereit
zu machen, kann der Durchsatz in einem Computersystem
allgemein erhöht werden; davon profitieren dann alle auf
diesem Computersystem ausgeführten Programme.
Die richtige Verwaltung von Verarbeitungsressourcen reduziert
die Gesamtkosten, die für Datenverarbeitungsumgebungen
aufgewendet werden müssen. Anwendungssysteme, die für ein
Workload-Management geeignet sind, werden in Umgebungen mit
Workload-Management zu bevorzugten Systemen.
In einer anderen Ausführungsform der Erfindung enthält das
Verfahren einen Enklave-Verbindungs-Schritt, in dem, wenn der
Kontrollfluß in eine Aktivität eintritt, die ein Knoten in dem
Enklave-Graphen ist und wenn für den Enklave-Graphen bereits
eine Workload-Management-Enklave erstellt worden ist, das WFMS
die Aktivität der Workload-Management-Enklave im WLM
hinzufügt.
Die oben genannten Vorteile gelten auch für diese andere
Ausführungsform. Außerdem nimmt die Erfindung den
Aktivitäten/Anwendungen nicht nur die Erstellung von Workload-
Management-Enklaven ab, sondern auch die Verbindung mit
bereits vorhandenen Enklaven.
In einer weiteren Ausführungsform der Erfindung enthält das
Verfahren einen Enklave-Lösch-Schritt, in dem, wenn der
Kontrollfluß den Enklave-Graphen verlassen hat, der WLM die
Workload-Management-Enklave für die Aktivitäten löscht.
Die oben genannten Vorteile gelten auch für diese andere
Ausführungsform. Außerdem nimmt die Erfindung den
Aktivitäten/Anwendungen nicht nur die Erstellung von Workload-
Management-Enklaven ab, sondern auch das Löschen bereits
vorhandener Enklaven. Somit sind alle Interaktionen einer
Anwendung mit dem WLM, die nach dem Stand der Technik
erforderlich sind, jetzt nicht mehr notwendig und werden vom
WFMS übernommen.
In einer weiteren Ausführungsform der Erfindung wird den
Aktivitäten eine Enklave-Identifikation der Workload-
Management-Enklave verfügbar gemacht. Unabhängig davon wird,
wenn eine Aktivität innerhalb einer Ausführungsumgebung
auszuführen ist, der Ausführungsumgebung eine Enklave-
Identifikation verfügbar gemacht.
Dadurch liegt es bei der Aktivität/Anwendung, ob das Workload-
Management für sie "transparent" ist oder sie über die
bereitgestellte Enklave-Identifikation beeinflussen kann. Der
Ausführungsumgebung die Enklave-Identifikation der Workload-
Management-Enklave zur Verfügung zu stellen ist besonders
vorteilhaft, da bestimmte Ausführungsumgebungen als Subsysteme
mit separaten Workload-Managern implementiert sind. Diese
separaten Workload-Manager können mit dem globalen WLM
zusammenarbeiten, benötigen dafür aber die Enklave-
Identifikation einer Enklave im globalen WLM.
In einer weiteren Ausführungsform der Erfindung steht die
Enklave-Identifikation der Workload-Management-Enklave als
Element in einem Eingabe-Behälter (Input-Container) zur
Verfügung.
Dies ist die eleganteste und wirtschaftlichste Art, die
Enklave-Identifikation den Aktivitäten zur Verfügung zu
stellen. Weitere Änderungen sind weder im WFMS noch in der
Anwendung, in der die Aktivität implementiert ist,
erforderlich, da dies der übliche Weg ist, der Aktivität
Informationen aus dem WFMS zur Verfügung zu stellen.
In einer weiteren Ausführungsform der Erfindung wird das
Verfahren von einer WFMS Engine ausgeführt, die durch das
Prozessormodell navigiert, oder das Verfahren wird von einem
WFMS-Agenten ausgeführt, der für das Starten einer Aktivität
zuständig ist.
Die Ausführung des Verfahrens durch die WFMS Engine ist
vorteilhaft, da alle Informationen über das Prozeßmodell
(einschließlich aller Laufzeitparameter für eine aktuelle
Prozeßmodellausprägung) - einschließlich der Struktur des
Enklave-Graphen - der WFMS-Engine zur Verfügung stehen.
Andererseits erlaubt die Ausführung des Verfahrens durch einen
WFMS-Agenten die Auslagerung bestimmter Arbeiten aus der WFMS-
Maschine, wodurch eine stärkere Parallelität innerhalb der
WFMS-Umgebung erreicht wird.
Die Aufgaben der Erfindung werden durch Anspruch 7 erfüllt.
Die Erfindung schlägt ein Verfahren vor, das automatisch
mindestens einen Enklave-Graphen in einem Prozeßmodell eines
Workflow-Management-Systems (WFMS) bestimmt. Das Prozeßmodell,
enthält eine oder mehrere Aktivitäten, die die Knotenpunkte
eines beliebigen Graphen sind, und in dem gerichtete Kanten
des Graphen einen möglichen Kontrollfluß innerhalb des
Prozeßmodells definieren. Der Enklave-Graph ist ein Subgraph
des Graphen, der Aktivitäten enthält, die vom Workload-
Management-System (WLM) als Workload-Management-Enklave zu
behandeln sind. Das Verfahren bestimmt den Enklave-Graphen,
indem es eine Aktivität in den Enklave-Graphen aufnimmt, falls
das Prozeßmodell die Aktivität als ohne Benutzereingriff
ausführbar definiert.
Die oben genannten Vorteile gelten auch für diese andere
Ausführungsform. Weitere Vorteile ergeben sich dadurch, daß
Anwendungsprogrammierer oder Administratoren jetzt auf ein
automatisches Verfahren zur Bestimmung und Definition von
Enklave-Strukturen zurückgreifen können. Was noch wichtiger ist:
während nach dem Stand der Technik die Enklave-Struktur nicht
explizit ist - jede Anwendung müßte analysiert werden, um die von
den Anwendungen erstellten, gelöschten oder verbundenen Enklaven
zu bestimmen -, macht die vorliegende Erfindung die Enklave-
Struktur auf der globalen Ebene des Prozeßmodells explizit. Auf
diese Weise sind die Enklave-Strukturen nicht länger in den
einzelnen Anwendungen "begraben". Aufgrund der vorliegenden
Erfindung können Enklave-Strukturen jetzt schnell erstellt oder
geändert werden.
In einer weiteren Ausführungsform der Erfindung bestimmt das
vorgeschlagene Verfahren den Enklave-Graphen, indem eine
Aktivität in den Enklave-Graphen aufgenommen wird, wenn sie
und alle anderen Aktivitäten des Enklave-Graphen Elemente der
gleichen atomaren Sphäre sind, wobei die atomare Sphäre
Aktivitäten enthält, die in einer Transaktion auszuführen
sind.
Da globale Transaktionen Aktivitäten sind, die zu einer
atomaren Sphäre gehören, unterliegen sie der ACID-Anforderung
(Atomicity, Consistency, Isolation, Durability). Indem die
Informationen im Prozeßmodell in bezug auf atomare Sphären zur
Definition von Enklaven verwendet wird, kann der WLM bei der
Ausführung die atomare Sphäre im Hinblick auf die ACID-
Anforderung effizient ausführen.
Fig. 1 ist ein Beispiel für die automatische Ableitung von
Enklaven für ein Workload-Management-System (WLM)
aus Prozeßmodellen eines Workflow-Management-Systems
(WFMS).
Fig. 2 zeigt die neue Modellkonstruktion in der
Definitionssprache FlowMark Definition Language
(FDL) am Beispiel einer Enklave-Graphen-Definition.
Fig. 3 visualisiert bestimmte Szenarien innerhalb von
Prozeßmodellen, die entweder Kandidaten oder keine
Kandidaten für Enklave-Graphen sind.
Die aktuelle Erfindung wird anhand des Workflow-Management-
Systems FlowMark von IBM beschrieben. Selbstverständlich
können auch andere WFMS verwendet werden. Außerdem gilt die
Lehre der Erfindung auch für andere Arten von Systemen, die
eine WFMS-Funktionalität nicht in Form eines separaten WFMS,
sondern innerhalb eines anderen Systemtyps bieten.
Die gleiche Aussage gilt auch für das spezielle Workload-
Management-System. Die vorliegende Spezifikation bezieht sich
auf das Workload-Management-System von IBM unter OS/390 MVS;
dies ist aber nur als Beispiel zu verstehen, nicht als
Beschränkung des Umfangs der Erfindung.
Im folgenden werden die Grundbegriffe eines Workflow-Management-
Systems anhand des WFMS IBM FlowMark skizziert.
Aus der Sicht eines Unternehmens wird die Verwaltung von
Geschäftsprozessen immer wichtiger. Geschäftsprozesse oder
kurz Prozesse steuern, welche Arbeitsaufgabe von wem
ausgeführt wird, und welche Ressourcen dafür verwendet werden,
d. h. ein Geschäftsprozeß beschreibt, wie ein Unternehmen seine
Unternehmensziele erreichen will. Ein WFMS kann sowohl die
Modellierung der Geschäftsprozesse als auch deren Ausführung
unterstützen.
Die Modellierung eines Geschäftsprozesses als syntaktische
Einheit auf eine Art und Weise, die direkt von einem
Softwaresystem unterstützt wird, ist höchst erstrebenswert.
Darüber hinaus kann das Softwaresytem auch als Interpreter
arbeiten, der im wesentliche ein solches Modell als Eingabe
erhält: Das Modell, als Prozeßmodell oder Workflow-Modell
bezeichnet, kann dann als konkrete Ausprägung erzeugt werden,
und die individuelle Reihenfolge der Arbeitsschritte kann in
Abhängigkeit vom Kontext des speziellen Modellfalls bestimmt
werden. Ein solches Modell eines Geschäftsprozesses kann als
Schablone für eine Klasse ähnlicher Prozesse in einem
Unternehmen aufgefaßt werden; es ist ein Schema, das alle
möglichen Ausführungsvarianten einer bestimmten Art von
Geschäftsprozessen beschreibt. Eine solche Modellausprägung
und ihre Interpretation stellt einen individuellen Prozeß dar,
d. h. eine konkrete, kontextabhängige Ausführung einer vom
Modell beschriebenen Variante. Ein WFMS erleichtert die
Verwaltung von Geschäftsprozessen. Es bietet ein Mittel, um
Modelle von Geschäftsprozessen zu beschreiben (bei der
Erstellung), und es steuert Geschäftsprozesse auf der Basis
eines zugehörigen Modells (bei der Ausführung). Im folgenden
wird das Metamodell von IBMs WFMS FlowMark, d. h. die
Syntaxelemente zur Beschreibung des Geschäftsprozeßmodells und
die Bedeutung und Interpretation dieser Syntaxelemente,
beschrieben.
Ein Prozeßmodell ist eine vollständige Darstellung eines
Prozesses, bestehend aus einem Prozeßdiagramm und den
Einstellungen, die die Logik hinter den Komponenten des
Diagramms definiert. Mit Hilfe verschiedener Services von
FlowMark werden diese bei der Erstellung vorgenommenen
Definitionen der Prozeßmodelle dann in Prozeßschablonen
umgewandelt, auf die FlowMark bei der Ausführung zurückgreifen
kann. Wichtige Komponenten eines FlowMark-Prozeßmodells sind:
- - Prozesse
- - Aktivitäten
- - Blöcke
- - Steuerflüsse
- - Verbindungen
- - Datenbehälter
- - Datenstrukturen
- - Bedingungen
- - Programme
- - Mitarbeiter
Nicht alle von diesen Elementen werden im folgenden
beschrieben.
Vor diesem Hintergrund ist ein durch ein Prozeßmodell in
FlowMark modellierter Prozeß eine Folge von Aktivitäten, die
abgeschlossen werden müssen, um eine Aufgabe zu erfüllen. Der
Prozeß ist das oberste Element eines FlowMark-Workflow-
Modells. In einem FlowMark-Prozeß kann folgendes definiert
werden:
- - Wie die Arbeit von einer Aktivität zur nächsten weitergehen soll.
- - Welche Personen die Aktivitäten ausführen sollen, und welche Programme sie dazu benutzen sollen.
- - Ob andere Prozesse, sogenannte Subprozesse, in den Prozeß verschachtelt sind.
Selbstverständlich können mehrere Prozeßfälle eines FlowMark-
Prozesses parallel ausgeführt werden.
Aktivitäten sind die Grundelemente des Metamodells. Eine
Aktivität stellt eine Geschäftsaktion dar, die aus einer
bestimmten Perspektive eine eigene semantische Einheit bildet.
Mit dem Modell des Geschäftsprozesses könnte sie eine
Feinstruktur haben, die dann ihrerseits durch ein Modell
repräsentiert wird, oder deren Details aus der Sicht der
Geschäftsprozeßmodellierung überhaupt nicht relevant sind. Die
Verfeinerung von Aktivitäten mit Hilfe von Prozeßmodellen
ermöglichen eine Modellierung von Geschäftsprozessen von unten
nach oben oder von oben nach unten. Aktivitäten, die einen
Schritt innerhalb eines Prozesses darstellen, bilden eine
Arbeitseinheit, die die zugeordnete Person ausführen kann,
indem sie ein Programm oder einen anderen Prozeß startet. In
einem Prozeßmodell sind jeder Aktivität folgende Informationen
zugeordnet:
- - Welche Bedingungen erfüllt sein müssen, bevor die Aktivität beginnen kann.
- - Ob die Aktivität manuell von einem Benutzer gestartet werden muß, oder ob sie automatisch starten kann.
- - Welche Bedingung anzeigt, daß die Aktivität abgeschlossen ist.
- - Ob die Steuerung die Aktivität automatisch verlassen kann, oder ob die Aktivität zuerst von einem Benutzer als abgeschlossen bestätigt werden muß.
- - Wieviel Zeit für die Ausführung der Aktivität zur Verfügung steht.
- - Wer für die Ausführung der Aktivität zuständig ist.
- - Welches Programm oder welcher Prozeß zum Ausführen der Aktivität verwendet werden soll.
- - Welche Daten als Eingabedaten und als Ausgabedaten für die Aktivität benötigt werden.
Ein FlowMark-Prozeßmodell besteht aus folgenden
Aktivitätstypen:
Programmaktivität: Ihr ist ein Programm zur Ausführung zugeordnet. Das Programm wird beim Starten der Aktivität aufgerufen. In einem vollautomatisierten Workflow führt das Programm die Aktivität ohne menschliches Zutun aus. Sonst muß der Benutzer die Aktivität starten, indem er sie aus einer Ausführungszeit-Arbeitsliste auswählt. Die Ausgabe des Programms kann in der Beendigungsbedingung für die Programmaktivität und für die Übergangsbedingungen zu anderen Aktivitäten verwendet werden. Prozeßaktivität: Ihr ist ein (Sub-)Prozeß zur Ausführung zugeordnet. Der Prozeß wird beim Starten der Aktivität aufgerufen. Eine Prozeßaktivität ist eine Möglichkeit, eine Gruppe von Aktivitäten, die zu verschiedenen Prozessen gemeinsam gehört, wiederzuverwenden. Die Ausgabe des Prozesses kann in der Beendigungsbedingung für die Prozeßaktivität und für die Übergangsbedingungen zu anderen Aktivitäten verwendet werden.
Programmaktivität: Ihr ist ein Programm zur Ausführung zugeordnet. Das Programm wird beim Starten der Aktivität aufgerufen. In einem vollautomatisierten Workflow führt das Programm die Aktivität ohne menschliches Zutun aus. Sonst muß der Benutzer die Aktivität starten, indem er sie aus einer Ausführungszeit-Arbeitsliste auswählt. Die Ausgabe des Programms kann in der Beendigungsbedingung für die Programmaktivität und für die Übergangsbedingungen zu anderen Aktivitäten verwendet werden. Prozeßaktivität: Ihr ist ein (Sub-)Prozeß zur Ausführung zugeordnet. Der Prozeß wird beim Starten der Aktivität aufgerufen. Eine Prozeßaktivität ist eine Möglichkeit, eine Gruppe von Aktivitäten, die zu verschiedenen Prozessen gemeinsam gehört, wiederzuverwenden. Die Ausgabe des Prozesses kann in der Beendigungsbedingung für die Prozeßaktivität und für die Übergangsbedingungen zu anderen Aktivitäten verwendet werden.
Der Fluß von Steuerinformationen, d. h. Kontrollfluß, durch
einen laufenden Prozeß bestimmt die Reihenfolge, in der
Aktivitäten ausgeführt werden. Der FlowMark Workflow-Manager
folgt einem Pfad durch den Prozeß, der durch die Bewertung, ob
Startbedingungen, Endebedingungen und Übergangsbedingungen
erfüllt sind, bestimmt wird.
Die Ergebnisse, die in der Regeln von der durch eine Aktivität
repräsentierte Arbeit erzielt werden, werden in einen
Ausgabebehälter (Output Container), der jeder Aktivität
zugeordnet ist, geschrieben. Da eine Aktivität in der Regel
auf Ausgabebehälter anderer Aktivitäten zugreifen können
müssen, ist jeder Aktivität außerdem auch ein Eingabebehälter
(Input Container) zugeordnet. Bei der Ausführung bilden die
aktuellen Werte für die formalen Parameter, die den
Eingabebehälter einer Aktivität aufbauen, den aktuellen
Kontext einer Ausprägung der Aktivität. Jeder Datenbehälter
wird durch eine Datenstruktur definiert. Eine Datenstruktur
ist eine sortierte Liste von Variablen, den sog. Members, die
mit einem Namen und einem Datentyp gekennzeichnet sind.
Datenverbindungen repräsentieren den Transfer von Daten von
Ausgabebehältern in Eingabebehälter. Wenn eine Datenverbindung
einen Ausgabebehälter mit einem Eingabebehälter verbindet und
die Datenstrukturen der beiden Behälter exakt übereinstimmen,
bildet der Workflow-Manager von FlowMark die Daten automatisch
ab.
Verbindungen (Connectors) verknüpfen Aktivitäten in einem
Prozeßmodell miteinander. Mit Hilfe von Verbindungen kann man
die Reihenfolge der Aktivitäten und die Datenübertragung
zwischen den Aktivitäten definieren. Da Aktivitäten nicht
beliebig ausgeführt werden können, sind sie durch
Steuerverbindungen (Control Connectors) miteinander verbunden.
Eine Steuerverbindung kann als direkte Linie zwischen zwei
Aktivitäten betrachtet werden; die Aktivität am Endpunkt der
Verbindung kann erst gestartet werden, wenn die Aktivität am
Startpunkt der Verbindung (erfolgreich) abgeschlossen ist.
Steuerverbindungen modellieren also den potentiellen
Kontrollfluß innerhalb eines Geschäftsprozeßmodells.
Standardverbindungen geben an, welchen Weg die Steuerung
einschlagen soll, wenn die Übergangsbedingung keiner anderen
Steuerverbindung, die eine Aktivität verläßt, erfüllt ist. Mit
Hilfe von Standardverbindungen kann das Workflow-Modell
außergewöhnliche Ereignisse verarbeiten. Datenverbindungen
geben den Datenfluß in einem Workflow-Modell an. Eine
Datenverbindung geht von einer Aktivität oder einem Block aus
und hat eine Aktivität oder einen Block als Ziel. Man kann
festlegen, daß Ausgabedaten zu einem Ziel oder zu mehreren
Zielen geleitet werden können. Ein Ziel kann mehr als nur eine
eingehende Datenverbindung haben.
Bedingungen sind das Mittel, mit dem der Kontrollfluß in einem
Prozeß festgelegt werden kann. In FlowMark-Prozeßmodellen
können logische Ausdrücke definiert werden, die bei der
Ausführung von FlowMark bewertet werden, um festzustellen,
wann eine Aktivität starten, enden und die Kontrolle an die
nächste Aktivität weitergeben kann. Startbedingungen sind
Bedingungen, die bestimmen, wann eine Aktivität mit
eingehenden Steuerverbindungen starten kann. Die
Startbedingung kann festlegen, daß alle eingehenden
Steuerverbindungen erfüllt sein müssen, oder daß mindestens
eine von ihnen erfüllt sein muß. Wie auch immer die
Startbedingung lautet, müssen alle eingehenden Verbindungen
bewertet werden, bevor die Aktivität starten kann. Wenn eine
Aktivität keine eingehenden Steuerverbindungen besitzt, wird
sie bereit, wenn der Prozeß oder Block, in dem sie enthalten
ist, beginnt. Außerdem ist jeder Steuerverbindung ein
Boolescher Ausdruck zugeordnet, der als Übergangsbedingung
bezeichnet wird. Parameter aus Ausgabebehältern von
Aktivitäten, die bereits ihre Ergebnisse hervorgebracht haben,
werden als in Übergangsbedindungen genannte Parameter befolgt.
Wenn bei der Ausführung eine Aktivität erfolgreich beendet
wird, werden alle von ihr abgehenden Steuerverbindungen
ermittelt, und der Wahrheitswert der betreffenden
Übergangsbedingungen wird anhand der aktuellen Werte ihrer
Parameter berechnet. Nur die Endpunkte von Steuerverbindungen,
deren Übergangsbedingungen mit WAHR bewertet werden, werden
als Aktivitäten betrachtet, die im aktuellen Kontext des
Geschäftsprozesses ausgeführt werden können.
Übergangsbedingungen modellieren also den kontextabhängigen
tatsächlichen Kontrollfluß innerhalb eines Geschäftsprozesses
(d. h. einer Ausprägung des Modells). Geschäftsprozesse
beinhalten im allgemeinen lang dauernde Aktivitäten; bei
solchen Aktivitäten muß eine Unterbrechung möglich sein. Die
Beendigung einer Aktivität bedeutet deshalb nicht
notwendigerweise, daß die zugehörige Aufgabe erfolgreich
abgeschlossen worden ist. Um zu messen, ob die von einer
Aktivität ausgeführte Arbeit erfolgreich war, ist jeder
Aktivität ein Boolescher Ausdruck zugeordnet, der als
Endebedingung bezeichnet wird. Genau diejenigen Aktivitäten,
deren Endebedingungen im aktuellen Kontext als wahr bewertet
werden, werden als erfolgreich beendete Aktivitäten behandelt.
Zur Bestimmung des tatsächlichen Kontrollflusses werden genau
die erfolgreich abgeschlossenen Aktivitäten herangezogen. Der
logische Ausdruck einer Endebedingung, sofern ein solcher
angegeben wurde, muß also mit wahr bewertet werden, daß die
Kontrolle von einer Aktivität oder einem Block weitergegeben
wird.
Ein Geschäftsprozeßmodell beschreibt nicht nur den
potentiellen Steuerungs- und Datenfluß zwischen Aktivitäten
eines Geschäftsprozeßmodells, sondern umfaßt auch eine
Beschreibung der Abfolge der Aktivitäten selber zwischen
"Ressourcen", die die von jeder Aktivität repräsentierten
Arbeitsschritte tatsächlich ausführen. Eine Ressource kann als
ein bestimmtes Programm, eine Person, eine Rolle oder eine
organisatorische Einheit definiert werden. Bei der Ausführung
werden Aufgaben aufgelöst in an bestimmte Personen gerichtete
Aufforderungen, bestimmte Aktivitäten auszuführen, die
Arbeitsschritte für diese Person zur Folge haben.
Personenzuweisungen sind das Mittel, mit dem Aktivitäten in
der vom Kontrollflußaspekt eines Geschäftsprozeßmodells
vorgeschriebenen Reihenfolge auf die richtigen Personen
verteilt werden. Jede Aktivität in einem Prozeß wird einer
oder mehreren in der FlowMark-Datenbank definierten Personen
zugeordnet. Unabhängig davon, ob eine Aktivität manuell vom
Benutzer oder automatisch vom FlowMark-Workflow-Manager
gestartet werden kann, und ob zum Beenden eine Interaktion mit
dem Benutzer erforderlich ist oder die Aktivität automatisch
beendet wird, muß ihr eine Person zugeordnet werden. Eine
FlowMark-Personendefinition beinhaltet mehr als nur die
Identifikation der in dem Unternehmen tätigen Personen in der
FlowMark-Datenbank. Für jede definierte Person können eine
Ebene, eine Organisation und mehrere Rollen angegeben werden.
Diese Attribute können bei der Ausführung dazu benutzt werden,
Aktivitäten dynamisch Personen mit geeigneten Attributen
zuzuordnen.
Die Prozeßdefinition beinhaltet die Modellierung von
Aktivitäten, Steuerverbindungen zwischen den Aktivitäten, Ein-
/Ausgabebehältern und Datenverbindungen. Ein Prozeß wird als
mit Richtungspfeil versehener, azyklischer Graph dargestellt,
in dem die Aktivitäten die Knotenpunkte und die Steuer-
/Datenverbindungen die Kanten bilden. Der Graph wird mit einem
eingebauten, ereignisgesteuerten, CUA-konformen Grafikeditor
bearbeitet. Die Datenbehälter werden als mit Namen
gekennzeichnete Datenstrukturen angegeben. Diese
Datenstrukturen selber werden mit der
Datenstrukturdefinitions-Funktion festgelegt. FlowMark
unterscheidet drei Haupttypen von Aktivitäten:
Programmaktivitäten, Prozeßaktivitäten und Blöcke.
Programmaktivitäten sind durch Programme implementiert. Die
Programme werden mit der Programmdefinitions-Funktion
registriert. Blöcke enthalten die gleichen Konstruktionen wie
Prozesse, nämlich Aktivitäten, Steuerverbindungen usw. Sie
haben aber keine Namen, und sie haben ihre eigenen
Endebedingungen. Wenn die Endebedingung nicht erfüllt ist,
wird der Block neu gestartet. Der Block implementiert also
eine "Do Until"-Konstruktion (Ausführung, bis die Bedingung
erfüllt ist). Prozeßaktivitäten sind als Prozesse
implementiert. Diese Subprozesse werden separat als reguläre,
mit Namen gekennzeichnete Prozesse mit allen üblichen
Eigenschaften definiert. Prozeßaktivitäten bieten eine größere
Flexibilität bei der Prozeßdefinition. Sie ermöglichen nicht
nur die Konstruktion eines Prozesses durch permanente
Verfeinerung von Aktivitäten in Programm- und
Prozeßaktivitäten (von oben nach unten), sondern bauen einen
Prozeß auch aus einer Gruppe vorhandener Prozesse auf (von
unten nach oben). Insbesondere helfen Prozeßaktivitäten dabei,
die Modellierung zu organisieren, wenn mehrere
Prozeßmodellierer zusammenarbeiten. Sie ermöglichen den Team-
Mitgliedern, unabhängig voneinander an verschiedenen
Aktivitäten zu arbeiten. Programm- und Prozeßaktivitäten kann
ein Zeitlimit zugeordnet werden. Das Zeitlimit gibt an, wie
lange die Aktivität dauern darf. Wenn das Zeitlimit
überschritten ist, wird eine bestimmte Person informiert. Wenn
diese Person ihrerseits nicht innerhalb eines anderen
Zeitlimits reagiert, wird der Prozeßadministrator
benachrichtigt. Da alle Benachrichtigungen in einem Protokoll
aufgezeichnet werden, hilft dies nicht nur, kritische
Situationen zu erkennen, sondern auch, Unzulänglichkeiten des
Prozesses zu bemerken.
Alle Datenstrukturen, die als Schablonen für die Behälter von
Aktivitäten und Prozessen verwendet werden, werden mit der
Datenstrukturdefinitions-Funktion definiert. Datenstrukturen
sind Namen und werden in Form elementarer Datentypen
definiert, z. B. als Gleitkommazahlen, ganze Zahlen, oder
Zeichenfolgen und Verweise auf vorhandene Datenstrukturen. Daß
Datenstrukturen als separate Einheiten verwaltet werden hat
den Vorteil, daß alle Schnittstellen von Aktivitäten und ihre
Implementationen konsistent an einer einzigen Stelle verwaltet
werden (ähnlich wie Kopfdateien in Programmiersprachen).
Alle Programme, die Programmaktivitäten implementieren, werden
mit der Programmregistrierungs-Funktion definiert. Registriert
wird für jedes Programm der Programmname, der Ort, an dem es
sich befindet, und die Zeichenfolge zum Aufrufen. Die
Zeichenfolge zum Aufrufen des Programms besteht aus dem
Programmnamen und der an das Programm übergebenen
Befehlsfolge.
Bevor Prozeßausprägungen erstellt werden können, muß das
Prozeßmodell umgewandelt werden, um seine Richtigkeit und
Vollständigkeit sicherzustellen. Die umgewandelte Version des
Modells wird als Schablone bei der Erstellung eines
Prozeßexemplars verwendet. Auf diese Weise können Änderungen
am Prozeßmodell vorgenommen werden, ohne daß gerade
ausgeführte Prozeßausprägungen davon betroffen werden. Eine
Prozeßausprägung wird entweder über die grafische
Schnittstelle oder über die aufrufbare Prozeß-API
(Anwendungsprogrammschnittstelle) gestartet. Wenn ein Prozeß
gestartet wird, werden die Startaktivitäten gesucht, die
richtigen Personen ermittelt und die Aktivitäten als
Arbeitsaufträge auf die Arbeitsliste der ausgewählten Personen
gesetzt. Wenn ein Benutzer den Arbeitsauftrag, d. h. die
Aktivität, auswählt, wird diese ausgeführt und aus der
Arbeitsliste anderer Benutzer, denen sie ebenfalls vorgelegt
wurde, gelöscht. Wenn eine Aktivität ausgeführt worden ist,
wird ihre Endebedingung bewertet. Ist diese Bedingung nicht
erfüllt, wird die Aktivität erneut für die Ausführung
eingeplant, andernfalls werden alle abgehenden
Steuerverbindungen und die zugehörigen Übergangsbedingungen
bewertet. Eine Steuerverbindung wird ausgewählt, wenn die
Bedingung mit WAHR bewertet wird. Dann werden die
Zielaktivitäten der ausgewählten Steuerverbindungen bewertet.
Wenn ihre Startbedingungen erfüllt sind, werden sie auf die
Arbeitsliste ausgewählter Personen gesetzt. Ein Prozeß wird
als beendet betrachtet, wenn alle Endaktivitäten abgeschlossen
sind. Um sicherzustellen, daß alle Endaktivitäten zum Abschluß
kommen, wird eine Eliminierung toter Pfade vorgenommen.
Dadurch werden alle Kanten im Prozeßgraphen, die wegen nicht
erfüllter Übergangsbedingungen niemals erreicht werden können,
gelöscht. Alle Informationen über den aktuellen Status eines
Prozesses werden in der auf dem Server verwalteten Datenbank
gespeichert. Dadurch ist im Fall eines Absturzes eine
Vorwärts-Fehlerbehebung möglich.
Jede Computersystem-Installation will ihre Ressourcen
möglichst gut nutzen und den höchstmöglichen Durchsatz
erzielen, damit das System bestmöglich reagiert. Mit dem
Workload-Management werden Leistungsziele definiert und jedem
Leistungsziel eine Wichtigkeit für das Unternehmen zugeordnet.
Man definiert die Ziele für die Arbeit aus Geschäftssicht, und
das System entscheidet wieviele Ressourcen, wie z. B. CPU-Zeit
und Speicherplatz, der Arbeit zugeteilt werden sollen, damit
sie ihr Ziel erreicht. Eine Installation muß wissen, was in
Form von Leistungszielen erreicht werden soll, und wie wichtig
das Erreichen der einzelnen Leistungsziele für das Unternehmen
ist. Mit dem Workload-Management werden Leistungsziele für
Arbeiten definiert, und um diese Ziele zu erreichen paßt das
System die Ressourcen an die Arbeit an, indem es die
Verarbeitung ständig überwacht und neu anpaßt. Berichte
zeigen, wie gut das System seine Ziele erreicht.
Im folgenden werden Begriffe und Verfahren anhand des OS/390
MVS Workload Management System von IBM erläutert.
Die Leistungsverwaltung (Performance Administration) ist der
Prozeß der Definition und Anpassung von Leistungszielen und
Ressourcengruppen auf der Basis von Geschäftszielen der
Installation. Das Workload-Management führt die Rolle des
Service-Level-Administrators ein. Der Service-Level-
Administrator ist für die Definition der Leistungsziele der
Installation auf der Basis von Bedürfnissen des Unternehmens
und aktuellen Leistungsdaten zuständig. Diese explizite
Definition von Workloads und Leistungszielen wird als Service-
Definition bezeichnet. Die Service-Definition gilt für alle
Arten von Arbeiten, z. B. für CICS, IBS, TSO/E, OpenEdition
MVS, JES, APPC/MVS, LSFM, DDF, DB2, SOM, Internet-
Verbindungsserver und andere. Man kann für alle von MVS
verwalteten Arbeiten Ziele angeben, unabhängig davon, ob es
sich um Online-Arbeiten, Transaktionen oder Stapeljobs
handelt. Die in der Service-Definition definierten Ziele
gelten für alle Arbeiten im System oder Sysplex. Wenn sich die
Service-Level-Anforderungen ändern, kann der Service-Level-
Administrator die betreffenden Workload-Management-Begriffe
ändern. Das Workload-Management bietet eine online
ausgeführte, anzeigebasierte Anwendung zum Definieren und
Anpassen der Service-Definition. Die Service-Definition wird
durch diese ISPF-Verwaltungsanwendung festgelegt. Das
Workload-Management bietet die Möglichkeit, Leistungs- und
Verzögerungsdaten im Kontext der Service-Definition zu
sammeln. Die Leistungs- und Verzögerungsdaten sind für
Berichte und Überwachungsprodukte verfügbar, so daß sie die
gleiche Terminologie verwenden können.
Das Leistungs-Management (Performance Management) ist der
Prozeß, mit dem das Workload-Management entscheidet, wie
Ressourcen in Abhängigkeit von Leistungszielen und
Verarbeitungskapazität verteilt werden. Workload-Management-
Algorithmen benutzen die Informationen aus der Service-
Definition und interne Überwachungsdaten, um festzustellen,
wie gut die Ziele erreicht werden. Die Algorithmen passen die
Ressourcenzuteilung in regelmäßigen Abständen an, wenn sich
die Workload ändert. In jedem System verwaltet das Workload-
Management die Systemressourcen. Das Workload-Management
koordiniert und verteilt die Leistungsinformation im System
oder Sysplex. Wie gut es ein System verwaltet hängt davon ab,
wie gut die anderen Systeme ihre Ziele erreichen. Wenn es eine
Konkurrenz um die Ressourcen gibt, schließt das Workload-
Management die geeigneten Kompromisse anhand der Wichtigkeit
der Arbeit und dem Abschneiden in bezug auf das Erreichen der
Ziele. Das Workload-Management kann auch dynamisch Server
adreßbereiche starten und stoppen, um Arbeiten von
Anwendungsumgebungen zu verarbeiten. Das Workload-Management
startet und stoppt Serveradreßbereiche in einem Einzelsystem
oder im Sysplex, um die Ziele der Arbeits zu erfüllen.
Zusätzlich zur internen Feedback-Überwachung verfolgt das
Workload-Management das Geschehen im Sysplex in Form einer
Echtzeiterfassung von Leistungsdaten und einer Überwachung von
Verzögerungen. Alle diese Informationen stehen für die
Leistungsüberwachung und Berichterstattung zur Aufnahme in
detaillierte Berichte zur Verfügung.
Um das Workload-Management möglichst gut zu nutzen, muß die
Arbeit richtig verteilt werden, so daß das MVS die Ressourcen
verwalten kann. Es ist wichtig, daß die Subsysteme (mit
separaten Ausführungsumgebungen), die die Arbeit verteilen,
für die Workload-Verteilung in einem System oder Sysplex
richtig konfiguriert sind. Dies ist besonders wichtig, wenn
die Subsysteme separate Komponenten für die automatische und
dynamische Verteilung der Arbeit besitzen, wie z. B. JES, CICS,
IMS, DB2 usw. Dies wird mit den in den einzelnen Subsystemen
vorhandenen Steuerungsmöglichkeiten erreicht. In einer JES-
Umgebung beispielsweise werden Initiator-Adreßbereiche im
System verteilt.
Die Service-Definition enthält alle Informationen über die
Installation, die für die Verarbeitung durch das Workload-
Management benötigt werden. Für jedes System oder Sysplex gibt
es nur eine einzige Service-Definition. Der Service-Level-
Administrator legt die Service-Definition mit Hilfe der WLM-
Verwaltungsanwendung fest. Er erstellt "Regelsätze" innerhalb
der Service-Definition, um die Ziele für Arbeiten festzulegen.
Ein Service-Level-Administrator muß verstehen, wie Arbeit
organisiert wird, und ihr Leistungsvorgaben zuordnen können.
Eine Service-Definition identifiziert die Workloads, die
Ressourcengruppen, die Serviceklassen, die
Serviceklassenperioden und Ziele anhand der Leistungsvorgaben.
Außerdem enthält eine Service-Definition
Klassifizierungsregeln. Alle diese Informationen zusammen
bilden die Service-Definitionsbasis. Dabei handelt es sich im
einzelnen um folgende Informationen:
- - Ein oder mehrere Service-Regelsätze (Service Policies), bei denen es sich um mit Namen gekennzeichnete Gruppen von Leistungszielen handelt, die das Workload-Management als Richtlinie für die Zuteilung von Ressourcen für die einzelnen Arbeiten verwendet. Wenn ein Regelsatz aktiviert ist, werden die Überschreibungen mit der Service-Definition gemischt. Es können verschiedene Strategien zur Festlegung von Zielen vorhanden sein, die für verschiedene Zeiten bestimmt sind. Service-Strategien werden durch einen Bedienerbefehl oder durch die ISPF- Verwaltungsanwendungsfunktion aktiviert werden.
- - Workloads, die eine Gruppe von Serviceklassen zum Zweck
der Berichterstellung zusammenfassen; d. h. eine Gruppe
von Arbeiten, die gemeinsam verfolgt, überwacht und
berichtet werden soll; außerdem eine Gruppe von
Serviceklassen. Innerhalb einer Workload können Arbeiten
mit ähnlichen Leistungsmerkmalen zu Serviceklassen
zusammengefaßt werden. Eine Serviceklasse kann für
Gruppen von Arbeiten erstellt werden, bei denen folgendes
ähnlich ist:
- - Leistungsziele
- - Ressourcenbedarf
- - unternehmerische Bedeutung für die Installation
- - Serviceklassen, die in Perioden unterteilt sind, fassen Gruppen von Arbeiten mit ähnlichen Zielen, ähnlicher Wichtigkeit für das Unternehmen, und ähnlichem Ressourcenbedarf zu Verwaltungs- und Berichtszwecken zusammen. Den Perioden innerhalb einer Serviceklasse werden Leistungsziele zugeordnet. Jeder Serviceklassenperiode wird ein Leistungsziel zugeordnet, z. B. eine gewünschte Antwortzeit, die eine Wichtigkeit anzeigt. Entscheidend ist, wie wichtig die Erreichung des Leistungsziels für das Unternehmen ist. Es gibt drei Arten von Zielen: Antwortzeit, Ausführungstempo und Ermessensfreiheit. Antwortzeitziele geben an, wie schnell die Arbeit verarbeitet werden soll. Da Antwortzeitziele nicht für jede Art von Arbeiten geeignet sind, z. B. bei lange dauernden Stapelverarbeitungsjobs, gibt es Ausführungsgeschwindigkeitsziele. Ausfüh rungsgeschwindigkeitsziele legen fest, wie schnell eine Arbeit ausgeführt werden soll, wenn sie bereit ist, ohne daß sie in bezug auf Prozessor-, Speicher- oder E/A-Zu griffe verzögert wird. Ausführungsgeschwindigkeitsziele sind für Arbeiten gedacht, für die Antwortzeitziele nicht geeignet sind, z. B. für gestartete Tasks oder lange laufende Stapelverarbeitungsjobs. Ermessensfreiheitsziele sind für Arbeiten mit niedriger Priorität gedacht, für die es kein spezielles Leistungsziel gibt. Das Workload- Management verarbeitet dann die Arbeit mit Hilfe von Ressourcen, die nicht von anderen Serviceklassen für die Erreichung ihrer Ziele benötigt werden. Da manche Arbeiten einen variablen Ressourcenbedarf haben, können für eine Serviceklasse mehrere Perioden definiert werden. Perioden sind eine Möglichkeit, verschiedene Ziele für eine Arbeit in Abhängigkeit von den von ihr beanspruchten Ressourcen zu definieren. Typischerweise werden Perioden dazu benutzt, kürzeren Transaktionen aggressivere Ziele und länger dauernden Arbeiten der gleichen Art weniger aggressive Ziele zuzuweisen. Es können mehrere Perioden vorhanden sein, wobei jede Periode mit Ausnahme der letzten eine Dauer hat. Die Dauer ist die Ressourcenmenge in Service- Einheiten, die die Arbeit beansprucht, bevor zu den Zielen der nächsten Periode umgeschaltet wird. Arbeiten können auch nach ihrem Ressourcenbedarf in Serviceklassen eingeteilt werden. Wenn man eine Gruppe von Stapelverarbeitungsarbeiten hat, die sehr viele Ressourcen beanspruchen können, und man diesen Ressourcenbedarf begrenzen will, kann man eine Serviceklasse definieren und sie einer Ressourcengruppe mit maximaler Kapazität zuordnen. Wenn die Arbeit diese Kapazität überschreitet, verringert das Workload- Management das Ausführungstempo. Auch wenn eine bestimmte Gruppe von Arbeiten nur minimale Prozessorkapazitäten benötigt, kann man für sie eine Serviceklasse definieren und diese einer Ressourcengruppe zuordnen.
- - Ressourcengruppen: eine Verarbeitungskapazitätsmenge in einem oder mehreren MVS-Abbildern, die einer oder mehreren Serviceklassen zugeordnet ist, die Grenzwerte für die Prozessorkapazität definiert. Einer Arbeit kann ein Minimalwert und ein Maximalwert von CPU-Service- Einheiten pro Sekunde zugeordnet werden, indem eine Serviceklasse einer Ressourcengruppe zugeordnet wird.
- - Klassifizierungsregeln, die bestimmen, wie eingehende Arbeiten einer Service- und Berichtsklasse zugeordnet wird.
- - Anwendungsumgebungen sind Ausführungsumgebungen, die aus Gruppen von Anwendungsfunktionen bestehen, die in Serveradreßbereichen ausgeführt und von einem Client angefordert werden können. Das Workload-Management verwaltet die Arbeiten gemäß dem definierten Ziel und startet und stoppt bei Bedarf automatisch Serveradreßbereiche.
Eine Enklave ist eine Arbeit, die wie eine Transaktion
verarbeitet werden soll, die mehrere zuteilbare Einheiten
(SRBs und Tasks) in einem oder mehreren Adreßbereichen
umfassen kann und in ihrer Gesamtheit berichtet oder verwaltet
wird. Die Enklave wird separat von dem Serveradreßbereich oder
den Serveradreßbereichen, in denen sie ausgeführt wird,
verwaltet. CPU- und E/A-Ressourcen zur Verarbeitung der Arbeit
werden nach dem Leistungsziel der Arbeit verwaltet, für die
Arbeit abgerechnet und der Arbeit berichtet. Ein Programm kann
eine Enklave erstellen, SRBs in ihr planen oder Tasks in sie
aufnehmen. Eine in einem einzigen Adreßbereich erstellte
Enklave kann beliebig viele SRBs oder Tasks mit mehreren
Adreßbereichen haben. Eine Enklaventransaktion erstreckt sich
nur über ein einzelnes System. Dies bedeutet, daß eine
Enklaventransaktion nicht auf einem anderen System fortgesetzt
werden kann.
Eine Enklave kann verwendet werden, wenn eine Arbeit oder
Transaktion, die mehrere Tasks oder SRBs in einem oder
mehreren Adreßbereichen umfaßt, als Einheit verwaltet werden
soll. Eine Enklave ermöglicht die Verwaltung und
Berichterstellung über den Ressourcenverbrauch in der Enklave
auf der Basis eines Leistungsziels, das nicht mit dem
Leistungsziel oder den Leistungszielen des Adreßbereichs oder
der Adreßbereiche, in denen die zuteilbaren Einheiten der
Enklave ausgeführt werden, im Zusammenhang steht. Eine
unabhängige Enklave stellte ein vollständige Transaktion dar.
Ihr Leistungsziel wird anhand der Serviceklasse, der sie
beider Erstellung der Enklave zugewiesen wird, zugeordnet.
Jede unabhängige Enklave startet in Perioden ihrer
Serviceklasse (oder PGN) und führt Periodenwechsel auf der
Basis des von den zuteilbaren Einheiten der Enklave
verbrauchten Service durch. Eine abhängige Enklave stellt die
Fortsetzung einer bestehenden Adreßbereichstransaktion unter
einer neuen Gruppe zuteilbarer Einheiten dar.
Ihr Leistungsziel wird aus der bestehenden
Adreßbereichstransaktion anhand der Serviceklasse (oder PGN)
und Periode übernommen, die zur Verwaltung des Adreßbereichs
zum Zeitpunkt der Erstellung der abhängigen Enklave verwendet
wird. CPU-Services, die von einer abhängigen Enklave
beansprucht werden, werden so behandelt, als würden sie von
der Adreßbereichstransaktion beansprucht, und können zur Folge
haben, daß der Adreßbereich zusammen mit der abhängigen
Enklave in eine spätere Periode überwechselt.
Eine Enklave muß erstellt werden, bevor sie an der Workload-
Management-Umgebung teilhaben kann. Folgende Services, die von
Anwendungsprogrammierern in der Anwendung codiert werden
müssen, um mit Enklaven zu arbeiten, stehen zur Verfügung:
- - Das Makro IWMECREA ermöglicht die Erstellung einer Enklave.
- - Das Makro IEAMSCHD ermöglicht die Einplanung eines SRB in die bestehende Enklave.
- - Das Makro SYSEVENT ENCASSOC macht es möglich, daß eine Enklave SRBs ausführen kann, die einem Adreßbereich zuzuordnen sind, so daß die speicherbezogenen Ressourcen des Serveradreßbereichs für das Leistungsziel der Enklave verwaltet werden können.
- - Das Makro IWMEJOIN ermöglicht das Verbinden mit einer Enklave.
- - Das Makro IWMELEAV ermöglicht das Verlassen einer Enklave.
- - Das Makro IWMECQRY ermöglicht es einem Programm, die Klassifizierungsdaten für eine Enklave abzufragen.
- - Das Makro IWMESQRY liefert einem Programm Informationen darüber, ob die aktuelle zuteilbare Einheit zu einer Enklave gehört.
- - Das Makro IWMEDELE ermöglicht es einem Programm, eine zuvor erstellte Enklave zu löschen.
Prozeßmodelle z. B. im Workflow-Management-Systemen enthalten
viele Informationen über die semantischen Beziehungen zwischen
den Anwendungsfunktionen. Aufgrund der Tatsache, daß Enklaven
Arbeitsaufträge sind, die "in optimaler Zeit" durch das System
geschleust werden sollten, sind Sequenzen automatischer
Aktivitäten (genauer: verbundene Graphen, die durch
Zusammenfassung automatischer Aktivitäten definiert sind) und
atomare Sphären (atomic spheres) (dies sind Zusammenfassungen
von Transaktions-Arbeitseinheiten, d. h. Aktivitäten im
Prozeßmodell mit einem gemeinsamen COMMIT-Umfang, die deshalb
eine globale Transaktion bilden. Für den Zweck der Definition
solcher atomaren Sphären kann das Prozeßmodell analysiert
werden, um Subgraphen zu finden, die die Eigenschaft haben,
daß ein solcher Subgraph nicht notwendigerweise verschiedene
Aktivitäten enthalten muß, die durch einen Pfad von
Steuerverbindungen verbunden sind, der mindestens eine nicht
in der atomaren Sphäre enthaltene Aktivität enthält.) usw.
Kandidaten für Enklaven. Die fundamentale Erkenntnis besteht
darin, daß Enklavenkandidaten algorithmisch und automatisch
aus Prozeßmodellen abgeleitet werden können.
Fig. 1 ist ein Beispiel für die automatische Ableitung von
Enklaven für ein Workload-Management-System (WLM) aus
Prozeßmodellen eines Workflow-Management-Systems (WFMS). Auf
der linken Seiten von Fig. 1 ist ein Beispiel eines
Prozeßmodells in einem WFMS zu sehen. Die Knoten stellen die
Aktivitäten dar, und die Kanten die Steuerverbindungen.
Aktivitäten, die im Prozeßmodell als automatisch ausführbar
definiert sind, d. h. keine Interaktion mit dem Benutzer oder
Eingabe von einem Benutzer benötigen, sind mit <auto<
gekennzeichnet. Außerdem ist ein Subgraph (101) dargestellt,
der im Prozeßmodell als atomare Sphäre definiert ist. Auf der
linken Seite von Fig. 1 sind die Enklave-Graphen E1, E2, E3
dargestellt, die vom erfindungsgemäßen Verfahren automatisch
generiert werden. Für die automatische Generierung von
Enklave-Graphe werden zwei Ansätze vorgeschlagen:
- - Die Spezifikationen, die das Prozeßmodell ausmachen, werden auf "automatische" Aktivitäten analysiert. Subgraphen des Prozeßmodells wie E1 und E3, die "automatische" Aktivitäten enthalten, werden dann automatisch als Enklavegraphen definiert.
- - Die Spezifikationen, die das Prozeßmodell ausmachen, werden auf Aktivitäten mit "atomaren Sphären" analysiert. Subgraphen des Prozeßmodells wie E2, die Aktivitäten mit "atomaren Sphären" enthalten, werden dann automatisch als Enklavegraphen definiert.
Wenn die Enklavegraphen in einem Prozeßmodell definiert worden
sind, schlägt die vorliegende Erfindung vor, daß das WFMS für
die Aktivitäten im Enklavegraphen eine Workload-Management-
Enklave im WLM erstellt; weitere Informationen dazu folgen
weiter unten.
Kurz gesagt wird also in Fig. 1 gezeigt, wie
aufeinanderfolgende Sequenzen von Aktivitäten, die im
Prozeßmodell als automatisch zu startende Aktivitäten
definiert worden sind, auf Enklaven (E1 und E3) abgebildet
werden. Auch die atomische Sphäre AS-1 wird auf eine Enklave
abgebildet, nämlich auf E2.
Zusätzlich zum obigen Ansatz, Enklavegraphen automatisch aus
einem Prozeßmodell zu generieren, wird eine neue Konstruktion
vorgeschlagen, die dem Workflow-Metamodell hinzugefügt werden
kann und eine explizite Angabe von Enklaven im Workflow-
Modellierungsprozeß ermöglicht. Diese explizit angegebenen
Enklaven können natürlich auf den oben erwähnten Kriterien
basieren. Außerdem kann der Ansatz, Enklavegraphen automatisch
zu generieren, mit dem Ansatz, Enklavegraphen explizit
anzugeben, kombiniert werden.
In Fig. 2 ist ein Beispiel für die Definition eines Enklave-
Graphen in der Definitionssprache von FlowMark (FLD)
dargestellt. Das neue Schlüsselwort ENCLAVE leitet die
Definition eines Enklavegraphen ein; darauf folgt der Name des
Enklavegraphen, in diesem Fall E3. Das Beispiel in Fig. 2
könnte die Spezifikation der Enklave E3 aus Fig. 1 sein. Das
Schlüsselwort RELATED_CLASSIFICATION bezieht sich auf eine
Serviceklassendefinition, in diesem Beispiel "DINKY", im WLM.
RELATED_ACTIVITIES ist die Definitionskonstruktion zur
Auflistung der Prozeßaktivitäten des Prozeßmodells, die als
Enklavegraph behandelt werden sollen. Im vorliegenden Beispiel
werden die Prozeßaktivitäten Pr_Act1, Pr_Act2, Pr_Act3 - siehe
(102), (103), (104) in Fig. 1 - angegeben, um einen
Enklavegraphen zu bilden. Auf die Schlüsselwörter DESCRIPTION
und DOCUMENTATION folgen die Beschreibung und der
Dokumentationstext.
Ansammlungen von Aktivitäten sind nicht nur aus
Unternehmenssicht semantisch miteinander verwandt, sondern
auch syntaktisch Kandidaten für die Definition als Enklave,
die bei der Ausführung möglicherweise bei nacheinander oder
parallel laufen. Ein Beispiel ist in Fig. 3 dargestellt:
Sammlung C1 ist ein Kandidat für einen Enklavegraphen, da die
einschlossenen Aktivitäten nacheinander ausgeführt werden
können. C2 ist kein Kandidat, da Aktivität A ein
Verbindungsknoten ist und es deshalb unwahrscheinlich ist, daß
die Quellen seiner eingehenden Steuerverbindungen etwa zur
gleichen Zeit enden - eine Voraussetzung dafür, daß nicht auf
den Start von A gewartet werden muß. C3 ist ein Kandidat, da
die parallelen Aktivitäten alle von der gleichen
Steuerverbindungsquelle abhängig sind und somit etwa
gleichzeitig gestartet werden.
Wenn beispielweise bekannt ist, daß es in einer
Aktivitätengruppe, die als Kandidat in Frage kommt, eine lang
andauernde Aktivität (wie z. B. eine Netzwerksitzung oder eine
Editierungssitzung) gibt, so sollte diese Aktivität nicht Teil
einer Enklave sein.
Das das WFMS zur Zeit der Ausführung über alle Informationen
über die Enklaven (in dem Prozeßmodell) verfügt, kann es auch
anstelle und im Namen der Aktivitäten, die Bestandteile eines
Enklavegraphen sind, die Enklavengrenzen festlegen. Das WFMS
(!) kann die Enklave starten, wenn der Steuerungsfluß erstmals
in die Enklave eintritt. Es kann die Enklave beenden, wenn der
Steuerungsfluß bereit ist, die Enklave zu verlassen, d. h. wenn
klar ist, daß im Rahmen der aktuellen Enklave keine weitere
Arbeit gestartet wird. Beim Aufrufen von
Aktivitätsimplementationen im Rahmen einer Enklave kann er die
Enklave für die Anwendungsfunktion verbinden.
Wenn die vorliegende Erfindung das WFMS als Instanz zum
Erstellen, Verbinden, Löschen usw. einer Enklave innerhalb des
WLM vorschlägt, sind verschiedene Implementierungsvarianten
möglich: entweder die Programmstartfunktion des WFMS (bei
FlowMark der Program Execution Agent (PEA)), oder die Workflow
Engine selber könnte entsprechend erweitert werden.
Außerdem kann das WFMS die Enklaven-Identifikation für die
Anwendungsfunktion, die die Prozeßaktivität implementiert,
verfügbar machen (z. B. über eine spezielle API, oder indem es
sie der Anwendung über ihren Eingabebehälter übergibt), so daß
diese Funktion über die Enklave, zu der sie gehört, informiert
ist. Das WFMS kann die Enklaven-Identifikationen auch an die
Einheit übergeben, die die Funktionsumgebung der Anwendung
bereitstellt (z. B. CICS, IMS) - d. h. an die
Ausführungsumgebung der Anwendung -; dies ist wichtig, um
diese Einheiten in die vorliegende Enklave aufzunehmen. Dies
ist von besonderer Bedeutung, da bestimmte
Ausführungsumgebungen als Subsysteme mit separaten Workload-
Managern implementiert sind. Diese separaten Workload-Manager
können mit dem globalen WLM zusammenarbeiten, benötigen dafür
aber die Enklave-Identifikation einer Enklave im globalen WLM.
Mit der Erfindung ist die Festlegung und Ableitung von
Enklaven wesentlich einfacher als nach dem Stand der Technik.
Die Komplexität beim Schreiben von Anwendungsfunktionen, die
von WLM verwaltet und in workload-verwaltete Einheiten (d. h.
Enklaven) höherer Ebenen aufgenommen werden, wird drastisch
reduziert.
Nach dem Stand der Technik nehmen WLM an, daß die verwaltete
Anwendung eine selbstinstrumentierte Komponente ist. Dies
bedeutet normalerweise, daß die Anwendung selber die WLM API
verwenden muß, um Informationen mit der WLM-Umgebung
auszutauschen. Dazu wären also invasive Änderungen vorhandener
Anwendungen oder eine explizite Einfügung von Code in neu
geschriebene Anwendungen erforderlich. Wegen diesem
zusätzlichen Aufwand wäre der Einsatzbereich von WLM
eingeschränkt. Der Hersteller einer Anwendung muß zum Beispiel
entscheiden, an welche der vorhandenen WLM-Umgebungen er sich
halten soll; im schlimmsten Fall kann dies bedeuten, daß er
alle berücksichtigen muß. Schlimmer noch, die Instrumentierung
ist nicht immer möglich; der Quellcode gehört vielleicht einer
anderen Organisation oder ist nicht mehr vorhanden usw. Die
vorliegende Erfindung macht es möglich, daß Anwendungen in
WLM-Umgebungen aufgenommen werden können, ohne daß sie
speziell dafür instrumentiert werden müssen.
Aber nicht nur Anwendungen innerhalb eines Prozeßmodells
profitieren von der vorliegenden Erfindung. Da es so viel
einfacher wird, Aktivitäten für ein Workload-Management bereit
zu machen, kann der Durchsatz in einem Computersystem
allgemein erhöht werden; davon profitieren dann alle auf
diesem Computersystem ausgeführten Programme.
Die richtige Verwaltung von Verarbeitungsressourcen reduziert
die Gesamtkosten, die für Datenverarbeitungsumgebungen
aufgewendet werden müssen. Anwendungssysteme, die für ein
Workload-Management geeignet sind, werden in Umgebungen mit
Workload-Management zu bevorzugten Systemen.
Claims (11)
1. Ein auf mindestens einem Computersystem ausgeführtes
Verfahren zur Bereitstellung eines Workload-Managements
in einem Workflow-Management-System (WFMS) durch ein
Workload-Management-System (WLM),
wobei das WFMS ein Prozeßmodell enthält, das eine oder mehrere Aktivitäten umfaßt, die die Knotenpunkte eines beliebigen Enklave-Graphen sind, und in dem gerichtete Kanten des Enklave-Graphen einen möglichen Kontrollfluß innerhalb des Prozeßmodells definieren, und
in dem die Aktivitäten des Enklave-Graphen als Workload- Management-Enklave ausgeführt werden müssen,
wobei das Verfahren einen Enklave-Erstellungsschritt umfaßt, in dem das WFMS, wenn der Kontrollfluß zum ersten Mal in den Enklave-Graphen eintritt, im WLM eine Workload-Management-Enklave für die Aktivitäten erzeugt.
wobei das WFMS ein Prozeßmodell enthält, das eine oder mehrere Aktivitäten umfaßt, die die Knotenpunkte eines beliebigen Enklave-Graphen sind, und in dem gerichtete Kanten des Enklave-Graphen einen möglichen Kontrollfluß innerhalb des Prozeßmodells definieren, und
in dem die Aktivitäten des Enklave-Graphen als Workload- Management-Enklave ausgeführt werden müssen,
wobei das Verfahren einen Enklave-Erstellungsschritt umfaßt, in dem das WFMS, wenn der Kontrollfluß zum ersten Mal in den Enklave-Graphen eintritt, im WLM eine Workload-Management-Enklave für die Aktivitäten erzeugt.
2. Ein Verfahren zur Bereitstellung eines Workload-Manage
ments in einem Workflow-Management-System (WFMS) durch
einen WLM nach Anspruch 1,
wobei das Verfahren einen Enklave-Verbindungs-Schritt enthält, in dem, wenn der Kontrollfluß in eine Aktivität eintritt, die ein Knoten in dem Enklave-Graphen ist, und wenn für den Enklave-Graphen bereits eine Workload- Management-Enklave erstellt worden ist, das WFMS die Aktivität mit der Workload-Management-Enklave im WLM hinzufügt.
wobei das Verfahren einen Enklave-Verbindungs-Schritt enthält, in dem, wenn der Kontrollfluß in eine Aktivität eintritt, die ein Knoten in dem Enklave-Graphen ist, und wenn für den Enklave-Graphen bereits eine Workload- Management-Enklave erstellt worden ist, das WFMS die Aktivität mit der Workload-Management-Enklave im WLM hinzufügt.
3. Ein Verfahren zur Bereitstellung eines Workload-
Managements in einem Workflow-Management-System (WFMS)
durch einen WLM nach Anspruch 1 oder 2,
wobei das Verfahren einen Enklave-Lösch-Schritt enthält,
in dem, wenn der Steuerfluß den Enklave-Graphen verlassen
hat, der WLM die Workload-Management-Enklave für die
Aktivitäten löscht.
4. Ein Verfahren zur Bereitstellung eines Workload-
Managements in einem Workflow-Management-System (WFMS)
durch einen WLM nach einem der vorhergehenden Ansprüche,
in dem eine Enklaven-Identifikation der Workload-Manager- Enklave für die Aktivitäten verfügbar ist, und/oder
in dem, wenn eine Aktivität innerhalb einer Ausführungsumgebung auszuführen ist, eine Enklave- Identifikation der Workload-Management-Enklave für die Ausführungsumgebung verfügbar ist.
in dem eine Enklaven-Identifikation der Workload-Manager- Enklave für die Aktivitäten verfügbar ist, und/oder
in dem, wenn eine Aktivität innerhalb einer Ausführungsumgebung auszuführen ist, eine Enklave- Identifikation der Workload-Management-Enklave für die Ausführungsumgebung verfügbar ist.
5. Ein Verfahren zur Bereitstellung eines Workload-
Managements in einem Workflow-Management-System (WFMS)
durch einen WLM nach einem der vorhergehenden Ansprüche,
in dem die Enklave-Identifikation der Workload-
Management-Enklave den Aktivitäten als Element in einem
Eingabebehälter zur Verfügung gestellt wird.
6. Ein Verfahren zur Bereitstellung eines Workload-
Managements in einem Workflow-Management-System (WFMS)
durch einen WLM nach einem der vorhergehenden Ansprüche,
in dem das Verfahren durch eine WFMS Engine ausgeführt wird, die durch das Prozeßmodell navigiert, oder
in dem das Verfahren durch einen WFMS-Agenten ausgeführt wird, der für das Starten einer Aktivität zuständig ist.
in dem das Verfahren durch eine WFMS Engine ausgeführt wird, die durch das Prozeßmodell navigiert, oder
in dem das Verfahren durch einen WFMS-Agenten ausgeführt wird, der für das Starten einer Aktivität zuständig ist.
7. Ein computerbasiertes Verfahren, das automatisch
mindestens einen Enklave-Graphen in einem Prozeßmodell
eines Workflow-Management-Systems (WFMS) bestimmt,
wobei das Prozeßmodell eine oder mehrere Aktivitäten umfaßt, die die Knotenpunkte eines beliebigen Enklave- Graphen sind, und in dem gerichtete Kanten des Graphen einen möglichen Kontrollfluß innerhalb des Prozeßmodells definieren, und
wobei der Enklave-Graph ein Subgraph des Graphen ist, der Aktivitäten enthält, die vom Workload-Management-System (WLM) als Workload-Management-Enklave zu behandeln sind,
wobei das Verfahren den Enklave-Graphen bestimmt, indem es eine Aktivität in den Enklave-Graphen aufnimmt, falls das Prozeßmodell die Aktivität als ohne Benutzereingriff ausführbar definiert.
wobei das Prozeßmodell eine oder mehrere Aktivitäten umfaßt, die die Knotenpunkte eines beliebigen Enklave- Graphen sind, und in dem gerichtete Kanten des Graphen einen möglichen Kontrollfluß innerhalb des Prozeßmodells definieren, und
wobei der Enklave-Graph ein Subgraph des Graphen ist, der Aktivitäten enthält, die vom Workload-Management-System (WLM) als Workload-Management-Enklave zu behandeln sind,
wobei das Verfahren den Enklave-Graphen bestimmt, indem es eine Aktivität in den Enklave-Graphen aufnimmt, falls das Prozeßmodell die Aktivität als ohne Benutzereingriff ausführbar definiert.
8. Ein computerbasiertes Verfahren, das automatisch
mindestens einen Enklave-Graphen in einem Prozeßmodell
eines Workflow-Management-Systems (WFMS) nach Anspruch 7
bestimmt,
wobei das Verfahren den Enklave-Graphen bestimmt, indem
eine Aktivität in den Enklave-Graphen aufgenommen wird,
wenn sie und alle anderen Aktivitäten des Enklave-Graphen
Elemente der gleichen atomaren Sphäre sind, wobei die
atomare Sphäre Aktivitäten enthält, die in einer
Transaktion auszuführen sind.
9. Ein System, das Mittel für die Ausführung der Schritte
des Verfahrens nach einem der Ansprüche 1 bis 8 enthält.
10. Ein Datenverarbeitungsprogramm zur Ausführung in einem
Datenverarbeitungssystem mit Software-Code-Teilen zur
Durchführung eines Verfahrens nach einem der Ansprüche 1
bis 8.
11. Ein auf einem von einem Computer verwendbaren Datenträger
gespeichertes Computerprogrammprodukt, das von einem
Computer lesbare Programm-Mittel enthält, um den Computer
dazu zu veranlassen, ein Verfahren nach einem der
Ansprüche 1 bis 8 auszuführen.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP98122697 | 1998-12-01 |
Publications (1)
Publication Number | Publication Date |
---|---|
DE19955004A1 true DE19955004A1 (de) | 2000-06-29 |
Family
ID=8233055
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19955004A Ceased DE19955004A1 (de) | 1998-12-01 | 1999-11-16 | Ableitung und Ausführung von Workload-Manager-Enklaven aus Workflows |
Country Status (2)
Country | Link |
---|---|
US (1) | US6631354B1 (de) |
DE (1) | DE19955004A1 (de) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2706489A1 (de) * | 2012-09-06 | 2014-03-12 | Günther Helbok | Computergestütztes Verfahren zur automatischen Zuweisung von Arbeitsaufgaben in einem Arbeitsablauf-Verwaltungs-System |
Families Citing this family (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2453797A (en) * | 1996-04-10 | 1997-10-29 | Paul M. Konnersman | Computer-based system for work processes that consist of interdependent decisions involving one or more participants |
US7257642B1 (en) * | 1999-11-11 | 2007-08-14 | Surp Communication Solutions Ltd. | Channel load balancing |
CA2402854A1 (en) * | 2000-03-17 | 2001-09-27 | Emperative, Inc. | Communications services provisioning method and apparatus and object programming language for developing provisioning models |
US6823513B1 (en) * | 2000-04-27 | 2004-11-23 | International Business Machines Corporation | Workflow distribution process granting to operators with assigned activities access to needed computer resources and withdrawing such access upon the completion of the assigned activity |
US7490328B2 (en) * | 2000-05-09 | 2009-02-10 | Surf Communication Solutions, Ltd. | Method and apparatus for allocating processor pool resources for handling mobile data connections |
JP2001356907A (ja) * | 2000-06-09 | 2001-12-26 | Ibm Japan Ltd | 処理コード情報を有するデータベース・システムおよび情報処理システム |
JP2002032544A (ja) * | 2000-07-13 | 2002-01-31 | Suntory Ltd | 業務運営システム、ワークフロープロセッサおよびワークフローメッセンジャー |
US6886007B2 (en) * | 2000-08-25 | 2005-04-26 | International Business Machines Corporation | Taxonomy generation support for workflow management systems |
US6892376B2 (en) * | 2001-03-20 | 2005-05-10 | International Business Machines Corporation | Flexible infrastructure for managing a process |
US20020142273A1 (en) * | 2001-03-30 | 2002-10-03 | Dollins James T. | Interactive process learning aid |
GB2376094A (en) * | 2001-05-30 | 2002-12-04 | Ibm | Flexible navigation of a workflow graph in a data processing system |
US7403878B2 (en) * | 2001-10-18 | 2008-07-22 | International Business Machines Corporation | Using nodes for representing hyper-edges in process models |
US7529762B2 (en) * | 2002-08-28 | 2009-05-05 | Hewlett-Packard Development Company, L.P. | Workflow data warehousing |
US20040078105A1 (en) * | 2002-09-03 | 2004-04-22 | Charles Moon | System and method for workflow process management |
AU2003278960A1 (en) * | 2002-09-26 | 2004-04-19 | Electronic Data Systems Corporation | Representing resources needed to provide a complex portfolio of offerings |
US20050080640A1 (en) * | 2003-10-10 | 2005-04-14 | International Business Machines Corporation | System and method for generating a business process integration and management (BPIM) solution |
US7890309B2 (en) * | 2003-10-10 | 2011-02-15 | International Business Machines Corporation | System and method for analyzing a business process integration and management (BPIM) solution |
US20050154607A1 (en) * | 2004-01-12 | 2005-07-14 | Orestis Terzidis | User interface for displaying multiple organizational hierarchies |
US20050154606A1 (en) * | 2004-01-12 | 2005-07-14 | Orestis Terzidis | User interface for displaying organization structure |
US7945657B1 (en) * | 2005-03-30 | 2011-05-17 | Oracle America, Inc. | System and method for emulating input/output performance of an application |
US7765291B1 (en) * | 2004-05-19 | 2010-07-27 | Ultimus, Inc. | Business process management/workflow automation software |
US7844969B2 (en) * | 2004-06-17 | 2010-11-30 | Platform Computing Corporation | Goal-oriented predictive scheduling in a grid environment |
US20060178921A1 (en) * | 2005-02-04 | 2006-08-10 | Taiwan Semiconductor Manufacturing Co., Ltd. | Project management system and method therefor |
US7392258B2 (en) | 2005-02-25 | 2008-06-24 | International Business Machines Corporation | Method and computer program product for dynamic weighting of an ontological data model |
US7809754B2 (en) * | 2005-02-28 | 2010-10-05 | International Business Machines Corporation | Method and computer program product for generating a lightweight ontological data model |
US8015051B2 (en) * | 2005-03-11 | 2011-09-06 | Sap Ag | System and method for business process integration |
US20060253397A1 (en) * | 2005-04-12 | 2006-11-09 | Gomez Omar M | Business model and software |
US7941332B2 (en) * | 2006-01-30 | 2011-05-10 | International Business Machines Corporation | Apparatus, system, and method for modeling, projecting, and optimizing an enterprise application system |
US20070276714A1 (en) * | 2006-05-15 | 2007-11-29 | Sap Ag | Business process map management |
US20080201713A1 (en) * | 2007-02-16 | 2008-08-21 | Pivotal Labs, Inc. | Project Management System |
US20120113134A1 (en) * | 2009-04-17 | 2012-05-10 | Rainer Heller | Providing a Proxy Step in a Model of an Automation System |
US20140067453A1 (en) * | 2012-09-05 | 2014-03-06 | International Business Machines Corporation | Shared asset management |
US9519803B2 (en) * | 2012-11-30 | 2016-12-13 | Intel Corporation | Secure environment for graphics processing units |
US10044695B1 (en) | 2014-09-02 | 2018-08-07 | Amazon Technologies, Inc. | Application instances authenticated by secure measurements |
US9577829B1 (en) | 2014-09-03 | 2017-02-21 | Amazon Technologies, Inc. | Multi-party computation services |
US10079681B1 (en) | 2014-09-03 | 2018-09-18 | Amazon Technologies, Inc. | Securing service layer on third party hardware |
US9246690B1 (en) | 2014-09-03 | 2016-01-26 | Amazon Technologies, Inc. | Secure execution environment services |
US9491111B1 (en) | 2014-09-03 | 2016-11-08 | Amazon Technologies, Inc. | Securing service control on third party hardware |
US10061915B1 (en) | 2014-09-03 | 2018-08-28 | Amazon Technologies, Inc. | Posture assessment in a secure execution environment |
US9754116B1 (en) | 2014-09-03 | 2017-09-05 | Amazon Technologies, Inc. | Web services in secure execution environments |
US9584517B1 (en) * | 2014-09-03 | 2017-02-28 | Amazon Technologies, Inc. | Transforms within secure execution environments |
US10477363B2 (en) | 2015-09-30 | 2019-11-12 | Microsoft Technology Licensing, Llc | Estimating workforce skill misalignments using social networks |
US10545567B2 (en) * | 2017-01-06 | 2020-01-28 | International Business Machines Corporation | Method and apparatus for power savings in communications equipment |
US10977265B2 (en) * | 2018-10-23 | 2021-04-13 | Drumwave Inc. | Path-based population visualization |
US11048800B2 (en) * | 2018-12-17 | 2021-06-29 | Intel Corporation | Composable trustworthy execution environments |
US11314620B1 (en) * | 2020-12-09 | 2022-04-26 | Capital One Services, Llc | Methods and systems for integrating model development control systems and model validation platforms |
CN112527508B (zh) * | 2020-12-21 | 2022-12-09 | 卓尔智联(武汉)研究院有限公司 | 基于sgx的云端飞地资源管理方法、装置、计算机设备和介质 |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5535322A (en) * | 1992-10-27 | 1996-07-09 | International Business Machines Corporation | Data processing system with improved work flow system and method |
US5537542A (en) * | 1994-04-04 | 1996-07-16 | International Business Machines Corporation | Apparatus and method for managing a server workload according to client performance goals in a client/server data processing system |
JP2666755B2 (ja) * | 1995-01-11 | 1997-10-22 | 日本電気株式会社 | ワークフローシステム |
US5799297A (en) * | 1995-12-15 | 1998-08-25 | Ncr Corporation | Task workflow management system and method including an external program execution feature |
US5870545A (en) * | 1996-12-05 | 1999-02-09 | Hewlett-Packard Company | System and method for performing flexible workflow process compensation in a distributed workflow management system |
US5937388A (en) * | 1996-12-05 | 1999-08-10 | Hewlett-Packard Company | System and method for performing scalable distribution of process flow activities in a distributed workflow management system |
US6041306A (en) * | 1996-12-05 | 2000-03-21 | Hewlett-Packard Company | System and method for performing flexible workflow process execution in a distributed workflow management system |
US5826239A (en) * | 1996-12-17 | 1998-10-20 | Hewlett-Packard Company | Distributed workflow resource management system and method |
US5974462A (en) * | 1997-03-28 | 1999-10-26 | International Business Machines Corporation | Method and apparatus for controlling the number of servers in a client/server system |
US6085217A (en) * | 1997-03-28 | 2000-07-04 | International Business Machines Corporation | Method and apparatus for controlling the assignment of units of work to a workload enclave in a client/server system |
US6199068B1 (en) * | 1997-09-11 | 2001-03-06 | Abb Power T&D Company Inc. | Mapping interface for a distributed server to translate between dissimilar file formats |
US6052684A (en) * | 1998-03-24 | 2000-04-18 | Hewlett-Packard Company | System and method for performing consistent workflow process execution in a workflow management system |
US6311144B1 (en) * | 1998-05-13 | 2001-10-30 | Nabil A. Abu El Ata | Method and apparatus for designing and analyzing information systems using multi-layer mathematical models |
US6067548A (en) * | 1998-07-16 | 2000-05-23 | E Guanxi, Inc. | Dynamic organization model and management computing system and method therefor |
US6347256B1 (en) * | 1998-11-02 | 2002-02-12 | Printcafe System, Inc. | Manufacturing process modeling techniques |
-
1999
- 1999-11-16 DE DE19955004A patent/DE19955004A1/de not_active Ceased
- 1999-12-01 US US09/452,255 patent/US6631354B1/en not_active Expired - Lifetime
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2706489A1 (de) * | 2012-09-06 | 2014-03-12 | Günther Helbok | Computergestütztes Verfahren zur automatischen Zuweisung von Arbeitsaufgaben in einem Arbeitsablauf-Verwaltungs-System |
Also Published As
Publication number | Publication date |
---|---|
US6631354B1 (en) | 2003-10-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE19955004A1 (de) | Ableitung und Ausführung von Workload-Manager-Enklaven aus Workflows | |
DE19948028A1 (de) | Verfahren und System zum Optimieren des Anforderungsschickens in Workflow Management Systemen | |
DE19955718A1 (de) | Paralleler Datenbank-Support für Workflow-Management-Systeme | |
US6122633A (en) | Subscription within workflow management systems | |
DE10003015A1 (de) | Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus Prozessmodellen | |
DE69735922T2 (de) | System und Verfahren zum flexiblen Darstellen von Arbeitsvorgängen | |
DE19712946A1 (de) | Methode zum Generieren einer Implementierung wiederverwendbarer Teile von Containern eines Workflow-Prozessmodells | |
DE4303062C2 (de) | Verfahren zur Behebung von Systemausfällen in einem verteilten Computersystem und Vorrichtung zur Durchführung des Verfahrens | |
DE19705955A1 (de) | Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung | |
US6237020B1 (en) | Task-oriented automatic distribution of software | |
DE19954268B4 (de) | Verfahren und System zur Verbesserung des Workflow in Workflow-Management-Systemen | |
DE602006000907T2 (de) | Zugangssteuerungssystem, Regelmaschinen-Anpasseinrichtung, regelbasierte Erzwingungsplattform und Verfahren zum Ausführen einer Zugriffssteuerung | |
US6073111A (en) | Container materialization/dematerialization for reduced dataload and improved data-coherency in workflow-management systems | |
DE112011100094T5 (de) | Verfahren und System zum Abstrahieren eines auf nichtfunktionalen Anforderungen beruhenden Einsatzes von virtuellen Maschinen | |
DE10247529A1 (de) | Anpassbare Zustandsmaschine und Zustandsaggregationstechnik zur Verarbeitung von Zusammenarbeits- und Transaktionsgeschäftsobjekten | |
DE19844071A1 (de) | Verfahren zum Lösen von Datenkonflikten in einem gemeinsamen Datenumfeld | |
DE112013000916T5 (de) | System zum Anzeigen und Bearbeiten von Artefakten an einem zeitbezogenen Referenzpunkt | |
EP1699005A1 (de) | Integration von MES- und Controls-Engineering | |
DE19960048A1 (de) | Zeitgesteuerte Startbedingungen für Aktivitäten in Workflow-Management-Systemen | |
DE102006036796A1 (de) | Zeitplanmanagement | |
DE10119876A1 (de) | Verfahren, System und Computerprorammprodukt zur Bereitstellung einer Jobüberwachung | |
DE102016200028A1 (de) | Personalbereichsverwaltungssystem | |
EP2648094A2 (de) | Verfahren und System zum Erzeugen eines Quellcodes für ein Computerprogramm zur Ausführung und Simulation eines Prozesses | |
US6507844B1 (en) | Method and system for minimizing network traffic | |
DE10125956A1 (de) | Archivierung in Arbeitsablaufverwaltungssystemen |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8131 | Rejection |