PDK - Process Development Kit (Produkt) (PS)

PDK - Process Development Kit [Produkt] [PS]
Knowledge Space
Exported on 08/15/2018

Knowledge Space – PDK - Process Development Kit [Produkt] [PS]
Table of Contents
1 logLevel (ActionList und JobScheduler) ............................................................8
2 Schreibweise .......................................................................................................9
3 Updates und Bugfixes .......................................................................................10
4 PDK-Whitepaper................................................................................................11
4.1 Einleitung ............................................................................................................................... 11
4.2 PDK Übersicht ........................................................................................................................ 11
4.2.1 Verwendete Komponenten ..................................................................................................................................11
4.2.2 Genereller Prozess ................................................................................................................................................12
4.3 PDK Komponenten ................................................................................................................ 13
4.3.1 Prozessprotokoll ...................................................................................................................................................13
4.3.1.1 Anforderungen ......................................................................................................................................................13
4.3.1.2 Datenmodell..........................................................................................................................................................14
4.3.1.3 Integration in EPIM ...............................................................................................................................................15
4.3.2 ActionList...............................................................................................................................................................16
4.3.2.1 Allgemein...............................................................................................................................................................16
4.3.2.2 Actions ...................................................................................................................................................................16
4.3.2.3 Actions-Methoden.................................................................................................................................................16
4.3.3 ProcessLogger.......................................................................................................................................................24
4.3.4 SOS JobScheduler Zitiert von der Webseite www.sos-berlin.com ....................................................................25
4.4 Technische Dokumentation .................................................................................................. 25
4.4.1 Doku-Beispiel ........................................................................................................................................................25
4.4.1.1 Start des Prozesses ...............................................................................................................................................26
4.4.1.2 Job-Kette...............................................................................................................................................................26
4.4.1.3 Job .........................................................................................................................................................................27
4.4.1.4 ActionList...............................................................................................................................................................28
4.4.2 JobScheduler ........................................................................................................................................................29
4.4.3 XML Schema Dateien ............................................................................................................................................29
4.4.4 JavaDoc .................................................................................................................................................................30
4.4.5 Process Logger WebService API ...........................................................................................................................30
4.4.6 Anwendungsbeispiel.............................................................................................................................................31
4.4.6.1 Grafische Visualisierung des Gesamtprozesses ..................................................................................................31
4.4.6.2 ActionList aufbauen ..............................................................................................................................................31
– 2
4.4.6.3 Job definieren .......................................................................................................................................................32

4.4.6.4 Job über JobScheduler aufrufen .........................................................................................................................33
4.4.6.5 Prozessprotokoll ...................................................................................................................................................34
5 PDK-Module.......................................................................................................35
5.1 PDK-AssetProcess .................................................................................................................. 35
5.2 PDK-Dispatcher ...................................................................................................................... 35
5.3 PDK-Housekeeping ................................................................................................................ 35
5.4 PDK-Indesign.......................................................................................................................... 35
6 Installation ........................................................................................................36
6.1 Upgrade des PDK ................................................................................................................... 36
6.2 Installation des PDK............................................................................................................... 37
6.2.1 Anlage der Standardverzeichnisse.......................................................................................................................37
6.2.2 Installation der mariadb in VMPROGRAMS/PDK/MariaDB .................................................................................38
6.2.2.1 Schritt 1: ................................................................................................................................................................38
6.2.2.2 Schritt 2: ................................................................................................................................................................39
6.2.2.3 Schritt 3:................................................................................................................................................................40
6.2.2.4 Schritt 4:................................................................................................................................................................41
6.2.2.5 Schritt 5: ................................................................................................................................................................42
6.2.3 DB-Script ausführen..............................................................................................................................................42
6.2.4 Anpassen der my.ini..............................................................................................................................................43
6.2.5 Ausführen der JobScheduler-Auto-Installation ..................................................................................................43
6.2.6 Anpassen von sos.ini, factory.ini und scheduler.xml ..........................................................................................44
6.2.7 Den JDBC-Treiber tauschen .................................................................................................................................45
6.2.8 Altes Jobverzeichnis leeren..................................................................................................................................45
6.2.9 SOS JobScheduler-Dienst namens „SOS JobScheduler -id=scheduler“ starten ..............................................45
6.2.10 Deinstallation möglich machen ...........................................................................................................................46
6.2.11 Konfiguration der Actionlist .................................................................................................................................46
6.2.12 Installation des JobScheduler Operations Center (JOC-Cockpit)......................................................................46
6.2.13 //Horst, 2017-12-05, erstmals auf Rehau_TEST ..................................................................................................46
7 Standardverzeichnisse .....................................................................................51
7.1 Standardverzeichnisse in der Kunden-Umgebung .............................................................. 51
7.1.1 Übersicht ...............................................................................................................................................................51
7.1.2 Erläuterung............................................................................................................................................................53
– 3
7.2 Standardverzeichnisse in der lokalen Umgebung/Subversion ........................................... 55

8 actionlist............................................................................................................57
8.1 Actions .................................................................................................................................... 57
8.1.1 callRFC *TO DO* ....................................................................................................................................................57
8.1.2 callWebService *TO DO*/TB .................................................................................................................................59
8.1.3 choose ...................................................................................................................................................................61
8.1.4 config .....................................................................................................................................................................62
8.1.4.1 Achtung - potentielle Fehlerquelle bei Jobkette mit Verzeichnisüberwachung und file_order_sink:.............65
8.1.5 copy *TO DO*/TB...................................................................................................................................................65
8.1.6 createList...............................................................................................................................................................66
8.1.7 delete .....................................................................................................................................................................67
8.1.8 echo .......................................................................................................................................................................68
8.1.9 email *TO DO* .......................................................................................................................................................69
8.1.10 encode *TO DO* ....................................................................................................................................................71
8.1.11 EPIMWebServiceXMLImport *DEPRECATED - DO NOT USE* ..............................................................................72
8.1.12 executeJobschedulerXml *TO DO* ......................................................................................................................74
8.1.13 executeShell *TO DO* ...........................................................................................................................................75
8.1.14 executeSQL *TO DO*.............................................................................................................................................77
8.1.15 executeXQuery *TO DO* .......................................................................................................................................78
8.1.16 exit .........................................................................................................................................................................80
8.1.17 extractvalue*TO DO* ............................................................................................................................................80
8.1.18 fail ..........................................................................................................................................................................82
8.1.19 fop *TO DO* ...........................................................................................................................................................82
8.1.20 foreachconfigfile *DEPRECATED - DO NOT USE* ................................................................................................84
8.1.21 forEachItemListXml *TO DO* /TB.........................................................................................................................85
8.1.22 forEachKeyValueList .............................................................................................................................................86
8.1.23 forEachList *TO DO*..............................................................................................................................................87
8.1.24 ftpTransfer *ab v2.7.1 - TO DO* ............................................................................................................................88
8.1.25 getDataFromSAP *TO DO*....................................................................................................................................90
8.1.26 mkDir .....................................................................................................................................................................91
8.1.27 move *TO DO*/TB .................................................................................................................................................92
8.1.28 property *TO DO*/TB ............................................................................................................................................92
8.1.29 rename *TO DO*....................................................................................................................................................93
8.1.30 reportEPIM *TO DO*..............................................................................................................................................95
8.1.31 searchandreplace *TO DO*/TB ............................................................................................................................96
– 4
8.1.32 setOrderBack *TO DO*/TB....................................................................................................................................97

8.1.33 sleep*TO DO*/TB...................................................................................................................................................98
8.1.34 touch *TO DO*.......................................................................................................................................................98
8.1.35 transform *TO DO*..............................................................................................................................................100
8.1.36 unzip *TO DO*/TB ...............................................................................................................................................101
8.1.37 validateXML *TO DO* ..........................................................................................................................................102
8.1.38 waitforlogfile *DEPRECATED - DO NOT USE* ....................................................................................................103
8.1.39 zip *TO DO*/TB....................................................................................................................................................105
8.2 Konfiguration ....................................................................................................................... 106
8.2.1 global.properties.................................................................................................................................................106
8.2.2 Customer-Config .................................................................................................................................................109
8.2.3 Process-Config ....................................................................................................................................................110
8.3 Special functions.................................................................................................................. 112
8.4 Standard-Variablen.............................................................................................................. 114
9 Prozess-Templates .........................................................................................116
9.1 remoteActionlist .................................................................................................................. 116
10 Logging ............................................................................................................117
– 5
• PDK-Whitepaper (see page 11)

• PDK-Module (see page 35)
• PDK-AssetProcess (see page 35)
• PDK-Dispatcher (see page 35)
• PDK-Housekeeping (see page 35)
• PDK-Indesign (see page 35)
• Installation (see page 36)
• Standardverzeichnisse (see page 51)
• actionlist (see page 57)
• Actions (see page 57)
• callRFC *TO DO* (see page 57)
• callWebService *TO DO*/TB (see page 59)
• choose (see page 61)
• config (see page 62)
• copy *TO DO*/TB (see page 65)
• createList (see page 66)
• delete (see page 67)
• echo (see page 68)
• email *TO DO* (see page 69)
• encode *TO DO* (see page 71)
• EPIMWebServiceXMLImport *DEPRECATED - DO NOT USE* (see page 72)
• executeJobschedulerXml *TO DO* (see page 74)
• executeShell *TO DO* (see page 75)
• executeSQL *TO DO* (see page 77)
• executeXQuery *TO DO* (see page 78)
• exit (see page 80)
• extractvalue*TO DO* (see page 80)
• fail (see page 82)
• fop *TO DO* (see page 82)
• foreachconfigfile *DEPRECATED - DO NOT USE* (see page 84)
• forEachItemListXml *TO DO* /TB (see page 85)
• forEachKeyValueList (see page 86)
• forEachList *TO DO* (see page 87)
• ftpTransfer *ab v2.7.1 - TO DO* (see page 88)
• getDataFromSAP *TO DO* (see page 90)
• mkDir (see page 91)
• move *TO DO*/TB (see page 92)
• property *TO DO*/TB (see page 92)
• rename *TO DO* (see page 93)
• reportEPIM *TO DO* (see page 95)
• searchandreplace *TO DO*/TB (see page 96)
• setOrderBack *TO DO*/TB (see page 97)
• sleep*TO DO*/TB (see page 98)
• touch *TO DO* (see page 98)
• transform *TO DO* (see page 100)
• unzip *TO DO*/TB (see page 101)
• validateXML *TO DO* (see page 102)
• waitforlogfile *DEPRECATED - DO NOT USE* (see page 103)
• zip *TO DO*/TB (see page 105)
• Konfiguration (see page 106)
• global.properties (see page 106)
• Customer-Config (see page 109)
• Process-Config (see page 110)
– 6
• Special functions (see page 112)

• Standard-Variablen (see page 114)
• Prozess-Templates (see page 116)
• remoteActionlist (see page 116)
• Logging (see page 117)
– 7
1 logLevel (ActionList und JobScheduler)

Wenn ein Prozess durch die Abnahme vom Kunden in den Produktivbetrieb geht, sollten die logLevel bei allen
zugehörigen ActionLists, JobKetten und Jobs auf 1 gesetzt werden.
logLevel (ActionList und JobScheduler) – 8

2 Schreibweise
Prozesse, Properties, etc. werden auf Basis von British English gebildet (British English: initialise anstatt
initialize).
Typ Beschreibung Bespiel
ActionLists Innerhalb von ActionLists, JobKetten und Jobs wird als sessionId
Schreibweise →camelCase1 verwendet (Namen von Properties,
JobKetten nextValue
etc.)
Jobs
Dateinamen Bei Dateinamen werden hingegen die einzelnen "Fragement" mit - ecom-interface
(Minus) getrennt, generell werden die Namen nur mittels
erp-interface
Kleinbuchstaben gebildet.
Namenskonvention: [Name1]-[Name2]-[Name3].
[Dateiendung]
JobKetten Bei JobKetten wird bei den einzelnen JobKetten sowie Jobs eine 100_standard-
Nummerierung (3-stellig) - entsprechend dem Aufbau der JobKette process.job_chain.xml
Jobs
- mit einem _ (Unterstricht) vorangestellt.
110_initialise.job.xml
Namenskonvention: [Nummerierung]_[Name1]-[Name2].
[job_chain|job].xml
Dies hat den Vorteil, dass im entsprechenden Verzeichnis die
Dateien entsprechend dem Aufbau der JobKette sortiert angezeigt
werden
OrderDateien Der Name von OrderDateien zum Starten einer JobKette werden 100_standard-
analog zu den JobKetten und Jobs aufgebaut. process,daily.order.xml
Namenskonvention: [Nummerierung]_[Name der JobKette],
[Name].order.xml
1 https://en.wikipedia.org/wiki/CamelCase
Schreibweise – 9
3 Updates und Bugfixes

Es versteht sich von selbst, dass Udpates und Bugfixes immer sofort in Subversion eingecheckt werden.
Wird von einem Dritten (nicht direkt dem Kunden/Projekt/etc. zugewiesen) ein Bugfix vorgenommen, so muss
dieser ebenfalls ins Subversion (inkl. Kommentar) eingecheckt werden.
Zudem muss per E-Mail der zuständige Projektleiter (oder wenn nicht bekannt zumindest der Teamleiter)
informiert werden!
Updates und Bugfixes – 10

4 PDK-Whitepaper
4.1 Einleitung
Die Viamedici Software GmbH hat ein Framework zur Prozessunterstützung realisiert: das Process Development Kit
(PDK).
Das PDK soll Pre- und Post-Prozesse zwischen EPIM und Drittsystemen
• schneller, zuverlässiger, flexibler und plattform-neutral implementieren.
• überwachen und automatisch auf Ereignisse, Warnungen und Fehler reagieren.
• darstellen und Kennzahlen wie Durchlaufzeiten transparenter machen.
Beispiele für den Einsatzbereich sind uni- und bidirektionale Schnittstellen zu ERP Systemen, MAM Systemen, TM
Systemen, Print-Systemen (wie z.B. Adobe InDesign Server), WebCMS und Shops. Außerdem ist/wird die Lösung
Grundlage für weitere Viamedici Lösungen sein wie z.B. das Review Portal und die automatisierte
Attributkonvertierung.
Per WebService API ist sichergestellt, dass auch Drittsysteme Prozesse anlegen und Fortschritte aktualisieren
können.
Das PDK besteht aus den folgenden Komponenten:
• Prozessprotokoll: EPIM Servermodul zur Anzeige und Recherche von Prozessen. Hauptanwendung ist die
Prozessüberwachung als Grundlage für die Analyse von Prozessfehlern.
• ActionList: XML-basiertes Konfigurationsmodul für die Konfiguration von Prozesseinzelschritten
• ProcessLogger: Modul zum Befüllen und Verwalten der Einträge im Prozessprotokoll.
• SOS JobScheduler: Automatisierte Steuerung und Überwachung von Prozessen auf Basis von Jobs oder
Job-Ketten.
Hinweis: Das Modul „Prozessprotokoll" wird basierend auf dem Patch 12 für Release 3.8 an die Kunden
ausgeliefert. Der Einsatz des „Prozessprotokolls" ist immer zwingend mit den oben aufgeführten Komponenten
(SOS JobScheduler, ActionList, ProcessLogger) gekoppelt.
Die vorliegende Dokumentation erläutert das generelle Zusammenspiel der Komponenten. Außerdem wird das
Dokument ergänzt durch die Integration einer Beispielkonfiguration anhand der die Nutzung der technischen
Dokumentation erläutert wird.
4.2 PDK Übersicht
4.2.1 Verwendete Komponenten

Zum besseren Verständnis hier eine kurze Erläuterung der wichtigsten Elemente, die vom PDK verwendet werden:
• Elemente im SOS JobScheduler
• Order: Dies entspricht einem Auftrag zur Ansteuerung einer Job-Kette und kann auch die Übergabe
von Parametern an die aufgerufene Job-Kette beinhalten.
• Job: Teilprozess
• Job-Kette: Prozess bestehend aus Teilprozessen, sprich eine sequenziell abzuarbeitende Liste von
Jobs mit vorgegebener Reihenfolge.
• Elemente in der ActionList
• ActionList: Ausprägung der Teilprozesse. Liste von atomaren Aktionen im XML-Format, die durch
einen Job aufgerufen wird.
• Action: eine atomare Aktion wie z.B. kopieren, löschen, transformieren.
PDK-Whitepaper – 11
4.2.2 Genereller Prozess

Ein Anwender, EPIM oder Drittsysteme können einen Prozess mittels einer Konfigurationsdatei oder einer
periodischen Planung starten (1). Die Job-Kette im JobScheduler nimmt den Prozess auf und steuert einzelne Jobs
an (2). Die ActionList von VM wird aus einem Job gestartet (3) und führt die darin konfigurierten Actions (4) aus.
Nachrichten und Fehler werden im Gesamtprozess von unten nach oben gereicht (5). Variablen (z.B. Session-ID,
temporäre Pfade) können ebenso nach oben gereicht und so z.B. innerhalb einer Job-Kette in einem nächsten Job
weiterverwendet werden.
Wenn ein Job abgeschlossen ist, evaluiert die Job-Kette den Status des Jobs (6). Ist dieser erfolgreich
abgeschlossen, dann läuft die Job-Kette weiter und es werden ggf. neue Jobs aufgerufen (7). Im Fehlerfall kann die
Job-Kette abzweigen und Jobs zur Fehlerbehandlung (z.B. Benachrichtigung des Admins und Sicherung sowie
Aufräumen temporärer Verzeichnisse) aufrufen (8). Auf Job-Ebene ist es ebenfalls möglich, automatisch Emails im
Erfolgs- oder Misserfolgsfall zu senden.
Wenn alle Jobs der Job-Kette erfolgreich durchlaufen sind oder die Fehlerbehandlung abgeschlossen ist, dann ist
die Job-Kette beendet.
Das Ansteuern des ProcessLoggers geschieht dabei bei Nutzung der ActionList in Verbindung mit dem SOS
JobScheduler automatisch. Drittsysteme können den ProzessLogger über WebService-Methoden nutzen.
Hinweis zur ActionList:
Jobs können im JobScheduler in verschiedenen Programmiersprachen (JAVA, PHP, …) implementiert werden.
Viamedici hat hierfür die ActionList implementiert. Diese Vorgehensweise vereinfacht die Nutzung des
JobSchedulers, da keine tiefgreifenden Programmierkenntnisse für die Konfiguration von Jobs notwendig sind.
Abbildung 1: Generelle Prozessabbildung der ActionList im Zusammenspiel mit dem JobScheduler
4.3 PDK Komponenten
4.3.1 Prozessprotokoll
4.3.1.1 Anforderungen
Allgemeine Anforderungen sind:
• Lokalisierung (in de, en und fr)
• EPIM-Look&Feel inklusive Nutzung desselben GUI-Frameworks (extJS)
• Integration in EPIM Standard Entwicklungsprozesse (Qualitätssicherung, Upgrades, Patches, Deployment)
Spezifische Anforderungen für das Prozessprotokoll sind:
• Mengengerüst/Performance: Bis zu 100000 Root-Prozesse pro Tag (z.B. Einzelaufrufe einer MAM-
Schnittstelle). Ein Root-Prozess hat geschätzt im Durchschnitt bis zu 1000 verschachtelte Kind-Prozesse, es
gibt jedoch keine Einschränkung nach oben.
• Datenmodell: Das Prozessprotokoll liest die relevanten Daten aus den Tabellen PDK_PROCESSES
(Prozessdaten) und PDK_DETAILS (Detaildaten). Ein Prozess kann mehrere Detail-Datensätze besitzen. Die
Prozessdatensätze können eine Baumstruktur abbilden.
• Deep Link: Das Prozessprotokoll kann direkt mit einer Prozess-ID als Parameter im Web Browser aufgerufen
werden. Der Baum zum Prozess wird direkt angezeigt.
• Menu-Eintrag: Das Prozessprotokoll kann via Menu (Benutzer->Protokoll->Prozessprotokoll) aufgerufen
werden.
• Prozessdarstellung: Die Prozesse werden im Prozessprotokoll als Baumstruktur in einem Tree Grid
dargestellt
• Recherche: Der Anwender kann Prozesse recherchieren (z.B. ID, Start-/Ende-Datum, Status, System)
4.3.1.2 Datenmodell
Abbildung 2: ER-Datenmodell des PDKs

Es wird zwei neue Datenbanktabellen in EPIM geben, die nachfolgend beschrieben sind.
Tabelle PDK_PROCESSES
• Name: PDK_PROCESSES
• Kürzel: PDKP
• Beschreibung: In der Tabelle PDK_PROCESSES werden die Prozessdaten mit ihren Abhängigkeiten
abgespeichert
• Sequence: SEQ_PK_PDKP
• Columns
• ID NUMBER(15,0) NOT NULL; Primary Key
• PDKP_ID NUMBER(15,0); ID des Parent Prozesses - Zeigt auf PDKP.ID; Wenn PDKP_ID==NULL => Root-
Prozess
• CLIE_ID NUMBER(15,0) NOT NULL DEFAULT 1; Mandanten ID - Per default auf 1 setzen
• NAME VARCHAR2(200) NOT NULL; Name des Prozesses
• SYSTEM VARCHAR2(200) NOT NULL; Name der Schnittstelle oder des Drittsystems (z.B. MAM, ERP,
SAP, WCMS, ...); Namen werden frei vergeben
• STATE VARCHAR2(50) NOT NULL; Status des Prozesses; Status sind fest definiert: planned, in work,
success, warning, error, canceled
• LIFE_TIME DATE; Zeitstempel zum automatischen Löschen der Prozessdaten
• CREATION_DATE DATE NOT NULL; Start-Zeitstempel
• CHANGE_DATE DATE; Zeitstempel der letzten Änderung bzw. des Prozessendes
• EXTERNAL_ID VARCHAR2(200); Externe ID (z.B. SAP-Materialnummer);
• ROOT_ID NUMBER(15,0) NOT NULL; ID des obersten Parent Prozesses

Tabelle PDK_DETAILS
• Name: PDK_DETAILS
• Kürzel: PDKD
• Beschreibung: In der Tabelle PDK_DETAILS werden die Detailinformationen (Statuswechsel, Debuginfos, ...)
zu einem Prozess abgespeichert
• Sequence: SEQ_PK_PDKD
• Columns
• ID NUMBER(15,0) NOT NULL; Primary Key
• PDKP_ID NUMBER(15,0) NOT NULL; Prozess ID zur der der PDK_Details-record gehört
• CLIE_ID NUMBER(15,0) NOT NULL DEFAULT 1; Mandanten ID - Per default auf 1 setzen
• STATE VARCHAR2(50); Typ der Detailmeldung; Typen sind fest definiert: Info, Warning, Error
• DETAIL CLOB; Detailinformation zum Prozess (Können auch Debuginfos sein).
• CREATION_DATE DATE NOT NULL; Anlage-Zeitstempel
4.3.1.3 Integration in EPIM

Im Menü wird der neue Menü-Eintrag Benutzer / Protokolle / Prozessprotokoll angelegt.
Außerdem werden zwei neue Benutzerrechte in EPIM angelegt:
• Modulrecht (Recht für den Menü-Eintrag)
• Administrationsrecht (für weiterführende Aktionen aus der Oberfläche heraus - noch nicht verwendet)
Das User Interface besteht aus 4 Teilen:
• Das Hauptmenü EPIM im Norden.
• Die Suchmaske im Westen. Damit können die wichtigsten Prozessdaten recherchiert werden (Name,
Prozess-ID, Start-/Ende-Datum, Status). Es werden immer alle Prozesse durchsucht (Root- und Kind-
Prozesse)
• Die Darstellung der Root- und Kind-Prozesse im Center. Initial werden immer die neuesten Root-Prozesse in
zugeklappter Form dargestellt. Beim Aufklappen werden die Kind-Prozesse des ausgewählten Root-
Prozesses dynamisch nachgeladen. Die Kind-Prozesse sind chronologisch sortiert. Die Reihenfolge ergibt
sich aus der ActionList oder anderen loggenden Systemen.
• Die Darstellung der Prozessdetails im Süden. In der Überschrift findet sich der Namen des Prozesses. Beim
Anklicken eines Prozesses werden alle Detail-Datensätze des Prozesses in einem Grid dargestellt.
Abbildung 3: User Interface des Prozess Protokolls

4.3.2 ActionList
4.3.2.1 Allgemein
Die ActionList ist eine in Java realisierte Bibliothek, mit welcher einzelne Aktionen über eine XML Datei konfiguriert
und als JobScheduler-Job gestartet werden können. Damit ist die ActionList das Herzstück für die Konfiguration
der Schnittstellenprozesse, die im JobScheduler letztendlich gesteuert und überwacht werden.
Die aktuelle freigegebene Version ist 2.2.
4.3.2.2 Actions
Der Aufbau einer ActionList, deren Actions, E-Mail-Schablonen und SAP-Konfigurationsdateien sind in XML Schema
Dateien dokumentiert.
Im Folgenden werden die vorhandenen Actions für Version 2.2 in Kürze beschrieben. Eine entwicklungstechnische
Dokumentation findet sich im JavaDoc.
Folgende Methoden stehen innerhalb der ActionList zur Verfügung:
4.3.2.3 Actions-Methoden
callWebService
Ruft einen WebService auf.
Beispiel callWebService
<callWebService logLevel="-3" title="call ws:login">

<url>${WebServices_BaseURL}XMLExportService/login</url>
<username>${WebServices_User}</username>
<passwordCrypted>${WebServices_PasswordCrypted}</passwordCrypted>
<cookieProperty>productdata</cookieProperty>
<outputFile>${vmwebservicedir}/response-login-product-data.xml</outputFile>
</callWebService>
....
<callWebService logLevel="-3" title="call ws:start export">
<url>${WebServices_BaseURL}XMLExportService/exportPublicationForID</url>
<requestParameters>
<requestParameter name="p_iPuunId" value="${pubid}"/>
...
</requestParameters>
<outputFile>${vmwebservicedir}/${toolName}-response.xml</outputFile>
</callWebService>
choose
Bietet die Möglichkeit, einfache Programmlogik auf Action-Ebene abzubilden.
Beispiel choose
<choose>
<when test="'${FileCounter}' = '0'">
<echo message="Bei 0"/>
</when>
<when test="'${FileCounter}' > '0'">
<echo message="Bei größer 0"/>
</when>
<otherwise>
<echo message="Falls nichts zurtifft"/>
</otherwise>
</choose>
cleanupEPIM
Löscht Protokolleinträge in EPIM.
Beispiel cleanupEPIM
copy
Kopiert Dateien in ein Zielverzeichnis. Kann zu kopierende Dateien über einen regulären Ausdruck einschränken.
Beispiel copy
<copy title="Copy zip to handover directory">

<file>${langWorkDir}/file.zip</file>
<targetDir>${handoverdir}</targetDir>
<targetFileName>copy_of_file.zip</targetFileName>
</copy>
createList
Erzeugt aus einer Verzeichnisstruktur eine Liste.
Beispiel createList
<createList title="Create list of files in Handover">

<sourceFolder>${handoverdir}</sourceFolder>
<listFolders>true</listFolders>
<listToFile>${sessionTempDir}\still_in_handover.xml</listToFile>
<ignoreEmptyList>true</ignoreEmptyList>
</createList>
delete
Löscht Dateien und Verzeichnisse. Kann zu löschende Dateien über einen regulären Ausdruck einschränken.
Beispiel delete
<delete dir="${langWorkDir}/toBeZipped/" recursive="true" ignoreNoFilesFound="true" title="Delete zipped

files"/>

echo
Gibt eine Nachricht an die Konsole und an das Prozessprotokoll aus.
Beispiel echo
<echo message="Hello World"/>
email
Sendet eine E-Mail über SMTP. Text- und HTML-basierte Emails sowie Anhänge werden unterstützt.


<email file="${emailDir}/export.email.xml" title="send report email"/>


TODO
executeJobschedulerXml
Führt ein JobScheduler XML Kommando aus (z.B. Order oder Job erstellen)
Beispiel executeJobschedulerXml
executeShell
Ruft ein Shellskript oder eine Windowskommandodatei auf. An die aufgerufene Datei können Parameter übergeben
werden.
Beispiel executeShell
exit
Beendet die aktuelle ActionList erfolgreich (z.B. innerhalb einer choose-Action).
Beispiel exit
extractValue
Extrahiert einen Wert aus einer XML Datei und stellt ihn als Property für die weitere Verarbeitung zur Verfügung.
Kann auch als Order-Variable an den JobScheduler eskaliert werden, um diese Variable in folgenden Jobs zu
nutzen.
Beispiel extractValue
Fail
Beendet eine ActionList kontrolliert (z.B. innerhalb einer choose-Action) mit einem Fehler.
Beispiel Fail
Fop
Ruft den Apache FOP auf, um ein PDF automatisch zu erstellen.
Beispiel Fop
forEachItemListXml / forEachItemList
Durchläuft für jedes item-Element einer angegebenen XML-Datei eine ActionList oder einzelne Actions. Alle
Attribute innerhalb des item-Elementes werden innerhalb der Schleife als Properties ausgeprägt und stehen dort
zur Verarbeitung bereit.
Beispiel forEachItemList
<forEachItemListXml itemListXmlFile="export-list-sessionID.xml" title="Say Hello World for each Item in

List">
<echo message="Hello World"/>
</forEachItemListXml>
forEachList
Durchläuft für jedes Listenelement einer angegebenen Listproperty eine ActionList oder einzelne Actions. Das
aktuelle Listelement wird als Property ausgeprägt und zur weiteren Bearbeitung bereit.
Beispiel forEachList
getDataFromSAP
Ruft Daten von SAP mittels RFC ab.
Beispiel getDataFromSAP
mkDir
Erzeugt ein Verzeichnis.
Beispiel mkDir
<mkdir dir="${langWorkDir}" title="Create langWorkDir"/>
move
Verschiebt Dateien in ein Zielverzeichnis. Kann zu verschiebende Dateien über einen regulären Ausdruck
einschränken.
Beispiel move
<move overwrite="true" title="Rename extension">

<file>${handoverdir}/sessionId.temp</file>
<targetFileName>sessionId.zip</targetFileName>
</move>
moveRootProcess
Verschiebt im Prozessprotokoll einen Prozessknoten inklusive dessen Kindelemente an die angegebene
Prozessknoten-ID. Dabei wird der angegebene Prozessknoten durch den verschobenen Knoten ersetzt.
Beispiel moveRootProcess
plannedProcessNode
Bildet innerhalb des Gesamtprozesses einen Prozessknoten ohne Funktionalität ab. In der Regel wird diese Action
eingesetzt, um als Anker für asynchrone Prozesse zu dienen.
Beispiel plannedProcessNode
property
Erzeugt/setzt eine Variable, die von folgenden Actions genutzt werden kann. Kann auch als Order-Variable an den
JobScheduler eskaliert werden, um diese Variable in folgenden Jobs zu nutzen.
Beispiel property


<property name="timeStamp" value="${date,yyyy-MM-dd_HH-mm-ss}" title="set TimeStamp" overwrite="true"
handout="true"/>


<echo message="${timeStamp}"/>
rename
Benennt ein Verzeichnis um.
Beispiel rename
reportEPIM
Gibt das Ergebnis einer SQL-Abfrage im EPIM Standard-Report-Format für XML oder CSV aus.
Beispiel reportEPIM
searchAndReplace
Sucht und ersetzt Zeichenketten. Arbeitet mit regulären Ausdrücken. Durch zeilenbasiertes Vorgehen können
beliebig große Dateien behandelt werden.
Beispiel searchAndReplace
<searchandreplace>
<sourceFolder>${sessionTempDir}\sessionDir\</sourceFolder>
<sourceFile>export-list-sessionID.xml</sourceFile>
<searchReplacePair searchPattern ="exportID=""" replacePattern="exportID="$
{vmexportID}""/>
</searchandreplace>
setOrderBack
Setzt die derzeit aktive Order des aktiven Jobs zurück. Über den Parameter delay_after_order_setback kann
innerhalb einer Jobkette eine Schleife realisiert werden.
Beispiel setOrderBack


<setOrderBack title="Set JobScheduler job order back"/>



<delay_order_after_setback setback_count="1" delay="200"/>

<delay_order_after_setback setback_count="25" is_maximum="yes"/>
setOrderState
Setzt den Status des aktuellen Jobs. Damit kann eine Verzweigung in Abhängigkeit des Prozessablaufs realisiert
werden.
Beispiel setOrderState
sleep
Unterbricht die Verarbeitung für den angegebenen Zeitraum.
Beispiel sleep
<sleep hours="1" minutes="15" seconds="15"/>
touch
Erzeugt eine leere Datei.
Beispiel touch
transform
Transformiert eine XML-Datei. Unterstützte Prozessoren sind:
• Xalan
• Saxon für XSLT 1.0
• Saxon für XSLT 2.0
• Xalan für STX
• Saxon für STX und XSLT 1.0
• Saxon für STX und XSLT 2.0
Beispiel transform
unzip
Entpackt eine ZIP-Datei
Beispiel unzip
validateXML
Validiert eine XML Datei gegen ein XML Schema (XSD).
Beispiel validateXML
zip
Erzeugt aus Dateien oder Verzeichnissen eine ZIP-Datei
Beispiel zip
<zip title="zips files">

<sourceFolder>${langWorkDir}/toBeZipped</sourceFolder>
<sourcePattern>.*</sourcePattern>
<targetDir>${langWorkDir}</targetDir>
<targetFileName>sessionIds</targetFileName>
</zip>
4.3.3 ProcessLogger
Der ProcessLogger ist die Schnittstelle für die Kommunikation zwischen Drittsystemen und Prozessprotokoll.
Das Logging ist in die ActionList in Verbindung mit dem SOS JobScheduler integriert. Dabei werden automatisiert
Prozesse und Sub-Prozesse für Job-Ketten, Jobs, ActionLists und Actions erzeugt. Ebenso werden Meldungen
weitergereicht und frei konfigurierbare Nachrichten übertragen.
Drittsysteme können per WebService-Aufrufe
• neue Prozesse und Sub-Prozesse erzeugen.
• Prozesse und Sub-Prozesse aktualisieren (z.B. Statusänderungen).
• Detailinformationen typisiert (Error, Warning, Info, Debug) eintragen.
4.3.4 SOS JobScheduler Zitiert von der Webseite www.sos-berlin.com

Der SOS JobScheduler wird zur Automation von Prozessen in Verbindung mit den Datenbanksystemen SQL Server,
Oracle (und auch anderen DB) eingesetzt. Mit dem JobScheduler können beliebige Programme, Skripte und
Datenbankprozeduren automatisch ausgeführt werden. Jobs können als Web Services zur Integration mit anderen
Applikationen konfiguriert werden.
Betriebsweise:
• Der JobScheduler ist ein als Daemon betriebenes Batch-Programm auf Unix und ein Dienst auf Windows
Systemen.
• Der JobScheduler wird mit JOC überwacht - eine JavaScript basierte Oberfläche, die im Browser läuft.
• XML Konfigurations-Dateien steuern, welche Programme oder Shell-Skripte wann und wie oft ausgeführt
werden sollen. Die ActionList von Viamedici stellt hier die Verbindung zu den Schnittstellenprozessen und
dem ProcessTracker her.
Verarbeitung von Jobs:
• Der JobScheduler verarbeitet Jobs in sequentiellen und parallelen Prozessen.
• Jobs können in Job-Ketten organisiert werden, um die Reihenfolge der Abarbeitung sicherzustellen und zur
Skalierung in mehreren Instanzen ausgeführt werden.
• Job können über Events wie z.B. Verzeichnisüberwachung, Kalenderereignisse, die Web-Benutzeroberfläche
oder mit dem JobScheduler API durch andere Applikationen (Java, Skript-Sprachen) gestartet werden.
Da der JobScheduler eine Standardsoftware ist, wird hier auf weitere Erläuterungen verzichtet. Weitere
Informationen zum JobScheduler finden sich unter http://www.sos-berlin.com.
Die Viamedici Software GmbH ist offizieller Partner von SOS Berlin.
4.4 Technische Dokumentation
4.4.1 Doku-Beispiel
Ein ERP-Interface ist ein Beispiel für die Abbildung eines komplexeren Prozesses unter Verwendung des PDK. Das
ERP-Interface dient deshalb als Grundlage für die Erläuterung der eines Gesamtprozesses bestehend aus
Schemadateien und Java.doc.
Die nachfolgende Abbildung stellt den Gesamtprozess der ERP-Schnittstelle mit seinen Job-Ketten, den Einzeljobs
und der konfigurierten ActionList dar. Für den Job „ERP-InterfaceGetData" wird exemplarisch ins Detail gegangen.
Abbildung 4: Übersicht PDK Beispiel
4.4.1.1 Start des Prozesses

Im Beispiel startet ein Anwender den Prozess, indem er in ein Übergabeverzeichnis (hier: D:/VMHANDOVER/erp-
interface/orders/start-erp-interface) eine Konfigurationsdatei (Dateinamen aufgebaut nach dem regulärem
Ausdruck jobstart-.*\.txt) kopiert. Falls notwendig, kann mithilfe dieser Konfigdatei der Prozess dynamisch
konfiguriert werden.
4.4.1.2 Job-Kette
Die Job-Kette schlägt dann in ihrer Konfiguration nach, welcher Job starten soll (hier: initialize, der innerhalb des
JobScheduler-live-Verzeichnisses unter /vm/erp-interface/initialize zu finden ist).
Job-Kette
<?xml version="1.0" encoding="ISO-8859-1"?>

<job_chain orders_recoverable="yes" visible="yes" title="erp-interface"max_orders="1">
<file_order_source directory="D:/VMHANDOVER/erp-interface/orders/start-erp-
interface"regex="jobstart-.*\txt" max="1"/>
<job_chain_node state="initialize" job="/vm/erp-interface/
initialize"next_state="getdata"error_state="initialize-error"/>
<job_chain_node state="initialize-error" job="/vm/erp-interface/initialize-error"next_state="error"
error_state="error"/>
<job_chain_node state="getdata" job="/vm/erp-interface/getdata"next_state="checkimport"
error_state="getdata-error"/>
<job_chain_node state="getdata-error" job="/vm/erp-interface/getdata-error"next_state="error"
error_state="error"/>
…
<file_order_sink state="error"move_to="D:/VMBACKUP/erp-interface/orders/error"/>
<file_order_sink state="success"move_to="D:/VMBACKUP/erp-interface/orders/success"/>
</job_chain>
Hinweis: Über die JobScheduler GUI können Konfigurationen von Job-Ketten und Jobs eingesehen werden.
Abbildung 5: Job-Ketten-Übersicht in der JobScheduler Oberfläche beim PDK-Beispiel

Ebenso können Job-Ketten über „Orders" auch manuell gestartet werden.
Abbildung 6: Manueller Start einer Job-Ketten-Order
4.4.1.3 Job
In der Job-Konfigurationsdatei ist die Job-Implementierung hinterlegt Hier handelt es sich um einen in Java
implementierten Job, der die JobScheduler übergebenen Konfigurationsdatei ausliest und aus den Name-Werte-
Paaren JobScheduler Order-Variablen setzt, die in nachfolgenden Jobs genutzt werden können.
Job

<job order="yes" stop_on_error="no" title="initialize">
<params>
<param name="JobsOrder" value="yes"/>
<param name="showParams" value="yes"/>
<param name="debug" value="1"/>
</params>
<script language="java" java_class="org.vm.jobschedulerlib.parseNameValuePairs"
java_class_path="vmJavaLib.jar"/>
<run_time />
</job>

Für dieses Beispiel gehen wir davon aus, dass das Auslesen fehlerlos gelingt. Da der Job erfolgreich verlief, findet
die Job-Kette unter next_state den Job getdata und startet diesen.
4.4.1.4 ActionList
Der Job getdata ist als ActionList implementiert. Dazu wird die ActionList-Library eingebunden und die ActionList
Konfigurationsdatei angegeben.
ActionList

<job order="yes"
stop_on_error="no"
title="ERP_InterfaceGetData">
<params>
<param name="log_level" value="-3"/>
<param name="actionListFile" value="D:/VMPROGRAMS/erp-interface/actionlists/
getdata.actionlist.xml"/>
</params>
<script language="java" java_class_path="ActionList.jar"
java_class="org.vm.actionlist.JobschedulerJob"/>
<run_time/>
</job>
Wenn der Job gestartet wird, wird die ActionList Konfigurationsdatei eingelesen. Für die folgende ActionList gilt ein
granularer logLevel, der alle debug-Informationen über den Prozess Logger an das Prozess Protokoll meldet. Dabei
bleiben die erzeugten Prozesse sowie die Meldungen zwei Tage (logLifetime) stehen. Die einzelnen Actions werden
nacheinander ausgeführt. In dem folgenden Beispiel wird zunächst eine zeitstempelbasierte sessionID als
ActionList-Property deklariert, dabei vorhandenen Properties überschrieben sowie Name und Wert der Property für
die Übergabe an die Job-Kette als Ordervariable vorgemerkt. Anschließend wird die SessionID für den
ProcessLogger explizit ausgegeben.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<actionList xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../
org.vm.actionlist.ActionList.xsd" logLevel="-9" logLifetime="2" title="getdata">
<actions>

<property name="sessionID" value="${date,yyMMddHHmmssSSS}" overwrite="true" handout="true"
title="create and handout sessionID"/>
<echo message="Generate a unique session ID and handout property sessionID to jobscheduler:
sessionID = ${sessionID} "/>

<fail/>
</actions>
</actionList>
Mittels der Action fail ist für dieses Beispiel sichergestellt, dass die ActionList mit Fehler abgebrochen wird. Damit
ist auch der Job mit Fehler beendet. Dementsprechend verzweigt die Job-Kette nun in den Job mit der
Fehlerbehandlung (error_state). Da an diesem Job die Endnote error als next_state angegeben ist, ist die
Abarbeitung der Job-Kette nach dem Verschieben des ursprünglichen Konfigurationsdatei nach D:/VMBACKUP/erp-
interface/orders/errordamit abgeschlossen.
4.4.2 JobScheduler
Für die Konfiguration des JobSchedulers lesen Sie bitte die technische Beschreibung unter http://www.sos-
berlin.com/doc/de/scheduler.pdf.
4.4.3 XML Schema Dateien

Die Konfiguration der ActionList wird mit XML-Schemadateien unterstützt, die erläutern, welche XML Elemente und
Attribute erlaubt sind. Es liegen Schemadateien vor für:
• Struktur der ActionList (org.vm.actionlist.ActionList.xsd)
• Vorlagedateien für emails (org.vm.actionlist.email.Email.xsd)
Zum Betrachten der XML Schema Dateien ist die Open Source Software XSD Diagram geeignet (http://
regis.cosnier.free.fr/?page=XSDDiagram).
Der folgende Screenshot ist dieser Software entnommen und zeigt einen Ausschnitt von
org.vm.actionlist.ActionList.xsd:
Abbildung 7: Beispielhafte Darstellung des ActionList XML Schemas
4.4.4 JavaDoc
Die XML Schema Dateien werden ergänzt durch eine JavaDoc. Dort werden die erlaubten XML Elemente und
Attribute der einzelnen Actions im Detail beschrieben. Öffnen Sie dazu die JavaDoc über index.html mit einem
Browser.
4.4.5 Process Logger WebService API

Drittsysteme können per SOAP WebService API den ProcessLogger über die Basis-URL http://%JobScheduler-
host%:%JobScheduler-port%/pdkService ansprechen.
Es stehen folgende Methoden zur Verfügung:
• login: Login inkl. Starten einer Session.
• loginEncrypted: Login mit verschlüsseltem Password inkl. Starten einer Session.
• createProcess: Erstellen eines neuen (Sub-)Prozesses.
• updateProcess: Aktualisiert einen Prozess.
• setState: Setzen des Status eines Prozesses inkl. automatischem Setzen weiterer Prozesse.
• addDetail: Erstellen eines neuen Detaildatensatzes/Meldung zu einem Prozess.
• setLoopProgress: Melden des Fortschritts bei Schleifen (z.B. 5. Durchlauf von 5000).
Details zu den Methoden können der Javadoc entnommen werden. Zur vereinfachten Integration von Dritten steht
eine WSDL-Dokumentation zur Verfügung.
4.4.6 Anwendungsbeispiel
In diesem Kapitel wird ein kleines Beispiel für die Lösung einer Aufgabe mit Hilfe des PDK beschrieben.
Aufgabe:
Es soll eine XML-Datei von A nach B kopiert werden. Im Zielverzeichnis wird diese Datei 2 Mal transformiert und
anschließend eine Mail versendet.
4.4.6.1 Grafische Visualisierung des Gesamtprozesses
Abbildung 8: Überblick WebService Anwendungsbeispiel
4.4.6.2 ActionList aufbauen

Durch das Verwenden der Schemadatei und einem geeigneten Tool wird der entworfene Prozess in eine Acitonlist
überführt.
ActionList aufbauen
<?xml version="1.0" encoding="UTF-8"?>

<actionList xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../ActionList/org.vm.actionlist.ActionList.xsd">
<actions>
<property name="sourcedir" value="//opt/viamedici/jobscheduler.work/scheduler/
config/live/comspace"/>
<property name="targetdir" value="//data/exchange/epimFS/produktion/_hybris"/>
<property name="filename" value="beispiel.xml"/>
<property name="workDir" overwrite="true" value="${targetdir}"/>
<copy title="Kopiern von A nach B" ignoreNoFilesFound="true">
<file>${sourcedir}/${filename}</file>
<targetDir>${targetdir}</targetDir>
<targetFileName>copy_${filename}</targetFileName>
</copy>
<executeShell title="call shell with ls -l">

<executable>${sourcedir}/beispiel.sh</executable>
</executeShell>
<transform title="Transformieren 1">

<xslProcessor>xalan</xslProcessor>
<inputFile>${sourcedir}/${filename}/</inputFile>
<stylesheet>${sourcedir}/IG.xsl</stylesheet>
<outputFile>${targetdir}/output2.xml</outputFile>
</transform>
<transform title="Transformieren 2">

<xslProcessor>xalan</xslProcessor>
<stylesheet>${sourcedir}/IG.xsl</stylesheet>
<outputFile>${targetdir}/output3.xml</outputFile>
</transform>
<extractvalue xpath="//row[1]/field[1]/." file="${sourcedir}/${filename}"
propertyName="wert" title="read value"/>
<choose>
<when test="${wert}=5" title="analyse property wert">
<echo message="Meldung 1 ausgeben"/>
</when>
<otherwise>
<echo message="Meldung 2 ausgeben"/>
</otherwise>
</choose>
</actions>
</actionList>
4.4.6.3 Job definieren

Wie die Jobstruktur aufgebaut ist und welche Möglichkeiten man hat entnehmen sie bitte der JobScheduler-
Dokumentation.
Job definieren

<job order="no" stop_on_error="no" title="hybris_initialisation">
<params>
<param name="log_level" value="-3"/>

<param name="actionListFile" value="/opt/viamedici/jobscheduler.work/scheduler/
config/live/comspace/beispiel.actionlist.xml"/>
</params>
<script language="java" java_class_path="/data/exchange/vmprograms/javaEnvironments/
ActionList/*" java_class="org.vm.actionlist.JobschedulerJob"/>
<run_time/>
</job>
4.4.6.4 Job über JobScheduler aufrufen

Über die JobScheduler Oberfläche kann der Job wie im Folgenden gezeigt nach Rechtsklick auf den Job direkt
gestartet werden.
Abbildung 9: Aufruf Job für WebService Anwendungsbeispiel
4.4.6.5 Prozessprotokoll
Nach dem Aufruf über den JobScheduler wird die gesamte Struktur des Jobs als Prozesskette abgebildet:
Abbildung 10: Ansicht Prozessprotokoll für WebService Anwendungsbeispiel
5 PDK-Module
5.1 PDK-AssetProcess
5.2 PDK-Dispatcher
5.3 PDK-Housekeeping
5.4 PDK-Indesign
PDK-Module – 35
6 Installation
6.1 Upgrade des PDK

"Upgrade" heißt: Backup + Deinstallation + Installation.
Unbedingt Backups der alten Jobs und Programmordner anlegen, um später Jobs zu übernehmen und
Konfigurationsaufwand zu sparen!
1) Zu Backup-Zwecken diese Ordner zippen:
PDK\ActionList
PDK\fop
PDK\jobscheduler\***\scheduler\data\config
PDK\jobscheduler\scheduler\jobs
Die JobScheduler-Jobs können je nach Version auch z.B. liegen in:
• VMPROGRAMS\scheduler\config\live
• VMPROGRAMS\scheduler-data\scheduler\vm
• VMPROCESSES\PDK\jobscheduler\scheduler\scheduler_data\config\live
• VMPROCESSES\scheduler-live
2) Die Backup-ZIP-Dateien im VMINSTALL-Unterordner ablegen, den man mit Datum (JJJJ-MM-DD) für die PDK-
Installation anlegt.
3) Folgende Dateien müssen in die neue Installation mitgenommen werden:
actionlist\fop\conf\fop.xconf
Konfigurationsdatei für FOP. Speicherort ist bei alten PDK-Installationen unterschiedlich. Ab v.2.7.0 liegt sie
standardmässig in D:\VMPROGRAMS\PDK\actionlist\fop\conf
actionlist\global.properties
Einträge bzw. Werte, welche in der neuen Standard-Datei nicht enthalten sind, müssen übernommen
werden.
jobscheduler\scheduler\scheduler_data\config\factory.ini
Folgende Einträge müssen in die neue Installation übernommen werden:
mail_on_error
mail_on_warning
mail_on_success
mail_on_process
log_mail_from
log_mail_to
log_mail_cc
log_mail_bcc
smtp
log_level
mail.smtp.user
mail.smtp.password
mail.smtp.port
jobscheduler\scheduler\scheduler_data\config\scheduler.xml
Eventuell vorhandene <http_server > - Elemente müssen mit in die neue Datei.
Installation – 36
4) Service-Owner des alten JobSchedulers und der MariaDB notieren.

5) JobScheduler und der MariaDB deinstallieren.
6.2 Installation des PDK
6.2.1 Anlage der Standardverzeichnisse

Die Ordner liegen in D:\VMINSTALL\<DATUM>-PDK-Installation\<Version>\01_Standardverzeichnisse
Nach dem Kopieren:
Ordner D:\VMPROGRAMS\PDK\java öffnen
Je nach Betriebssystem nun einen der Unterordner "jdk_linux" oder "jdk_windows" in "jdk" umbenennen,
den anderen Ordner löschen.
HINWEIS von Horst:
Bei bestehender Standard-EPIM3.9-Installation sind, Stand 2016-12-07, nur folgende Ordner mit offensichtlich
benötigtem Inhalt zu kopieren aus dem o.g. Archiv:
VMLOGS\jobscheduler
VMPROCESSES
VMPROGRAMS
VMTOOLS => vorhandene Tools NICHT überschreiben (z.B. FirefoxPortable, Notepad++, sqldeveloper)
Installation – 37
6.2.2 Installation der mariadb in VMPROGRAMS/PDK/MariaDB
6.2.2.1 Schritt 1:
„I accept …“ + „Next“
Installation – 38
6.2.2.2 Schritt 2:
„Third party tools“ entfernen

"Location" des „MariaDB Server“ ändern auf D:\VMPROGRAMS\PDK\MariaDB\ (siehe Screenshot)
„Next“ klicken
Installation – 39
6.2.2.3 Schritt 3:
„New root password“ = ViamediciPDK

Hinweis: „Enable access from remote machines for ‚root‘ user“ nur mit gutem Grund aktivieren, sonst
deaktiviert lassen.
„Use UTF8 …“ aktivieren + „Next“
Installation – 40
6.2.2.4 Schritt 4:
„Buffer pool size“ auf voreingestelltem Wert lassen.
Installation – 41
6.2.2.5 Schritt 5:
Next“, im nächsten Fenster dann „Install“, danach „Finish“

Installationsbeschreibung (incl. Silent Install):
https://mariadb.com/kb/en/mariadb/installing-mariadb-msi-packages-on-windows/
6.2.3 DB-Script ausführen

Win Startmenü > „MariaDB 10.1 (x64)“ > „MySQL Client (MariaDB 10.1 (x64))“ starten
RootPass: ViamediciPDK eingeben
Dann folgendes Script ausführen (Pfad anpassen) in der „Dosbox“ des MySQL Client
source D:\VMINSTALL\<DATUM>-PDK-Installation\<Version>\02_MariaDB\CreateDB.sql
Ergebnis sollte ungefähr so aussehen:
Installation – 42
Danach „exit“ [ENTER].
6.2.4 Anpassen der my.ini

Ersetzen der d:\VMPROGRAMS\PDK\MariaDB\data\my.ini durch VMINSTALL\<DATUM>-PDK-
Installation\<Version>\02_MariaDB\my.ini
 Die Zeile „log-bin=mysql-bin“ unbedingt auskommentieren! (Dies ist in der neuen my.ini aus VMINSTALL
bereits der Fall)
 WICHTIG: Anschließend den MariaDB-Dienst namens „MySQL“ neu starten!
6.2.5 Ausführen der JobScheduler-Auto-Installation

Voraussetzungen:
Der Ordner VMPROGRAMS\PDK\java\jdk muss existieren.
Wenn nicht auf Laufwerk D installiert wird:
In den Dateien jobscheduler_install.xml und setup.cmd nach "D:" suchen und durch "E:" ersetzen (Pfade:
siehe "CMD" unten).
CMD öffnen:
cd /d D:\VMINSTALL\<DATUM>-PDK-
Installation\<Version>\03_JobScheduler\jobscheduler_x64_<Betriebssystem>
<Betriebssystem> steht dabei für Linux oder Windows (nicht den "Universal Agent" nehmen!).
Nun folgenden Befehl ausführen (ggf. JRE_Home in setup.cmd oder setup.sh vorher anpassen):
setup ../autosetup/jobscheduler_install.xml
Installation – 43
 WICHTIG: Der Dienst startet NICHT (es erscheint die untenstehende Fehlermeldung). Zum Dienststart
müssen wir die sos.ini und factory.ini anpassen – siehe nächster Schritt.
Diese Meldung ist also „normal“:
Wichtig bei manueller Installation:
6.2.6 Anpassen von sos.ini, factory.ini und scheduler.xml

Ordner VMPROGRAMS\PDK\jobscheduler\scheduler\config öffnen
Die Default-Dateien sos.ini, factory.ini und scheduler.xml sichern durch einzelnes Zippen ...
... und danach durch die neuen Dateien aus diesem Ordner ersetzen: D:\VMINSTALL\<DATUM>-PDK-
Installation\<Version>\03_JobScheduler\default-config
Hinweis: Wenn nicht auf Laufwerk D installiert wird: VOR dem Kopieren in den drei ini-Dateien aus der
"default-config" nach "D:" suchen und durch "E:" ersetzen.
Für Linux: ggf. in factory.ini und sos.ini die vm-Einträge anpassen.
Änderungen im Detail (einfach überspringen, wenn die Dateien durch die neuen Versionen ersetzt werden):
----------------------------------------------------------------------------------------------------------------------------------------------------------
------------------
sos.ini
Die auskommentierten Zeilen „vm“ und „options“ aktivieren und wie folgt umstellen:
Installation – 44
vm -> aktiv schalten, Pfad von bin\client auf bin\server ändern

options -> aktiv schalten, Wert ändern auf –Xmx2048m
Die (im Standardfall) korrekten Settings der sos.ini sind dann:
[java]
vm = d:\VMPROGRAMS\PDK\java\jdk\jre\bin\server\jvm.dll
options = -Xmx2048m
factory.ini
class_path -> „D:/VMPROGRAMS/PDK/actionlist/actionlist.jar“ + Strichpunkt an den Anfang setzen
vm -> aktiv schalten, Pfad von bin/client auf bin/server ändern (siehe unten)
Ergebnis:
vm = "d:\VMPROGRAMS\PDK\java\jdk_linux\jre\lib\amd64\server\libjvm.so" (Installation auf
Linux)
vm = "d:\VMPROGRAMS\PDK\java\jdk\bin\server\jvm.dll" (Installation auf Windows)
log_dir = D:/VMLOGS/jobscheduler
log = D:/VMLOGS/jobscheduler/scheduler.log
scheduler.xml:
im Element "config" das Attribut "configuration_directory" wie folgt anpassen:
<config mail_xslt_stylesheet = "config/scheduler_mail.xsl" port = "4444" configuration_directory="D:/
VMPROCESSES/scheduler-live">
----------------------------------------------------------------------------------------------------------------------------------------------------------
------------------
6.2.7 Den JDBC-Treiber tauschen

Alten Treiber löschen: …\VMPROGRAMS\PDK\jobscheduler\scheduler\lib\jdbc\mariadb-java-client-1.1.7.jar
Neuen Treiber einfügen: 03_JobScheduler\MariaDB_JDBC\mariadb-java-client-1.5.3.jar
6.2.8 Altes Jobverzeichnis leeren

• Den Inhalt des Verzeichnisses D:\VMPROGRAMS\PDK\jobscheduler\scheduler\config\live bis auf die
Readme.txt leeren. Die Jobs liegen ja jetzt woanders
6.2.9 SOS JobScheduler-Dienst namens „SOS JobScheduler -id=scheduler“

starten
Nach dem Start sollte der Dienst dann auf "Running" stehen in den Windows-Diensten.
Hinweis: Wenn sich der JobScheduler nicht gestartet werden kann, z.B. mit "Fehler 1053: Der Dienst antwortete
nicht rechtzeitig auf die Start- oder Steuerungsanforderung" => prüfen, ob z.B. in den ini-Dateien (wie sos.ini, s.o.)
der falsche Pfad verwendet wird => ggf. nach "D:" suchen und durch "E:" ersetzen, falls auf E: installiert wurde.
Installation – 45
6.2.10 Deinstallation möglich machen

Datei öffnen: D:\VMPROGRAMS\PDK\jobscheduler\scheduler\Uninstaller\uninstall.cmd
Zeile vorher:
start javaw.exe -jar "%~dp0uninstaller.jar
Zeile nachher:
start D:\VMPROGRAMS\PDK\java\jdk\bin\javaw.exe -jar "%~dp0uninstaller.jar"
 to-do: Korrekte Angaben für Linux ergänzen.
6.2.11 Konfiguration der Actionlist

Bei einem JobScheduler-Upgrade einfach die Global.properties transferieren:
• Die Datei global.properties einer Alt-Installation aus dem Backup bzw. dem Ordner
D:\VMPROGRAMS\javaEnvironments\ActionList
• transferieren nach (vorher die dort existierende Datei zippen):
D:\VMPROGRAMS\PDK\actionlist
• Die u.g. "nötigen Anpassungen" entfallen dank dieses Transfers!

Bei einer JobScheduler-Neuinstallation:
Datei öffnen: VMPROGRAMS\PDK\actionlist\global.properties
Hinweis1: Wenn nicht auf Laufwerk D installiert wird: nach "D:" suchen und durch "E:" ersetzen.
Hinweis2: Verschlüsselte Passwörter in der global.properties werden mit dem vmpsCipher-Tool erstellt (siehe PS-
Subversion unter SW+Tools\vmpsCipher)
Stets nötige Anpassungen an der standardmäßig ausgelieferten Datei global.properties:
EPIM_ConnectString
EPIM_JdbcDriver
EPIM_User
EPIM_PasswordCrypted
------------------------------------------------------------
6.2.12 Installation des JobScheduler Operations Center (JOC-Cockpit)
6.2.13 //Horst, 2017-12-05, erstmals auf Rehau_TEST
Nur Sichtpunkte bei der Installation des JobScheduler 1.11.5 (Mindestvoraussetzung ist 1.11.4)
Installation – 46
Installation – 47
Installation – 48
Voraussetzung, um den Dienst zu starten

• Ausführen:
D:\VMPROGRAMS\PDK\JOC\service\set_java_home_for_jetty_windows_service.cmd D:
\VMPROGRAMS\PDK\java\jdk\jre
(ich habe den Dienst sonst nicht starten können)
• Gleiche DB-Verbindung wie JobScheduler eintragen.
Eine Quelle (DB-Verbindung hieraus nehmen):
PDK/joc/resources/joc/jobscheduler.hibernate.cfg.xml
Zwei Ziele:
PDK/joc/resources/joc/reporting.hibernate.cfg.xml
PDK\jobscheduler\scheduler\config\hibernate.cfg.xml
• Erst nach einem Daemon-Server-Windows-Restart startete der Dienst!
Installation – 49
Test am Ende:
http://localhost:4446/joc/
JOC-Anmeldung mit root/root
Installation – 50
7 Standardverzeichnisse
7.1 Standardverzeichnisse in der Kunden-Umgebung
7.1.1 Übersicht
Standardverzeichnisse – 51
7.1.2 Erläuterung
Das übergeordnete Verzeichnis "KUNDENSERVER_ROOT" muss nicht für alle Fälle auf dem selben Server liegen. So
sind z.B. EPIMFS und EPIMHOME normalerweise auf dem Applicationserver zu finden, wohingegen sämtliche VM* -
Verzeichnisse auf dem (ersten) Daemonserver liegen.
Verzeic Erklärung
hnis
EPIMFS Dateisystem für Anwendungen (z.B. EPIM, ECAT, ECOM).

Die wesentlichen Verzeichnisse für PS sind zur Verdeutlichung abgebildet.
EPIMH Wurzelverzeichnis für (Java-)Anwendungen, welche innerhalb des von EPIM genutzten Apache
OME WebServer deployt werden sollen.
Enthält damit auch EPIM. Für PS wesentlich sind hier die Properties-Dateien unter %EPIMHOME%/
viaMEDICI/WEB-INF/classes/resources.
Enthält auch weitere kundenspezifische Webapplikationen (z.B. Review Portal, Interaktive
Vorschau,...). In der httpd des Apaches dann httpd-vm%NameApplikation%.conf (liegt in
%APACHEHOME%/conf/extra) einhängen. Ob die EPIM-Tomcats mitgenutzt werden oder eigene
deployt werden, muss je Applikation mit der IT abgestimmt werden.
VMBAC Backups von einzelnen Anwendungen und Prozessen werden hier abgelegt.
KUP
Je Prozess ist ein Unterverzeichnis einzurichten.
Wichtig:
Es gibt keine implizite Archivierungsfunktion! Wenn etwas langfristig gesichert werden muss, dann
muss dies kundenspezifisch eingerichtet werden.
VMHAN Prozessspezifische Übergabeverzeichnisstruktur. Der detaillierte Aufbau hängt von dem gewählten
DOVER Übergabeverfahren ab.
Übergebende Anwendungen und Prozesse legen inhaltliche Dateien innerhalb input in einem
Sessionverzeichnis ab.
Konfigurationsdateien (aka starter-Dateien) werden in start abgelegt.
VMINST Ablage für Installationsdateien und Konfigurationstransport.

ALL
VMLOG Log-Dateien der Anwendungen und Prozesse.

S
Jobscheduler-Logdateien sollten hier im Unterverzeichnis "jobscheduler" liegen.
Prozesse sollten ins Prozessprotokoll loggen, können aber zusätzlich hier noch Textlogs ablegen falls
erforderlich.
Verzeic Erklärung
hnis
VMPRO Verzeichnisstruktur für Prozesse. Domäne von Professional Services.

CESSES
In scheduler-live befinden sich die Job- und JobKetten definitionen für den Jobscheduler.
In der %CUSTOMER%-config.xml sind alle die EPIM-Umgebung betreffenden Basispfade hinterlegt.
In common werden Prozesse oder Prozessteile abgelegt, welche von mehreren anderen Prozessen
wiederverwendet werden.
Innerhalb eines Prozesses gibt es die folgenden Standardverzeichnisse. Kundenspezifische
Erweiterungen sind nicht ausgeschlossen.
• actionlists: actionlist-Dateien
• config: Konfigurationsdateien
• documentation: technische Dokumentation, Pfade, Konfigurationsdoku.
• email: Email-Vorlagen
• resources: InDesign-Vorlagen oder PAR-Dateien für InDesign-Server, CSS und Bilder für HTML-
Ausleitungen, Dateien für Test-Läufe; Grundsätzlich alles, was für den Betrieb eines Prozesses
notwendig ist und nicht in die anderen Verzeichnisse passt.
• scripts: Sonstige Scripte wie Javascript oder batch. Sollte die Ausnahme sein.
• xsl: Transformationsdateien, vorwiegend xslt, stx
VMPRO Verzeichniss für EPIM-relevante Programme. z.B. PDK, masterdaemon usw.

GRAMS
Hauptsächlich von der IT verwendet.
VMTEM Sonstige temporäre Dateien.

P
 Der Inhalt von VMTEMP könnte zu Platzgewinnungszwecken unangekündigt gelöscht

werden. Daher bitte wirklich ausschließlich unwichtige Arbeitsdaten ablegen.
VMTOO Sämtliche weitere Tools und Anwendungen, welche nicht direkt für den Betrieb von EPIM notwendig
LS sind. z.B. Notepad++, sqldeveloper, curl o.ä.
Verzeic Erklärung
hnis
VMWOR Arbeitsverzeichnis für Prozesse

K
Prozesse sollten stets innerhalb einer abgeschlossenen Session und dementsprechendem
Verzeichnis behandelt werden.
Bei komplexeren Prozessen sind tiefere Unterstrukturen wie z.B. %jobname% zu empfehlen.
 Ältere Sessionverzeichnisse unterhalb von VMWORK könnten zu Platzgewinnungszwecken

unangekündigt gelöscht werden. Daher bitte wirklich ausschließlich Arbeitsdaten ablegen.
Daten, welche noch benötigt werden können, in VMBACKUP gesichert werden.
 Bei einfachen Publikationsprozessen hat es oft Sinn, im Exportverzeichnis zu bleiben.

Allerdings können die Pfade dann u.U. zu lang für die Verarbeitung werden.

Für die Verzeichnisse VMBACKUP/VMLOGS/VMHANDOVER/VMTEMP/VMWORK gilt grundsätzlich, dass darununter
für jeden Prozess ein Verzeichnis ${processName} angelegt wird, in welchem dann einzelne Sessionverzreichnisse
liegen (z.B. D:/VMWORK/template-process/20161012_123427).
7.2 Standardverzeichnisse in der lokalen Umgebung/Subversion

Das neue PS-Subversion-Repository ist unter folgender Adresse zu finden:
http://192.168.100.199/ps/trunk
Es gibt dort aktuell die folgenden Verzeichnisse, welche einzeln per Checkout aus dem Repository gezogen und
direkt auf D: abgelegt werden sollten.
Pfad Ebene 1 Pfad Ebene 2 Pfad Ebene Inhalt

3
SV-PS- %KUNDENNAM Archiv Ablage für Daten aus dem alten SVN, welche nicht
Implementieru E% verifiziert sind oder noch nicht auf aktuelle PDK-
ng Strukturen angepasst wurden.
 Bei der Übernahme sollten die Daten geprüft

werden auf Sinnhaftigkeit, z.B sollten alte
Exporte, logs, temporäre Dateien nicht mit
übernommen werden!
Pfad Ebene 1 Pfad Ebene 2 Pfad Ebene Inhalt

3
EPIMFS Kundenspezifische Dateien aus EPIMFS vom

Kundensystem
EPIMHOME Kundenspezifische Dateien aus EPIMHOME vom

Kundensystem
MISC Dinge, die nicht in die anderen Verzeichnisse passen
PDK-config factory.ini, sos.ini und scheduler.xml aus der

JobScheduler-Installation des Kunden, global.properties-
Datei der actionlist
VMPROCESS Inhalt VMPROCESSES des Kunden, muss zum bearbeiten/

ES testen in das eigene, lokale VMPROCESSES/Kundenname-
Verzeichnis kopiert.
siehe Kapitel Standardverzeichnisse und actionlist/
Konfiguration
VMPROCESSES/scheduler-live
Inhalt des JobScheduler live Ordners des Kunden, muss
zum bearbeiten/testen in das eigene, lokale live-
Verzeichnis (default: D:/VMPROCESSES/scheduler-live/
Kundenname) kopiert werden
SV-PS-Presales Presales-Ablage, analog zu bisherigem SVN
SV-PS- PDK PDK und dessen Standard-Module und Installer

Produkte
%PS- Hier werden sämtliche von PS erstellten Produkte, deren

Produkt% Sourcen und Installer hinterlegt
SV-PS-Projekt Ablage für Dokumentenvorlagen
SV-PS-Tools SW+Tools-Order aus altem SVN
8 actionlist
Generierung für xml-Schema-Dateienfür actionlist/email-Template/SAPConnectionConfiguration/SAP
RFCConfiguration:
d:\VMPROGRAMS\PDK\actionlist>java -cp actionlist.jar org.vm.actionlist.CreateXMLSchema
8.1 Actions
In den folgenden Kapiteln sind Beschreibungen sämtlicher actions inklusive Beispielen zu finden.
Neben den action-spezifischen Attributen gibt es noch allgemeine, welche bei allen actions verwendet werden
können.
Diese sind:
Attribut Beschreibung
logLevel Gibt den Detailierungsgrad des Logging an. Näheres dazu im Kapitel "Logging"
logLifetime Wert (in Tagen), der angibt, wie lange Prozessprotokolleinträge behalten werden sollen. Nicht
auf ganze Tage beschränkt (0,25 = 6 Stunden)
errorOffset Wert (in Tagen), der angibt, wie lange Prozessprotokolleinträge im Fehlerfall zusätzlich zur
logLifetime behalten werden sollen.
title Titel, der im Prozessprotokoll und im Log angezeigt wird.

Anwendungsbeispiel
<mkdir dir="D:/Verzeichnis" logLevel="-7" logLifetime="2" errorOffset="14" title="Hier wird ein Verzeichnis

erstellt!" />
8.1.1 callRFC *TO DO*

"callRFC" ruft SAP RFCs auf.
Config-Dateien müssen wie folgt aufgebaut sein:
actionlist – 57
Beispiel Config-Datei

<config>
<property name="property_01" value="value_01"/>
<property name="property_02" value="${property_01}_value_02"/>
<property name="property_03" value="${property_01}_value_03" handout="true" overwrite="true" />
<property name="property_04" value="${property_01}_value_04" handout="true" overwrite="true" mode="all"
/>
<property name="property_05" value="${property_01}_value_05" handout="true" overwrite="true"
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
<property name="property_07" value="${property_01}_value_07" handout="true" overwrite="true" mode="QA"/
>
mode="PROD"/>
</config>
Als Pflicht-Attribute müssen "name" und "value" gesetzt werden. Bei "value" kann Bezug genommen werden auf
davor bereits gesetzte Variablen.
Zusätzlich gibt es noch folgende, optionale Attribute:
handout handout legt fest, ob die property an die nächste actionlist mitgegeben werden soll.
Mögliche Werte: true/false
overwrite overwrite legt fest, ob die property überschrieben werden soll, falls sie bereits existiert.
mode mode definiert einen Modus, der beim laden einer Config-Datei mit angegeben werden
kann.Wenn mode nicht vorhanden oder auf "all" gesetzt ist, dann wird die property immer
geladen.
Ansonsten wird der mode-Wert mit dem in der action angegebenen Wert verglichen.
Standardmässig wird als mode die location-Variable (siehe Konfiguration/global.properties)
verwendet, es kann aber jeder beliebeige Wert gesetzt werden.
Der Syntax der config-action ist wie folgt:
actionlist – 58
Anwendungsbeispiel


<config action="load" file="${customerConfigFile}" handout="true" overwrite="true" />


<config action="load" file="${processConfigFile}" handout="true" overwrite="true" mode="${location}" />


<config action="save" file="${saveConfigFile}" />


<config action="save" file="${saveConfigFile}"
propertyList="errorFlag;errorFlagCleanup;customerConfigFile" />
Beim Laden (action="load") funktionieren die Attribute "handout" und "overwrite" als Standardvorgabe für die
gesamte Datei und werden von abweichenden Werten für einzelne properties übersteuert.
Beim Speichern (action="save") werden entweder alle bekannten properties gespeichert oder es kann eine
"propertyList" angegeben werden. Dabei handelt es sich um eine Semikolon-getrennte Liste von properties, welche
als Filter für zu speichernde properties dient. Beim Speichern werden handout und overwrite nicht gesetzt.
8.1.2 callWebService *TO DO*/TB

"callWebService" dient zum aufrufen von REST services mit den Methoden GET, POST und PUT.
Vorraussetzung ist der vorherige Login.
Informationen aus der Entwicklung zu REST und allen Services : REST-Aufruf2
Informationen zum Login: 2017-11-21_16-30-14_loginEncrypted_web_service_operation (see page 59) oder login
(Web-Service-Operation)3
Attribut P Beschreibung
f
li
c
h
t
?
url Angabe welcher Service angesprochen werden soll.
usernam Datentyp: String. Erforderlicher Parameter. Anmeldename des Viamedici EPIM Benutzers.

e
2 http://192.168.1.222:8090/display/VD/.REST_Aufruf+v3.9.28
3 http://192.168.1.222:8090/display/VD/.login_Web_Service_Operation+v3.9.28
actionlist – 59
Attribut P Beschreibung
f
li
c
h
t
?
passwor Datentyp: String. Erforderlicher Parameter. Passwort des Viamedici EPIM Benutzers.

dCrypte
d
cookieP
roperty
outputF Datei in der die Antwort / das Ergebnis des Services gespeichert/dokumentiert wird
ile
request Parameter die beim Service-Aufruf übergeben werden. Abhängig vom gerufenen Service siehe
Paramet Dokumentation der einzelnen Services
er
httpHead
ers
ignoreEr
ror
inputFil
e
Der Syntax der callWebService-action ist wie folgt:
actionlist – 60
Anwendungsbeispiel


<callWebService logLevel="-3" title="call ws:login">
<url>${WebServices_BaseURL}XMLExportService/login</url>
<username>${WebServices_User}</username>
<passwordCrypted>${WebServices_PasswordCrypted}</passwordCrypted>
<outputFile>${vmwebservicedir}/response-login-product-data.xml</outputFile<>
</callWebService>
....


<callWebService logLevel="-3" title="call ws:start export">
<url>${WebServices_BaseURL}XMLExportService/exportPublicationForID</url>
<requestParameters>

<requestParameter name="p_iPuunId" value="${pubid}"/>
...
</requestParameters>
<outputFile>${vmwebservicedir}/${toolName}-response.xml</outputFile>
</callWebService>
8.1.3 choose
"choose" wird verwendet um Teile des scripts nur unter bestimmten Bedingungen auszuführen.
Unterhalb von "choose" können die actions "when" und "otherwise" verwendet werden.
Die action "choose" verwendet folgende Parameter:
Parame Ty Pfl De Beschreibung

ter p ich fa
t? ult
when Ele ja In einem "when"-Element wird ein xpath-Ausdruck ausgewertet. Kind-actions

me (1.. werden im "true"-Fall ausgeführt.
nt m
eh
rer
e)
otherwis Ele nei Kind-actions werden ausgeführt, falls kein "when"-Block "true" war.
e me n
nt
Die action "when" verwendet folgende Parameter:
actionlist – 61

ter p ich fa
t? ult
test Att ja xpath-Ausdruck, der ausgewertet wird.

rib
ut
file Att nei Falls "file" gefüllt ist wird der xpath-Ausdruck auf die Datei angewendet.
rib n
ut
Sobald der "test" in einem "when"-Block "true" ist werden die anderen Blöcke nicht mehr ausgeführt.
Der Syntax der choose-action ist wie folgt:
Anwendungsbeispiel
<choose>
<when test="'${FileCounter}' = '0'">
<echo message="Bei 0"/>
</when>
<when test="count(//item) > 0" file="D:/VMWORK/temp/somefile.xml">
<echo message="Bei größer 0"/>
</when>
<otherwise>
<echo message="Falls nichts zurtifft"/>
</otherwise>
</choose>
8.1.4 config
"config" lädt oder speichert Variablen von/in Dateien.
actionlist – 62

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
mode mode definiert einen Modus, der beim laden einer Config-Datei mit angegeben werden kann.
Wenn mode nicht vorhanden oder auf "all" gesetzt ist, dann wird die property immer geladen.
Die action verwendet folgende Parameter:

ter p ich fa
t? ult
action Att ja Definiert, ob eine config-Datgei geladen oder gespeichert werden soll (Werte:
rib load / save)
ut
actionlist – 63

ter p ich fa
t? ult
file Att ja Pfad und Name der Config-Datei (laden oder speichern)
rib
ut
mode Att nei loc Definiert, welche properties aus der Config-Datei geladen werden.
rib n ati
ut on
fro
m
glo
bal
.pr
op
ert
ies
property Att nei Definiert die Liste der zu speichernden properties (nur bei action="save")
List rib n
ut
property Att nei Name einer property in die die config Daten zusätzlich zum file gespeichert
Name rib n werden (nur bei action="save")
ut
overwrit Att nei fal Definiert, ob bestehende properties überschrieben werden (nur bei
e rib n se action="load")
ut
handout Att nei fal Definiert, ob die geladenen properties nach Beenden der actionlist an den
rib n se JobScheudler übergeben werden (nur bei action="load")
ut
actionlist – 64
Anwendungsbeispiel




8.1.4.1 Achtung - potentielle Fehlerquelle bei Jobkette mit Verzeichnisüberwachung und

file_order_sink:
Wird config zur Generierung eines Order-Files für eine JobKette mit Verzeichnisüberwachung verwendet, in der
dann der Inhalt per config action="load" ausgelesen wird, sollten die properties explizit über propertyList definiert
werden.
Schleift man über diese Systematik eine Order durch zwei JobKetten, so wird ggf. (overwrite="true") beim Einlesen
in der zweiten Jobkette die property scheduler_file_path überschrieben. Diese teilt der file_order_sink am Ende der
Jobkette den Pfad zum Order-File mit. Diese sucht dann im Pfad des Order-Files von Jobkette 1 und findet dieses
entweder nicht oder versucht, das falsche Order-File in success/error von Jobkette 2 zu verschieben.
8.1.5 copy *TO DO*/TB

"copy" wird verwendet um Dateien zu kopieren.
Attribute:
Attribut Pflicht? Beschreibung
file Pfad inkl. Dateinamen und Dateiart der Datei die kopiert werden soll.
targetDir Zielverzeichnis
targetFileName Name der Kopie im Zielverzeichnis
append
ignoreNoFilesFound
actionlist – 65
sourcePattern
Der Syntax der copy-action ist wie folgt:
Anwendungsbeispiel
<copy title="Copy zip to handover directory">

<file>${langWorkDir}/file.zip</file>
<targetFileName>copy_of_file.zip</targetFileName>
</copy>
8.1.6 createList
"createList" erstellt Dateilisten im xml-Format (Itemlist).
Die Ausgabe-Datei sieht wie folgt aus:
Beispiel List-Datei
<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<items sourceFolder="D:\VMPROCESSES">
<item changeDate="20170113_160347" fileName="listfile.xml" path="D:\VMPROCESSES\" size="10"/>
<item changeDate="20160708_124806" fileName="CheckDaysSchedule.job.xml" path="D:\VMPROCESSES\scheduler-
live\sos\dailyschedule\" size="1"/>
<item changeDate="20160708_124806" fileName="CreateDaysSchedule.job.xml" path="D:
\VMPROCESSES\scheduler-live\sos\dailyschedule\" size="1"/>
<item changeDate="20161202_121704" fileName="" path="D:\VMPROCESSES\VIAMEDICI"/>
</items>
"size" ist die Größe in kiloByte


ter p ich fa
t? ult
listDirs Att nei fal Legt fest, ob Verzeichnisse auch aufgelistet werden. In diesem Fall ist "fileName"
rib n se leer und nur "path" gefüllt.
ut
includeS Att nei fal Definiert ob Unververzeichnisse rekursiv durchsucht werden.

ubDirs rib n se
ut
actionlist – 66

ter p ich fa
t? ult
pathIsRe Att nei fal Definiert, ob relativer oder absoluter Pfad in "path" eingetragen wird.
lative rib n se
ut
ignoreE Att nei tru Entscheidet, ob action einen Fehler wirft, wenn keine Dateien gefunden werden
mptyList rib n e (auch dann, wenn listFolders=true ist und Verzeichnisse gefunden werden).
ut
sourceDi Ele nei Verzeichnis, in dem nach Dateien gesucht wird.

r me n
nt
listFileP Ele nei Regulärer Ausdruck, mit dem Dateien gefunden werden. Falls nicht angegeben
attern me n werden alle Dateien gelistet.
nt
outputFi Ele nei Gibt Datei an, in die die Liste geschrieben wird. (File und/oder Property muss
le me n angegeben werden.)
nt
outputP Ele nei Gibt Property an, in die die Liste geschrieben wird.
roperty me n
nt
Der Syntax der createList-action ist wie folgt:
Anwendungsbeispiel


<createList listDirs="false" includeSubDirs="false" pathIsRelative="false" ignoreEmptyList="true">
<sourceDir>D:/VMPROCESSES</sourceDir>
<listFilePattern>.*\.xml</listFilePattern>
<outputFile>D:/VMPROCESSES/listfile.xml</outputFile>
<outputProperty>listFileProperty</outputProperty>
</createList>
8.1.7 delete
"delete" löscht Dateien und Verzeichnisse
actionlist – 67
Paramet Ty Pfl d Beschreibung

er p ich e
t? f
a
u
l
t
dir Att ja Definiert das Quellverzeichnis. Falls weder recursive noch pattern angegeben ist,
rib wird versucht, das angegebene Verzeichnis zu löschen (welches leer sein muss).
ut
recursive Att nei f Legt fest, ob das angegebene "dir" rekursiv gelöscht werden soll. Dabei wird das
rib n a "pattern" nicht beachtet. Falls recursive=true gesetzt wird, muss der angegebene
ut l Pfad in der Property "deleteBase" vorhanden sein (global.properties). Default-
s Wert: false
e
pattern Att nei Regulärer Ausdruck, mit dem Dateien im angegebenen "dir" gefunden und
rib n gelöscht werden. Falls "pattern" und "recursive" angegeben werden, wird
ut "recursive" ignoriert.
ignoreNo Att nei t Entscheidet, ob ein Fehler geworfen wird, wenn keine zu löschenden Dateien
FilesFoun rib n r existieren. Ist nur relevant bei "pattern". Default-Wert: false
d ut u
e
Der Syntax der delete-action ist wie folgt:
Anwendungsbeispiel


<delete dir="D:/VMWORK/test-process" pattern=".*\.xml" ignoreNoFilesFound="true" title="Delete all *.xml
files in D:/VMWORK/test-process"/>


<delete dir="D:/VMWORK/test-process" recursive="true" title="Delete D:/VMWORK/test-process and everything
below"/>


<delete dir="D:/VMWORK/test-process" pattern=".*\.xml" ignoreNoFilesFound="false" title="Delete all *.xml
files in D:/VMWORK/test-process"/>

8.1.8 echo
"echo" gibt Nachrichten entweder ins Log oder in Dateien aus.
actionlist – 68

ter p ich fa
t? ult
message Att nei Nachricht, die Ausgegeben wird.

rib n
ut
file Att nei Pfad und Name einer Dateifür die Ausgabe.
rib n
ut
property Att nei Name einer property für die Ausgabe.

Name rib n
ut
appendF Att nei fal Nur wenn "file" gesetzt: Definiert, ob an bestehende Datei angehängt werden soll
ile rib n se
ut
overwrit Ele nei fal Nur wenn "propertyName" gesetzt: Bestimmt, ob bestehende property
e me n se überschrieben wird.
nt
Der Syntax der echo-action ist wie folgt:
Anwendungsbeispiel
<echo message="Hello World" file="D:/VMWORK/temp/somefile.log" appendFile="true"

propertyName="myLogProperty" overwrite="true"/>
8.1.9 email *TO DO*

"email" versendet Mails über den in der global.properties angegebenen Mailserver.
actionlist – 69

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
geladen.
actionlist – 70
Anwendungsbeispiel




8.1.10 encode *TO DO*

"encode" erstellt hasch-Werte aus Dateien (MD5, SHA256, SHA384, SHA512) und schreibt das Ergebnis in eine
Property
TO_DO: Umwandeln in special function!

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
actionlist – 71
geladen.
Anwendungsbeispiel




8.1.11 EPIMWebServiceXMLImport *DEPRECATED - DO NOT USE*

"EPIMWebServiceXMLImport" startet XML-Importe über EPIM Webservices. Ersetzt von callWebService.
actionlist – 72

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
geladen.
actionlist – 73
Anwendungsbeispiel




8.1.12 executeJobschedulerXml *TO DO*

"executeJobschedulerXml"ruft JobScheduler XML-Commands auf.
Wird eigentlich nicht mehr benötigt.

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
actionlist – 74
geladen.
Anwendungsbeispiel




8.1.13 executeShell *TO DO*

"executeShell" führt shell commandos aus.
actionlist – 75

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
geladen.
actionlist – 76
Anwendungsbeispiel




8.1.14 executeSQL *TO DO*

"executeSQL" SQL-Befehle (ausser SELECT) auf der EPIM-Datenbank aus:
TO_DO: Zusammenführen mit reportEPIM
TO_DO: Erweitern um die Möglichkeit, andere DBs anzusprechen.

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
actionlist – 77
geladen.
Anwendungsbeispiel




8.1.15 executeXQuery *TO DO*

"executeXQuery" führt XQuery scripts und DB-Commands auf BaseX XML-DB aus.
TO_DO: Missverständlich benannt, muss überarbeitet werden.
actionlist – 78

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
geladen.
actionlist – 79
Anwendungsbeispiel




8.1.16 exit
"exit" beendet die actionlist ohne Fehler.

ter p ich fa
t? ult
message Att nei Die Nachricht, die im Log ausgegeben wird.

rib n
ut
Anwendungsbeispiel
<exit message="This is a clean exit!"/>
8.1.17 extractvalue*TO DO*

"extractvalue" liest Daten mittels xpath aus xml Dateien.
TO_DO: DEPRECATED setzen, da Funktion ab v2.7.1. in property-action aufgenommen wird.
actionlist – 80

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
geladen.
actionlist – 81
Anwendungsbeispiel




8.1.18 fail
"fail" bricht die actionlist mit Fehler ab.

ter p ich fa
t? ult
listDirs Att nei Legt fest, ob Verzeichnisse auch aufgelistet werden. In diesem Fall ist "fileName"
rib n leer und nur "path" gefüllt.
ut
Anwendungsbeispiel
<fail message="This is an intentional error!"/>
8.1.19 fop *TO DO*

"fop" erstellt PDFs mittels Apache FOP.
TO_DO:
actionlist – 82

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
geladen.
actionlist – 83
Anwendungsbeispiel




8.1.20 foreachconfigfile *DEPRECATED - DO NOT USE*

"foreachconfigfile" iteriert über Config-Dateien (key-value-Paare) und liest alle Dateien als properties ein.
TO_DO:

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
actionlist – 84
geladen.
Anwendungsbeispiel




8.1.21 forEachItemListXml *TO DO* /TB

"forEachItemListXml" iteriert eine Itemlist-Datei und stellt in jeder Iteration alle xml-Attribute als properties bereit.
TO_DO:
actionlist – 85
itemListXmlFile Pfad der Datei in der die Liste gespeichert ist.
ignoreErrorsInIteration
Der Syntax der forEachItemListXml-action ist wie folgt:
Anwendungsbeispiel


<forEachItemListXml itemListXmlFile="${sessionTempDir}\sessionDir\export-list-sessionID.xml" title="For
each Item in List">
<echo message="${targetLanguageID}"/>
...
</forEachItemListXml>


<items sessionId="sessionId">
<item targetLanguageID="4"/>
<item targetLanguageID="2"/>
</items>
8.1.22 forEachKeyValueList
Die action liest in einer Schleife werte aus key-value Listen. Dabei werden Leerzeichen entfernt und Zeilen, die mit
"#" beginnen oder leer sind werden ignoriert.
Bei keys ohne value wird der value-Wert leer gesetzt. In jedem Schleifendurchlauf wird die Properties "key" und
"value" mit dem Wert der aktuellen Zeile belegt.
Wie in allen forEach-Schleifen werden die Properties "position" und "total" mit der aktuellen Position und der
Gesamtzahl der Durchläufe gesetzt.

ter p ich fa
t? ult
file Att ja Text-Datei, die Key-Value Paare im Format "key = value" enthält. Die einzelnen
rib Wertepaare werden in einer Schleife nacheinander geladen.
ut
actionlist – 86
Anwendungsbeispiel
<forEachKeyValueList file="D:/VMPROCESSES/VIAMEDICI/test-cases/resources/global.properties">
<echo message="(${position}/${total}) - key: ${key} value: ${value}" />
</forEachKeyValueList>
8.1.23 forEachList *TO DO*

"forEachList" iteriert über eine vorgebene, trennzeichen-getrennte Liste.
TO_DO:

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
actionlist – 87
geladen.
Anwendungsbeispiel




8.1.24 ftpTransfer *ab v2.7.1 - TO DO*

"ftpTransfer" überträgt Datein per FTP.
TO_DO: um download ergänzen - aktuell werden nur uploads unterstützt.
actionlist – 88

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
geladen.
actionlist – 89
Anwendungsbeispiel




8.1.25 getDataFromSAP *TO DO*

"getDataFromSAP" verwendet den Viamedici-SAP-RFC-Baustein zum holen von Daten aus SAP.
TO_DO:

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
actionlist – 90
geladen.
Anwendungsbeispiel




8.1.26 mkDir
"mkDir" erstellt ein Verzeichnis.
Falls der verwendete Pfad nicht vorhanden sein sollte, werden alle dafür benötigten Verzeichnisse erstellt.
actionlist – 91

ter p ich fa
t? ult
dir Att ja fal Zu erstellender Pfad

rib se
ut
Anwendungsbeispiel
<mkDir dir="D:\VMWORK\processname\sessiondir"/>
8.1.27 move *TO DO*/TB

"move" verschiebt Dateien.
TO_DO:
file Pfad zur Datei die verschoben werden soll
targetDir Zielpfad wohin die Datei verschoben werden soll
targetFileName Name der Datei im Zielpfad
overwrite
Der Syntax der move-action ist wie folgt:
Anwendungsbeispiel
<move overwrite="true" title="Rename extension">

<file>${handoverdir}/${divisionName}-product-${targetLocaleLanguage}-${sessionId}.temp</file>
<targetFileName>${divisionName}-product-${targetLocaleLanguage}-${sessionId}.zip</targetFileName>
</move>
8.1.28 property *TO DO*/TB

Erzeugt/setzt eine Variable, die von folgenden Actions genutzt werden kann. Kann auch als Order-Variable an den
JobScheduler eskaliert werden, um diese Variable in folgenden Jobs zu nutzen.
TO_DO:
actionlist – 92
Attrib P Beschreibung
ut f
li
c
h
t
?
name Name der Variable mit dem diese angesprochen werden kann.
value zugewiesener Wert
file
overw legt fest, ob die property überschrieben werden kann, falls sie bereits existiert. Mögliche Werte:
rite true/false
hand gibt an ob die property übergeben werden kann. Mögliche Werte: true/false
out
Anwendungsbeispiel


<property name="timeStamp" value="${date,yyyy-MM-dd_HH-mm-ss}" title="set TimeStamp" overwrite="true"
handout="true"/>


<echo message="${timeStamp}"/>
8.1.29 rename *TO DO*

"rename" benennt Dateien um.
TO_DO:
actionlist – 93

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
geladen.
actionlist – 94
Anwendungsbeispiel




8.1.30 reportEPIM *TO DO*

"reportEPIM" führt SQL-Abfragen auf EPIM-DB aus und schreibt das Ergebis in eine Datei.
TO_DO:

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
actionlist – 95
geladen.
Anwendungsbeispiel




8.1.31 searchandreplace *TO DO*/TB

"searchandreplace" ersetzt Daten in Dateien. Sucht und ersetzt Zeichenketten. Arbeitet mit regulären Ausdrücken.
Durch zeilenbasiertes Vorgehen können beliebig große Dateien behandelt werden.
TO_DO:
actionlist – 96
Attribut Pf Beschreibung
lic
ht
?
sourceFolder Pfad der Datei in der gesucht werden soll.
sourceFile Name und Typ der Datei in der gesucht werden soll.
searchPattern Die Stelle die gesucht und ersetzt werden soll.
replacePattern Der Inhalt durch den ersetzt wird.
encoding
ignoreNoFilesFound
sourcePattern
targetFile
Der Syntax der searchandreplace-action ist wie folgt:
Anwendungsbeispiel


<searchandreplace>
<sourceFolder>${sessionTempDir}\sessionDir\</sourceFolder>
<sourceFile>export-list-sessionID.xml</sourceFile>
<searchReplacePair searchPattern ="exportID=""" replacePattern="exportID="${vmexportID}
""/>
</searchandreplace
8.1.32 setOrderBack *TO DO*/TB

"setOrderBack" setzt eine Jobscheduler-Order zurück, so dass der aktuell laufende Job neu gestartet wird.
Setzt die derzeit aktive Order des aktiven Jobs zurück. Über den Parameter delay_after_order_setback kann
innerhalb einer Jobkette eine Schleife realisiert werden.
TO_DO:
actionlist – 97
geladen.
Der Syntax der setOrderBack-action ist wie folgt:
Anwendungsbeispiel


<setOrderBack title="Set JobScheduler job order back"/>



<delay_order_after_setback setback_count="1" delay="200"/>

<delay_order_after_setback setback_count="25" is_maximum="yes"/>
8.1.33 sleep*TO DO*/TB

Unterbricht die Verarbeitung für den angegebenen Zeitraum.
Der Syntax der sleep-action ist wie folgt:
Anwendungsbeispiel


<sleep hours="1" minutes="15" seconds="15"/>
8.1.34 touch *TO DO*

"touch" erstellt eine leere Datei.
actionlist – 98
TO_DO:

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
geladen.
actionlist – 99
Anwendungsbeispiel




8.1.35 transform *TO DO*

"transform" führt xsl-Transformationen mit folgenden Prozessoren aus: xalan, saxon1, saxon2, saxonEE, stx_xalan,
stx_saxon1, stx_saxon2, xsltc_translet, xquery
TO_DO:

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
actionlist – 100
geladen.
Anwendungsbeispiel




8.1.36 unzip *TO DO*/TB

"unzip" entpackt zip-Dateien
TO_DO
actionlist – 101
file
targetBaseDir
targetDirName
ignoreNoFilesFound
Der Syntax der unzip-action ist wie folgt:
Anwendungsbeispiel
<unzip title="Unzip handed over file">

<file>${sessionWorkDir}/${inputFileName}</file>
<targetBaseDir>${sessionWorkDir}</targetBaseDir>
<targetDirName>${inputFileNameWithoutExtension}</targetDirName>
</unzip>
8.1.37 validateXML *TO DO*

"validateXML" validiert XML-Dateien gegen ein Schema
TO_DO:

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
actionlist – 102
geladen.
Anwendungsbeispiel




8.1.38 waitforlogfile *DEPRECATED - DO NOT USE*

"waitforlogfile" wartet, bis eine bestimmte Datei erstellt wurde
TO_DO:
actionlist – 103

<config>
/>
mode="DEVLOCAL"/>
mode="DEVSERVER"/>
>
mode="PROD"/>
</config>
geladen.
actionlist – 104
Anwendungsbeispiel




8.1.39 zip *TO DO*/TB

Erzeugt aus Dateien oder Verzeichnissen eine ZIP-Datei
TO_DO:
sourceFolder Quellpfad
sourcePattern .* = alles im Quellpfad packen
targetDir Zielpfad
targetFileName Name der .zip Datei
file
ignoreNoFilesFound
Der Syntax der zip-action ist wie folgt:
actionlist – 105
Anwendungsbeispiel
<zip title="zips files">

<sourceFolder>${langWorkDir}/toBeZipped</sourceFolder>
<sourcePattern>.*</sourcePattern>
<targetDir>${langWorkDir}</targetDir>
<targetFileName>sessionIds</targetFileName>
</zip>
8.2 Konfiguration
In den folgenden Kapiteln wird die Konfiguration der actionlist und von Prozessen beschrieben.
Für die Konfiguration sind folgende Dateien relevant:
global.properties
Basiskonfiguration der actionlist
%CUSTOMER%-config-%location%.xml
Beispiel: METABO-config-PROD.xml
Diese Konfigurationsdateien enthalten die Basiskonfiguration sämtlicher Pfade und sind im VMPROCESSES-
Verzeichnis zu finden.
%CUSTOMER% ist dabei der Kundenname (gesetzt in global.properties oder job)
%location% ist die Umgebung, auf dem das PDK läuft. (siehe global.properties)
Mögliche Werte für %location% sind:
DEVLOCAL
DEVSERVER
QA
PROD
process-config.xml
Hier sind die prozessspezifischen Konfigurationseinträge zu finden.
Die Datei liegt standardmäßig in D:/VMPROCESSES/%processName%/config
Sie enthält sämtliche Konfigurationseinträge unabhänging von location und runMode.
8.2.1 global.properties
Die Datei global.properties enthält die Basiskonfiguration der actionlist und liegt im selben Verzeichnis wie die
actionlist.jar (Normalerweise D:\VMPROGRAMS\PDK\actionlist).
Der Aufbau ist wie folgt:
actionlist – 106
global.properties
#actionListAppDir - Normally actionlist determines its own execution path. If this is not possible, this
variable needs to be set.
#actionListAppDir=D:/VMPROGRAMS/PDK/actionlist

#Name of the customer(upper case), used to build paths to config files
#Can be set here globally, but should be set in job definition for use with local/customer dev systems
#param entries in jobs override global.properties
customer=VIAMEDICI

#Directory where the PDK processes directory is located
#parent directory of VMPROCESSES (customer) or VMPROCESSES/%CUSTOMER% (local)
rootDir=D:

#location means the location where the actionlist is running
# available values:
# DEVLOCAL - local development system
# DEVSERVER - customer development system
# QA - customer QA system
# PROD - customer production system
# This decides which customer configuration file is used.
location=DEVLOCAL

#runMode describes if the process is running in TEST or LIVE mode
# TEST mode means it will not run with exports or SAP connetcs, but with previously provided test
files
# TEST files are to be placed in VMPROCESSES/%process-name%/resources
# default value is "LIVE". TEST mode should be set in process as job-param for initialize
runMode=LIVE

#debug describes if the process is running in debug mode (NOT YET IMPLEMENTED)
# debug=true means that logLevel will default to -9, no matter what is set in job/actionlist/action
# and that the email action will send mails to DEBUG_redirectAllMailsTo (see below)
# default value is "false". debug mode should be set in process as job-param for initialize
debug=false

# Directory where to look for an actionlist file if no full path is specified (can be used in jobs as base
dir for actionlists. processName must be added)
# Defaults (depending on location):
# DEVLOCAL : ${rootDir}/VMPROCESSES/${customer}
# DEVSERVER/QA/PROD : ${rootDir}/VMPROCESSES
actionListsDir=${rootDir}/VMPROCESSES/${customer}

# Directory where fonts for FOP are stored
fopFonts=${actionListsDir}/common/resources/fopFonts

#List directories under which recursive deletion should be allowed. Diretories are separated by semicolon ;
deleteBase=D:/VMWORK;D:/VMTEMP

# JDBC connection string for EPIM data base.
# Examples: "jdbc:oracle:thin:@//DB:1521/via"
# jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=xe)))
actionlist – 107
EPIM_ConnectString=jdbc:jtds:sqlserver://CHLYSDB10:1433;instance=IT
# JDBC data base driver class name for EPIM connection
# Oracle: oracle.jdbc.driver.OracleDriver
EPIM_JdbcDriver=net.sourceforge.jtds.jdbc.Driver
# EPIM data base user name
EPIM_User=epim
# EPIM data base user password (of course encrypted)
EPIM_PasswordCrypted=GPWgiOfrKLY1NnVvfg3yFA==

#Use a connection pool when opening the database ?
connectionPool.enabled=false

#Controls how many active database connections are on the connection pool. In order to debug non-closed DB
connections, set this to 1 (or to 2 if an additional db connection is used for PDK logging). Default: 8
connectionPool.maxActive=8

# Web service connection settings:
EPIM_WebServerHost=10.19.4.113
# Important: there must be a trailing / in the url <- NO! always fill slashes in between manually...
EPIM_WebServices_BaseURL=http://${EPIM_WebServerHost}:5555/axis2/services
EPIM_WebServices_User=system
EPIM_WebServices_PasswordCrypted=fSYukREsGxjwOASgKR5Q6g==

#PDK logging switch
PDK_enable=false
#PDK logging connection Settings:
PDK_ConnectString=${EPIM_ConnectString}
PDK_JdbcDriver=${EPIM_JdbcDriver}
PDK_User=${EPIM_User}
PDK_PasswordCrypted=${EPIM_PasswordCrypted}
#set this to true if you want to ignore it when no pdk database connection can be established or if you
want to run the actionlist without pdk logging.
PDK_ignoreErrors=true
#global default log-lifetime: Number of days after which PDK process entries will expire and be cleaned up
by the CleanupPDK Job. 0 = cleaned up immediately after execution.
logLifetime=1
#TODO: doku
errorOffset=1
#TODO: doku
keepLoopLogs=10

### Mail Settings: ###
# set this to the email address you like to recieve all the mail instead. Unset/comment-out to arm for
golive.
#DEBUG_redirectAllMailsTo=
# Set to true to disable all mails in case of testing on a system with no mailserver connection.
#DEBUG_disableMails=true
# Additional SMTP Settings can be found here: http://javamail.kenai.com/nonav/javadocs/com/sun/mail/smtp/
package-summary.html
#The SMTP server to connect to.
mail.smtp.host=mail.viamedici.de
# Port of the SMTP server port to connect to. Use 465 for secure connections
mail.smtp.port=25
actionlist – 108
# Set these 2 parameters to true to use STARTTLS. Required for viamedici mail server
mail.smtp.starttls.enable=false
mail.smtp.starttls.required=false
#Set this to * to trust the mail host. Otherwise a valid certificate for the mail host has to be installed
on this system.
mail.smtp.ssl.trust=*
# set this only to false if you don't want any authentication
mail.smtp.auth=true
# Username for SMTP
mail.smtp.user=
# Password for SMTP
mail.smtp.password=
8.2.2 Customer-Config
Die %CUSTOMER%-config - Dateien enthalten sämtliche Basispfade, welche für PDK-Prozesse benötigt werden und
liegen im VMPROCESSES-Verzeichnis (Normalerweise D:\VMPROCESSES).
actionlist – 109

<config>


<property name="EPIMFS" value="D:/EPIMFS" handout="true" overwrite="true" />
<property name="EPIMIMPORT" value="${EPIMFS}/import" handout="true" overwrite="true" />
<property name="EPIMEXPORT" value="${EPIMFS}/export" handout="true" overwrite="true" />
<property name="EPIMHOME" value="D:/EPIMHOME" handout="true" overwrite="true" />


<property name="VMBACKUP" value="D:/VMBACKUP" handout="true" overwrite="true" />
<property name="VMHANDOVER" value="D:/VMHANDOVER" handout="true" overwrite="true" />
<property name="VMINSTALL" value="D:/VMINSTALL" handout="true" overwrite="true" />
<property name="VMLOGS" value="D:/VMLOGS" handout="true" overwrite="true" />
<property name="VMPROCESSES" value="D:/VMPROCESSES" handout="true" overwrite="true" />
<property name="VMPROGRAMS" value="D:/VMPROGRAMS" handout="true" overwrite="true" />
<property name="VMWORK" value="D:/VMWORK" handout="true" overwrite="true" />
<property name="VMTEMP" value="D:/VMTEMP" handout="true" overwrite="true" />
<property name="VMTOOLS" value="D:/VMTOOLS" handout="true" overwrite="true" />


<property name="emailFrom" value="PDK@viamedici.de" handout="true" overwrite="true" />


<property name="commonActionlistsDir" value="${VMPROCESSES}/common/actionlists" handout="true"
overwrite="true" />
<property name="commonConfigDir" value="${VMPROCESSES}/common/config" handout="true" overwrite="true" /
>
<property name="commonEmailDir" value="${VMPROCESSES}/common/email" handout="true" overwrite="true" />
<property name="commonResourcesDir" value="${VMPROCESSES}/common/resources" handout="true"
overwrite="true" />
<property name="commonScriptsDir" value="${VMPROCESSES}/common/scripts" handout="true"
overwrite="true" />
<property name="commonXslDir" value="${VMPROCESSES}/common/xsl" handout="true" overwrite="true" />
</config>
Geladen wird die config mit der <config> action.

Die Attribute handout und overwrite funktionieren dabei wie in der actionlist.
overwrite(true/false) steuert, ob eine vorhandene property überschrieben wird.
handout(true/false) steuert, ob eine property in einer Jobkette an den nächsten Job übergeben wird. In diesem Fall
kann gesteuert werden ob die property nur für die actionlist, in der die config geladen wird, relevant ist oder auch
für alle folgenden actionlists.
8.2.3 Process-Config
Die process-config - Dateien enthalten sämtliche Basispfade, welche für PDK-Prozesse benötigt werden und liegen
im Prozess-Verzeichnis (Normalerweise D:\VMPROCESSES\%process-name%\config).
Im Gegensatz zur Customer-Config gibt es nur eine Datei (nicht eine pro location). Falls bestimmte properties sich je
nach location unterscheiden erfolgt dies über das "mode"-Attribut. (siehe Beschreibung der "config"-action.)
actionlist – 110

<config>

<property name="actionlistsDir" value="${VMPROCESSES}/${processName}/actionlists" handout="true"
overwrite="true" mode="all"/>
<property name="configDir" value="${VMPROCESSES}/${processName}/config" handout="true" overwrite="true"
mode="all"/>
<property name="emailDir" value="${VMPROCESSES}/${processName}/email" handout="true" overwrite="true"
mode="all"/>
<property name="resourcesDir" value="${VMPROCESSES}/${processName}/resources" handout="true"
<property name="scriptsDir" value="${VMPROCESSES}/${processName}/scripts" handout="true"
<property name="xslDir" value="${VMPROCESSES}/${processName}/xsl" handout="true" overwrite="true"
mode="all"/>

<property name="emailRecipients" value="PDK-recipient@viamedici.de" handout="true" overwrite="true"
mode="all"/>
<property name="emailRecipientsDebug" value="PDK-recipient-debug@viamedici.de" handout="true"



<property name="backupWorkDir" value="true" handout="true" overwrite="true" mode="all"/>
<property name="deleteWorkDir" value="false" handout="true" overwrite="true" mode="all"/>
<property name="backupHandoverDir" value="false" handout="true" overwrite="true" mode="all"/>
<property name="deleteHandoverDir" value="false" handout="true" overwrite="true" mode="all"/>
<property name="backupTempDir" value="false" handout="true" overwrite="true" mode="all"/>
<property name="deleteTempDir" value="true" handout="true" overwrite="true" mode="all"/>

<property name="deleteBackupAfterDays" value="2" handout="true" overwrite="true" mode="all"/>


<property name="processVariable1" value="something" handout="true" overwrite="true" mode="all"/>
<property name="processVariable2" value="somethingElse" handout="true" overwrite="true" mode="all"/>


<property name="processVariable3" value="something" handout="true" overwrite="true" mode="DEVLOCAL"/>
<property name="processVariable3" value="something" handout="true" overwrite="true" mode="DEVSERVER"/>
<property name="processVariable3" value="something" handout="true" overwrite="true" mode="QA"/>
<property name="processVariable3" value="something" handout="true" overwrite="true" mode="PROD"/>
</config>
Geladen wird die config mit der <config> action.

Die Attribute handout und overwrite funktionieren dabei wie in der actionlist.
overwrite(true/false) steuert, ob eine vorhandene property überschrieben wird.
actionlist – 111
handout(true/false) steuert, ob eine property in einer Jobkette an den nächsten Job übergeben wird. In diesem Fall
kann gesteuert werden ob die property nur für die actionlist, in der die config geladen wird, relevant ist oder auch
für alle folgenden actionlists.
8.3 Special functions

Als special functions werden Funktionen bezeichnet, die z.B. bei einer Property-Definition oder generell immer
dann, wenn properties eingesetzt werden, verwendet werden können.
Der Syntax ist wie folgt:
Syntax
${function-name,parameter1[,parameter2][,parameter_n]}
 Achtung!
Die Parameter dürfen keine Kommas beinhalten (z.B. Kommas in Dateinamen)
Aktuell gibt es folgende specialFunctions:

Datums und Zeitstempel:
Anwendungsbeispiele


<property name="date" value="${date}" />


<property name="date_with_format" value="${date,dd.MM.yyyy - HH:mm:ss}" />




<property name="dateOffset" value="${dateOffset,yyyyMMdd_HHmmss_SSS,0,0,-1,0,0,0,0}" />


<property name="getunixtime" value="${getunixtime}" />
Filesystem:
actionlist – 112
Anwendungsbeispiele


<property name="ifExists" value="${ifExists,D:/VMPROCESSES}" />


<property name="getFileName" value="${getFileName,D:/VMPROCESSES/viamedici.txt}" />

<property name="getFileName" value="${getFileName,D:/VMPROCESSES}" />



<property name="getParentDirectoryPath" value="${getParentDirectoryPath,D:/VMPROCESSES/
viamedici.txt}" />

<property name="getParentDirectoryPath" value="${getParentDirectoryPath,D:/VMPROGRAMS/PDK}" />



<property name="pathToURL" value="${pathToURL,D:/VMPROGRAMS/PDK}" />




<property name="getFreeSpace" value="${getFreeSpace,MB,D:}" />



<property name="getUsableSpace " value="${getUsableSpace,MB,D:}" />


<property name="getTotalSpace " value="${getTotalSpace,MB,D:}" />
String-Operationen
actionlist – 113
Anwendungsbeispiele


<property name="urlEncode" value="${urlEncode,The string ü@foo-bar,UTF-8}" />




<property name="split" value="${split,das;ist;ein;string,1,;}" />




<property name="generateUUID" value="${generateUUID}" />

Sonstige
Anwendungsbeispiele




<property name="toString" value="${toString,propertyName}" />
<property name="toString_with_encode" value="${toString,propertyName,UTF-8}" />
8.4 Standard-Variablen
Neben den in den Konfig-Dateien verwendeten properties stellt die actionlist noch folgende Variablen zu
Verfügung:
Property-Name Bedeutung
actionListAppDir Pfad zur actionlist.jar.

Wird im Regelfall automatisch beim start einer actionlist ermittelt. Falls dies nicht
funktioniert kann sie in der global.properties gesetzt werden.
actionListsDir Basisverzeichnis für actionlist-Dateien. Default: D:\VMPROCESSES (gesetzt in

global.properties)
actionListFile Pfad zur auszuführenden actionlist.xml Datei. Wird in Jobs gesetzt. Dort ist nur der relative
Pfad ab ${actionListsDir} (gesetzt in global.properties) notwendig.
actionlist – 114
Property-Name Bedeutung
sessionId Bei start durch den Jobscheduler wird hier die Jobscheduler SessionID übernommen.
Andernfalls wird ein timestamp gesetzt (yyyyMMdd_HHmmss_SSS)
orderId Bei Start durch Jobscheduler wird hier hier ID der Order übernommen. Bei einer fest
definierten Order wird der Order-Name verwendet. Bei einer fileOrderSource wird Pfad/
Dateiname der Orderfiles übergeben.
lastStep Name des zuletzt ausgegührten Jobs einer Kette
currentStep Name des aktuell laufenden Jobs einer Kette
inputRequest Falls Jobkette über einen JobScheduler-Webservice gestartet wird, wird hier die
Webservice-Payload übergeben. Format entweder key-value (bei GET-Aufruf) oder xml (bei
SOAP)
inputFile Eingangsdatei. Bei Start durch fileOrderSource wird der Pfad des OrderFile übergeben.
lastResult letzte verwendete Datei (z.B. bei transform)
 Nicht vollständig für alle actions implementiert

actionlist – 115
9 Prozess-Templates
9.1 remoteActionlist
Dabei handelt es sich um eine Vorlage, mit der man einzelne actionlists (also keine längeren Prozesse) auf dem
DaemonServer (bei Multiserver-Installation) aus einer Exportformatgruppen per Batch anstoßen kann.
Das Template liegt im SVN unter
SV-PS-Implementierung\VIAMEDICI\VMPROCESSES\remoteActionlist
die zugehörige Jobkette liegt in
SV-PS-Implementierung\VIAMEDICI\VMPROCESSES\scheduler-live\remoteActionlist\
Eine Beispiel-Batch-Datei liegt im scripts-Ordner. Diese Batch-Datei erstellt ein config-File, welches dann in ein
JobScheduler hotfolder (file_order_source der zugehörigen Jobkette) kopiert wird
Dort müssen einige Variablen geplfegt werden:
CUSTOMER
PROCESSNAME (Name des Prozesses, der die auszuführende actionlist beinhaltet. Standardmäßig
"remoteActionlist". Wird im Pfad des HANDOVER Verzeichnis verwendet.)
REMOTE_ACTIONLIST_PATH (Pfad zur auszuführenden actionlist)
REMOTE_ACTIONLIST_NAME (Name der auszuführenden actionlist (ohne .actionlist.xml)
Die Variablen, welche EPIM übergibt werden, zusätzlich zu actionlist-Name/Pfad und einer sessionID, welche im
Batch generiert wird, in das config-File übernommen.
Die Jobkette liest das config-File aus und startet die konfigurierte actionlist.
Prozess-Templates – 116
10 Logging
Es gibt grundsätzlich 2 Stellen, an denen Logs vorhanden sein können:
Prozessprotokoll
Das Prozessprotokoll ist ein Loggingmechanismus innerhalb des EPIM, welcher in der global.properties der
actionlist Konfiguriert/Aktiviert wird.
JobScheduler-Log
Hier wird die Standard-Ausgabe der actionlist gelogt, falls diese über den jobScheduler gestartet wurde.
Der Detailierungsgrad des Loggings kann, abhängig vom Aufruf der actionlist, wie folgt eingestellt werden:
LogLevel Bedeutung
-9 bis -1 Debug-Level, je kleiner die Zahl desto ausführlicher das Log.
0 Info (alle Nachrichten mit Level Info, Warnung und Fehler werden ausgegeben)
1 Warning (alle Nachrichten mit Level Warnung und Fehler werden ausgegeben)
2 Error (alle Nachrichten mit Level Fehler werden ausgegeben)

Der LogLevel kann wie folgt eingestellt werden:
Start durch Shell-Script:
Attribut logLevel in actionlist-element bestimmt den Filter, welche Einträge ausgegeben werden sollen. Falls nicht
angegeben, ist 0 der default-Wert
Attribut logLevel in action-element übersteuert den in actionlist angegebenen Wert.
Im folgenden Beispiel wird logLevel = 1 gesetzt für die gesamte actionlist und für die action "property" wird er mit 0
übersteuert.
Beispiel für LogLevel in actionlist
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<actionList xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="D:/VMPROGRAMS/PDK/actionlist/org.vm.actionlist.ActionList.xsd"
logLifetime="1" logLevel="1" title="Initialize">
<actions>
<property name="x" value="y" logLevel="0" />
</actions>
</actionList>
Start durch JobScheduler:

param "log_level" in Job bestimmt den Filter, welche Einträge ausgegeben werden sollen. Falls nicht angegeben,
wird der default-Wert aus der factory.ini des jobSchedulers gezogen.
Attribut logLevel in actionlist-element wird ignoriert.
Attribut logLevel in action-element wird ignoriert.
Im folgenden Beispiel wird logLevel = 1 (param log_level) gesetzt.
Logging – 117
Beispiel für LogLevel in job

<job title="Initialize" order="yes" stop_on_error="no" tasks="1" java_options = "-Xmx128m">
<params>
<param name="log_level" value="1"/>

<param name="actionListFile"
value="D:/VMPROCESSES/VIAMEDICI/test_001/actionlists/test.actionlist.xml"/>
</params>
<script language="java"
java_class_path="actionlist.jar"
java_class="org.vm.actionlist.JobschedulerJob"/>

<run_time/>
</job>
Logging – 118

PDK - Process Development Kit (Produkt) (PS)

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PDK - Process Development Kit (Produkt) (PS)

Hochgeladen von

Copyright:

Verfügbare Formate

PDK - Process Development Kit [Produkt] [PS]

Exported on 08/15/2018

4.4.6.3 Job definieren .......................................................................................................................................................32

7.2 Standardverzeichnisse in der lokalen Umgebung/Subversion ........................................... 55

8.1.32 setOrderBack *TO DO*/TB....................................................................................................................................97

• PDK-Whitepaper (see page 11)

• Special functions (see page 112)

1 logLevel (ActionList und JobScheduler)

logLevel (ActionList und JobScheduler) – 8

Typ Beschreibung Bespiel

3 Updates und Bugfixes

Updates und Bugfixes – 10

4.2 PDK Übersicht

4.2.1 Verwendete Komponenten

4.2.2 Genereller Prozess

Abbildung 1: Generelle Prozessabbildung der ActionList im Zusammenspiel mit dem JobScheduler

4.3 PDK Komponenten

Abbildung 2: ER-Datenmodell des PDKs

• ROOT_ID NUMBER(15,0) NOT NULL; ID des obersten Parent Prozesses

4.3.1.3 Integration in EPIM

Abbildung 3: User Interface des Prozess Protokolls

<callWebService logLevel="-3" title="call ws:login">

<copy title="Copy zip to handover directory">

<createList title="Create list of files in Handover">

<delete dir="${langWorkDir}/toBeZipped/" recursive="true" ignoreNoFilesFound="true" title="Delete zipped

<echo message="Hello World"/>

<forEachItemListXml itemListXmlFile="export-list-sessionID.xml" title="Say Hello World for each Item in

<mkdir dir="${langWorkDir}" title="Create langWorkDir"/>

<move overwrite="true" title="Rename extension">

<sleep hours="1" minutes="15" seconds="15"/>

<zip title="zips files">

4.3.4 SOS JobScheduler Zitiert von der Webseite www.sos-berlin.com

4.4 Technische Dokumentation

Abbildung 4: Übersicht PDK Beispiel

4.4.1.1 Start des Prozesses

<?xml version="1.0" encoding="ISO-8859-1"?>

Abbildung 5: Job-Ketten-Übersicht in der JobScheduler Oberfläche beim PDK-Beispiel

Abbildung 6: Manueller Start einer Job-Ketten-Order

<?xml version="1.0" encoding="ISO-8859-1"?>

<?xml version="1.0" encoding="ISO-8859-1"?>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

4.4.3 XML Schema Dateien

Abbildung 7: Beispielhafte Darstellung des ActionList XML Schemas

4.4.5 Process Logger WebService API

4.4.6.1 Grafische Visualisierung des Gesamtprozesses

Abbildung 8: Überblick WebService Anwendungsbeispiel

4.4.6.2 ActionList aufbauen

<?xml version="1.0" encoding="UTF-8"?>

<executeShell title="call shell with ls -l">

<transform title="Transformieren 1">

<transform title="Transformieren 2">

4.4.6.3 Job definieren

<?xml version="1.0" encoding="ISO-8859-1"?>

4.4.6.4 Job über JobScheduler aufrufen

Abbildung 9: Aufruf Job für WebService Anwendungsbeispiel

Abbildung 10: Ansicht Prozessprotokoll für WebService Anwendungsbeispiel

6.1 Upgrade des PDK

4) Service-Owner des alten JobSchedulers und der MariaDB notieren.

6.2 Installation des PDK

6.2.1 Anlage der Standardverzeichnisse

8.1.32 setOrderBack TO DO/TB....................................................................................................................................97

8.1.1 callRFC TO DO

8.1.2 callWebService TO DO/TB