Ein neues Feld in der Ausgangsstruktur, in der Eigenschaft Fixwert ist 12345 eingetragen.

Bei Ausgangsformat CSV sieht ein Auftragskopf dann wie folgt aus: OH;Order2,12345

Feldwerte verändernDie Werte von Feldern können auch verändert werden. Beispiele sind:

• führende Leerzeichen entfernen

• Kommata durch Punkte ersetzen

• Mengeneinheiten in Quelldateien durch eigene Mengeneinheiten ersetzen.

Manipulationen auf den Feldwerten werden im Datawizard durch Filter vorgenommen. Es existieren weit mehr als 100 Filter, und es kommen ständig neue Funktionen hinzu. Zusätzlich hat der Benutzer die Möglichkeit über die offene API eigene Filter anzulegen und diese im DataWizard zu benutzen.

Im nachfolgenden Beispiel wird eine Zeichenkette an einen Feldwert angehängt. Dazu wird der Filter concat(a,b) verwendet.

Erster Parameter a des Filters wird mit dem Feldwert belegt. Das Feld kann mit seinem Anzeigenamen aus einem Dialog ausgewählt werden, eingetragen wird aber die ID des Feldes

Die Zeichenkette, die an den Feldwert des Feldes in angehängt werden soll. Das Ergebnis (result) wird in das Feld, zu dem der Filter gehört, eingetragen. Da immer die gleiche Zeichenkette angehängt werden soll, wird nicht der Inhalt einer Variable oder Feldes, sondern eine Konstante hinterlegt.

Hinweis: Eine allgemeine Beschreibung der Filterfunktionalitäten ist im Abschnitt Arbeitsweise von Filtern nachzulesen. Es können beliebig viele Filter aneinander gehängt werden und so auch kleine Programme zur Manipulation eines Feldwertes erstellt werden.

Feldwerte protokollierenDie Werte einzelner Felder im Ausgangsbaum können mitprotokolliert werden. Dadurch können die Logs später sehr komfortabel nach kundenspezifischen Merkmalen durchsucht werden. Als Beispiel kann die Protokollierung der Auftragsnummer gewünscht sein. Die Protokollierung wird in den

91 / 140

1

Abbildung: Postfix anhängen

1

2

Abbildung: Feld mit Fixwert

Root

Position

recordtype2

posnumber

recordtype1

number

OrderHeader

Root

Position

recordtype2

posnumber

recordtype1

number

OrderHeader

PLZ

1

Eigenschaften zu einem Ausgangsfeld mit dem Flag Feld loggen aktiviert. Als Beispiel kann eine Auftragsnummer in den Dateien genannt werden. Die Benutzer können bei Anfragen die Logs nach der Auftragsnummer durchsuchen und müssen nicht in den Eingangsdateien recherchieren.

Mit diesem Schalter wird die Protokollierung des Feldwertes aktiviert. Die Werte werden auch protokolliert wenn der Schalter SQL ausführen deaktiviert ist. Die Protokollierung hängt nicht mit dem Ausführen der SQL-Anweisungen in Phase 4 zusammen.

Protokolleintrag für einen Feldwert number.

BerechnungsfelderManchmal ist es im Mapping erforderlich Berechnungen vorzunehmen. Die Berechnungen benötigen oftmals Durchläufe (Knoten) über Teile der Eingangsstruktur ,ohne dass diese Struktur in den Ausgangsdaten sichtbar sein darf.

Beispiel: In den Kopfdaten eines Auftrags muss die Anzahl der Auftragspositionen angegeben werden. Die Anzahl wird mit einer Variablen ermittelt, in dem ein Knoten mit Pfad auf Position erstellt wird. Im Knoten wird ein Feld angelegt, das bei jedem Durchlauf den Zähler der Positionen erhöht. Dieser Teil des Ausgangsbaums darf nicht in den Ausgangsdaten sichtbar sein. Dies wird erreicht in dem die Eigenschaft Berechnungsfeld=true für das Feld einstellt.

Über dem Auftragskopf OrderHeader wird ein neuer Knoten eingefügt counting. In diesem Knoten wird die Eigenschaft Pfad auf den gleichen Wert wie im Knoten Position gelegt. Damit wird der Knoten so oft wiederholt wie der Knoten .

Das Feld counterPos wird angelegt, diesem wird kein Eingangsfeld zugewiesen. Die

92 / 140

Abbildung: Protokollierung für ein Feldwert zu aktivieren.

1

Abbildung: Monitor Protokollierung Feldwerte

1

Abbildung: Berechnungsfeld

Root

Position

recordtype2posnumber

recordtype1number

OrderHeader

counting

counterPos

Root

record

Position

OrderHeader

Position

Position

counting

counting

counting

positions

1

2

4 3

5

Eigenschaft Berechnungsfeld wird auf true gestellt. Im Feld werden zwei Filter hinterlegt; a + b und save(a,b) um den Wert der Variablen VAR_counterPos zu erhöhen und den neuen Wert in die Variable zurück zu schreiben. Nach dem letzten Durchlauf enthält die Variable die Anzahl von Auftragspositionen.

Das Feld positions wird angelegt, diesem wird kein Eingangsfeld zugewiesen. Über den Filter copy(a,b) wird der Wert der Variable VAR_counterPos in das Feld gefüllt. Da dieses Feld im Ausgangsbaum erst durchlaufen wird, wenn der Knoten abgearbeitet ist, erhält das Feld als Wert die Anzahl von Auftragspositionen.

Knoten mit dem Pfad auf Positionen in der Eingangsstruktur.

Der Knoten counting wird im Ausgangsbaum ebenso oft wiederholt wie der Knoten Position. Da unterhalb des Knotens aber kein echtes Feld existiert, wird der Knoten bei der Erstellung der Ausgangsdaten ignoriert.

Es ist auch möglich, berechnete Felder und normale Felder in beliebiger Reihenfolge innerhalb von Knoten zu mischen. Allerdings werden Knoten mit normalen Feldern für die Erstellung der Ausgangsdaten nicht mehr ignoriert. Für die Erstellung der Ausgangsdaten verhält sich das Programm so, als wenn die Berechnungsfelder nicht vorhanden wären.

Priorität der WertezuweisungenDie Eigenschaft Berechungsfeld ist nur sichtbar, wenn der erweiterte Datenmapper verwendet wird.

Um zu verstehen, warum dieser Weg zu beschreiten ist, ist etwas Wissen über die Arbeitsweise des Mappers notwendig:

Es wurden drei Arten vorgestellt, wie ein Feld im Ausgangsbaum mit einem Wert versehen werden kann; → Feldzuweisung, Filter, Fixwert. Wenn nun mehrere Zuweisungen auf ein Feld vorgenommen werden, welche Zuweisung gewinnt dann?

Der Mapper beginnt mit seiner Arbeit, nachdem der Parser den Eingangsbaum erstellt hat. Als Erstes werden die normalen Zuordnungen für ein Feld bearbeitet; das bedeutet, die Werte des zugewiesenen Eingangsfeldes wird in das Ausgangsfeld geschrieben. Anschließend werden die Filter bearbeitet und das Ergebnis in das Feld geschrieben. Zum Schluss wir der Fixwerte in das Ausgangsfeld eingetragen.

Unten stehende Grafik soll diese Arbeitsweise verdeutlichen.

93 / 140

94 / 140

Abbildung: Arbeitsschritte des Mappers

Direkte Zuweisung

Filter bearbeiten

Fixwerte zuweisen

Phase 4: Daten in DB schreibenBeim Mappen der Daten können parallel auch SQL Statements erzeugt werden. Diese SQL Statements werden nach Beendigung der Phase 3 ausgeführt. Dazu muss einem Ausgabefeld ein Spaltenname zugeordnet werden.

Ausgabefelder mit Spaltennamen müssen unterhalb eines Knotens liegen, dem eine DB-Tabelle zugeordnet ist. Im Knoten wird neben dem Tabellennamen auch der DB-Alias angegeben. Folglich können die Tabellen auch in unterschiedlichen Datenbanken liegen. Ausgabefelder unter Knoten mit Tabellennamen werden nicht in die Datenbank geschrieben, wenn im Feld kein Spaltennamen eingetragen ist.

Zusätzlich kann pro Knoten auch der SQL-Modus eingestellt werden. Folgende Modi sind möglich:

• Append → Die Daten werden in die Datenbank geschrieben, der Modus entspricht einem ‚insert’.

• Update → Der DataWizard versucht zuerst einen Update auf einem Datensatz mit den gleichen Schlüsselfeldern. Schlägt der Update fehl, wird ein Insert durchgeführt.

• Delete → Entspricht dem Modus ‚append’, mit vorgeschaltetem Löschen der Einträge mit den entsprechenden Primary Keys.

Es existiert eine weitere Eigenschaft, SQL Tabelle leeren, mit der das Wegschreiben von Daten in die DB beeinflusst werden kann. Ist diese Eigenschaft auf true gestellt wird der Tabelleninhalt beim ersten Betreten des Knotens gelöscht.Das Schreiben der SQL-Anweisungen kann dynamisch deaktiviert werden. Neben dem generellen aktivieren/deaktivieren der SQL-Anweisungen kann eine Variable angegeben werden. Ist keine Variable eingetragen (default) gilt die Einstellung der Checkbox. Ist eineVariable eingetragen, wird der Inhalt in einen Boolschen Wert verwandelt und mit der Checkbox UND-Verknüpft. Die Variable wird NACH dem Mapping ausgewertet. Im Logging wird bei Phase 4 ausgegeben ob das Schreiben auf Grund der Variablen aktiviert/deaktiviert wurde.

Die Variable schaltet das Ausführen von SQL-Anweisungen frei. Ist keine Variable eingetragen, gilt das als true. Kann der Inhalt der Variable nicht zu true ausgewertet werden, werden die SQL-Anweisungen nicht ausgeführt. Die Variable muss vom Benutzer manuell mit einem frei wählbaren Namen angelegt werden.

Leerzeichen in Statements entfernenManchmal enthalten Zeichenketten führende oder abschließende Leerzeichen. Normalerweise sollten die Zeichenketten in Datenbanken jedoch keine Leerzeichen am Anfang oder Ende enthalten. Führende oder Abschließende Leerzeichen in den SQL-Anweisungen können vermieden werden, in dem der Schalter Leerzeichen bei SQL entfernen aktiviert wird.

95 / 140

Abbildung: SQL Anweisungen dynamisch einschalten

1

Schalter steuert ob führende und abschließende Leerzeichen in SQL-Anweisungen entfernt werden.

TransaktionssteuerungNormalerweise werden sämtliche SQL-Anweisungen in einer Transaktion in die Datenbank(en) geschrieben. Das Transaktionsverhalten kann jedoch geändert werden, in dem die Eigenschaft Transaktionssteuerung verändert gesetzt wird.

Steuert die Transaktionsgrenzen für den Ausgangsbaum. Folgende Einstellungen sind möglich: 0 - commit at end, 1 - commit all und 2 – commit alias of this node.

Commit at endBeim Verlassen des Knotens wird kein Commit an die DB ausgelöst. Dies ist die Standardeinstellung. Sind alle Knoten des Ausgangsbaumes mit diesem Wert eingestellt, löst der DataWizard erst nach dem letzten Knoten des Ausgangsbaumes einen Commit an alle beteiligten Aliase aus. Die SQL-Anweisungen des Knotens werden commited, wenn ein Vaterknoten einen Commit auslöst.

Hinweis: Die Commitsteuerung ist von den Fähigkeiten der verwendeten Datenbank abhängig. Falls in der database.xml im zugehörigen Abschnitt <Set name="rollback">True</Set> auf false steht, unterstützt die DB keine Transaktionen und die Verbindung wird im autocommit Modus betrieben.

Commit allBeim Verlassen des Knotens wird für alle Aliase mit offenen Transaktionen ein Commit ausgelöst. Diese Einstellung ist z. B. sinnvoll, um auf Datenblatt Ebene alle erstellten SQL-Anweisungen abzuschließen. Kann der Commit von der DB nicht durchgeführt werden, löst der DataWizard auf dem betreffenden Alias einen Rollback aus.

Hinweis: Es handelt sich nicht um einen Zwei-Phasen Commit! Ein durchgeführter Commit auf einem Alias kann nicht mehr zurückgenommen werden!

Hinweis: Durch das Betreten eines Knotens mit der Einstellung commit all, werden bereits geöffnete Transaktionen nicht abgeschlossen, sondern die vorhandenen Transaktionen verwendet.

Commit alias of this nodeDies ist die gebräuchlichste Einstellung für eine Commit Steuerung. Beim Verlassen des Knotens wird für den zugehörigen Alias ein Commit ausgelöst. Kann der Commit von der DB nicht ausgeführt werden, löst der DataWizard auf dem Alias einen Rollback aus.

96 / 140

Abbildung: Transaktionssteuerung

1

Abbildung: Leerzeichen bei SQL entfernen

1

Hinweis: Durch das Betreten eines Knotens mit der Einstellung commit alias of this node, werden bereits geöffnete Transaktionen nicht abgeschlossen, sondern die vorhandene Transaktion verwendet.

Dynamisches Aktivieren von SQL-AnweisungenDas Schreiben der SQL-Anweisungen kann dynamisch deaktiviert werden. Neben dem generellen aktivieren/deaktivieren der SQL-Anweisungen kann nun noch eine Variable angegeben werden. Ist keine Variable eingetragen (default) gilt die Einstellung der Checkbox. Ist eineVariable eingetragen, wird der Inhalt in einen Boolschen Wert verwandelt und mit der Checkbox UND-Verknüpft. Die Variable wird nach dem Mapping ausgewertet. Im Logging wird unter Phase 4 ausgegeben ob das Schreiben auf Grund der Variablen deaktiviert wurde.

Die Variable schaltet das Ausführen von SQL-Anweisungen frei. Ist keine Variable eingetragen, gilt das als true. Kann der Inhalt der Variable nicht zu true ausgewertet werden, werden die SQL-Anweisungen nicht ausgeführt. Die Variable muss vom Benutzer manuell mit einem frei wählbaren Namen angelegt werden.

Knoten aus dem Ausgangsbaum entfernenEin Knoten in der Ausgangsstruktur hat die Eigenschaft Knoten gilt nur für SQL, ist dieses Flag aktiviert wird der Knoten und seine Kinder am Ende der Phase 4 aus der Ausgangsstruktur entfernt. Der Knoten wird auch enfernt wenn keine SQL-Anweisungen an die Datenbank gesendet wurden.

Eigenschaft um Knoten und dessen Kinder nicht in die Ausgangsdaten zu schreiben.

Für die nachfolgenden Phase 5 und Phase 6 stellt sieht der Ausgangsbaum aus als wenn der Knoten nicht vorhanden wäre.

97 / 140

Abbildung: SQL Anweisungen dynamisch einschalten

1

Abbildung: Knoten nur für SQL

1

Phase 5: Integration UnitWenngleich auch die Einstellungsmöglichkeiten des DataWizard sehr umfangreich sind, gibt es manchmal Ausnahmewünsche, die darüber hinausgehen. Hierfür wurde das Konstrukt der Integration Units eingeführt. Integration Unit ist eine Klasse, die ein bestimmtes Interface implementieren muss. Die Benutzer des DataWizard können selbst eigene Klassen erstellen und diese mit den Ausgabedaten aufrufen. Die Integration Units dienen zur Weiterleitung der Ausgabedaten an Drittsysteme.

Die angefertigten Klassen geben eine Liste mit notwendigen Parametern zurück. Diese Parameter werden im unteren Bildschirmabschnitt aufgelistet. Sie können nicht mit Platzhaltern (Variablen aus Ausgangsbaum) versehen werden.

Ein IntegrationUnit Eintrag wird mit Klassenname und Parametern vom Datawizard abgespeichert.

Die vier Felder Mandant ID, Partner ID, Funktion ID und Unter-Funktion ID bilden den Key des Eintrages. Um nicht versehentlich Einträge zu überschreiben, die bereits von anderen Profilen benutzt werden, kann mit dem Button Prüfe Rechte abgefragt werden, ob bereits ein Eintrag zu diesen Schlüsseln vorhanden ist. Diese Prüfung wird auch durchgeführt, wenn der Weiter Button betätigt wird.

Mit dem DataWizard werden die nachfolgenden Integration Units ausgeliefert:

• EDICreationUnit – Aus den Daten des Ausgangsbaums wird eine EDIFACT Struktur erzeugt. Die Unit kann mittels untenstehenden Parametern konfiguriert werden.

• Delimiters – gibt die Zeichen für das UNA Segment an.

• Replace Umlauts with checking case – Berücksichtigt beim Ersetzen von Umlauten ob der Umlaut an erster Stelle eines Wortes steht. In diesem Fall wird nur der erste Buchstabe der Ersetzung groß geschrieben.

98 / 140

Abbildung: Bildschirm für Aufruf von Integration Unit

• Cut line after 80 chars – Bei aktiviertem Schalter wird nach 80 Zeichen eine Zeilenschaltung eingefügt. Die Option ist erforderlich wenn die Daten für eine AS400 bestimmt sind.

• Add UNA Segment to result – Mit dem Schalter kann unterbunden werden, dass der DataWizard ein UNA Segment in die Ausgangsdaten einfügt. In diesem Fall müssen selbstverständlich die Default Metazeichen verwendet werden.

• Replace umlauts – Mit dem Schalter kann das Ersetzen der Umlaute deaktiviert werden.

• Replace umlauts with checking Case – Ist der Schalter aktiviert, werden aus großen Umlauten nach einem Blank ein Großbuchstabe und ein Kleinbuchstabe gemacht. (z.B. aus ' Ü' wird ' Ue', aus 'DRÜBEN' wird aber 'DRUEBEN').

• Write message in one line – Normalerweise schreibt der DataWizard jedes Segment in eine eigene Zeile, mit diesem Schalter können die Segmente in eine einzige Zeile geschrieben werden.

• Return EDIFACT in uppercase completely – Wandelt alle Kleinbuchstaben in Großbuchstaben um.

• XMLTemplateParserUnit – Die Unit füllt ein XML-Template mit den Daten aus dem Ausgangsbaum. Der Unit muss der Name des XML-Templates übergeben werden. Mit dieser Unit können die Ausgabedaten im beliebige XML Strukuren gefüllt werden. Die Unit kann mittels untenstehenden Parametern konfiguriert werden.

• expand empty nodes – Mit diesem Schalter wird veranlasst, dass leere Knoten nicht mittels Kurznotation <tagname/> sondern in der Langnotation <tagname></tagname> ausgegeben werden.

• Template-file – Legt Name und Pfad des Templates für das zu erstellende XML Dokument fest.

• File encoding – Legt die Zeichenkette fest, die im Header des XML Dokuments angegeben wird. Der Parameter bestimmt NICHT die Zeichencodierung sonder ist nur Prosatext um z.B folgenden Tag zu erzeugen; <?xml version="1.0" encoding="ISO-8859-1"?> Die tatsächliche Zeichencodierung der Ausgangsdaten muss im Antwortweg eingetragen werden.

• With empty fields – Gibt an ob Tags für leere Feldwerte ausgegeben werden sollen. Der oben angeführte Parameter expand empty nodes bestimmt das Format der leeren Tags. Die Einstellung gilt nicht für Knoten.

Hinweis: Im Kontextmenu der Ausgangsstruktur kann eine automatische Erstellung eines XML-Templates veranlasst werden.

• ExcelAppenderUnit – Die Unit füllt eine vorhandene Excel Datei mit Werten. Der Unit müssen Dateiname mit Pfad und Zeile, nach der die Daten eingetragen werden sollen, übergeben werden.

• CSVWithHeaderUnit – Die Unit erzeugt eine CSV Datei, in deren erster Zeile die Feldnamen der Ausgangsstruktur stehen. Der Unit kann das Trennzeichen im Parameter csv delimiter übergeben werden.

• CSVWithoutQuotesIU – Die Unit erzeugt eine CSV Datei, in der kein Hochkomma enthalten ist. Der Unit kann das Trennzeichen im Parameter csv delimiter übergeben werden.

99 / 140

Die erzeugte Struktur kann in der Phase 6 in die gewünschten Antwortkanäle ausgegeben werden.

Der Benutzer kann eigene Integration-Units schreiben und im DataWizard aufrufen. Zum Beispiel könnte damit eine nicht unterstützte Daten-Komprimierung realisiert werden.

Hinweis: Mehr Informationen zum Erstellen einer Integration-Unit ist im Dokument Erstellen von Integration-Units vorhanden.

Hinweis: Wenn eine IntegrationUnit auch Nicht-ASCII Zeichen erzeugt (z.B. PDF Format), muss im Antwortweg als Zeichencodierung 'raw data' eingestellt werden.

100 / 140

Benutzer-VerwaltungDer DataWizard verfügt über eine einfache Benutzerverwaltung, um die Rechte von Benutzern im System einzuschränken. Zu einem Benutzer gehören folgende Angaben:

• Anmeldename -> Name,, mit dem sich ein Benutzer im System anmeldet.

• Benutzername -> Name unter dem der Benutzer dem Administrator bekannt ist.

• Passwort -> Passwort, mit dem sich der Benutzer im System anmeldet.

• Administrator -> Legt fest, ob es sich beim Benutzer um einen Administrator handelt. Die Rechte von Administratoren können nicht eingeschränkt werden.

Zu einem Benutzer können folgende Berechtigungen vergeben werden:

• Log Datei ansehen -> Bestimmt, ob der Benutzer den Monitor verwenden darf.

• Profile erzeugen -> Bestimmt ,ob der Benutzer neue Profile anlegen darf.

• Profile löschen -> Bestimmt, ob der Benutzer Profile löschen darf. Wenn der Schalter aktiviert ist, kann noch unterschieden werden zwischen:

o Darf alle löschen -> Benutzer darf alle Profile ändern.

o Nur angegebene Profile -> Benutzer darf nur die festgelegten Profile löschen.

• Profile ändern -> Bestimmt, ob der Benutzer vorhandene Profile ändern darf. Wenn der Schalter aktiviert ist, kann noch unterschieden werden zwischen:

o Darf alle ändern -> Benutzer darf alle Profile ändern.

o Nur angegebene Profile -> Benutzer darf nur die festgelegten Profile ändern.

Unten stehend der Bildschirm um Namen und Berechtigungen von Benutzern zu administrieren.

101 / 140

Liste, der im System vorhandenen Benutzer. Die Daten des markierten Benutzers werden im unteren Bildschirmteil angezeigt.

Gibt an ob der Benutzer Administrator-Rechte hat. Wenn ja, sind alle anderen Berechtigungen aktiviert.

Liste aller Profile im DataWizard. Wenn der Benutzer nur ausgewählte Profile löschen darf, können hier die entsprechenden Einträge markiert werden.

Liste aller Profile im DataWizard. Wenn der Benutzer nur ausgewählte Profile bearbeiten darf, können hier die entsprechenden Einträge markiert werden.

Ein neuer Benutzer wird angelegt, dessen Zugangsdaten und Berechtigungen noch eingegeben werden müssen . Der Benutzer wird erst gespeichert, wenn der Button betätigt wird.

Änderungen an einem markierten Benutzer aus werden abgespeichert.

Gibt an ob der Benutzer den ContentInspector benutzen darf.

Löscht einen markierten Benutzer aus der Liste .

102 / 140

Abbildung: Administration von Benutzerrechten

1

2

3 4

5 6

7

8

Phase 6: Erstellung AusgangsdatenDie erstellten Daten können auf unterschiedlichen Wegen abgelegt bzw. versendet werden. Diese Ausgabemöglichkeiten können parallel genutzt werden.

Es gibt folgende mögliche Antwortwege:

• Mail(SMTP)

• X400

• FTP

• OFTP

• MessageService

• SMS

• Eigene Klasse

• Datei

• HTTP(S)

• AS/400

• SAP

• SCP

• WebDAV

Prinzipiell muss kein einziger solcher Antwortweg ausgewählt sein. Dies kann sinnvoll sein, wenn entweder schon die IntegrationUnit alle Ausgaben erledigt oder die Daten nur beim Mappingvorgang in eine Datenbank geschrieben werden.

Ausgangsbaum, mit einem oder mehreren Datenblättern.

Die Formate, in die der Ausgangsbaum umgewandelt werden kann.

Die möglichen Wege (Kanäle), über die die Antwort versendet werden kann.

Es kann eine Liste von Wegen erstellt werden, auf denen die Daten ausgegeben werden sollen. Diese Wege können in Abhängigkeit zueinander stehen. Jede Art von Antwortweg (z.B. "Datei") kann mehrfach vorkommen.

103 / 140

Abbildung: Mögliche Ausgangsformate und -wege

1 2 3

Ein Antwortweg, mit Format und Versandart. Es können beliebig viele dieser Antwortwege in einem Profil geben.

Status einer Antwort, in diesem Fall Status error.

Status einer Antwort, in diesem Fall Status success. Der Status einer Antwort kann immer nur einen Wert annehmen - oder .

Abhängigkeit einer Antwort von einem vorherigen Antwortstatus (, ). In diesem Fall ist die Abhängigkeit on error dargestellt. Wenn also der Status von Antwortweg 1 auf error steht, wird der Antwortweg 2 aktiviert.

Antwortweg ohne Abhängigkeit von vorangegangenen Antworten.

Abhängigkeit einer Antwort von einem vorherigen Antwortstatus (, ). In diesem Fall ist die Abhängigkeit on success dargestellt. Wenn also der Status von Antwortweg 1 auf success steht, wird der Antwortweg 4 aktiviert.

Beispiel aus der Praxis: Versuche, die Daten per FTP zu versenden. Sollte FTP fehlschlagen, speichere sie lokal in einer Datei und schicke sie auch noch per Mail an einen Sachbearbeiter. Sollte der FTP-Versand aber gelingen, schicke eine Mail mit einer Nachricht an einen Adminstrator.

Bei Abhängigkeiten kann, je nach Konfiguration, folgender Sonderfall auftreten: Ein Profil (A) ist von einem vorhergehenden Profil (B) abhängig, das aber nicht aufgerufen wurde (Aufgrund dessen Abhängigkeit). In diesem Fall wird der Status des Antwortwegs intern mit dem Status übersprungen (skipped) geführt. Das abhängige Profil (B) wird dann nicht ausgeführt. Allgemein gilt: die von übersprungenen Profilen abhängigen Profile werden nicht ausgeführt!

Es stellt sich die Frage, wie das Profil die Stati der Antwortwege interpretiert, wenn einige Antwortwege erfolgreich durchlaufen wurden und einige Fehler erzeugten? Hier gilt eine einfache Regel: Wenn mindestens ein Antwortweg erfolgreich war oder alle Antwortwege übersprungen wurden, gilt eine Antwort als erfolgreich.

Verhalten im FehlerfallSind mehrere Antwortwege eingetragen, kann es vorkommen, dass ein oder mehrere angesprochene Antwortwege nicht erfolgreich waren. Das System verhält sich für die untenstehenden Fälle wie folgt (Voraussetzung: in keinem Antwortweg ist das Flag Eintrag im Fehlerlog bei Fehler gesetzt)

● Keiner der angesprungenen Antwortwege war erfolgreich: In diesem Fall wird der

104 / 140

Abbildung: Abhängigkeiten Antwortwege

6

5

4 3

21

DataWizard immer eine Fehlermeldung in den Fehlermonitor schreiben.

● Mindestens einer der angesprungenen Antwortwege war erfolgreich: In diesem Fall hält der DataWizard die Antwort für erfolgreich und schreibt nur in die error.log Einträge für die fehlerhaften Antwortwege. In den Fehlermonitor wird kein Eintrag gemacht.-> Haben die Antwortwege keinerlei Abhängigkeiten, kann dieses Verhalten übersteuert werden, in dem in der Konfigurationsdatei startup.xml folgender Eintrag gemacht wird:Mit diesem Eintrag wird beim Auftreten eines Fehlers ein Eintrag in den Fehlermonitor

gemacht. Die Standardeinstellung für diesen Schalter ist false.

● Alle angesprungenen Antwortwege waren erfolgreich: Es liegt kein Fehler vor.

Ist bei einem Antwortweg das Flag Eintrag im Fehlerlog bei Fehler gesetzt, wird immer ein Eintrag im Fehlermonitor gemacht, falls der Antwortweg fehlschlägt.

Ist das Flag gesetzt, wird der Fehlermonitor immer benachrichtigt, falls im Antwortweg ein Fehler auftritt. Auch bei aktivierter Schalterstellung, werden die anderen Antwortwege im Fehlerfall durchlaufen.

Einstellungen für die AntwortwegeNachfolgend werden die Bildschirm Elemente beschrieben, mit denen die oben genannten Eigenschaften eingestellt werden können. Diese Einstellungen sind für alle Antwortwege gleich:

Ist Ausführen als Thread gewählt, wird für die Versendung der Antwortwege ein eigener Thread aufgemacht. Näheres zu diesem Punkt siehe weiter unten.

Will man auf mehreren Antwortwegen Dateien erzeugen, kann man einen Basis Dateinamen angeben, der dann überall verwendet wird. So können die Daten auf mehreren Wegen konsistent mit demselben Dateinamen ausgegeben werden. Hier können Muster angegeben werden, aus denen ein Dateiname generiert wird. Näheres dazu erläutert Abschnitt Filenamen generieren.

Gibt den Kanal an, über den die Antwort versendet werden soll (z.B. FTP oder Mail).

Gibt die Bedingung an, unter der die Antwort versendet werden soll (none, on error, on success). Bei none wird immer versendet, bei on error wird nur versendet wenn die Antwort über Kanal nicht erfolgreich war, die Bedingung on success arbeitet genau gegenteilig.

105 / 140

Abbildung: Einstellungen für Ausführung von Antwortwegen

1 23

4 56 7

8

<Call name="handleResponsesWithoutDependenciesAsError"><Arg type="boolean">True</Arg></Call>

Abbildung: Fehlermonitor immer benachrichtigen

1