Das Tag <jobdefinition> ist das Tag der höchsten Ebene. Alle weiteren Tags werden von diesem Element umhüllt.
Attribut | Verwendung | Werte | Defaultwert | Beschreibung |
---|---|---|---|---|
failedMailRecipients | optional | <mail address>,<mail address> | Im Fehlerfall werden an diese Adressen E-Mails versendet. Mehrere Adressen sind mit Kommas zu trennen. | |
globalMutex | optional | <mutex name> | Name eines globalMutex. Diese Art von Mutex verhindert die parallele Abarbeitung von Jobs mit gleichnamigem globalMutex über alle Worker hinweg. | |
model | benötigt | <path to eox file> |
UNC-Pfad zur EOX- oder EECX-Datei des Basis-Modells. Es ist eine relative Pfadangabe möglich, wenn in der Benutzervorgabe oder der Initialisierungsdatei ein Pfad für den Repository-Ordner angegeben ist. Fehlt diese Angabe, wird statt dessen der Pfad zur JMX-Datei angewendet. Der Pfad zum Modell kann auch per Formel mit =trigger.filePath angegeben werden. Dann wird im incomingFolder nach einer EOX- oder EECX-Datei gesucht. Dazu ist ein entsprechender Filter zu setzen. Wird ein webTrigger mit der Formel =trigger.params.<model parameter> angegeben, ist der Pfad zur EOX oder EECX-Datei als Parameter im Webaufruf anzugeben. |
|
name | benötigt | <job name> | Name des Jobs. Wird der Name mit Hilfe einer Formel definiert, kann der Name mit der Erweiterung trigger.fileName dynamisch zu einem Namen inklusive Jobdateinamen zusammengesetzt werden. | |
successMailRecipients | optional | <mail address>,<mail address> | Im Erfolgsfall werden an diese Adressen E-Mails versendet. Mehrere Adressen sind mit Kommas zu trennen. | |
workerMutex | optional | <mutex name> | Name eines workerMutex. Diese Art von Mutex verhindert die parallele Abarbeitung von Jobs mit gleichnamigem workerMutex auf dem selben Worker. | |
xmlns:xi | benötigt, wenn nicht in Tag <xi:include> angegeben | http://www.w3.org/2001/XInclude | Namensraumerweiterung, um xi:include nutzen zu können |
Erlaubte Unterelemente | Anzahl |
---|---|
fileTrigger | 1 |
webserviceTrigger | 1 |
actions | 1 |
custom | 1 |
Hinweis:
Im Erfolgs- und Fehlerfall können E-Mails an vorbestimmte Adressen versendet werden. Dies ist nur möglich, wenn in den Benutzervorgaben das Kontrollkästchen Sende E-Mails im Erfolgsfall, bzw. Sende E-Mails im Fehlerfall markiert ist und gültige Angaben für den SMTP-Server gemacht sind.
Benennung der Jobs:
In diesem Fall (siehe Definition oben) sähe die Liste der Jobs (z.B. als Unterverzeichnisse mit Jobergebnis, Definition, UMC-Logs) so aus:
File_Werk1_140805_1544_00012
File_Werk1_140805_1546_56435
File_Werk2_140805_1546_03455
<?xml version="1.1"?>
<jobdefinition name="='test'+ trigger.fileName" model="models\model.eox" xmlns:xi="http://www.w3.org/2001/XInclude">
<fileTrigger>
<failedFolder value="failed" />
<incomingFolder value="input" />
<outputFolder value="output" />
<filter value="*.px" />
</fileTrigger>
<custom>
<jobStatusHtml value="html/my_status_page.html" />
</custom>
<actions>
<action name="T_Mechatronic_ModularSystem.Action.ImportPXAction" arguments="List{trigger.filePath}" />
<action name="Engineering.ExportPXCommand" arguments="List{'TestProj',trigger.additionalResultsDir + 'proj.px',true}" />
<action name="T_Mechatronic_ModularSystem.Action.SendMailOnEndCommand" arguments="List{trigger.outputFolder,trigger.failedFolder,trigger.jobName}" />
</actions>
</jobdefinition>
Beispiel für eine Jobdefinition, die per fileTrigger den Speicherort für das Basismodell angibt:
Jobdefinition mit dynamischer Angabe des Basismodells per fileTrigger:
<?xml version="1.1"?>
<jobdefinition name="='test'+ trigger.fileName" model="=trigger.filePath" xmlns:xi="http://www.w3.org/2001/XInclude">
<fileTrigger>
<failedFolder value="failed" />
<incomingFolder value="input" />
<outputFolder value="output" />
<filter value="*.eox" />
</fileTrigger>
<actions>
<action name="UtilLib.Do"/>
</actions>
</jobdefinition>
Beschreibung:
Im Tag <jobdefinition> wird mit dem Attribut model="=trigger.filePath" keine Modelldatei direkt angegeben, sondern diese muss sich in dem Ordner befinden, der mit dem Tag <incomingFolder> angegeben ist. Der Dateityp wird mit dem Tag <filter> angegeben, in diesem Fall wird nach einer EOX-Datei gesucht.
Beispiel für eine Jobdefinition, die per webserviceTrigger den Speicherort für das Basismodell angibt:
Jobdefinition mit dynamischer Angabe des Basismodells per webserviceTrigger:
<?xml version="1.1"?>
<jobdefinition name="='test'+ trigger.fileName" model="=trigger.params.model" xmlns:xi="http://www.w3.org/2001/XInclude">
<webserviceTrigger>
<failedFolder value="failed" />
<outputFolder value="output" />
</webserviceTrigger>
<actions>
<action name="UtilLib.Do"/>
</actions>
</jobdefinition>
Beschreibung:
Im Tag <jobdefinition> wird mit dem Attribut model="=trigger.params.model" keine Modelldatei direkt angegeben, sondern diese wird als Parameter model per Webaufruf übergeben.
Beispiel für einen Aufruf:
http://localhost:8787/jobs/request/jobdef_web?model=K:\JobServer\input\feeder.eox
Beispiel für eine Jobdefinition mit webserviceTrigger, um Jobs in Abhängigkeit des Aufrufs unterschiedlich zu benennen:
Jobdefinition mit dynamischer Angabe des Job Namens per webserviceTrigger:
<?xml version="1.1"?>
<jobdefinition name="='Conveyor_'
+ if((trigger.params.belt).size>0).ifEmptyNullOrError(false)
then 'Belt_' + trigger.params.belt + '_'
else ''
endif
+ if((trigger.params.roller).size>0).ifEmptyNullOrError(false)
then 'Roller_' + trigger.params.roller + '_'
else ''
endif
+ if((trigger.params.chain).size>0).ifEmptyNullOrError(false)
then 'Chain_' + trigger.params.chain + '_'
else ''
endif"
continueOnError="false"
model="WebShop.eecx"
xmlns:xi="http://www.w3.org/2001/XInclude">
<webserviceTrigger>
<failedFolder value="failed" />
<outputFolder value="output" />
</webserviceTrigger>
<actions>
<action name="JobServerActions.WebShopCall"
arguments="List{trigger.params,
trigger.jobName,
trigger.outputFolder,
trigger.failedFolder}"/>
</actions>
</jobdefinition>
Beschreibung:
Der Jobname wird in Abhängigkeit des übergebenen Parameters in der Jobliste angezeigt.
Dazu wird im Tag <jobdefinition> eine Abfrage mit Bedingungen eingefügt, die den Jobnamen aus Fragmenten unterschiedlich zusammensetzt.
Mögliche Varianten sind:
- Conveyor_Belt_<Job-ID>_POS_<Position>_<Time stamp>
- Conveyor_Roller_<Job-ID>_POS_<Position>_<Time stamp>
- Conveyor_Chain_<Job-ID>_POS_<Position>_<Time stamp>
Paralleles abarbeiten von Jobs ausschließen
Ist in den Benutzervorgaben die Maximale Anzahl paralleler Jobs auf einen Wert größer 1 gesetzt, können mehrere Jobs parallel abgearbeitet werden. Für bestimmte Jobs kann die parallele Abarbeitung jedoch nicht erlaubt sein und muss ausgeschlossen werden können.
Der wechselseitige Ausschluss wird allgemein kurz Mutex (von mutual exclusion) genannt. Die parallele Abarbeitung von Jobs kann durch die Attribute workerMutex und globalMutex in zwei Stufen ausgeschlossen werden.
- Mit Hilfe von einem workerMutex wird verhindert, dass auf einem Worker Jobs für die gleichen Jobdefinition parallel abgearbeitet werden. Der workerMutex ist immer dann zu verwenden, wenn gemeinsame Ressourcen eines Workers nicht parallel genutzt werden dürfen, beispielsweise P8. Dadurch werden diese Jobs sequentiell abgearbeitet. Jobs für Jobdefinitionen ohne workerMutex oder anderen workerMutex werden nach wie vor parallel ausgeführt.
- Durch die Definition eines globalMutex wird verhindert, dass über alle Worker hinweg ein Job für die gleiche Jobdefinition parallel abgearbeitet wird. Der globalMutex ist immer dann zu verwenden, wenn gemeinsame Ressourcen für alle Worker nicht parallel genutzt werden dürfen, beispielsweise bei schreibenden Datenbankzugriffen. Dadurch werden diese Jobs sequentiell abgearbeitet. Jobs für Jobdefinitionen ohne globalMutex oder anderen globalMutex werden nach wie vor parallel ausgeführt.
<?xml version="1.1"?>
<jobdefinition name="Generate_P8" workerMutex="P8" model="model.eox" xmlns:xi="http://www.w3.org/2001/XInclude">
<webserviceTrigger>
<outputFolder value="\output" />
</webserviceTrigger>
<actions>
...
</actions>
</jobdefinition>
<?xml version="1.1"?>
<jobdefinition name="WriteToDb" globalMutex="DB" model="models\model.eox" xmlns:xi="http://www.w3.org/2001/XInclude">
<fileTrigger>
<failedFolder value="failed" />
<incomingFolder value="input" />
<outputFolder value="output" />
<filter value="*.px" />
</fileTrigger>
<actions>
...
</actions>
</jobdefinition>
Siehe auch: