Übersicht der verfügbaren Modellelemente
Modellelement | Beschreibung |
|---|---|
| Ein Kontrollflusselement verbindet zwei Knoten (Modellelemente) miteinander und definiert somit den Ablauf der einzelnen Aufgaben. Kontrollflussübergänge können mit einer Bedingung versehen werden um bedingte Pfade zu modellieren. |
| Dieses Element dient dazu, mehrere Zuständigkeitsbereiche innerhalb eines Geschäftsprozesses anzulegen. Jeder Prozessbahn ist ein Sachbearbeiter oder eine Benutzergruppe/Rolle zugeordnet, welche für die Ausführung der Aufgaben zuständig ist. Die Zuordnung der Benutzer zu den Gruppen/Rollen (MN10490) erfolgt über dessen Abteilung (Benutzerverwaltung von oxaion (MN10640R) oder Crossfeed (MN10400R)). |
| Mit einem Startknoten beginnt jeder Geschäftsprozess. Er darf nur genau einmal vorkommen. Der Prozessstart kann auf verschiedene Weise ausgelöst werden. |
| Dieses Element ist eine Aktion innerhalb eines Geschäftsprozesses, die entweder mit Hilfe einer XML-Maske oder als manuelle Aufgabe realisiert wird. Das bedeutet, dass kein Programmaufruf zur Durchführung dieser Aufgabe dient, sondern lediglich Daten über eine Oberflächenmaske erfasst, bearbeitet oder angezeigt werden oder eine manuelle Prozessverzweigung gewählt werden kann. Es wird folglich keine Geschäftslogik auf dem Server ausgeführt. Die Operationen zur Speicherung und Abfrage von Daten müssen getrennt mit Hilfe von oxaion-Programmen oder –Prozeduren realisiert werden. |
| Ein oxaion Prozedur/Befehl ist eine Aktion innerhalb eines Geschäftsprozesses, die komplett automatisch mit Hilfe einer Serverkomponente ausgeführt wird. Zum Beispiel kann ein Geschäftsprozess den Versand einer E-Mail beinhalten. Dies ist eine Systemaufgabe, da diese ohne Interaktion mit dem Benutzer erledigt werden kann. |
| Ein oxaion Programm ist eine Aktion innerhalb eines Geschäftsprozesses, die ein Sachbearbeiter mit Hilfe eines oxaion-Programms durchführt. Das bedeutet, dass die entsprechenden Benutzer über ihre Aufgabenliste informiert werden, dass Sie für die Durchführung dieser Aufgabe verantwortlich sind. Startet ein Benutzer dann die Durchführung der Aktion, so öffnet sich automatisch das entsprechende oxaion-Programm. Sobald er die Aufgabe im Programm erledigt hat, erfolgt automatisch eine Rückmeldung an die Process Engine. |
| Ein Subprozess ermöglicht das Anstoßen eines weiteren BPM-Prozesses aus einem laufenden Prozess heraus. |
| Ein Ausdrucksknoten dient dazu, Java-Ausdrücke innerhalb eines Geschäftsprozesses auszuwerten. Dies ist vor allem sinnvoll, wenn Datenfelder initialisiert oder manipuliert werden sollen. |
| Das Zustandsobjekt überwacht und aktualisiert ein Status-Feld einer oxaion-Datenbankdatei. Die Überwachung kann sich auf ein beliebiges Feld einer beliebigen oxaion-Datei beziehen und wird in den Prozesseigenschaften festgelegt (siehe Prozesseigenschaften). |
| Ein Webserviceknoten ermöglicht es unter der Angabe einer Endpoint Reference (EPR), einer Methode und den erforderlichen Parametern, eine Anfrage an einen Webservice zu senden. Die Values der Parameter werden über die Eingabedaten angegeben, in welchem die Parameter schon vorbelegt sind. Das Ergebnis des Services wird über die Ausgabedaten verarbeitet, in welchen man die Rückgabewerte in beliebige Variablen schreiben kann. Es werden nur Webservices mit Request-Response-Muster unterstützt. |
| Der Endeknoten beendet einen Geschäftsprozess komplett. |
| Ein Entscheidungsknoten dient dazu, aus mehreren Folgepfaden entsprechend der Erfüllung von Bedingungen genau einen Pfad auszuwählen. Die Bedingung kann dabei direkt im Entscheidungsknoten hinterlegt werden oder in den einzelnen Kontrollflusskanten, die dem Entscheidungsknoten folgen. |
| Ein Parallelitätsknoten dient dazu, die Folgepfade parallelisiert auszuführen. Somit können mehrere Aktionen gleichzeitig ausgeführt werden. |
| Der Synchronisationsknoten ist das Pendant zum Parallelitätsknoten. Er führt alle eingehenden Pfade zusammen, indem solange gewartet wird, bis alle eingehenden Pfade den Synchronisationsknoten erreicht haben. |
| Dieses Element beschreibt eine unspezifische Aufgabe, die textlich beschrieben wird. |
| Der allgemeine Aufruf wird im Rahmen des Elements „Allgemeine Aufgabe" dazu verwendet, ein oxaion Programm, eine Webseite oder eine Datei durch Mausklick des Users aufzurufen. Außerdem kann damit in einen anderen Subprozess verzweigt werden. Wird ein oxaion Programm hinterlegt, ist es möglich jegliche RPC Addin zu hinterlegen, wie bspw. OPEN_PGM, NEW. |
| Dieses Element ermöglicht die Einbindung von Grafikdateien in das Prozessmodell. |
weitere grafische Elemente | Neben den angeführten funktionalen Modellelementen stehen auch noch weitere Elemente zur grafischen Aufbereitung bzw. die Kommentierung von Prozessschritten zur Verfügung. Diese Elemente werden nicht an die BPM Process Engine übertragen.  |
Nachdem die verfügbaren Modellelemente in der obigen Tabelle beschrieben wurden, werden im Folgenden die Eigenschaften der einzelnen Modellelemente genauer beleuchtet.
Prozesseigenschaften
Eigenschaft | Erklärung |
|---|---|
Name | Unter dem hier vergebenen Namen wird der Prozess in den Prozessdefinitionen in oxaion aufgeführt. |
Anzeigefeld 01 ..10 | Hier können bis zu 10 Anzeigefelder spezifiziert werden. Diese werden als Spalten in den offenen Aufgaben angezeigt. |
Status-Datei(Optional) | Hier kann die (logische) Datei für eine Statusüberwachung eingetragen werden. Es dürfen nur logische Dateien verwendet werden, da ein Schlüssel benötigt wird. |
Status-Feld(Optional) | Hier kann das zu überwachende Feld aus der gewählten Datei eingetragen werden. |
| Verzögerter Start | true = Wird die Ausprägung "true" angegeben, startet der Prozess nur dann, wenn der entsprechend überwachte Status eintrifft. Zudem werden alle vorhanden Prozessinstanzen des Geschäftsobjektes gelöscht, sobald ein Status bei einer Überwachung geändert wird. false = Der Prozess startet nur einmalig bei Anlage des Datensatzes. Der Prozess wird für jedes Geschäftsobjekt gestartet, unabhängig von der Statusausprägung. |
Kontrollfluss
Ein Kontrollfluss-Element verbindet zwei Knoten miteinander und definiert somit den Ablauf der einzelnen Aufgaben.
Kontrollflussübergänge können Entscheidungen mit einer Bedingung versehen werden um bedingte Pfade zu modellieren. Kontrollflussübergänge ausgehend von oxaion Masken können über die Definition von Anzeigeberechtigungen als Auswahl in der oxaion Maske angezeigt werden oder nicht.
Eigenschaft | Erklärung |
|---|---|
Bedingung | Hier kann eine Bedingung hinterlegt werden, die erfüllt sein muss, damit der Geschäftsprozess entlang dieser Kante fortgeführt wird. Typische Bedingungen sind Ausdrücke der Form [Datenfeld] [Operator] [Literal]. Wurde bspw. aufgrund einer oxaion Prozedur eine Fehlermeldung ausgeworfen, wird ein Kontrollfluss mit der Bedingung "ERROR" benötigt, sodass der Prozess fortgeführt werden kann. Sollen nummerische Werte in einer Bedingung hinterlegt werden, dürfen diese wegen abweichender Punkt-/Komma-Separatoren nicht so: "KOBRDM < 10000", sondern so: "num(KOBRDM) < 10000" abgefragt werden. |
Anzeigeberechtigung | Bei Kontrollflüssen, die von einer oxaion Maske ausgehen, kann über diese Bedingung gesteuert werden, ob dieser Kontrollfluss als Transaktionsbutton auf der oxaion Maske angezeigt wird. |
Prozessbahn
Dieses Element dient dazu mehrere Zuständigkeitsbereiche innerhalb eines Geschäftsprozesses anzulegen. Jeder Prozessbahn ist ein Sachbearbeiter oder eine Benutzergruppe/Abteilung zugeordnet, welche für die Ausführung der Aufgaben zuständig ist. Die Zuordnung der Benutzer zu der Benutzergruppe (MN10490) erfolgt über dessen Abteilung (Benutzerverwaltung von oxaion (MN10640R (Anwenderberechtigungen)) oder Crossfeed (MN10400R (Crossfeed-Benutzer))).
Eigenschaft | Erklärung |
|---|---|
Abteilungsschlüssel | Die Prozessbahn kann entweder einem einzelnen Mitarbeiter oder einer Abteilung/Benutzergruppe zugeordnet werden. Ist eine Abteilung eingetragen, wird die in der FRDATN hinterlegte Benutzergruppe in die Workflow-Aufgaben übernommen und jedes Mitglieder der Benutzergruppe erhält die Aufgabe. Näheres dazu ist hier zu lesen. |
Name | Gibt den Namen der Prozessbahn an. |
Feldname des Sachbearbeiters | Wenn der Prozess eine oxaion-Datenbank-Datei überwacht, kann hier optional die Überwachung eines Sachbearbeiter-Feldes hinterlegt werden. |
Start
Dieses Element stellt den Start des Geschäftsprozesses dar. Folglich darf es nur ein solches Element geben. Diese Einschränkung bezieht sich allerdings nur auf Prozesse, die in der oxaion BPM Process Engine ausgeführt werden.
Eigenschaft | Erklärung | ||||||
|---|---|---|---|---|---|---|---|
Name | Gibt den Namen des Knotens an. | ||||||
Nachricht | Gibt den Typ der Nachricht an, auf den diese Aktion als Zeichen der Beendigung wartet. Diese Nachrichten werden von oxaion-Programmen versandt, sobald bestimmte Aktionen ausgeführt wurden. | ||||||
Nachrichtenparameter | Hier kann die Bedingung für die Nachricht, die zum Start des Prozesses führt, angegeben werden. Hierfür wird in der Eingabemaske das Feld „Schlüssel" leer gelassen und die Bedingung in das Feld „Wert" geschrieben (z.B. SAFIRM = '990'). | ||||||
Eingabeparameter | Keine Bedeutung für diesen Knotentyp. | ||||||
Ausgabeparameter | Gibt an, welche Felder der Rückgabenachricht des oxaion-Programms nach dem Ausführen der entsprechenden Aktion in welche Prozessdatenfelder eingefügt werden sollen.
Der Nachrichtenteil KOAAUNR wird in die Prozessvariable AUNR übernommen. Die Variable FIRM wird mit 990 gefüllt. |
oxaion Maske / manuelle Aufgabe
Eine oxaion Maske ist eine Aktion innerhalb eines Geschäftsprozesses, die mit Hilfe einer XML-Maske realisiert wird. Das bedeutet im Unterschied zur Benutzeraufgabe, dass kein komplettes oxaion-Programm zur Durchführung dieser Aufgabe dient, sondern lediglich Daten über eine Oberflächenmaske erfasst, bearbeitet oder angezeigt werden. Es wird folglich keine Geschäftslogik auf dem Server ausgeführt. Die Operationen zur Speicherung und Abfrage von Daten müssen getrennt mit Hilfe von Systemaufgaben realisiert werden.
Alternativ: Wird bei diesem Modellelement keine XML-Maske hinterlegt, handelt es sich um eine manuelle Aufgabe, die losgelöst vom oxaion ausgeführt wird. Der Prozess muss anschließend manuell weitergespult werden.
Eigenschaft | Erklärung | ||||||
|---|---|---|---|---|---|---|---|
Name | Gibt den Namen der Aktion an. | ||||||
Reaktionszeit | Gibt bei Benutzeraufgaben und manuellen Aufgaben die maximale Zeit an, die für die Ausführung dieser Aktion benötigt werden darf. Wird diese überschritten, wird die Aktion gestartet, die über eine Kontrollflusskante mit der Bedingung NO_REACTION mit diesem Knoten verbunden ist. | ||||||
XML-Maskenname | Gibt den Namen der XML-Maske an, die angezeigt werden soll. | ||||||
Eingabedaten | Gibt an, welche Daten dem hinterlegten oxaion-Programm beim Aufruf zur Verfügung gestellt werden und wie diese auf die Felder der Oberfläche abgebildet werden.
Das Feld IAUNR auf der Oberfläche wird mit dem Wert des Datenfeldes AUNR gefüllt. Das Oberflächenfeld ITEXT wird mit „Ein Text" gefüllt. | ||||||
Ausgabedaten | Gibt an, welche Teile der Interaktionsaufgabe in welche Prozessvariablen übernommen werden sollen. Kann auch für die Initialisierung von Prozessvariablen verwendet werden, indem als Wert ein Literal, eingeschlossen in Anführungszeichen, verwendet wird.
Der Nachrichtenteil KOAAUNR wird in die Prozessvariable AUNR übernommen. Die Variable FIRM wird mit 990 gefüllt. | ||||||
Anzeige Info | Gibt den Text an, der als Titel der Maske verwendet wird. | ||||||
Anzeige Text | Gibt den Text an, der als Beschreibung der Aktion in der Maske angezeigt wird. |
Es ist möglich, beim Aufruf einer XML-Maske eine Prüfung auf bspw. Pinnwand-Buttons oder einzelne Felder zu hinterlegen, indem die Transaktion "BPM_OK" innerhalb der XML-Maske manuell eingefügt wird.
Als Beispiel:
„OK“ ist eine Transaktion, die hinter jedem Pinnwand-Button existiert. Wird einer dieser Buttons gedrückt, wird am Ende der Button-Verarbeitung die Transaktion „RUN“ aufgerufen, welche die „BPM_OK“ im aktuell geöffneten XML startet.
Enthält das XML eine „BPM_OK“-Transaktion, können dort diverse XML-Transaktionen, wie bspw. Prüfungen, Programmaufrufe, etc., hinterlegt werden.
Gibt es dort keine „BPM_OK“ passiert nichts weiter.
oxaion Prozedur / Befehl
Eine Prozedur ist eine Systemfunktion, die innerhalb des oxaion Application Servers ohne Benutzerinteraktion direkt synchron ausgeführt wird.
Zum Beispiel kann ein Geschäftsprozess den Versand einer E-Mail beinhalten. Für das Versenden einer E-Mail steht eine oxaion Prozedur zur Verfügung.
Für den Aufruf von oxaion Prozeduren gilt:
Grundsätzlich sind diejenigen Prozeduren bzw. JAVA-Methoden aufrufbar, die im Methoden-Explorer (GE14090R oder Befehl „AKPRC") vom Funktionstyp "Prozedur" sind und deren Rückgabetypen einem der folgenden Typen entsprechen:
void, OxaionResponse, Table, Data, Dta, OxaionError, SQLFieldSet, Field, Boolean, Integer, String
Darüber hinaus werden Eingabe-Parameter der Prozedur nur dann unterstützt, wenn Sie einen der folgenden Typen besitzen
Data, java.io.File, String, boolean, int, Field
Im Modeler werden Prozeduren folgendermaßen hinterlegt.
Wenn die Methode korrekt verwendet wurde, werden die benötigten (Schlüssel-)Parameter automatisch über den Toolserver abgeglichen und vorgegeben.
Die verfügbaren Parameter im Detail.
Eigenschaft | Erklärung | |
|---|---|---|
Name | Gibt den Namen der Aktion an. | |
oxaion Befehl/Prozedur | Gibt den Namen der Prozedur an, die gestartet werden soll. | |
Eingabedaten | Die Eingabe-Parameter sollten bei korrekter Angabe der Prozedur bzw. JAVA-Methode vom System automatisch vorgegeben werden. | |
Ausgabedaten | Die verwendbaren Ausgabe-Parameter sind abhängig von der genutzten JAVA-Methode. Möglich sind folgende Objekttypen:
| |
Asynchron | Gibt an, ob das Programm synchron oder asynchron ausgeführt werden soll. |
Über dieses Modellelement ist es zudem möglich, Extensions innerhalb des BPM-Prozesses aufzurufen.
- Voraussetzungen:
- Neue Extension unter "oxaion Extensions verwalten" (OP40500) anlegen
- Die Extension, die im Prozess aufgerufen wird, muss mit „_J“ enden
- Aufruf im BPM-Prozess:
Aufgrund der Crossfeed-Funktionalitäten gibt es eine Methode, die den "BPM-Link" (setBPMLink) zu einer Aufgabe oder einer Pinnwand setzt. Hierzu werden folgende Konfigurationen benötigt.
Schlüssel | Wert |
|---|---|
| piid | PIID → muss immer angegeben werden |
| link | Dieser Wert setzt den Link für eine Aufgabe unter einem Objekt-Explorer. Wird hier ein Link angegeben, so wird die BPM-Aufgabe unter dem "Workflow"-Knoten des Geschäftsobjektes im Explorer angezeigt.
Folgende Wert-Kette ist hierfür anzugeben: "Programm." + FeldnameAuftrag + "@" + FeldnameFirma Bsp.: "VK20090R." + KOAAUNR + "@" + KOAFIRM |
| pwid | Hier wird der Link zur Pinnwand des entsprechenden Geschäftsobjektes gesetzt. Die BPM-Aufgabe wird dann unter der Pinnwand des Objektes angezeigt.
Folgende Wert-Kette ist hierfür anzugeben: "LogischeDatei." + FeldnameFirma + "." + FeldnameAuftrag Bsp.: "VXAKOL01." + KOAFIRM + "." + KOAAUNR |
Während der Prozessmodellierung ist es möglich, als oxaion Prozedur "Dummy" anzugeben, bevor die eigentliche Methode geschrieben wird. Die Dummy-Methode gibt dann lediglich Eingabeparameter zurück, um den Prozess durchspielen zu können.
oxaion Programm
Ein oxaion Programm ist eine Aktion innerhalb eines Geschäftsprozesses, die ein Sachbearbeiter mit Hilfe eines oxaion-Programms durchführt. Das bedeutet, dass die entsprechenden Benutzer über ihre Aufgabenliste informiert werden, dass Sie für die Durchführung dieser Aufgabe verantwortlich sind. Startet ein Benutzer dann die Durchführung der Aktion, öffnet sich automatisch das entsprechende oxaion-Programm. Sobald die Aufgabe im Programm erledigt ist, erfolgt eine automatische Rückmeldung an die Process Engine.
Eigenschaft | Erklärung | ||||||
|---|---|---|---|---|---|---|---|
Name | Gibt den Namen der Aktion an. | ||||||
Oberflächenaktionen | Gibt eine Reihe von XML-Transaktionen an, die nach dem Aufruf des Programms ausgeführt werden. | ||||||
oxaion-Programm | Gibt den Namen des Programms an, das gestartet werden soll. | ||||||
Reaktionszeit | Gibt bei Benutzeraufgaben und manuellen Aufgaben die maximale Zeit in Stunden an, die für die Ausführung dieser Aktion benötigt werden darf. Wird diese überschritten, wird die Aktion gestartet, die über eine Kontrollflusskante mit der Bedingung NO_REACTION mit diesem Knoten verbunden ist. | ||||||
Nachricht | Gibt den Typ der Nachricht an, auf den diese Aktion als Zeichen der Beendigung wartet. Diese Nachrichten werden von oxaion-Programmen versandt, sobald bestimmte Aktionen ausgeführt wurden. | ||||||
Nachrichtenparameter | Hier kann die Bedingung für die Nachricht, die zum Weiterführen des Prozesses führt, angegeben werden. Hierfür wird in der Eingabemaske das Feld „Schlüssel" leer gelassen und die Bedingung in das Feld „Wert" geschrieben (z.B. SAFIRM = '990'). | ||||||
Eingabedaten | Gibt an, welche Daten dem hinterlegten oxaion-Programm beim Aufruf zur Verfügung gestellt werden und wie diese auf die Felder der Oberfläche abgebildet werden.
Das Feld IAUNR auf der Oberfläche wird mit dem Wert des Datenfeldes AUNR gefüllt. Das Oberflächenfeld ITEXT wird mit „Ein Text" gefüllt. | ||||||
Ausgabedaten | Gibt an, welche Daten der Rückgabenachricht des oxaion-Programms nach der erfolgreichen Ausführung der entsprechenden Aktion in welche Datenfelder eingefügt werden sollen.
Der Nachrichtenteil KOAAUNR wird in die Prozessvariable AUNR übernommen. Die Variable FIRM wird mit 990 gefüllt. |
Ausdruck
Ein Ausdrucksknoten dient dazu Java-Ausdrücke innerhalb eines Geschäftsprozesses auszuwerten. Dies ist vor allem sinnvoll, wenn Datenfelder initialisiert oder manipuliert werden sollen.
Eigenschaft | Erklärung |
|---|---|
Ausdruck | Gibt den Ausdruck an, der ausgewertet werden soll. |
Name | Gibt den Namen der Aktion an. |
Subprozess
Ein Subprozess ermöglicht das Anstoßen eines weiteren BPM-Prozesses aus einem laufenden Prozess heraus.
In der business Version ist diese Funktion allerdings zurzeit nur im Rahmen der Prozessdokumentation nutzbar, da sie von der oxaion BPM Process Engine noch nicht unterstützt wird. Durch Mausklick auf den Subprozess wird in diesem Fall der verlinkte Prozess geöffnet. Eingabe- und Ausgabeparameter sind deshalb für die business Version nicht relevant.
Eigenschaft | Erklärung | ||||||
|---|---|---|---|---|---|---|---|
Datei | Gibt den Namen der Datei an. | ||||||
Name | Gibt den Namen der Aktion an. | ||||||
Subprozess Name | Gibt den Namen des Subprozesses an. | ||||||
Ausgabedaten | Gibt an, welche Daten der Rückgabenachricht des oxaion-Programms nach der erfolgreichen Ausführung der entsprechenden Aktion in welche Datenfelder eingefügt werden sollen.
Der Nachrichtenteil KOAAUNR wird in die Variable AUNR übernommen. Die Variable FIRM wird mit 990 gefüllt. | ||||||
Eingabedaten | Gibt an, welche Daten dem hinterlegten oxaion-Programm beim Aufruf zur Verfügung gestellt werden und wie diese auf die Felder der Oberfläche abgebildet werden.
Das Feld IAUNR auf der Oberfläche wird mit dem Wert des Datenfeldes AUNR gefüllt. Das Oberflächenfeld ITEXT wird mit „Ein Text" gefüllt. |
Zustand
Der Zustand ist eines der wirkungsvollsten BPM-Objekte. Diese Objekte sind Sprungmarke und Statusschreiber zugleich. Je nachdem wie das Objekt im laufenden Prozess aufgerufen wird.
Ein Beispiel:
Um den „Abschluss Status" von Serviceaufträgen zu überwachen wird im Prozess die (logische) Datei SAKOPL01 und das zu überwachende Feld AKXAUS hinterlegt.
Bsp. 1
Wird an einer beliebigen Stelle im laufenden Prozess der Auftragsstatus SAS (AKXAUS) auf „08" („Auftrag eingeplant") gesetzt, so wird direkt zum Zustandsobjekt mit der Ausprägung „08" gesprungen. Von dort aus läuft der Prozess regulär weiter.
Bsp. 2
Läuft der gleiche Prozess jedoch auf „normalem" Weg bis zum besagten Zustandsknoten, also ohne dass der Auftragsstatus SAS (AKXAUS) vorher auf „08" gesetzt wurde, so geschieht dies dann an dieser Stelle. Mit dem Erreichen des Zustandsknotens über eine Prozessbahn wird das Feld AKXAUS in der Datei SAKOPL01 auf „08" gesetzt und der Prozess läuft auch hier regulär weiter.
Eigenschaft | Erklärung |
|---|---|
Name | Gibt den Namen der Aktion an. |
Status-Ausprägung | Gibt an, bei welchem Zustand die Aktion ausgeführt werden soll. |
Webservice
Ein Webserviceknoten ermöglicht es unter der Angabe einer Endpoint Reference (EPR), einer Methode und den erforderlichen Parametern, eine Anfrage an einen Webservice zu senden. Die Values der Parameter werden über die Eingabedaten angegeben, in welchem die Parameter schon vorbelegt sind. Das Ergebnis des Services wird über die Ausgabedaten verarbeitet, in welchen man die Rückgabewerte in beliebige Variablen schreiben kann. Es werden nur Webservices mit Request-Response-Muster unterstützt.
Eigenschaft | Erklärung | ||||||
|---|---|---|---|---|---|---|---|
Methode | Gibt den Namen der auszuführenden Methode des Webservices an. Nach der Angabe der Methode wird über die WSDL-Datei geprüft, ob diese auch vom Webservice zu Verfügung gestellt wird. | ||||||
Name | Gibt den Namen der Aktion an. | ||||||
Referenz zum Endpunkt | Gibt die Endpoint Reference des auszuführenden Webservices an. Nach Angabe der EPR wird sofort geprüft, ob eines WSDL-Datei gefunden wird bzw. ob der Webservice erreichbar ist. | ||||||
Ausgabedaten | Gibt an, welche Teile der Webservices in welche Prozessvariablen übernommen werden sollen. Kann auch für die Initialisierung von Prozessvariablen verwendet werden, indem als Wert ein Literal, eingeschlossen in Anführungszeichen, verwendet wird.
Der Nachrichtenteil KOAAUNR wird in die Variable AUNR übernommen. Die Variable FIRM wird mit 990 gefüllt. | ||||||
Eingabedaten | Gibt an, welche Daten dem hinterlegten oxaion-Programm beim Aufruf zur Verfügung gestellt werden und wie diese auf die Felder der Oberfläche abgebildet werden.
Das Feld IAUNR auf der Oberfläche wird mit dem Wert des Datenfeldes AUNR gefüllt. Das Oberflächenfeld ITEXT wird mit „Ein Text" gefüllt. |
Ende
Der Endeknoten beendet einen Geschäftsprozess vollständig.
Eigenschaft | Erklärung |
|---|---|
Name | Gibt den Namen der Aktion an. |
Entscheidung
Ein Entscheidungsknoten dient dazu, aus mehreren Folgepfaden entsprechend der Erfüllung von Bedingungen genau einen Pfad auszuwählen. Die Bedingung kann dabei direkt im Entscheidungsknoten hinterlegt werden oder in den einzelnen Kontrollflusskanten, die dem Entscheidungsknoten folgen.
Eigenschaft | Erklärung |
|---|---|
Bedingung | Hier kann optional eine Bedingung hinterlegt werden. Sollen nummerische Werte in der Bedingung hinterlegt werden, dürfen diese wegen abweichender Punkt-/Komma-Separatoren nicht so: "KOBRDM < 10000", sondern so: "num(KOBRDM) < 10000" abgefragt werden. |
Name | Gibt den Namen der Aktion an. |
Parallelität
Ein Parallelitätsknoten dient dazu, die Folgepfade parallelisiert auszuführen. Somit können mehrere Aktionen gleichzeitig ausgeführt werden.
Eigenschaft | Erklärung |
|---|---|
Name | Gibt den Namen der Aktion an. |
Synchronisation
Der Synchronisationsknoten ist das Pendant zum Parallelitätsknoten. Er führt alle eingehenden Pfade zusammen, indem solange gewartet wird, bis alle eingehenden Pfade den Synchronisationsknoten erreicht haben.
Eigenschaft | Erklärung |
|---|---|
Name | Gibt den Namen der Aktion an. |