- Erstellt von Redakteur7 am Feb. 16, 2021
Für dieses Element ist ein How-To Artikel verfügbar.
Semantik
Mit <docxworld-fetch-production-environment> ist es möglich, Ressourcen (Produktions- und Binär-Pakete) aus einem Redaktions-System anzufordern. Damit stellt <docxworld-fetch-production-environment> die Anbindung des EOMS an das Redaktions-System bereit. In dem Element müssen Sie eine ganze Reihe an Subelementen notieren, damit eine Zuverlässige Verbindung und Übertragung der Pakete gewährleistet ist. Wenn alle nötigen Subelemente vorhanden und korrekt sind, stellt <docxworld-fetch-production-environment> eine Verbindung zu dem Redaktions-System her und läd automatisch die für den Job benötigten Pakete auf den Workerrechner, wo sie in einem lokalen Cache gespeichert werden. Die Zusammenführung der Pakete mit der XML-Spooler muss aber noch separat in einem <exec> vorgenommen werden. Es gibt 2 unterschiedliche Arten, wie <docxworld-fetch-production-environment> arbeiten kann. Sie geben dies über das Attribut runtime-environment an:
- merged (Standard):
Bei merged wird für jeden Job erneut ein temporäres Verzeichnis angelegt (angegeben durch <merge-home>). Zuerst wird geprüft, ob das benötigte Produktions-/Binär-Paket bereits im Cache des Workers vorhanden ist (durch einen vorherigen Job bereits dort abgelegt). Ist dies der Fall, werden die Pakete in das Jobverzeichnis kopiert. Fehlen beide oder 1 Paket, wird eine Verbindung zum Redaktions-System hergestellt und die benötigte Pakete von dort in den lokal Cache des Workers übertragen, von wo sie dann ins Jobverzeichnis kopiert werden. Zusätzlich wird noch die Spooler-XML in das Verzeichnis kopiert. Danach können die Pakete mit der XML zusammengeführt werden. Durch den hohen Kopieraufwand bei jedem Job ist merged langsamer als shared. Allerdings beherrschen einige externe Auftrags-Systeme shared eventuell nicht. Sollten Probleme auftreten, verwenden Sie merged. - shared:
shared agiert wie merged, mit dem Unterschied, dass die Pakete und Spooler-XML nicht für jeden Job neu in ein temporäres Verzeichnis kopiert werden, sondern der Aufruf der Pakete und der XML bei der Zusammenführung erfolgt an dem Ort, wo sie liegen. Das bedeutet, anstatt alle benötigten Dateien in ein Verzeichnis zu kopieren und dort die Ausführung zu starten, wird dem Programm mitgeteilt, wo es die Pakete und die Spooler-XML finden kann. Das Programm greift dann auf die Pakete "aus der Entfernung" zu. shared ist wesentlich schneller als merged und sollte daher merged vorgezogen werden. Falls Ihr Auftrags-System shared nicht unterstützt, müssen Sie merged verwenden.
Attribute
Attributname | Datentyp | Beschreibung | Mögliche Werte | Standardwert | Obligatorisch? |
---|---|---|---|---|---|
id | STRING | Die ID des Elements, über die es im Code angesprochen werden kann. | beliebiger, regelkonformer Name. | — | |
runtime-environment | STRING | Gibt an, wie die Daten gespeichert und verarbeitet werden sollen: shared (gecached) oder merged. Mehr dazu finden Sie in der Semantikbeschreibung. | "shared" : "merged" | merged | |
execution-mode | STRING | Hiermit lässt sich bestimmen, ob der Prozess in einer produktiven- oder einer Testumgebung laufen soll. Wird hier "test" angegeben, läuft der Prozess in einer Testumgebung. Das bedeutet, es muss hier für den Worker kein Redaktions-System erreichbar sein, sondern der Datenaustausch wird nur simuliert. Wird "production" angegeben, interagiert der Worker ganz normal mit einem Redaktions-System. "error" ist in der momentanen Implementierung identisch zu "test". In einer produktiven Umgebung muss unbedingt "production" gesetzt werden (oder das Attribut weggelassen werden). | "error" : "test" : "production" | production | |
clear-on-shutdown | STRING (long) | Gibt an, ob das Verzeichnis nach Beendigung des Prozesses automatisch gelöscht werden soll (true) oder nicht (false) oder ob es nur gelöscht werden soll, falls kein Fehler aufgetreten ist (keep-on-error) | "true" : "false" : "keep-on-error" | false |
Subelemente / Inhalt
Das <eoms-input-query-status>-Element besitzt 6 Subelemente, die nur innerhalb eines <docxworld-fetch-production-environment> notiert werden dürfen. Davon sind nur <binary-bundles-home> und <production-bundles-home> obligatorisch.
Um eine zuverlässige Verarbeitung zu garantieren, muss 1 der folgenden beiden Subelemente notiert werden:
Das <docxworld-contract>-Element zur Angabe einer docxworld-Vertragsnummer. Dieses Element darf nur notiert werden, falls kein <link-name> benutzt wird.
Das <link-name>-Element zur Angabe eines docxworld-Links. Dieses Element darf nur notiert werden, falls kein <docxworld-contract> benutzt wird.
Folgende 2 Elemente sind obligatorisch:
Das <binary-bundles-home>-Element zur Angabe des Home-Verzeichnisses für Binär-Pakete. Dieses Element ist obligatorisch.Jedes <docxworld-fetch-production-environment> muss dieses Element enthalten.
Das <production-bundles-home>-Element zur Angabe des Home-Verzeichnisses für Produktions-Pakete. Jedes <docxworld-fetch-production-environment> muss dieses Element enthalten.
Um eine zuverlässige Verarbeitung zu garantieren, muss 1 der folgenden 2 Subelemente notiert werden, je nachdem, ob Sie als runtime-environment merged (dann <merge-home>) oder shared (dann <runtime-home>) verwenden. Es dürfen auch beide Elemente notiert werden.
Das <runtime-home>-Element zur Angabe des Verzeichnisses, in dem bei runtime-environment="shared" Daten gespeichert werden.
Das <merge-home>-Element zur Angabe des Verzeichnisses, in dem bei runtime-environment="merged" Daten gespeichert werden.
Variablenbindungen
Das <docxworld-fetch-production-environment>-Element ist vom Typ FETCHED-PRODUCTION-ENVIRONMENT. Dieser Typ besitzt folgende Variablenbindungen:
Bindung | Beschreibung | Rückgabetyp |
---|---|---|
getTxApiVersion() | Gibt die API-Version des Produktions-Pakets zurück. | STRING |
getCommandLine(FILEOBJECT file) | Gibt den Kommandobefehl zurück, der in der übergebenen Datei enthalten ist. | STRING |
getBinaryBundleQuery() | — | STRING |
getMessage() | Gibt die interne Message zurück. Eignet sich für Debuggingzwecke. | STRING |
getDocxworldContract() | Gibt den docxworld-Vertrag zurück, der mit diesem Job assoziiert ist (falls verwendet). | STRING |
getProductionBundleLinkName() | Gibt den Linknamen des Produktions-Paktes zurück (falls gesetzt). | STRING |
getResultCode() | Gibt den Rückgabewert des gesamten <docxworld-fetch-production-environment> zurück (zeigt an, ob die Verarbeitung innerhalb von <docxworld-fetch-production-environment> erfolgreich war. 0 falls erfolgreich, 4 falls CACHE_HIT, 8 bei einem Fehler. | INTEGER |
getRuntimeEnvironmentResultCode() | Gibt den Rückgabewert des <runtime-environment> zurück: 0 falls "merged" verwendet wird, 4 falls "shared". | INTEGER |
getProductionBundleResultCode() | Gibt den Rückgabewert des Produktions-Pakets zurück: 0 falls erfolgreich, 4 falls CACHE_HIT und 8 bei einem Fehler. | INTEGER |
getBinaryBundleResultCode() | Gibt den Rückgabewert des Binär-Pakets zurück: 0 falls erfolgreich, 4 falls CACHE_HIT, 8 bei einem Fehler und 12 falls kein Binär-Paket angefordert wurde ("shared"). | INTEGER |
getProductionBundleId() | Gibt die ID des Produktions-Paket zurück. | STRING |
getBinaryBundleId() | Gibt die ID des Binär-Paket zurück. | STRING |
getSchemaName() | Gibt den Schemanamen zurück, der vom Produktions-Paket benutzt wird. | STRING |
getSchemaVersion() | Gibt die Schemaversion zurück, die vom Produktions-Paket benutzt wird. | STRING |
Beispiel
Zu diesem Element gibt es ein How-To mit umfangreichem Beispiel.
Zweck:
Interaktion mit R-S
Typ:
Top-Level
Elternelement:
Top-Level-Elemente
Subelemente:
Ja
Variablenbindungen:
Ja
- <rcml>
- <process>
- <docxworld-fetch-production-environment>
- <exec>
- <if>/<else>
- <switch>
- <while>
- <docxworld-fetch-production-environment>
- <process>
—
- Keine Stichwörter