OpenM2 Zusatzinfo 2 - Workflow

Aus openM2-Wiki
Wechseln zu: Navigation, Suche


openM2


Zusatzinformation Teil 2
Der Workflow


Version 2.3.1


Klagenfurt, 10. April 2007


trinitec IT Solutions & Consulting GmbH


Lakeside B01
9020 Klagenfurt
Austria | Europe


http://www.trinitec.at


Inhaltsverzeichnis


Versionsprotokoll
Dieses Dokument ist unter Versionskontrolle. Jeder Änderung, die sich auf den Inhalt bezieht bzw. diesen maßgeblich verändert, muss ein Eintrag in die folgende Tabelle und die Inkrementierung der Versionsnummer der Titelseite und in der Fußzeile folgen.
Die Änderungen müssen für alle Parteien transparent und nachvollziehbar bleiben und können nur bei gegenseitiger Übereinstimmung erfolgen.


Version Bearbeitet von Bis Abgenommen von am Bemerkung
1 Horst Pichler 06.03.01 Urversion
2 Horst Pichler 24.04.01 Update; FAQ
3 Horst Pichler 03.05.01 Neue FAQ
4 Horst Pichler 05.09.02 Ergänzungen für V2.3

Version 1
Die Urversion der Dokumentation des Workflows für openM2 Version 2.2.
Version 2
Zusätzliches Kapitel 2.2.7, Workflow abbrechen: wie, wer, wann.
Zusätzliches Kapitel 4.6, welches notwendige Änderungen im Formular-Customizing beschreibt.
Zusätzliches Kapitel 5, welches FAQs für den Workflow-Bereich anbietet.
Version 3
Neue FAQs
Version 4
Allgemeine Fehlerkorrekturen.
Allgemeine Ergänzungen.
Zusätzliches Kapitel 6, welches Erweiterungen und Änderungen von 2.2 auf 2.3 beschreibt.


Workflow Allgemein

Die hier angeführten Begriffe wurden sinngemäß aus dem Paper: „Workflow Management Coalition - Terminology & Glossary" übernommen (dieses und andere Dokumente sind beim Autor erhältlich).


Geschäftsprozess (Business Process)

Definiert Abläufe, Zusammenhänge und Teilnehmer von Aktivitäten, welche meist im Kontext einer Organisationsstruktur zu sehen sind. Vor der Erstellung einer Prozessdefinition müssen die betroffenen Geschäftsprozesse analysiert werden.


Beispiel: Bearbeitungsschritte und Datenflüsse der Auftragsabarbeitung innerhalb einer Firma: wer ist in welchem Bearbeitungsschritt beteiligt und welche Aktivitäten sollen innerhalb dieser Schritte durchgeführt werden.
Download attachments 65929244 image039.gif


Prozessdefinition (Process Definition)

Die Repräsentation eines Geschäftsprozesses in einer Form, die einer Automatisierung des Prozesses entgegenkommt. In openM2 wird dieser mittels XML definiert.


Anmerkung: Derzeit gibt es noch keinen einheitlichen Standard für die Definition von Geschäftsprozessen. Praktisch jede Software-Firma, welche sich mit Workflow beschäftigt, entwickelte ihre eigene proprietäre Definitions-Sprache, welche genau auf die Anforderungen des jeweiligen Produkts ausgelegt ist. Dies gilt auch für openM2.


Prozessdefinitionen können auf verschiedenste Weise in grafischer Form dargestellt werden. Die Verwendung von Darstellungsformen, wie z.B. Ablauf-, Fluss- oder State/Transition-Diagrammen wird hiermit wärmstens empfohlen.
Download attachments 65929244 image006.gif


Anmerkung: Es gibt übrigens unzählige Tools mit deren Hilfe man Geschäftsprozesse grafisch definieren kann (z.B. Rational Rose, ARIS, ...), es existiert jedoch noch kein Werkzeug um daraus openM2-Workflow-Definitionen zu generieren.


Workflow Instanz (Workflow Instance, Process Instance)

Beim Start eines Workflows wird eine neue Workflow-Instanz gebildet. D.h. es können auf Grund einer Prozessdefinition beliebig viele Workflow-Instanzen laufen. Jede dieser Instanzen ist unabhängig von den anderen (eigener Status). Eine Instanz hält die Daten, welche für das Weiterleiten notwendig sind.


Achtung: Wenn von „dem Workflow" die Rede ist, ist meist eine Workflow-Instanz gemeint.


Workflow Status (Process State, Workflow State)

Definierter Status, welchen eine Instanz haben kann, z.B. initiated, running, suspended, completed, aborted, etc. Dieser Status ist für einen Teilnehmer normalerweise nicht von Interesse. Er dient der Workflow-Engine zur Steuerung von Instanzen. ACHTUNG: Workflow State'C'openM2 State.


Workflow Aktivität (Activity, Step, Task)

Ein definierter Teil (Schritt) der Arbeit, welche in der Prozessdefinition beschrieben ist. Dieser wird von einem Workflow-Teilnehmer ausgeführt, z.B. ‚Akt übernehmen und abstempeln'. Aktivitäten entsprechen den Kästchen in einem Ablaufdiagramm.


Workflow Teilnehmer (Workflow Participant, Agent)

Sind Personen (Benutzer) oder Applikationen, die im Zuge eines Workflows eine Aktivität ausführen, bzw. in irgendeiner anderen Form beteiligt sind.


Work Item (Work Object)

Repräsentation einer Workflow-Instanz für einen bestimmten Teilnehmer. Wird meist in sogenannten Work-Lists angezeigt.


Beispiel: Benutzer A hat derzeit 15 verschiedene Workflow-Instanzen zugewiesen bekommen, wobei er je nach Fortschritt unterschiedliche Aktiväten auszuführen hat. Diese werden als 15 Work-Items in seiner Work-List dargestellt. Wenn er mit der Bearbeitung eines Work-Items fertig ist, teilt er dies der Workflow-Engine mit, welche die betroffene Instanz entsprechend weiterbearbeitet (z.B. weiterleiten). Danach bleiben ihm noch immer 14 Work-Items zur Bearbeitung.


Workflow Engine

Der Kern eines Workflow-Systems. Führt alle notwendigen Aktivitäten durch, die während eines Workflows zu bewältigen sind:


  • Verwaltung der diversen (aktiven) Workflow-Instanzen.
  • Ausführung der notwendigen Workflow-Operationen (weiterleiten, notifizieren, ...).
  • Verwaltung von Workflow-Kontrolldaten (zum Beispiel Daten und Status einer Instanz).

Notifikation (Notification)

Darunter versteht man die Benachrichtigung von Workflow-Teilnehmern bei bestimmten Workflow-Ereignissen (z.B. Weiterleiten).


Verzweigungen, Transitionen (Transitions)

Dies sind die „Kontrollstrukturen" eines Workflows. Transitionen werden in der Workflow-Definition verwendet und beschreiben mögliche Übergänge zwischen Aktivitäten. Mögliche Kontrollstrukturen sind u.a. Sequenzen, bedingte Verzweigungen oder Alternativen. Anmerkung: Transitionen definieren die Linien zwischen Aktivitäten in einem Ablaufdiagramm.


Modellierungs-Zeit (Build-Time)

Das ist jener Zeitraum, in dem eine Workflow-Definition erstellt wird.


Lauf-Zeit (Run-Time)

Das ist jener Zeitraum, in dem eine Workflow-Instanz aktiv ist (vom Start bis zum Abschluss eines Workflows).


Elemente des Workflows in openM2

openM2-Objekte im Workflow-Kontext

Workflow-Vorlage (Workflow-Template)

Entspricht der Prozessdefinition. Die Workflow-Vorlage enthält eine Definition eines Workflows in XML. Sie beschreibt die einzelnen Schritte (Aktivitäten) in sogenannten STATE, welche u.a. Informationen darüber enthalten in welcher Reihenfolge ein BusinessObject an wen weitergeleitet werden kann, wer Referenzen erhält, welche openM2-Rechte zu welchem Zeitpunkt auf das Objekt vergeben werden u.v.m. Ein einfaches Beispiel mit drei STATEs:


Download attachments 65929244 image008.gif


Workflow (Workflow-Object)

Entspricht der Workflow- bzw. Prozess-Instanz. Es ist das "Kontroll"-Objekt der Instanzierung eines bestimmten Workflows. Es werden u.a. folgende Informationen von einer Instanz verwaltet:


  • Welches Objekt soll weitergeleitet werden?
  • Wer besitzt dieses Objekt derzeit?
  • In welchem STATE befindet sich die Instanz?
  • Wann wurde die letzte Aktion durchgeführt?

Dieses Objekt wird für einen Workflow-Teilnehmer im Normalfall nicht von Interesse sein.
!image043.gif|width=455,height=314!Jedesmal wenn ein Workflow mit einem beliebigen openM2-Objekt auf Grund einer Workflow-Vorlage eingeleitet wird, so wird ein Workflow-Objekt erzeugt, welches die Status-Informationen für den Workflow dieses einen openM2-Objekts hält.


Business-Object (Forward-Object)

Ein beliebiges openM2-Objekt welches im Zuge eines Workflows weitergeleitet wird; wird auch als Forward-Object bezeichnet. Es gibt keine wirkliche Entsprechung im WfMC-Glossar. Am ehesten könnte man es, wenn es bei einem Teilnehmer liegt, mit einem Work-Item vergleichen.


„Der Workflow in openM2 ist Objekt-zentriert!"


D.h. dieses eine Objekt (inklusive allen Subobjekten) wird im Zuge eines Workflows in andere Ablagen verschoben, seine Rechte werden entsprechend der Definition angepasst, etc.


Stationen eines Workflows in openM2

Erstellen einer Workflow-Definition

Auf Grund der Analyse eines Geschäftsprozesses wird eine Workflow-Definition erstellt. Wie bereits erwähnt, basiert diese Definition auf XML und muss außerdem gewissen syntaktischen und semantischen Vorschriften (abhängig von der jeweiligen openM2-Version) genügen. Die Erstellung erfolgt außerhalb von openM2 in einem beliebigen Texteditor oder Tool (z.B. XML-Spy).


Anlegen einer Workflow-Vorlage

  1. Anlegen eines Objekts vom Typ Workflow-Vorlage inkl. Upload der XML-Definition zu dieser Workflow-Vorlage.
  2. Vergeben von Rechten auf die Workflow-Vorlage (wer soll überhaupt Workflows mit dieser Vorlage sehen und dadurch auch starten können).

Anmerkung: Zu diesem Zeitpunkt werden noch keine Überprüfungen durchgeführt, d.h. die Workflow-Vorlage wird nicht daraufhin geprüft, ob alle angegebenen Benutzer oder States existieren, die angegebenen Rechte korrekt sind, etc. Dies geschieht erst beim Starten oder Weiterleiten.


Workflow-Objekt: Verbindung einer Workflow-Vorlage mit einem openM2-Objekt

Normalerweise wählt der Benutzer beim Starten eines Workflows die Workflow-Vorlage, auf Grund derer das Forward-Object weitergeleitet werden soll (siehe „Starten eines Workflows"). Dadurch wird ein Workflow-Object (Workflow-Instanz) erzeugt, welches die notwendigen Statusinformationen verwaltet und die Verbindung zwischen einer Workflow-Vorlage und einem openM2-Objekt darstellt.
Image011.gifImage044.gifDownload attachments 65929244 image015.gif


Die Informationen des Workflow-Object sind über den Link „Aktueller Status" eines weitergeleiteten Objektes erreichbar (siehe Abbildung). [ Anmerkung: Die Metadaten eines Objekts werden nur angezeigt wenn im Benutzerprofil „erweiterte Informationen anzeigen" aktiviert ist. Bei Formular-Objekten sind diese jedoch meist deaktiviert.] Aus dem Objekt-Pfad in der Abbildung ist zu ersehen, dass das Workflow-Object unter dem Forward-Object gespeichert wird.


Anmerkungen:


  • Informationen zu Fehlern im Workflow, können über den Link „Protokoll-Datei" angesehen werden. Die Protokolldatei selbst wird im openM2 Webverzeichnis unter .../workflow/log/ gespeichert.
  • Tritt bereits im ersten Schritt ein Fehler auf, so wird das Attribut „Aktueller Status" auf den Wert UNDEFINED gesetzt. In diesem Fall scheint beim Forward-Object weiterhin der Button „Workflow Starten" auf.

!image017.gif|width=407,height=275!In Formularvorlagen und für Formular-Ablagen gibt es zusätzlich die Möglichkeit eine fixe Workflow-Vorlage für einen Formulartyp festzulegen.
Wird ein Workflow mit einem Objekt eines solchen Typs gestartet, so wird automatisch die angegebene Workflow-Vorlage gewählt. Um zu prüfen welche Workflow-Vorlage bei einem bestimmten Forward-Object den Verlauf des Workflows bestimmt, kann die Info-Ansicht des Workflow-Object konsultiert werden (siehe oben).


Starten eines Workflows

Ein Workflow kann derzeit auf drei verschiedene Arten gestartet werden:


Start durch Import

Bei einem Import eines Objekts wird automatisch ein Workflow ausgelöst wenn die folgenden Bedingungen zutreffen:


  1. Das importierte Objekt ist ein Formular.
  2. Es wird in eine Formularablage importiert.
  3. Der Formularablage ist eine Workflow-Vorlage zugeordnet.
  4. Die Option „Workflow Starten bei Import in eine Formularablage" wurde in der Importmaske aktiviert.

In diesem Fall wird nach dem Import des Objekts sofort der durch die angegebene Workflow-Vorlage definierte Workflow gestartet.


Start über einen Service-Point

Bei einem Service-Point kann wie bei Formularablagen eine Formularvorlage und eine Workflow-Vorlage angegeben werden. Wenn man einen Service-Point anklickt, so wird ein neues Formular erzeugt und dieses in der Bearbeiten-Ansicht angezeigt. Der Benutzer kann dieses Formular nun ausfüllen. Klickt er auf OK wird es gemäß der im Service-Point definierten Workflow-Vorlage weitergeleitet.


Start über den „Workflow Starten"-Button

Über den „Workflow Starten"-Button können openM2-Objekte in einen Workflow gebracht werden. Wann scheint dieser Button auf, nur ...


  • ... in der Info-Ansicht von Objekten
  • ... wenn der Benutzer die Rechte-Kombination Lesen/Löschen/Bearbeiten/Verteilen auf dieses Objekt besitzt
  • ... bei folgenden Objekt-Typen : Ablage, Datei, Dokument, Dokument-Ablage, Formular, Formular-Ablage, Hyperlink, Notiz, Termin, Terminplan [tri: Diese Objekt-Typen werden auch als „workflow-enabled" bezeichnet]

Sollte es sich beim Objekt nicht um ein Formular mit bereits vordefinierter Workflow-Vorlage handeln, so erscheint der Dialog zur Auswahl der Workflow-Vorlage, auf Grund welcher das Objekt weitergeleitet werden soll.
!image019.gif|width=469,height=288!In der Auswahlliste sind nur jene Workflow-Vorlagen zu sehen, auf welche der jeweilige Benutzer Lese-Rechte hat. Bei Formularen mit vordefinierten Workflow-Vorlagen wird der Workflow sofort eingeleitet - ohne diesen Dialog anzuzeigen.


Workflow „Weiterleiten"

Nachdem der Workflow gestartet wurde, wird das Objekt, gemäß Workflow-Vorlage, zu jenem STATE weitergeleitet, welcher als STARTSTATE angegeben wurde. Das Objekt wird in die bei RECEIVER-DESTINATION angegebene Ablage verschoben und bekommt einen neuen „Besitzer" - den RECEIVER dieses STATEs. Nur dieser Besitzer hat nun die Möglichkeit das Objekt weiterzuleiten. Der Button „Weiterleiten" findet sich wiederum nur in der Info-Ansicht. Weitergeleitet wird zu jenem STATE, der als NEXTSTATE angegeben wurde.


„Workflow Abschließen"

Abgeschlossen ist ein Workflow der einen END-STATE erreicht hat. Das Objekt, welches weitergeleitet wurde, hat die Zielablage erreicht und es kann (falls erwünscht) ein neuer Workflow eingeleitet werden - d.h. der „Workflow Starten" Button ist wieder verfügbar. Der Button „Workflow Abschließen" scheint in der Info wiederum nur für den Besitzer und außerdem nur dann auf, wenn der NEXTSTATE des letzten STATEs mit END gekennzeichnet wurde. Bei END-NOCONFIRM entfällt dieser Schritt, in diesem Fall wird der Workflow automatisch abgeschlossen.
Download attachments 65929244 image021.gif


„Workflow Abbrechen"

Falls ein Objekt versehentlich in einen Workflow eingeleitet wurde, so kann dieser durch den Prozess-Administrator abgebrochen werden. Für den Prozess-Administrator scheint der Button „Workflow Abbrechen" in der Instanzen-Information auf. Nach dem Abbruch kann ein neuer Worfkflow gestartet werden.


Interner Workflow Lebenszyklus

[Anmerkung: Für Benutzer und Administratoren nicht relevant.]


Interner Workflow-Status

!image046.gif|width=353,height=306!Der Workflow-Status dient der Verwaltung eines Workflows und wird nur intern genutzt.


Ein openM2-Workflow durchläuft normalerweise folgende Prozess-Stati:


open.notRunningNotStarted Neue Instanz erzeugt


open.running Instanz ist in einem State


open.runningLastStateReached Instanz hat letzten State erreicht
[tri:Nicht im WfMC Standard]


closed.completed Workflow ist abgeschlossen


Ausnahme-Stati

Außerdem kann eine openM2-Workflow-Instanz noch in folgende Stati geraten:


closed.aborted Abbruch durch Benutzer (‚Workflow Abbrechen')


closed.terminated Abbruch durch Fehler
[tri:Noch nicht implementiert]


open.notRunning.suspended Durch Benutzer angehalten; Workflow-Instanz pausiert
[tri:Noch nicht implementiert]


Wie stellt es sich dem Benutzer dar?

Welche Buttons sind bei einem (weitergeleiteten) BusinessObject zu sehen:


kein Status oder UNDEFINED'==>'Button "Workflow Starten"
Der Button scheint prinzipiell nur dann auf, wenn das Objekt „workflow-enabled" ist.


open.running'==>'Button "Weiterleiten"
Aktive Workflow-Instanz zum Objekt existiert bereits (z.B. 2. Schritt im Workflow). Dieser Button wird nur dem „current owner" angezeigt, also dem Benutzer, welcher der aktuelle RECEIVER ist.


open.running.lastStateReached'==>'Button "Workflow beenden"
Alle Schritte des Workflows wurden durchgeführt. Der letzte Benutzer muss das Objekt aus dem Workflow lösen. Dieser Button wird nur dem „Current Owner" (RECEIVER im END-STATE) angezeigt.


closed.completed'==>'Button "Workflow starten"
Workflow wurde beendet, es kann ein neuer gestartet werden.


closed.aborted'==>'Button „Workflow starten"
Workflow wurde durch den Prozeß-Administrator abgebrochen, es kann ein neuer gestartet werden.


Teilnehmer im Workflow

Im Kontext eines openM2-Workflow können verschiedene Arten von Teilnehmern unterschieden werden:


Starter
Der Benutzer, welcher den Workflow gestartet hat.


Processmanager
Der Benutzer, welcher den Workflow verwaltet. Dieser besitzt die Möglichkeit den Workflow abzubrechen, muss im Fehlerfall einschreiten, etc.


Current Owner
Der Benutzer, welcher das weiterzuleitende Objekt erhalten hat. Das entspricht dem jeweils dem aktuellen Receiver eines States. Wichtig: Der Current Owner ist nicht identisch mit dem openM2-Eigentümer eines Objekts. Der Current Owner bezeichnet nur den Benutzer, dem das Objekt in diesem Moment physisch zugeteilt wurde, mit genau den Rechten, welche für im RECEIVER-Tag definiert wurden. Der openM2-Eigentümer dagegen hat weiterhin alle Rechte auf das Objekt.


Receiver
Der Benutzer, welcher den Workflow in einem State erhält. Sobald er das Objekt erhalten hat ist der Receiver auch der Current Owner.


CC-Receivers
Alle Benutzer für welche in einem state eine Referenz auf das weitergeleitete Objekt erzeugt wird.


Others
Alle Benutzer, welche schon vor dem Start des Workflows eine Referenz oder Rechte auf das Weiterzuleitende Objekt hatten.


System-User
Dies ist ein interner Benutzer, welche eigentlich nur dem System bekannt sein sollte. Beim Starten eines Workflows wird dieser Benutzer openM2-Eigentümer des weitergeleiteten Objekts. In dieser Eigenschaft hat er als einziger weiterhin alle Rechte auf das Objekt. Wichtig: Nicht mit dem Current Owner verwechseln. Auf Grund einer „Notlösung" ist derzeit der Benutzer „Administrator" dieser System-User.


Rechte im Workflow

In einer Workflow-Definition können für die unterschiedlichen Teilnehmer openM2-Zugriffsrechte definiert werden. Diese Rechte beziehen sich immer auf das weitergeleitete Objekt.


Rechte-Aliases

Die in einer Workflow-Definition verwendeten Rechte-Aliases sind Kombination von openM2-Rechten. Derzeit sind 5 Alias-Rechte definiert:


Alias openM2 Rechte
NONE keine
READ view, read, viewelems
CREATE view, read, viewelems
new, addelems
CHANGE view, read, viewelems
new, addelems
change
CHANGEDELETE view, read, viewelems
new, addelems
change
delete, delelem
ALL alle ausser „Rechte verwalten"

Wie und wo diese Rechte in der Definition angewendet werden können, wird in einem späteren Kapitel erläutert.


[Anmerkung: Aliases können bei Bedarf durch einen Administrator mit DB-Zugang frei definiert werden (DB-Einträge in Tabelle ibs_RightsMapping). Z.B. hat der Workflow-Rechte-Alias CREATE fünf Einträge in ibs_RightsMapping:
CREATE'==>'READ
CREATE'==>'VIEW
CREATE'==>'VIEWELEMS
CREATE'==>'NEW
CREATE'==>'ADDELEMS
Es ist natürlich auch möglich beliebig neue Aliases zu definieren, indem man diese in die Tabelle einträgt.]


Möglichkeiten Rechte zu beeinflussen

Beim Start des Workflows

Im Workflow-Header können durch die folgenden Attribute Rechte gesetzt werden:


  • REMAINRIGHTSOTHERS: Jene Rechte, die allen Benutzern bleiben, welche vor dem Start des Workflows bereits Rechte auf das Objekt besaßen.
  • REMAINRIGHTSSTARTER: Jene Rechte, die dem Benutzer der den Workflow eingeleitet hat nach dem Start des Workflows bleiben.
  • MANAGERRIGHTS: Jene Rechte die für Benutzer der als Prozeß-Manager eingetragen wurde gesetzt werden.

Achtung: Rechte welche beim Start gesetzt werden, können durch die spätere Verwendung von RIGHTS und REMAINRIGHTS wieder überschrieben werden.


Beim Weiterleiten

Für RECEIVER und CC können pro STATE Rechte über RIGHTS und REMAINRIGHTS verändert werden:


  • RIGHTS definiert jene Rechte, welche gesetzt werden, wenn der Workflow einen STATE betritt.
  • REMAINRIGHTS definiert jene Rechte, welche gesetzt werden, wenn der Workflow einen STATE verläßt.

Achtung: REMAINRIGHTS eines END-STATEs werden beim Abschliessen des Workflows derzeit nicht gesetzt (Fehler oder Feature?).


Transitionen

Derzeit gibt es drei Kontrollstrukturen, durch welche STATEs verbunden sein können:


SEQUENZ
Bei einer TRANSITION vom Typ SEQUENCE kann genau ein NEXTSTATE angegeben werden. Zwei STATEs sind sequentiell verbunden, wenn man ausgehend vom vorhergehenden NUR den nachfolgenden STATE (mittels „Weiterleiten") erreichen kann.


ALTERNATIVE
Bei einer TRANSITION vom Typ ALTERNATIVE können beliebig viele NEXTSTATEs angegeben werden. Beim Weiterleiten hat der aktuelle Benutzer zu entscheiden (Eingabe über openM2-GUI), zu welchem NEXTSTATE verzweigt werden soll.


CONDITIONAL
Eine TRANSITION vom Typ CONDITIONAL bezeichnet eine bedingte Verzweigung. Es können beliebig viele NEXTSTATES jeweils in Verbindung mit einer Bedingung (IF-Block) angegeben werden. Es wird zu jenem NEXTSTATE verzweigt, dessen Bedingung zutrifft. Wenn keine Bedingung zutrifft, wird zum angegebenen DEFAULT NEXTSTATE verzweigt.
Image048.gif


AD-HOC Benutzerauswahl

Durch die AD-HOC Benutzerauswahl ist es möglich die Wahl des RECEIVERs dem weiterleitenden Benutzer zu überlassen. Dadurch die Wahl des RECEIVERs eines STATEs flexibler gestaltet werden. Es ist möglich die Auswahl auf bestimmte Gruppen und Benutzer einzuschränken. Ausgewählt werden kann genau ein RECEIVER.
Image049.gif


Notifikation

In jedem STATE können mit Hilfe von NOTIFICATIONS Angaben darüber gemacht werden, welche Benutzer wie benachrichtigt werden sollen, wenn der Workflow in diesen STATE eintritt. Die Art der Benachrichtigung hängt davon ab, was im Benutzer-Profil des jeweiligen Benutzers eingestellt ist (SMS, Mail, openM2-Benachrichtigung).


Variablen

Es ist möglich (für manche Funktionalitäten sogar notwendig) Variablen im Workflow zu deklarieren. Unter einer Variable versteht man einen „Platzhalter", der repräsentativ für einen bestimmten Wert in der Definition verwendet werden kann. Der Wert dieser Variablen ist (meist) nicht konstant, sondern kann sich im Verlauf des Workflows ändern. Wo und wie diese Variablen im Details angewendet werden können wird im Definitions-Teil beschrieben. Prinzipiell wird zwischen zwei Arten von Variablen unterschieden:


Benutzerdefinierte Variablen

Jede benutzerdefinierte Variable, die in der Definition verwendet wird, muß am anfangs definiert und initialisiert werden. Sobald ein Workflow mit dieser Definition gestartet wird, wird jede Variable persistent (in der DB) angelegt, d.h. sie ist über die diversen STATEs hinweg verfügbar. Benutzerdefiniert Variablen werden innerhalb der Definition folgendermaßen angegeben: #VARIABLE.<name># , für eine Variable namens var bedeutet dies also #VARIABLE.var# . Dort wo sie angewendet werden, wird im Prinzip ihr Wert, der beliebig sein kann, durch den Inhalt der Variable ersetzt.


Run-Time Variablen (Kontext-Konstanten)

Darunter versteht man vorgegebene Variablen, deren Wert nicht vom Benutzer festgelegt wird, sondern durch den vorgegebenen Workflow-Kontext automatisch gesetzt wird. Die folgenden Run-Time Variablen sind derzeit möglich:


  • #STARTER# bezeichnet den Benutzer, der den Workflow gestartet hat.
  • #PROCESSMANAGER# bezeichnet den Benutzer der als Prozeßmanager festgelegt wurde.
  • #STARTERCONTAINER# bezeichnet die Ablage aus der Workflow gestartet wurde.
  • #PROCESSMANAGERCONTAINER# bezeichnet die Ablage die als Prozeßmanager-Ablage definiert wurde.
  • #RECEIVER# bezeichnet den aktuellen RECEIVER eines STATEs
  • #CCs# bezeichnet alle aktuellen CC-Receiver eines STATEs
  • #ADHOC# bezeichnet einen Ad Hoc-ausgewählten Benutzer

Actions

Unter ACTIONs versteht man im Operationen, welche beim Eintritt in einen STATE ausgeführt werden und mit Hilfe derer man die Werte von Variablen setzen, bzw. beliebige (auszuprogrammiernde) Aktivitäten ausführen kann. Derzeit gibt es drei ACTION-Typen, welche beliebige aneinandergereiht und kombiniert werden können:


XPATH

XPATH ist ein ein definierter Standard um Werte aus XML-Formularen lesen zu können. Mit Hilfe einer XPATH-ACTION ist es in einem openM2 Workflow möglich Daten aus weitergeleiteten Formularen auszulesen. Dazu muß die Struktur des weitergeleiteten Formulars bekannt sein.


Beispiel: /OBJECT/VALUES/VALUE[tri:@FIELD='Filialnr']


Dieser XPATH-Ausdruck adressiert das Feld „Filialnr" in einem openM2-(XML)Formular. Über die XPATH-Action kann der Wert dieses Feldes ausgelesen und in einer VARIABLE gespeichert werden. Der Ausdruck muss derzeit immer ein einzelnes Feld adressieren.


Für Details zur XPATH-Adressierung in XML-Dokumenten sind entsprechende Bücher und Online-Dokumente heranzuziehen.


Anmerkung: Natürlich kann ein Workflow mit einer XPATH-Action nur mit openM2-Objekttypen verwendet werden, für welche der angegebene XPath auch gültig ist. Dies wird nicht abgeprüft und kann bei falscher Verwendung zu Fehlern beim Weiterleiten führen.


QUERY

Die QUERY-ACTION ist eine Schnittstelle zu einem openM2 Query-Object. Die QUERY-ACTION führt einen Datenbank-Zugriff aus und schreibt die angegebenen Werte des Ergebnisses in die definierten VARIABLEn.


Das Ergebnis der QUERY-ACTION muss genau eine Zeile sein, anderenfalls wird ein Fehler ausgegeben. Der Grund dafür liegt in der Notwendigkeit der eindeutigen Zuordnung des Ergebnisses zu den Variablen.


Anmerkung: Wenn eine neue Query ins System eingebracht wurde, muß der Web-Server neu gestartet werden. Grund: Der Query-Pool wird reinitialisiert. Wenn dies nicht geschieht, wird die Query vom Workflow nicht gefunden was in einem Fehler beim Weiterleiten resultiert.


INTERNALCALL

Die INTERNALCALL-ACTION ist eine Schnittstelle zu Java-Methoden, welche zu diesem Zweck eigens für einen openM2-Typ implementiert werden müssen.


Innerhalb dieser Java-Methode kann prinzipiell alles was mit Java machbar ist, ausgeführt werden. Dadurch wird diese Schnittstelle ziemlich mächtig.


Anmerkung: Natürlich kann ein Workflow mit einer INTERNALCALL-Action nur mit openM2-Objekttypen verwendet werden, für welche die angegebene Methode auch nach den vorgegebenen Richtlinien implementiert wurde. Dies wird nicht abgeprüft und kann bei falscher Verwendung zu Fehlern beim Weiterleiten führen.


Protokollierung und Augabe

DISPLAYLOG

Normalerweise werden die Workflow-Operationen, die während des Weiterleitens passieren dem Benutzer zur Ansicht gebracht.


Image028.gif
Dieses Ausgabe kann durch das Attribut DISPLAYLOG im Workflow-Header beeinflusst werden. Wenn DISPLAYLOG="NO" gesetzt wird, erfolgt keine Ausgabe von Detailinformationen, sondern nur „Eine Workflow-Operation wurde eingeleitet. Bitte warten."


CONFIRMOPERATION

Normalerweise wird nach der Durchführung einer Workflow-Operation eine Nachrichten-Box ausgegeben, welche über den Erfolg oder den Mißerfolg der Operation Auskunft gibt.
Image030.gif


Die Anzeige dieser Box kann durch das Attribut CONFIRMOPERATION im Workflow-Header beeinflusst werden. Wenn CONFIRMOPERATION ="NO" gesetzt wird, wird nicht auf die Bestätigung des Benutzer gewartet.


WRITELOG

!image032.gif|width=353,height=306!Normalerweise werden die Workflowoperationen inkl. zugehörigen Detailinformationen in einer Protokolldatei mitgeschrieben.


Diese Protokolldatei kann über die Workflow-Informationen eingesehen werden. Ist die Protokollierung in eine Datei nicht erwünscht so kann diese über WRITELOG="NO" im Header deaktiviert werden.


Anmerkung: Die Protokolldatei selbst wird im openM2 Webverzeichnis unter .../workflow/log/ gespeichert.


Workflow Definition

Eine Workflow-Beschreibung wird mittels XML definiert und besteht derzeit im wesentlichen aus drei Teilen:


  1. einem Header,
  2. der Variablen-Definition
  3. und einer Liste von STATEs, welche die einzelnen Schritte beschreiben.

Einführungsbeispiel:
Beschreibt einen Workflow mit 3 Schritten. Es wird jeweils ein Empfänger (RECEIVER) angegeben, zu dem das Objekt verschoben wird. [Anmerkung: Dieses Beispiel enthält nicht alle möglichen TAGs]
Header
Download attachments 65929244 image033.gif
Variablen
Definition
Image034.gifDownload attachments 65929244 image035.gifDownload attachments 65929244 image036.gif


Prinzipielle Konzepte und Anforderungen


  • Der Workflow-Header definiert Einstellungen, die beim Start des Workflows benötigt werden, bzw. während des ganzen Workflows für alle STATEs Gültigkeit haben.
  • Im Workflow-Header muß ein Prozeßmanager definiert werden (inkl. Ablage).
  • Das Attribut STARTSTATE definiert den ersten STATE der beim Start des Workflows angesprungen wird.
  • Jeder STATE muß einen Namen haben über den er eindeutig identfiziert werden kann.
  • Jeder STATE muß einen RECEIVER haben, der angibt wer die „Verantwortung" über das Weitergeleitete Objekt übernimmt.
    Anmerkung: nur der RECEIVER kann ein Objekt Weiterleiten.
  • Jeder STATE muß einen TRANSITION-Block haben, in dem die Anweisungen zu finden sind, welcher NEXTSTATE beim „Weiterleiten" angesprungen werden soll.
    Anmerkung: Die Reihenfolge in der die STATEs in der Definition stehen ist nicht von Bedeutung, sie wird nur über die TRANSITIONs bestimmt.
  • Die Workflow-Beschreibung muß mindestens einen END STATE haben (in NEXTSTATE), welcher das Ende des Geschäftsprozesses markiert.

Vorgaben für Syntaxbeschreibungen

Für Syntaxbeschreibungen der einzelnen Tags und ihrer Attribute gelten die folgenden Vorgaben:


  • Obligatorische (Muss) Einträge sind fett dargestellt
  • Optionale (Kann) Einträge sind normaldargestellt.
  • Einträge, welche überhaupt keine Auswirkung haben (informativen Charakter), sind kursiv dargestellt. Solche Einträge können beliebige Inhalte haben.
  • Drei Punkte innerhalb eines Tag-Paares, zB. <XXX> ... </XXX> bedeuten, daß Details zu diesem Tag woanders detailiert beschrieben wurden
  • Zwei identische Tag-Paare untereinander, gefolgt von drei Punkten, bedeutet, daß beliebig viele identische Tag-Paare folgen können.
  • [tri:state] kann durch einen beliebigen Statenamen dieses Workflows ersetzt werden
  • [tri:user] kann durch einen in openM2 gültigen Benutzernamen ersetzt werden
  • [tri:group] kann durch eine in openM2 gültige Gruppe ersetzt werden
  • [tri:path] kann durch einen gültigen openM2-Pfad ersetzt werden
  • [tri:alias] kann durch einen gültigen Rechte-Alias ersetzt werden
  • [tri:text] kann durch beliebige Zeichenfolgen (Zahlen, Texte, Kombination) ersetzt werden
  • [tri:number] kann durch eine beliebige Zahl ersetzt werden
  • [aaa|tri:bbb|ddd|...] kann durch aaa oder bbb oder ddd oder ... ersetzt werden
  • [semicolon-separated:type,type,...] bedeuted, daß die nachfolgenden Werte vom Typ ‚type' sein müssen und durch Strichpunkte getrennt sein müssen (ausser es ist nur einer); z.B. [semicolon-separated:user,group] könnte durch den folgenden Wert ersetzt werden: herbert;hugo;jeder
  • [tri:variable] kann durch eine benutzerdefiniert Variable ersetzt werden, z.B. #VARIABLE.var#
  • [tri:xpath] kann durch eine gültige XPath Expression ersetzt werden,
    z.B. /OBJECT/VALUES/VALUE[tri:@FIELD='Filialnr']
  • [tri:query] kann durch den Namen eines gültigen openM2-QueryObjects ersetzt werden.
  • [tri:method] kann durch den Namen einer gültigen Java-Methode ersetzt werden; muß eine Methode des weitergeleiteten Objekts sein

Tag <Workflow>

Das Workflow-Tag bildet die Klammer für den zu definierenden Geschäftsprozess, innerhalb dieser Klammer werden die notwendigen STATEs und VARIABLEn definiert. Die einzelnen Attribute definieren Eigenschaften bzw. Verhaltensweisen, die für den gesamten Workflow gelten.


Syntax

<WORKFLOW
STARTSTATE="[tri:state]"
PROCESSMANAGER="[tri:user]"
MANAGERDESTINATION="[tri:path]"


MANAGERRIGHTS="[tri:alias]"
REMAINRIGHTSSTARTER="[tri:alias]"
REMAINRIGHTSOTHERS="[tri:alias]"

WRITELOG="[YES|tri:NO]"
DISPLAYLOG="[YES|tri:NO]"
CONFIRMOPERATION="[YES|tri:NO]"


NAME="[tri:text]"
VERSION="[tri:text]"
_CREATED="[tri:text]" DESCRIPTION="[tri:text]"_
>


<VARIABLES> ... </VARIABLES>


<STATE> ... </STATE>
<STATE> ... </STATE>
...


</WORKFLOW>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
STARTSTATE Erster Schritt im Workflow
PROCESSMANAGER Wer überwacht den Workflow (bekommt eine Referenz)
MANAGERDESTINATION
Wo soll die Referenz für den Manager erzeugt werden.

Optional


ELEMENT Bemerkung
MANAGERRIGHTS
Welche Rechte soll der Prozeß-Manager auf das weitergeleitete Objekt haben
REMAINRIGHTSSTARTER
Welche Rechte soll der Auslöser des Workflows auf das weitergeleitete Objekt haben (er erhält auch eine Referenz, falls die angegebenen Rechte <> NONE sind)
REMAINRIGHTSOTHERS
Welche Rechte sollen allen Benutzern, die beim Start eine Referenz hatten auf das Objekt bleiben.
WRITELOG
Gibt an ob eine Protokoll-Datei geschrieben werden soll.
DISPLAYLOG
Sollen die Workflow-Aktionen im Browser angezeigt werden
CONFIRMOPERATION Gibt an ob Workflow-Aktionen vom Benutzer bestätigt werden müssen

Informativ


ELEMENT Bemerkung
NAME Name des Geschäftsprozesses
VERSION Versionsnummer der Definition des Geschäftsprozesses
CREATED Datum der Erzeugung dieser Definition
DESCRIPTION Beschreibung des Geschäftsprozesses

Variablenverwendung

Innerhalb des Workflow-Headers können folgende Variablen verwendet werden:


PROCESSMANAGER="# STARTER#"


MANAGERDESTINATION ="#STARTERCONTAINER#"


Anmerkung: Auf Grund einer Unzulänglichkeit ist #STARTER# als Substring in der MANAGERDESTINATION nicht zugelassen.


Tag: <VARIABLES>

Dieses Tag ist eine Klammer, innerhalb der alle in der Workflowdefinition verwendeten Variablen definiert werden müssen. Es können beliebig viele Variablen definiert werden.


Syntax

<VARIABLES>

<VARIABLE>...</VARIABLE>
<VARIABLE>...</VARIABLE>
...


</VARIABLES>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
VARIABLE Definition einer Variable, siehe unten

Variablenverwendung

Innerhalb des VARIABLES Tag dürfen/können keine Variablen verwendet werden.


Tag: <VARIABLE>

In diesem Tag wird eine Variable definiert und initialisiert, welche innerhalb der Workflowdefinition verwendet wird.


Syntax

<VARIABLE>

<NAME>[tri:text]</NAME>
<VALUE>[tri:text]</VALUE>


<TYPE>[TEXT|tri:NUMBER]</TYPE>
<LENGTH>[tri:number]</LENGTH>
<DESCRIPTION>[tri:text]</DESCRIPTION>


</VARIABLE>


Tags und Attribute


Obligatorisch


ELEMENT Bemerkung
NAME Name der Variable, sollte in diesem Workflow eindeutig sein
VALUE Initialer Wert der Variable; wird gesetzt, wenn der Workflow gestartet wird.

Informativ


ELEMENT Bemerkung
TYPE Der Typ der Variable; legt fest, welchen Inhalt sie haben darf, wird zukünftig von Bedeutung sein
LENGTH Die maximale Länge des VALUEs der Variable, wird zukünftig von Bedeutung sein.
DESCRIPTION Beschreibung des Variable (Sinn und Verwendungszweck)

Variablenverwendung

Innerhalb des VARIABLE Tag dürfen keine Variablen verwendet werden.


Tag: <STATE>

Ein STATE definiert alles was beim Weiterleiten eines Objektes relevant ist bzw. passieren soll.


Syntax

<STATE NAME="[tri:state]"

  • _DESCRIPTION="[tri:text]" TYPE="[tri:text]"_*
    >


<ACTION> ... </ACTION>
<ACTION> ... </ACTION>
...


<RECEIVER> ... </RECEIVER>

<CC> ... </CC>
<CC> ...</CC>
...

<TRANSITION> ... </TRANSITION>


<NOTIFICATIONS> ... </NOTIFICATIONS>


</STATE>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
NAME Name dieses STATEs; muß eindeutig sein
RECEIVER Definiert den Empfänger; siehe unten
TRANSITION Definiert den nächsten STATE; siehe unten

Optional


ELEMENT Bemerkung
ACTION
Definiert eine ACTION, die beim Eintreten in diesen STATE ausgeführt wird; ACTIONs werden in der Reihenfolge in der sie definiert wurden ausgeführt;
siehe unten
CC
Definiert einen Empfänger einer Referenz; siehe unten
NOTIFICATIONS
Definiert wer beim Weiterleiten benachrichtigt werden soll.

Informativ


ELEMENT Bemerkung
DESCRIPTION Beschreibung dieses STATEs
TYPE Typ dieses STATEs; ohne Funktion

Variablenverwendung

Innerhalb des STATE-Tags dürfen keine Variablen verwendet werden.


Tag: <ACTION TYPE="XPATH">

XPATH ist ein ein definierter Standard um Werte aus XML-Formularen lesen zu können. Für Details zur XPATH-Adressierung in XML-Dokumenten sind entsprechende Bücher und Online-Dokumente heranzuziehen. Der XPATH-Ausdruck wird auswertet (angewendet auf das weitergeleitete Objekt bzw. Formular) und das Ergebnis in eine Variable geschrieben.


Syntax

<ACTION TYPE="XPATH">


<CALL>[tri:text]</CALL>


<INPARAMS>
<PARAMETER>[tri:xpath]</PARAMETER>
<PARAMETER>[tri:xpath]</PARAMETER>
...
</INPARAMS>
<OUTPARAMS>
<PARAMETER>[tri:variable]</PARAMETER>
<PARAMETER>[tri:variable]</PARAMETER>
...
</OUTPARAMS>

</ACTION>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
TYPE XPATH
INPARAMS PARAMETER Definiert einen Input PARAMETER; muß einen XPath-Ausdruck enthalten
OUTPARAMS PARAMETER Definiert einen Output PARAMETER, muß eine benutzerdefinierte Variable enthalten



Variablenverwendung

Benutzerdefinierte Variable (#VARIABLE.var#) können in den INPARAMS XPath-Ausdrücken verwendet werden (z.B. /OBJECT/VALUES/VALUE[tri:@FIELD='#VARIABLE.fieldname#']) und müssen in den OUTPARAMS verwendet werden.


Anmerkungen

  • Die Anzahl der INPARAMS und OUTPARAMS muß gleich sein!
  • Das Mapping der INPARAMS auf OUTPARAMS wird gemäß der Reihenfolge durchgeführt, d.h.das Ergebnis des ersten INPARAMS wird in die Variable des ersten OUTPARAMS geschrieben.



Tag: <ACTION TYPE="QUERY">

Eine ACTION TYPE="QUERY" liest Daten aus der DB, wobei das im CALL angegebene Query-Object verwendet wird.


Syntax

<ACTION TYPE="QUERY">


<CALL>[tri:query]</CALL>


<INPARAMS>
<PARAMETER>[tri:variable]</PARAMETER>
<PARAMETER>[tri:variable]</PARAMETER>
...
</INPARAMS>
<OUTPARAMS>
<PARAMETER>[tri:variable]</PARAMETER>
<PARAMETER>[tri:variable]</PARAMETER>
<PARAMETER>[tri:variable]</PARAMETER>
...
</OUTPARAMS>

</ACTION>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
TYPE QUERY
CALL Name des QueryObjects, welches aufgerufen werden soll

Optional


ELEMENT Bemerkung
INPARAMS PARAMETER Definiert einen Input PARAMETER für das aufzurufende QueryObject.
OUTPARAMS PARAMETER Definiert einen Output PARAMETER

Variablenverwendung

Benutzerdefinierte Variable (#VARIABLE.var#) müssen in den INPARAMS und in den OUTPARAMS verwendet werden.


Anmerkungen

  • Die Anzahl der INPARAMS und OUTPARAMS hängt von der Definition des QUERY-Objects ab; nicht unbedingt obligatorisch
  • Die Variablen, welche in den PARAMETERs der INPARAMs angegeben werden, entsprechen den im Query-Object definierten Suchfeldern (searchfields). Mit den Werten dieser Variablen wird die angegebene Query ausgeführt und liefert das entsprechende Ergebnis. Wichtig: Der Name der Variable, welche im jeweiligen PARAMETER angegeben wird, muß mit einem der Suchfeldnamen des angegebenen Query-Objects übereinstimmen. Die Vergleichsart ist immer exakt .
  • Die OUTPARAMs entsprechen den Spaltennamen (columnames), welche im Query-Object definiert wurden. Wichtig: Der Name der Variable, welche im jeweiligen PARAMETER angegeben wird, muß mit einem der Spaltennamen des angegebenen Query-Objects übereinstimmen. Es müssen nicht alle Spaltennamen des Query-Objects als OUTPARAMs angegeben werden.

WICHTIG: Eine QUERY-ACTION muß genau eine Zeile als Ergebnis liefern, ansonsten wird ein Fehler generiert. Dies ist notwendig um ein eindeutiges Mapping des Ergebnisses auf die angegebenen Variablen zu ermöglichen.


Tag: <ACTION TYPE="INTERNALCALL">

Eine ACTION TYPE="INTERNALCALL" ruft die in CALL angegebene Java-Methode auf. Diese Methode muß für den jeweiligen Objekttyp gemäß unten angegebenen Kriterien implementiert werden.


Syntax

<ACTION TYPE="INTERNALCALL">


<CALL>[tri:method]</CALL>


<INPARAMS>
<PARAMETER>[variable|tri:text]</PARAMETER>
<PARAMETER>[variable|tri:text]</PARAMETER>
...
</INPARAMS>
<OUTPARAMS>
<PARAMETER>[tri:variable]</PARAMETER>
<PARAMETER>[tri:variable]</PARAMETER>
<PARAMETER>[tri:variable]</PARAMETER>
...
</OUTPARAMS>

</ACTION>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
TYPE INTERNALCALL
CALL Name der Java-Methode, welches aufgerufen werden soll

Optional


ELEMENT Bemerkung
INPARAMS PARAMETER Definiert einen Input PARAMETER für die aufzurufende Java-Methode
OUTPARAMS PARAMETER Definiert einen Output PARAMETER der aufzurufenden Java-Methode

Variablenverwendung

In den INPARAMS können benutzerdefinierte Variablen (#VARIABLE.var#) oder beliebige Texte (Zahlen, Zeichenfolgen, ...) verwendet werden; auch Kombinationen sind möglich z.B. „Haus Nummer #VARIABLE.nr#".


Benutzerdefinierte Variable (#VARIABLE.var#) müssen in den OUTPARAMS verwendet werden.


Anmerkungen

  • Die Anzahl der INPARAMS und OUTPARAMS hängt von der Definition der Java-Methode ab; nicht unbedingt obligatorisch
  • Das Mapping der Rückgabe-Werte auf die OUTPARAMS geschieht gemäß der Reihenfolge in der sie im Rückgabe String-Vektor angegeben werden (siehe unten).

Wichtig: Es ist darauf zu achten, daß das Weiterleiten von falschen Objekttypen bei dieser ACTION zu Fehlern führt, da in diesen die aufzurufende Java-Methode nicht implementiert wurde.


Implementierungsvorschrift

Eine von einer ACTION TYPE="INTERNALCALL" gerufene Methode muß gemäß der folgenden Definition implementiert werden:



  • The method of the given object must look like:
    *
  • public (Vector) <methodName> (Vector <paramname>);
    *
  • All parameters must be of type string. The return value is a
  • String-vector which must have 2 fixed String objects on position
  • 0 and 1:
  • position 0: errorcode (with default value "0")
  • position 1: errormessage (with default value "OK")
    *

Tag: <RECEIVER>

Innerhalb eines STATEs muß genau ein RECEIVER definiert werden. Der Receiver erhält das weitergeleitete Objekt in die angegebene DESTINATION-Ablage. D.h. das Objekt wird verschoben .


Syntax

<RECEIVER DESTINATION="[tri:path]" RIGHTS="[tri:alias]"
REMAINRIGHTS="[tri:alias]" >[tri:user]</RECEIVER>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
DESTINATION openM2-Pfad der Zielablage, in welche das Objekt weitergeleitet/verschoben wird
<RECEIVER..>[tri:user]</RECEIVER> Name des openM2-Benutzers, der der neue Eigentümer des Objekts wird

Optional


ELEMENT Bemerkung
RIGHTS Rechte, welche für den RECEIVER gesetzt werden
Default: ALL (wenn Attribut nicht angegeben wird)
REMAINRIGHTS Rechte, welche für den RECEIVER gesetzt werden, wenn der STATE verlassen wird (beim nächsten Weiterleiten)
Default: READ (wenn Attribut nicht angegeben wird)

Variablenverwendung

<RECEIVER>[tri:user]<RECEIVER>
Statt [tri:user] können auch die folgenden Variablen verwendet werden:


  • #STARTER#
  • #PROCESSMANAGER#
  • benutzerdefinierte Variablen (z.B. #VARIABLE.var#)

DESTINATION="[tri:path]"
Für [tri:path] können auch die folgenden Ausdrücke angegeben werden:


  • #STARTERCONTAINER#
  • #MANAGERCONTAINER#
  • .../#STARTER#/..., z.B. Privat/#STARTER#/Arbeitskorb
  • .../#PROCESSMANAGER#/..., z.B. Privat/#PROCESSMANAGER#/Arbeitskorb
  • .../#VARIABLE.xxx#/..., z.B. Privat/#VARIABLE.username#/Arbeitskorb

Tag: <RECEIVER> AD-HOC

Damit wird die Wahl (per Dialog) eines Empfängers (nur RECEIVER) durch den weiterleitenden Benutzer ermöglicht.


Syntax

<RECEIVER DESTINATION="[tri:path]" USERS="[semicolon-separated:user]" GROUPS="[semicolon-separated:group]" RIGHTS="[tri:alias]"
REMAINRIGHTS="[tri:alias]"
>#AD-HOC#</RECEIVER>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
DESTINATION openM2-Pfad der Zielablage, in welche das Objekt weitergeleitet/verschoben wird
USERS Namen von openM2-Benutzern, welche im Dialog zur Auswahl stehen sollen
GROUPS Namen von openM2-Gruppen, welche im Dialog zur Auswahl stehen sollen

Optional


ELEMENT Bemerkung
RIGHTS Rechte, welche für den RECEIVER gesetzt werden
Default: ALL (wenn Attribut nicht angegeben wird)
REMAINRIGHTS Rechte, welche für den RECEIVER gesetzt werden, wenn der STATE verlassen wird (beim nächsten Weiterleiten)
Default: READ (wenn Attribut nicht angegeben wird)

Variablenverwendung

DESTINATION="[tri:path]"
Für [tri:path] können auch die folgenden Ausdrücke angegeben werden:


  • #STARTERCONTAINER#
  • #MANAGERCONTAINER#
  • .../#STARTER#/..., z.B. Privat/#STARTER#/Arbeitskorb
  • .../#PROCESSMANAGER#/..., z.B. Privat/#PROCESSMANAGER#/Arbeitskorb
  • .../#VARIABLE.xxx#/..., z.B. Privat/#VARIABLE.username#/Arbeitskorb

und


  • .../#AD-HOC#/..., z.B. Privat/#AD-HOC#/Arbeitskorb, bezeichnet den Namen des Ad Hoc-gewählten Benutzers

Anmerkungen

  • Derzeit nur bei RECEIVER möglich!
  • Es darf GENAU einer ausgewählt werden!
  • USERS und GROUPS müssen durch Strichpunkte getrennt angegeben werden.
  • Es können USERS und/oder GROUPS angegeben werden, d.h. ein Tag kann weggelassen werden.
  • openM2-Rechte auf Benutzer oder Gruppen werden beim Auswahl-Dialog nicht berücksichtigt! D.h. alle angebenen Gruppen und Benutzer werden angezeigt.
    [Anmerkung HP: Dies kann auf Wunsch von Projects noch relativ leicht umgestellt werden]

Tag: <CC>

Innerhalb eines STATEs können beliebig viele CC-Receivers definiert werden. Der CC-Receiver erhält eine Referenz auf das weitergeleitete Objekt in die angegebene DESTINATION-Ablage.


Syntax

<CC DESTINATION="[tri:path]" RIGHTS="[tri:alias]"
REMAINRIGHTS="[tri:alias]" >[tri:user]</CC>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
DESTINATION openM2-Pfad der Zielablage, in welcher die Referenz erstellt werden soll
<CC..>[tri:user]</CC> Name des openM2-Benutzers, der die Referenz erhalten soll

Optional


ELEMENT Bemerkung
RIGHTS Rechte, welche für den CC-Receiver auf das weitergeleitete Objekt gesetzt werden
Default: READ (wenn Attribut nicht angegeben wird)
REMAINRIGHTS Rechte, welche für den CC-Receiver auf das weitergeleitete Objekt gesetzt werden, wenn der STATE verlassen wird (beim nächsten Weiterleiten)
Default: NONE (wenn Attribut nicht angegeben wird)

Variablenverwendung

<CC>[tri:user]<CC>
Statt [tri:user] können auch die folgenden Variablen verwendet werden:


  • #STARTER#
  • #PROCESSMANAGER#
  • benutzerdefinierte Variablen (z.B. #VARIABLE.var#)

DESTINATION="[tri:path]"
Für [tri:path] können auch die folgenden Ausdrücke angegeben werden:


  • #STARTERCONTAINER#
  • #MANAGERCONTAINER#
  • .../#STARTER#/..., z.B. Privat/#STARTER#/Arbeitskorb
  • .../#PROCESSMANAGER#/..., z.B. Privat/#PROCESSMANAGER#/Arbeitskorb
  • .../#VARIABLE.xxx#/..., z.B. Privat/#VARIABLE.username#/Arbeitskorb

Tag: <NOTIFICATION>

NOTIFICATIONS bildet eine Klammer für alle NOTIFY-Tags.


Syntax

<NOTIFICATIONS>


<NOTIFY>...</NOTIFY>
<NOTIFY>...</NOTIFY>
...

<NOTIFICATIONS>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
NOTIFY Definiert eine Nachricht, welche an diverse Benutzer versendet werden soll; siehe unten

Tag: <NOTIFY>

Mit Hilfe des NOTIFY Tag kann in jedem STATE definiert werden, wer beim Eintreten in diesen STATE wie benachrichtigt werden soll.


Syntax

<NOTIFY>
<USERS>[semicolon-separated:user]</USER>
<SUBJECT>[tri:text]</SUBJECT>
<CONTENT>[tri:text]</CONTENT>
<ACTIVITY>[tri:text]</ACTIVITY>
<DESCRIPTION>[tri:text]</DESCRIPTION>
</NOTIFY>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
USERS Liste von Benutzernamen, welche benachrichtigt werden sollen; getrennt durch Strichpunkte
SUBJECT
CONTENT
ACTIVITY
DESCRIPTION

Variablenverwendung

Es ist möglich in der Liste der Benutzernamen in USERS diverse Variablen zu verwenden, wobei die fixierten Run-Time Variablen #RECEIVER# und #CCs# nur bei der Notifikation verwendet werden können:


  • #RECEIVER#, der Empfänger in diesem STATE, definiert in RECEIVER
  • #CCs#, alle Benutzer, welche in diesem STATE eine Referenz bekommen, definiert in CC

außerdem:


  • #STARTER#
  • #PROCESSMANAGER#
  • #VARIABLE.xxx#

Anmerkungen

Die Benachrichtigung der einzelnen Benutzer erfolgt so wie es in deren Benutzer-Profilen eingestellt wurde (Email, SMS, openM2-Benachrichtigung).


Tag: <TRANSITION TYPE="SEQUENCE">

Transition bedeutet wörtlich übersetzt soviel wie: Übergang, Überführung. Im Workflow-Kontext, sind damit die Übergänge zwischen den einzelnen STATEs gemeint. Mittels Transitions definiert man also den NEXTSTATE eines STATES, d.h. jenen STATE, zu welchem beim „Weiterleiten" gesprungen wird.


Mittels einer TRANSITION vom TYPE="SEQUENCE" definiert man den Übergang von einem STATE zu genau einem nächsten STATE.


Syntax

<TRANSITION TYPE="SEQUENCE">
<NEXTSTATE>[tri:state]</NEXTSTATE>
</TRANSITION>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
TYPE SEQUENCE
<NEXTSTATE>[tri:state] Name des STATEs zu dem beim Weiterleiten gesprungen werden soll

Variablenverwendung

Hier können keine Variablen verwendet werden, jedoch gibt es für [tri:state] zwei vordefinierte Werte:


  • END: legt diesen STATE als END-STATE fest
  • END-NOCONFIRM: legt diesen STATE als END-STATE fest, jedoch ist hier im Gegensatz zu END das explizite „Abschliessen" des Workflows durch den Benutzer nicht notwendig.

Wichtig: Definition von END-STATES ist nur in TRANSITIONS vom TYPE="SEQUENCE" möglich.


Tag: <TRANSITION TYPE="ALTERNATIVE">

Mittels einer TRANSITION vom TYPE="ALTERNATIVE" definiert man den Übergang von einem STATE zu mehreren nächsten STATEs. Der Benutzer wird beim Weiterleiten dazu aufgefordert genau einen STATE auszuwählen, welcher angesprungen werden soll.


Syntax

<TRANSITION TYPE="ALTERNATIVE">
<NEXTSTATE>[tri:state]</NEXTSTATE>
<NEXTSTATE>[tri:state]</NEXTSTATE>
<NEXTSTATE>[tri:state]</NEXTSTATE>
...
</TRANSITION>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
TYPE ALTERNATIVE
<NEXTSTATE>[tri:state] Name eines STATEs der dem Benutzer zur Auswahl stehen soll

Variablenverwendung

Hier können keine Variablen verwendet werden.


END oder END-CONFIRM ist nicht erlaubt.


Tag: <TRANSITION TYPE="CONDITIONAL">

Mittels einer TRANSITION vom TYPE="CONDITIONAL" definiert man den Übergang von einem STATE zu mehreren nächsten STATEs. Auf Grund von in IF-Blöchen defnierten Bedingungen wird beim Weiterleiten automatisch der nächste STATE ermittelt und angesprungen.


Syntax

<TRANSITION TYPE="CONDITIONAL">
<IF>...</IF>
<IF>...</IF>
...
<DEFAULT>[tri:state]</DEFAULT>
</TRANSITION>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
TYPE CONDITIONAL
<DEFAULT>[tri:state] Name eines STATEs der angesprungen werden soll, wenn keine der Bedingungen in den IF-Blöcken zutrifft

Variablenverwendung

Hier können keine Variablen verwendet werden.


END oder END-CONFIRM ist nicht erlaubt.


Anmerkungen

Die Bedingungen in den IF-Blöcken werden der Reihe nach abgearbeitet, sobald der Vergleich in einem IF-Block zutrifft, wird der darin definierte NEXTSTATE angesprungen, unabhängig davon, ob nachfolgend definierte Bedingungen ebenfalls zutreffend sind.


Tag: <IF>

In einem IF-Block wird eine Bedingung (CONDITION) und der NEXTSTATE der angesprungen werden soll, falls diese Bedingung zutreffen sollte, definiert.


Syntax

<IF>
<CONDITION>
<LHSVALUE>[text|tri:variable|number]</LHSVALUE>
<OPERATOR>[tri:op]</OPERATOR>
<RHSVALUE>[text|tri:variable|number]</RHSVALUE>
</CONDITION>
<NEXTSTATE>[tri:state]</NEXTSTATE>
</IF>


Tags und Attribute

Obligatorisch


ELEMENT Bemerkung
CONDITION Klammert eine Bedingung der Form wert :op: wert

Beispiel: 12 = 13, Herbert <> Herberti, ...

<LHSVALUE>[tri:text] Der linke Teil der Bedingung
<OPERATOR>[tri:op] Der Vergleichsoperator, mit dem der linke mit dem rechten Teil der Bedingung verglichen wird
<RHSVALUE>[tri:text] Der rechte Teil der Bedingung
<NEXTSTATE>[tri:state] Der NEXTSTATE, der angesprungen wird, falls die Bedingung zutrifft

Variablenverwendung

Wie bei der Syntax-Definition bereits erwähnt können auch benutzerdefnierte Variablen können im LHSVALUE oder RHSVALUE verwendet werden.


  • #VARIABLE.xxx#, z.B. #VARIABLE.value#
  • ...#VARIABLE.xxx#..., z.B. „der Wert ist #VARIABLE.value#"

Mögliche Vergleichsoperatoren in [tri:op]: LESS, GREATER, EQUAL, LESSEQUAL, GREATEREQUAL, NOTEQUAL und nur bei Textvergleichen CONTAINS.


Anmerkungen

Wichtig: END oder END-CONFIRM ist im NEXTSTATE nicht erlaubt.


Behandlung von Typen bei Vergleichen
Die Angabe von Variablen-Typen (wie bereits erwähnt) hat derzeit noch keine Auswirkung auf Vergleiche. Bei Vergleichen wird derzeit folgendermaßen vorgegangen:


  1. Es wird versucht die angegebenen Werte zu Zahlen zu konvertieren
  2. Hat die Umwandlung funktioniert, werden die Werte als Zahlen verglichen
  3. Hat die Umwandlung nicht funktioniert, werden die Werte als Texte verglichen.
  4. Der Operator CONTAINS vergleicht IMMER auf Text-Basis.

Änderungen von 2.1 auf 2.2

Prinzipiell sollte jeder Workflow der auf Basis 2.1 definiert wurde auch in 2.2 noch funktionieren. Dies ist leider nicht der Fall. Änderungen, welche nicht abwärtskompatibel wurden speziell gekennzeichnet.


Anzeige des „Workflow Starten"-Buttons

Dieser Button wurde früher bei fast jedem Objekt(Typ) angezeigt. Dies wurde nun auf bestimmte Typen und bestimmte Rechte eingeschränkt. Für Details siehe entsprechendes Kapitel in diesem Dokument.


READ-Flags werden [tri:doch nicht] gelöscht

ACHTUNG: Dieses FEATURE wurde aus Performance-Gründen bereits WIEDER ENTFERNT.*
Beim Weiterleiten werden nun die READ-Flags gelöscht, d.h. das weitergeleitete Objekt und jede Referenz darauf werden als „Neu" markiert (z.B. blinkendes Icon).


h2. Keine Automatisch erzeugten Referenzen mehr
Früher wurden für den STARTER und den PROCESSMANAGER beim Start eines Workflows automatisch Referenzen im STARTERCONTAINER, bzw. in der MANAGERDESTINATION erzeugt. Dies geschieht nun nicht mehr, falls dies erwünscht wird, müssen entsprechende CC-Einträge im ersten STATE erfolgen.

h2. Geänderte Variablendefinition

  • ACHTUNG: NICHT ABWÄRTSKOMPATIBEL!

Unerklärlicherweise wurde die Variablendefinition geändert, statt


<VARIABLE NAME="suppliernr"
TYPE="STRING"
LENGTH="64"
DESCRIPTION="ID from Netto supplier">UNDEFINED</VARIABLE>


muss nun


<VARIABLE>
<NAME>suppliernr</NAME>
<TYPE>STRING</NAME>
<LENGTHT>64</LENGTH>
<DESCRIPTION>ID from Netto supplier</DESCRIPTION>
</VARIABLE>


verwendet werden.


<TRANSITION TYPE="SEQUENTIAL"> statt <NEXTSTATE>

ABWÄRTSKOMPATIBEL!
Im Workflow der Version 2.1 waren nur Sequenzen möglich, welche über das NEXTSTATE Tag (ohne klammerndes TRANSITION-Tag) anzugeben waren.


alte Version: <NEXTSTATE>[tri:state]</NEXTSTATE>

neue Version: <TRANSITION TYPE="SEQUENTIAL">
<NEXTSTATE>[tri:state]</NEXTSTATE>
</TRANSITION>


Wichtig: Kann noch in der alten Form verwendet, sollte jedoch bei neuen Definitionen vermieden werden


<MESSAGE>-Tag eliminiert

Dieses war schon in der letzten Version ohne Funktion - d.h. man kann es weiterhin verwenden und es wird weiterhin ignoriert ;)


ACTION Type=INTERNAL-CALL

ACHTUNG: NICHT ABWÄRTSKOMPATIBEL!
Die allseits bekannte und beliebte Methode ‚ transform ' wurde umbenannt in ‚ performTransformation '; dies ist entsprechend in den „gecustomisierten" („customisierten"?) Definitionen und Klassen nachzuziehen.


Formular-Customizing

ACHTUNG: NICHT ABWÄRTSKOMPATIBEL!
Bei Workflow 2.2 wurden die JavaScript Function-Calls geändert. Falls also in alten openM2 Versionen (Stand 2.1 oder Zwischenversionen wie NETTO) einem Formular-Stylesheet Workflow-Funktionen aufgerufen wurden (z.B. über Buttons), sind diese anzupassen:


v2.1 JavaScript-Aufruf top.load (function)
v2.2 JavaScript-Aufruf top.loadEvent (function, event)


Das Mapping der Funktionen (v2.1) auf das Funktions-Event-Modell (v2.2) sieht folgendermaßen aus:


  • Name function [tri:v2.1] function,event [tri:v2.2]*

START 185 185,1
FORWARD 184 185,3
FINISH 186 185,6


Aufruf über JavaScript

Sollten in einem Style-Sheet irgendwo JavaScript-Calls mit Workflow-Funktionsnummern vorkommen, so sind diese folgend umzubauen:


  • START top.load (185)*'==>'top.loadEvent (185,1)
  • FORWARD top.load (184)*'==>'top.loadEvent (185,3)
  • FINISH top.load (186)*'==>'top.loadEvent (185,6)


(Anmerkung: Finish habe ich nirgends gefunden.)


Aufruf mittels XSLT-Template ‚function'

Falls Style-Sheets, welche Workflow-Funktionen (184, 185, 186) mittels Michaels Steiners XSL-Call-Template aufrufen, verwendet werden ...


<xsl:call-template name="function">
<xsl:with-param name="fct">185</xsl:with-param>
<xsl:with-param name="text">print stock-receipt list</xsl:with-param>
</xsl:call-template>


... so ist folgend vorzugehen:


  1. Einspielen des XSL-Function-Templates ‚ functionEvent'
  1. Ändern aller Workflow-Aufrufe, nach folgendem Schema

<xsl:call-template name="functionEvent">
<xsl:with-param name="fct">185</xsl:with-param>
<xsl:with-param name="evt">1</xsl:with-param>
<xsl:with-param name="text">print stock-receipt list</xsl:with-param>
</xsl:call-template>


Dabei ist natürlich für die jeweilige Funktion das entsprechende Function/Event Paar
einzutragen


Änderungen von 2.2 auf 2.3

Prinzipiell sollte jeder Workflow der auf Basis 2.2 definiert wurde auch in 2.3 ohne Änderung funktionieren. Es wurden folgende Erweiterungen und Änderungen vorgenommen:


Starten eines Workflows über Workflow-Namen

Erweiterung für Formular-Customizing. Ermöglicht das Starten eines Workflows durch Aufruf einer JavaScript-Funktion. Der eindeutige Name identifiziert die Workflow-Vorlage, welche bereits in openM2 angelegt sein muss:


top.loadEventArg (185,7, "<WorkflowTemplateName>");


Workflow-Rechte ausschalten ermöglichen

Ermöglicht eine alternative Behandlung von Rechten durch Angabe eines neuen Attributs im Workflow-Header, welche folgendes bewirkt:


  • Die herkömmliche Rechtebehandlung (siehe Kapitel 2.5) wird deaktiviert.
  • Beim Weiterleiten werden die aktuellen Rechte des Objekts gelöscht.
  • Danach werden die Rechte der Zielablage für das Objekt und seine Subobjekte übernommen.

Syntax: < WORKFLOW ... IGNORERIGHTS=" YES " ...>


Attribute NAME in Parameter von QUERY-Actions

Bisher musste bei einer Query-Action der Name der Variable eines In-Parameters mit dem Namen des Query-Suchfeldes übereinstimmen (siehe Kapitel 2.7.4). Da sich dies während der Modellierung als recht umständlich gestaltet, ist es ab nun möglich den Namen des betroffenen Suchfeldes als Attribut anzugeben. Beispiel:


<ACTION TYPE="QUERY">
<CALL>_GetValue</CALL>
<INPARAMS>
<PARAMETER NAME="searchfield">#VARIABLE.searchvalue#</PARAMETER>
</INPARAMS>
<OUTPARAMS>
<PARAMETER>#VARIABLE.result#</PARAMETER>
</OUTPARAMS>
</ACTION>


In diesem Beispiel wird die Query _GetPMCUserName aufgerufen, wobei das Suchfeld der Query „searchfield" mit dem Wert der Variable „searchvalue" gefüllt wird. Das Ergebnis der Query wird in der Variable „result" gespeichert.


Verwendung von XPATH-Ausdrücken in TRANSITION-CONDITION

Beispiel:


  • Ein Objekt bzw. Formular wird weitergeleitet.
  • Beim Eintritt in einen neuen State wird ein Formular-Feld in einer Variable gespeichert - mit Hilfe einer XPATH-Action.
  • Innerhalb des States wird das Formular-Feld durch einen Benutzer geändert.
  • Der Benutzer klickt auf „Weiterleiten".
  • Der nächste State wird auf Grund einer Conditional-Transition ermittelt, welche die oben erwähnte Variable prüft.

Problem:


  • Eine Variable kann sich mittels XPATH auf ein Feld beziehen, welches im aktuellen State durch den Benutzer geändert wurde.
  • Beim Weiterleiten wird der Wert, welcher in der Variable auf Grund des XPATH-Ausdruckes gespeichert wurde, geprüft.
  • Dieser Wert ist jedoch nicht der aktuelle Wert des Feldes, sondern jener zum Zeitpunkt des Eintritts in den State.
  • Dies ist zugegebenermaßen eine Schwäche des Action-Konzepts, was zu Modellierungsproblemen führen kann.

Als Workaround für das geschilderte Problem kann man nun anstelle von Variablen auch XPATH-Ausdrücke in Transition-Conditions einsetzen, z.B.


<TRANSITION TYPE="CONDITIONAL">
<IF>
<CONDITION>
<LHSVALUE>#XPATH:/OBJECT/VALUES/VALUE[tri:@FIELD='Genehmigt']/child::text()#</LHSVALUE>
<OPERATOR>EQUAL</OPERATOR>
<RHSVALUE>true</RHSVALUE>
</CONDITION>
<NEXTSTATE>Projekt genehmigt</NEXTSTATE>
</IF>
...
</TRANSITION>


[Nur NETTO: PRINTONFORWARD]

Ausdrucken eines Objekts mittels Browser-Funktionalität beim Weiterleiten. Spezielle Netto-Anforderung, wurde nie in die Basis-Version 2.3 integriert. Ist meiner Meinung auch keine besonders saubere Lösung dieses Problems.


FAQ zu Workflow-Problemen

„Sie haben nicht das Recht ..."

Im Workflow2.2 wird der Benutzer „Administrator" als System-Benutzer missbraucht. D.h. er benötigt die Rechte zum Lesen der Workflow-Vorlage. Am sinnvollsten ist es diese auf die Workflow-Vorlagen-Ablage zu vergeben (+ vererben), auf daß auch neu angelegte Vorlagen gelesen werden können.


Problem bei Receiver-Pfaden mit Leerzeichen

Bei Fehlermeldungen der folgenden Form:


...
WARNING: the given receiver-container could not be found: administration/central office/bills
...


... kann es sein, daß z.B. bei Flexiblen Menüreitern aus Layoutgründen, das Leerzeichen nicht normal (Leertaste = ALT-32) sondern als Non-Breakable-Space ALT-255 angegeben wurde.


ACHTUNG:


  • Auch wenn es für den Benutzer gleich aussieht: SPACE kann ungleich SPACE sein.
  • Sonderzeichen sollten bei Objekten, welche Teil eines Pfades in Workflow-Vorlagen sind, nicht verwendet werden!!!

„...XPATH - Variable not defined: ..."

Die Variable wurde entweder gar nicht oder falsch definiert. Bitte unbedingt die neue v2.2-Notation verwenden, beim Netto-Prototypen war diese noch anders.


Netto-Prototype:


<VARIABLE NAME=" suppliernr "
TYPE=" STRING "
LENGTH=" 64 "
DESCRIPTION=" ID from Netto supplier ">UNDEFINED</VARIABLE>


v2.2:


<VARIABLE>
<NAME> suppliernr </NAME>
<VALUE>UNDEFINED</VALUE>
<TYPE> STRING </NAME>
<LENGTH> 64 </LENGTH>
<DESCRIPTION> ID from Netto supplier>
</VARIABLE>


..wenn eine Query nicht gefunden werden kann:

Es ist wichtig nach dem Erstellen von Queries den Webserver neu zu starten.
Ebenso ist es erforderlich, beim Query die Option System zu aktivieren.


use Query for:
SYSTEM

Kein „Weiterleiten" Button sichtbar ...

Falls für die Anzeige Stylesheets mit selbst definierten Buttons verwendet werden, so ist die Bedingung zu prüfen, wann ein Workflow-Button angezeigt wird. Diese ist meist abhängig von einem bestimmten Workflow-Status. Wenn dieser Status bei der Umstellung von einem englischen auf ein deutsches System (bzw. vice versa) übersetzt wird, so muß auch die Bedingung im XSL-File angepasst werden!


Anmerkung: Daraus läßt sich eine Anforderung ableiten, nämlich sprachenunabhängige Identifikationsmöglichkeit eines Workflow-STATEs.


Eine Workflow-Vorlage läßt sich nicht mehr löschen

Eine Workflow-Vorlage läßt sich in den folgenden Fällen nicht mehr löschen:


  • Es gibt noch ein aktives Objekt, dessen aktive Workflow-Instanz diese Vorlage benützt
  • Es gibt ein aktives Formular (XMLViewer_01), welches diese Workflow-Vorlage referenziert
  • Es gibt eine aktive Formularablage (XMLViewerContainer_01), welches diese Workflow-Vorlage referenziert.
  • Es gibt eine aktive Formularvorlage (DocumentTemplate_01), welches diese Workflow-Vorlage referenziert.

Anmerkungen:


  • Dies äußert sich darin, daß die Vorlage in der Löschen-Liste nicht aufscheint bzw. kein Löschen-Button angeboten wird:
  • Unter „aktiv" versteht man in diesem Zusammenhang „nicht gelöscht".

Was kann man in diesem Fall tun?


Das System muß „gesäubert" werden, d.h. im Detail:


  1. Löschen aller Objekte, zu welchen noch ein aktiver WF mit der betroffenen Vorlage existiert
  2. Entfernen aller WF-Vorlage-Referenzen in Formularen
  3. Entfernen aller WF-Vorlage-Referenzen in Formularablagen
  4. Entfernen aller WF-Vorlage-Referenzen in Formularvorlagen

Seltsame Nachricht beim Ändern einer Workflow-Vorlage

Das Ändern ist weiterhin in jedem Fall möglich - jedoch wird unter folgenden Bedingungen eine Nachricht ausgegeben:


  • Es gibt noch ein aktives Objekt, dessen aktive Workflow-Instanz diese Vorlage benützt
  • Es gibt ein aktives Formular (XMLViewer_01), welches diese Workflow-Vorlage referenziert
  • Es gibt eine aktive Formularablage (XMLViewerContainer_01), welches diese Workflow-Vorlage referenziert.
  • Es gibt eine aktive Formularvorlage (DocumentTemplate_01), welches diese Workflow-Vorlage referenziert.

Die Nachricht lautet:


„Warnung! Diese Workflow-Vorlage wird von derzeit laufenden Workflows genutzt. Eine Änderung kann zu Fehlern im Workflow führen."


Anmerkung: Diese Nachricht ist nicht ganz exakt - eigentlich sollten alle genannten Bedingungen angeführt werden.


Weitergeleitete Objekte verschwinden, kommen nicht an oder landen an den falschen Orten

Bei Systemen, auf welchen intensive Customizing-Tätigkeiten stattfinden, kann es leicht zu Verwirrungen kommen. Die häufigsten Fehler sind:


1. Es wurde eine alte Vorlage verwendet (bitte Upload-File prüfen)!
2. Es wurde eine alte Vorlage (u.U. schon gelöscht) mit demselben Namen verwendet (immer die OIDs vergleichen)!
3. Die Workflow-Vorlage des Formulars, der Formularablage oder der Formularvorlage wurde verwendet. Die Reihenfolge ist: Wenn beim Formular ein WF definiert wurde, wird dieser genommen, ansonsten jener der Ablage, ansonsten kann man einen auswählen.


Tipp: Immer im Workflow-Log nachsehen!!!!


  • Im Workflow-Log steht, welche Workflow-Vorlage verwendet wurde!
  • Im Workflow-Log steht, wohin weitergeleitet wurde und manches mehr!
  • Das Workflow-Log erreicht man über das Objekt-Attribut „Aktueller Status" (in der Info-Ansicht)
  • Falls „Aktueller Status" nicht angezeigt wird, kann man direkt am openM2-Server nachsehen im openM2-Webverzeichnis unter /workflow/log/. Der Name des Log-Files enthält die OID des weitergeleiteten Objekts.
  • ACHTUNG: Ein Log-File enthält alle Workflow-Log-Einträge für ein Objekt; es kann also die Einträge beliebig vieler Instanzen enthalten - bitte immer die letzten Einträge ansehen!