Workflow, Business Process Management, 2.Teil

Transcription

򔻐򗗠򙳰
Workflow, Business Process Management,
2.Teil
12. Dezember 2003
Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt
werden. Eine weitere Nutzung bedarf der schriftlichen Einverständnis des Autors.
© Copyright International Business Machines Corporation 2001,2003. Alle Rechte vorbehalten.
Inhaltsverzeichnis
Literaturverzeichnis. . . . . . . . . . v
Kapitel 2. Funktionale Struktur eines
Workflow-Systems . . . . . . . . . . 11
Kapitel 1. Codestruktur eines
Workflow-Systems . . . . . . . . . . 1
Administration Server . . .
Administration Client . . .
Navigation, Execution Server
Program Execution Server .
Scheduling Server . . . .
Cleanup Server . . . . .
Workflow API . . . . .
Web Client . . . . . .
Buildtime . . . . . . .
Workload Management . .
Aufgaben . . . . . . .
Kernel . . . . . . . . . . . . . . .
Messagelayer . . . . . . . . . . . . .
Das Interface zur Datenbank . . . . . . . .
Verwendete Funktionen des Datenbanksystems .
Database Access Layer . . . . . . . . .
TOM (Tiny Object Manager) . . . . . . .
Staff Resolution . . . . . . . . . . .
Server Framework . . . . . . . . . . .
FDL Parser, Verifier . . . . . . . . . . .
Regression Test . . . . . . . . . . . .
© Copyright IBM Corp. 2001,2003
.
.
.
.
.
.
.
.
.
.
1
2
3
3
4
5
5
7
8
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
12
13
13
13
13
13
14
14
iii
iv
Literaturverzeichnis
Gustavo Alonso, Fabio Casati, Harumi Kuno,
Vijay Machiraju: Web Services
Springer Verlag 2004, 350 Seiten.
Beschreibt Konzepte und Architektur
sowohl von Web Services als frühere
Beispiele von Middleware. Ohne auf die
technischen Details der einzelnen
Produkte einzugehen wird hier die
Entwicklung der Software hin zu den
Web Servies beschrieben.
William Crawford, Jonathan Kaplan: J2EE
Design Patterns
O’Reilly 2002, 350 Seiten.
v
vi
Kapitel 1. Codestruktur eines Workflow-Systems
Kriterien für die Strukturierung des Codes:
Vermeidung von Redundanz
1. über die verschiedenen Komponenten
2. über Plattformgrenzen
3. im Verarbeitungsfluß der Daten
Isolierung von Interfaces durch Wrapper
1. um mit vertretbarem Aufwand andere Interfaces zu unterstützen
2. um allgemeine Interfaces zu spezialisieren für die Bedürfnisse des
Produkts
3. zur Bereitstellung von Conveniance-Methoden
Kernel
Stellt Basisklassen zur Verfügung. Eine Auswahl:
String-Klasse
Enthält neben den Standard-String-Operationen auch Methoden zum Lesen
und Schreiben bei Datenbankzugriffen, Methoden zum Verschlüsseln von
Paßwörtern. Kann DBCS (Double Byte Character Sequence) verarbeiten.
Syntax Checker
Testet Eingabewerte z.B. von UserIds, Paßwörtern, Namen auf Länge und
gültige Zeichen.
Codepage Conversion
Einheitliche Benennung von gleichen oder fast gleichen Codepages über
die verschiedenen Plattformen. Ermittlung der System-Codepage.
Stringkonvertierung in zwei Schritten über Unicode.
Assertion Handling
Codiert wird nach dem Fail-Fast-Paradigma: Implizite Annahmen über
Daten, die Input für Methoden sind, werden explizit durch Pre-Conditions
geprüft. Konsistenzregeln am Ende einer Methode werden explizt durch
Post-Conditions geprüft. Was passiert, wenn eine dieser Bedingungen
verletzt ist:
1. Abbruch des Programms
2. Ausgabe der Sourcecodestelle des Fehlers
3. Schreiben eines Traceeintrags
4. Ausgabe des Callstacks
Beispiel im Code:
int Wert = 0;
FMC_ASSERT( Wert != 0 );
Beispiel im Trace:
THROW_INT, FmcAssertionException, Condition=***
Assertion failed in c:\V350\srd\fmctkstr.cxx(1724): Wert != 0
Tracing
Wurde schon in einem früheren Kapitel vorgestellt.
1
Profilezugriff
Konfigurationsparameter des Systems werden je nach Plattform
unterschiedlich gespeichert (Registry bei Windows, Files bei Unix, Data
Sets bei zOS). Die Profileklasse verbirgt diese Details. Eine Liste
Konfigurationsvariablen ist definiert.
Messages für Benutzer
Alle Texte für Benutzer werden separat vom ausführbaren Code gehalten
und werden in verschiedene Sprachen übersetzt. Es gibt Klassen, die dafür
sorgen, daß die durch eine Zahl identifizierte Message formatiert
(Parameterersetzung) und ausgegeben wird. Fehlermeldungen mit
Erklärungen erscheinen auch in einem Buch (Messages and Codes).
Streaming
Klasse zur Serialisierung und Deserialisierung von Datenstrukturen in
Messages oder in den Trace.
OID Handling
OIDs (Object Identifier), sind 16 Byte lang. Jedes Programm, welches
persistente Objekte anlegt, reserviert zuerst einen Bereich von OIDs, die es
verwenden kann. Die höchste vergebene OID ist persistent gespeichert
ID-Klassen
Die IDs dienen zur Identifizierung von Objekten sowohl im Code als auch
in der Datenbank. Dort sind die IDs Primary und Secondary Keys. Beispiel:
ATID
Activity Template ID, eine OID.
BTID
Block Template ID, eine OID. Zur Identifizierung von Blöck- und
Prozesstemplates.
BIID
Block Instance ID, besteht aus einer OID und der BTID des
entsprechenden Templates.
AIID
Activity Instance ID, besteht aus der laufenden Nummer in der
Block Instance, der BIID und der ATID.
Enthält auch Methoden zum Lesen und Schreiben bei Datenbankzugriffen
und zur Serialisierung in Messages.
Verwaltung von Shared Libraries
Methoden zum dynamischen Laden und Entladen von ausführbarem
Code.
Messagelayer
Interface zum Message Queueing System: Fehlerbehandlung.
Messages haben einen Messagetyp, der für die Aktion der Message steht, z.B. Start
Activity. Für jeden Messagetyp ist folgendes definiert:
1. Quelle und Ziel der Message
2. Request/Reply Messages sind paarweise definiert.
3. Liste der Datenfelder der Message
Für jedes Datenfeld einer Message sind folgende Attribute definiert:
1. Name
2. Typ
3. Maximale Länge
4. Mögliche Anzahl; 0, 1, mehrfach
2
Ein Codegenerator erzeugt C++ und Java Klassen mit den Interfaces zu Messages.
Das Interface zur Datenbank
Navigation Engine
Staff Resolution
TOM
DBA
Database
Abbildung 1. Die Code-Ebenen beim Datenbankzugriff
Verwendete Funktionen des Datenbanksystems
Trigger, Constraints
... werden nicht verwendet. Die Integrität der Datenbank zu erhalten ist
Aufgabe des Workflow-Systems. Es dürfen keine Updates in der
Datenbank gemacht werden unter Umgehung des Workflow-Systems.
Views
... sind definiert als Schnittstelle für Kunden: Selektiver Zugriff auf die
Daten z.B. auf Audittrail-Tabelle:
CREATE VIEW FMC.ACTSTART AS(
SELECT CREATED, ASSOCIATED_OBJECT AS ACTID
FROM FMC.AUDIT_TRAIL A1
WHERE EVENT IN (21007,21022) AND ACTIVITY_TYPE = 21100)
Der Grund zur Verwendung der Views ist eine Abkoppelung des Interfaces
für Kunden vom intern verwendeten Datenbankschema.
Authorisierung
Datenbanken haben ein Authorisierungskonzept. Verschiedene Personen
können unterschiedliche Rechte haben beim Zugriff auf die Datenbank.
Das Workflowsystem hat ein eigenes Authorisierungskonzept. Die
Datenbankzugriffe für alle Workflow-Benutzer erfolgen immer mit dem
gleichen Datenbankbenutzer.
Die Rechte dieses Datenbankbenutzers werden von manchen Kunden auf
ein Minimum eingeschränkt, es muß also dokumentiert sein, was dieser
minimale Satz an Berechtigungen ist.
Datenbankschema erweiterbar
3
Das mit dem Workflow-System bei der Installation angelegte
Datenbankschema ist fest mit der folgenden Ausnahme: Der Global
Datacontainer von Prozessen: Abhängig von der Struktur des Global
Datacontainers wird eine Tabelle beim Import des Processtemplates
angelegt.
Tablespaces der Datenbank
Bei der physischen Organisation der Daten unterstützen wir die Kunden,
damit sie über geeignete Schnittstellen bei der Konfiguration die
Datenbank an ihre Bedürfnisse bezüglich Speicherplatz und Performance
anpassen können.
Migration bei Releasewechsel
Von einem Workflow-Release zum nächsten können Schemaerweiterungen
vorgenommen werden. Falls in diesem Zusammenhang Änderungen der
Kundendaten notwendig ist, wird ein Programm zur Datenbankmigration
mit dem neuen Release ausgeliefert.
Database Access Layer
Generierter C++ Code
Dieser Layer besteht im Wesentlichen aus generiertem Code.
Beispieldefinition einer Query:
METHOD seluni2
UNIQUE SELECT *
FROM FMC.PROCESS_INST
WHERE NAME = ?
AND
STATE <> 128
;
Static SQL
Es wird hier statisches SQL verwendet, d.h. alle Queries und Update
SQL-Statements sind zum Compilezeitpunkt definiert.
Einfache Zugriffsstruktur
Typisch für die SQL-Calls des DBA ist das Lesen und Schreiben aus einer
Tabelle.
Isolation vom Datenbanksystem
Der generierte Code liest dann die Felder alle in eine entsprechende
Datenstruktur ein. Durch diesen Layer werden Unterschiede zwischen
verschiedenen DB2–Versionen und Oracle vom restlichen Code
abgeschirmt: z.B. Unterschiede bei der SQL-Syntax oder verschiedene
Datentypen, die verwendet werden können.
Da für Oracle und DB2 das Interface von DBA zu TOM gleich ist, reicht es
aus, nur den DBA an die Datenbank anzupassen und die Shared Libraries
für beide Datenbanktypen auszuliefern. Der restliche ausführbare Code ist
gleich.
Denormalisierung beim Lesen
Beim Lesen von Instanzdaten werden zusätzlich auch die Templatedaten
gelesen und auch in der Datenstruktur der Instanz gespeichert
(Denormalisierung der Daten beim Lesen). Templatedaten dürfen
grundsätzlich nicht geändert werden.
4
TOM (Tiny Object Manager)
Lesen
von A
Ändern
von A
Schreiben
von A
TOM
Datenbank
Abbildung 2. Der Tiny Object Manager
Eingenschaften des TOM
1. Hält Objekte in seinem Cache innerhalb einer Transaktion.
2. Objekte werden im Cache nach ihrem Schlüssel verwaltet
3. Updates vom Anwendungsprogramm finden direkt auf den Objekten des TOM
statt.
4. Das Zurückschreiben von Records in die Datenbank geschieht nur explizit
5. Einfache Updates von mehreren Records werden direkt ausgeführt, z.B.
UPDATE work_item
SET state = ’inactive’
WHERE process_inst = ? AND owner != ?
Dazu sollte der Cache geleert werden, damit keine veralteten Daten im Cache
stehen (Cache Coherency).
6. Werden mehrere Objekte mit einer Query gelesen, wird dem
Anwendungsprogramm eine Liste dieser Objekte zurückgegeben. Wenn das
Anwendungsprogramm nur eine beschränkte Anzahl an Objekten bearbeiten
will, sollte vom TOM nur diese Anzahl geholt werden.
Staff Resolution
Wie im ganzen Code wurde auch hier versucht, mit statischem SQL zu arbeiten.
Da die Menge der möglichen Staff-Resolution Queries nicht begrenzt ist, wurde
folgende Lösung gewählt:
5
Navigation
engine
Regression
test
Resolve
PerformQry
Code
generation
BldDynQry
ExecDynQry
ExecStatQry
Abbildung 3. Aufrufhierarchie Staff Resolution
Die Staff Resolution liefert im Wesentlichen eine Liste von Personen, die ein
Workitem zu einer bestimmten Activity erhalten sollen. Dies kann im Prinzip
durch eine Query erreicht werden.
Beispiel 1: Gesucht sind alle anwesenden Mitglieder einer Abteilung. Ist keiner
anwesend, sollen alle Mitglieder der Abteilung ermittelt werden.
DECLARE PQERY1111 CURSOR FOR
WITH
FMC.BASIC(NAME, ABSENT) AS
(
SELECT P.NAME, P.ABSENT
FROM
FMC.PERSON P
WHERE P.ORGANIZATION = :org
),
FMC.ABS_INDICATOR(EMPTY) AS
(
VALUES
(
CASE
WHEN (SELECT 1
FROM
(VALUES(1)) AS Q
WHERE EXISTS (SELECT *
FROM
FMC.BASIC
WHERE ABSENT = 0)) IS NOT NULL
THEN 0
ELSE 1
END
)
)
SELECT P.NAME, 0
FROM
FMC.BASIC P, FMC.ABS_INDICATOR I
WHERE I.EMPTY = P.ABSENT
FOR READ ONLY;
Erläuterungen
1. Es werden hier Common Table Expressions verwendet.
2. FMC.BASIC ermittelt alle Personen der Abteilung.
6
3. Mit FMC.ABS_INDICATOR wird ermittelt, ob es anwesende Personen gibt. In
diesem Fall hat er den Wert 0, sonst 1.
4. Abhängig von diesem Indikator sucht dann die Query entweder die
anwesenden Personen oder die abwesenden Personen dieser Abteilung.
Die gleiche Aufgabe wird jetzt mit einer allgemeineren Query gelöst:
SELECT P.NAME, P.ABSENT
FROM
FMC.PERSON P
FOR READ ONLY;
Hier liefert die Query alle Mitglieder der Abteilung. Danach muß noch im C++
Code durch die Liste durchgegangen werden um entweder alle abwesenden oder
alle anwesenden Personen zu löschen.
Beispiel 2: Wie oben werden die Mitglieder einer Abteilung gesucht. Ist eine Person
abwesend, soll ihr Vertreter ausgewählt werden, wenn sie anwesend ist.
WITH
FMC.BASIC(OID) AS (
SELECT P.OID
FROM
FMC.PERSON P
WHERE P.ORGANIZATION = :org ),
FMC.NORMAL(NAME, ASSIGNMENT_TYPE) AS (
SELECT P.NAME, 0
FROM
FMC.PERSON P
WHERE P.ABSENT = 0 AND P.OID IN (SELECT OID FROM FMC.BASIC) ),
FMC.SUBSTITUTE(NAME, ASSIGNMENT_TYPE) AS (
SELECT DISTINCT P.NAME, 1
FROM
FMC.PERSON P, FMC.PERSON P2
WHERE P2.ABSENT = 1 AND
P2.SUBSTITUTE_OID IS NOT NULL AND
P.OID = P2.SUBSTITUTE_OID AND
P.ABSENT = 0 AND
P2.OID IN (SELECT OID FROM FMC.BASIC) )
SELECT *
FROM
FMC.NORMAL
UNION ALL
SELECT *
FROM
FMC.SUBSTITUTE
WHERE NAME NOT IN (SELECT NAME FROM FMC.NORMAL)
FOR READ ONLY;
Wie oben erledigt die folgende Aufgabe mit etwas C++ Code die gleiche Aufgabe:
SELECT P.NAME, P.ABSENT, P.SUBSTITUTE, FMCS.ABSENT
FROM
FMC.PERSON P
LEFT OUTER JOIN FMC.PERSON FMCS ON P.SUBSTITUTE_OID = FMCS.OID
FOR READ ONLY;
Server Framework
Das Serverframework kann als Betriebssystem eines Servers bezeichnet werden.
Aufgaben:
1. Initialisierung und Beenden des Servers.
7
2. Fangen und korrektes Verarbeiten von Exceptions, die vom Server geworfen
wurden.
3. Weiterleiten der Message in eine Hold Queue, wenn sie nicht verarbeitet
werden kann.
4. Die Main-Message-Loop: Transaktionsbeginn, Lesen einer Message, Bearbeiten
und Abschluß der Transaktion.
5. Spezielle Anpassungen an das Betriebssystem bei z/OS.
FDL Parser, Verifier
Ausschnitt aus einer FDL-Definition eines Prozesses:
PROCESS ’CreditRequest’ ( ’PersonInfo’, ’Default Data Structure’ )
DESCRIPTION ’Credit request’
PROMPT_AT_PROCESS_START
NO AUTONOMY
WINDOW ZOOM_FACTOR 100
WINDOW PAPERSIZE WIDTH 2970 HEIGHT 2100
WINDOW SHOW ALL CONNECTORS
WINDOW SHOW TRANSITION_CONDITIONS
SOURCE 1 XPOS -918 YPOS 433
PROGRAM_ACTIVITY ’AssessRisk’ ( ’CreditInfo’, ’CreditInfo’ )
DESCRIPTION ’Credit request for %CredReq.FirstName% %CredReq.LastName%’
START MANUAL WHEN AT_LEAST_ONE CONNECTOR TRUE
EXIT AUTOMATIC
LAYOUT XPOS -232 YPOS 177
NAME_POSITION XPOS -232 YPOS 102
DONE_BY STARTER_OF_ACTIVITY ’CollectCreditInformation’
PROGRAM ’NAssessCreditRisk’
END ’AssessRisk’
...
CONTROL
FROM ’AssessRisk’ TO ’AcceptCredit’
WHEN ’CreditAmount<100000 AND RiskFactor="L"’
XPOS 188 YPOS 146
...
DATA
FROM SOURCE 1 TO ’CollectCreditInformation’
MAP ’_STRUCT’ TO ’_STRUCT’
...
END ’CreditRequest’
Die FDL Parser bestehen aus zwei Teilen:
Parser-Frontend
Das Parser-Frontend für C++ ist mit einem YACC- (yet another compiler
compiler) ähnlichen Tool geschrieben, für Java wurde JavaCC verwendet.
Das Frontend baut einen Parsertree im Speicher auf. Syntaktische und
semantische Fehler sollten möglichst bei diesem Schritt erkannt werden.
Parser-Backend
Der Parsetree wird vom Backend bearbeitet.
Beispielsweise haben Runtime-Import und Buildtime-Import ein gemeinsames
Frontend, aber verschiedene Backends.
Regression Test
Schon bei der Entwicklung von größeren Komponenten sind Tests zu schreiben,
die sicherstellen, daß Szenarien korrekt bearbeitet werden. Kennzeichen:
8
Produktstabilität
Die Hauptaufgabe von Regressiontests ist, zu gewährleisten, daß neu
eingebaute Funktionen oder Korrekturen nicht unerwünschte Nebeneffekte
haben.
Der Regression Test läuft automatisch ab.
Validierung
Die Ergebnisse werden entweder mit einem früheren, als korrekt
identifiziertem Ergebnis verglichen oder auf auch eine andere Weise
bestimmt und dann verglichen.
Fehlerursachen
Falls Differenzen auftreten, ist die Analyse oft sehr aufwändig. Mögliche
Ursachen sind: Setupproblem beim Testcase, korrekt geänderter Code,
liefert etwas andere Ergebnisse, neu eingebauter Fehler im Code.
Aufsetzpunkt
Speziell am Anfang eines Entwicklungsprojektes ist es sinnvoll, über
spezielle Interfaces eine Komponente zu testen. Zum Beispiel kann dann
ein Workflow-Server ohne das Message-Queueing-Interface getestet
werden.
Später sollten dann eher die offiziellen Schnittstellen beim Test verwendet
werden, um praxisnähere Bedingungen zu haben.
9
10
Kapitel 2. Funktionale Struktur eines Workflow-Systems
Folgende Kriterien wurden bei der Aufteilung der Funktionen verwendet:
Trennung der Verarbeitung der Client-Requests von anderen Aufgaben
Die Hauptlast eines Workflow-Systems sind Client-Requests. Durch diese
Trennung läßt sich das System besser kontrollieren.
Andere Transaktionen, die lange laufen, behindern dadurch nicht kurze
Transaktionen, die vom gleichen Server zu bearbeiten wären.
Sonderaufgaben müssen oft zentral für die ganze Installation ausgeführt
werden. Für diese Aufgaben speziell geschriebene Programme können dies
besser kontrollieren.
Fehlertoleranz
Fehler sollten zwar gemeldet werden, das System sollte aber nach
Möglichkeit robust sein.
Verschiedene Workflow-Installationen sinnvoll unterstützen
Speziell bei größeren Kunden gibt es Systeme zum Modellieren, Testen und
für die Produktion.
Administration Server
Watchdog
Überwacht und steuert die anderen Server des Systems, gibt Auskunft über
den Zustand des Systems.
Session Handling
Da eine Kommunikation mit dem Administration Server nur in einer
gültigen Session möglich ist, und der Administration Server auch allein
laufen sollte, wird das Session Handling für das gesamte Workflow-System
vom Administration Server ausgeführt.
Logging
Es gibt verschiedene Ziele für Log-Messages: Administration Client,
Datenbanktabellen, Files. Die Log-Messages werden an den Administration
Server geschickt, der sie dann weiterverteilt.
Hold-Quere Handling
Messages, deren Backout-Count überschritten wurden, werden in die
Hold-Queue geschickt. Der Administration Server ermöglicht die
Verwaltung dieser Messages (Löschen, Wiederausführung, Lesen der
Messages).
Administration Client
Stellt das Userinterface des Administration Servers dar:
1. Auskunft, welche Server gerade laufen.
2. Manuelles Starten und Stoppen von Serverinstanzen.
3. Ist Konsole des Systems, es werden Ereignisse des Systems wie z.B.
Fehlersituationenen angezeigt.
11
Navigation, Execution Server
Bearbeitet die Client Requests (Außer Logon/Logoff und Administration Tasks). Ist
Quelle und Ziel der Messages von verketteten Transaktionen.
Ready
Start
Running
Suspend
Resume
Suspended
Completed
Terminate
Finished
Terminated
Expire
Expired
Delete,
keep time
exeeded
Deleted
Abbildung 4. Vereinfachtes Statsübergangsdiagramm von Activities
Falls Memory Leaks auftreten, kann der Server nach einer festgelegten Anzahl von
Transaktionen stoppen. Der Administration Server startet in diesem Fall eine neue
Serverinstanz.
Anlegen und Löschen von Process Instances kann auf Zeiten verlegt werden, bei
denen das System weniger belastet ist.
Program Execution Server
Startet die Programmaktivitäten für das Workflow-System. Mögliche
Invokationmechanismen:
CICS, IMS Transaktionen
Aufruf als Safe Application, das heißt als verkettete Transaktion.
Ausführbares Programm
Keine Transaktionssicherheit
Java Programm, Shared Library
Keine Transaktionssicherheit. Wichtige Optionen:
1. Fenced Mode: in separatem Prozess für eine größere Robustheit.
2. Keep Loaded: die Library wird im Speicher für eine bestimmte Zeit
gehalten, damit nicht mit jedem Programmaufruf die Library erneut
geladen werden muß.
12
Scheduling Server
Es gibt zeitgesteuerte Ereignisse wie Notification (Mitteilung, wenn eine Activity
zu lange in Bearbeitung ist) oder Expiration (Weiternavigation nach einer
bestimmten Zeit).
Diese Ereignisse werden in einer Tabelle gesammelt.
Der Scheduling Server ermittelt regelmäßig die Ereignisse, die in der
Vergangenheit liegen. Für jedes Ereignis wird eine Message an den Execution
Server geschickt, der dann die notwendigen Aktionen ausführt.
Cleanup Server
Das Löschen von Prozessen läuft in drei Schritten ab:
1. Der Cleanup Server ermittelt dir Prozesse, die gelöscht werden sollen. Den
Execution Server wird eine Liste dieser Prozesse geschickt. Dieser Schritt kann
auch über ein API angestoßen werden.
2. Der Execution Server identifiziert alle Records, die gelöscht werden sollen und
markiert sie als Deleted.
3. Der Cleanup Server löscht alle Records, die im Status Deleted sind.
Workflow API
Die eigentliche Benutzerschnittstelle. Basis ist ein C-API, auf dem alle anderen
APIs aufbauen. Folgende Kategorien gibt es:
Prozessnavigation
Starten von Prozessen und Programmen
Prozessadministration
Status des Prozesses, Verändern des Prozessstuses.
Listen Basis zur Anzeige von Worklisten.
Container API
Zum Zugriff auf Containerfelder von einem Programm aus.
Web Client
Siehe auch Kapitel über Web-basierte Anwendungen oben.
Der Web Clientsetzt auf das Java API auf. Die Darstellungssicht ist über JSP (Java
Server Pages) programmiert.
Session Handling geschieht über Cookies im Browser und die Services des
Application Servers.
Buildtime
Modellierungskomponente
Kapitel 2. Funktionale Struktur eines Workflow-Systems
13
Workload Management
Plattformen für geschäftskritische Anwendungen bieten ein Workload Management
an. Hier werden Ziele für Durchsatz, Antwortzeiten und Prioritäten definiert.
Workload Management steuert das System dann so, daß diese Ziele möglichst
erreicht werden. Bei dem Workflow-System wurde dies auf z/OS umgesetzt.
Aufgaben des Administration Servers werden hier von Workload Management
übernommen.
Aufgaben
1. Der Schedulingserver hat einen Konfigurationsparameter: die Zeit, die
zwischen zwei Queries zum Ermitteln der aktuellen Ereignisse liegt.
a. Welche Kriterien sind relevant bei der Frage, wie lang dieses Intervall sein
sollte ?
b. Welche andere Lösungen wären möglich, um diesen Konflikt zu entschärfen
?
2. Für diese Aufgabe betrachten wir im Detail, was im Execution Server abläuft,
wenn ein Workitem im Zustand Ready selektiert wird und dadurch die
assoziierte Activity gestartet wird.
Wir nehmen an, diese Transaktion läuft wie folgt ab: Der Client-Request enthält
neben der Aktion Start Workitem die Id des Workitems. Der Reihe nach werden
folgende Records gelesen, um ihre Stati zu ändern: Als erstes wird der
Workitem-Record gelesen um daraus auch die Activity zu ermittlen. Diese wird
dann in einem zweiten Schritt gelesen. Zuletzt werden dann die restlichen
Workitems dieser Activity gelesen. Das eigene Workitem und die Activity
werden in den Status Running und alle anderen Workitems in den Zustand
Disabled gesetzt.
a. Überlegen Sie sich, welches Problem auftreten kann, wenn quasi gleichzeitig
zwei verschiedene Workitems einer Activity gestartet werden.
b. Überlegen Sie sich eine Lösung des Problems.. Hinweis: Datenbankrecords
können auch ohne Setzen eines Locks (uncommitted read) gelesen werden.
14

Workflow, Business Process Management, 2.Teil

Transcription

Documents pareils

SQL-Server Administrator (m/w)

Die Fakten zu Ramco Systems

Steckbrief DataManagement

Fehlermeldungen beim DSL

WMS - Workflowmanagement System | 4whatitis

12 msuServer

NEWBASE Print Systemvoraussetzungen

Wiederherstellen von Dateien, welche versehentlich - fraLine