File/FTP-Sender-Adapter konfigurieren 

Verwendung

Sie konfigurieren den File/FTP-Sender-Adapter, um damit Inhalte von Dateien an die Integration Engine zu verschicken.

Die Konfiguration besteht im Wesentlichen aus der Angabe

●      eines Verzeichnisses und eines Dateinamens mit Platzhalter (*) zur Auswahl der Dateien

●      eine Verarbeitungsvorschrift für erfolgreich versendete Dateien

●      einfacher Routinen zur Konvertierung einer Textdatei (mit Spalten fester Länge und/oder Spalten, die durch bestimmte Zeichen voneinander getrennt sind) in ein XML-Dokument (diese Angaben sind optional)

·        der Dispatcherklasse (optional) mit den entsprechenden Einstellungen sowie der vom Dispatcher aufzurufenden User-Exits und deren Einstellungen

●      der von der Integration Engine benötigten Absender- und Empfängerdaten für das Routing und Mapping

Voraussetzungen

Sie haben

...

       1.      den entsprechenden Adapter installiert

       2.      den Adapter in der Konfigurationsoberfläche ausgewählt

       3.      über Konfigurieren die Konfiguration des Adapters aufgerufen

Vorgehensweise

Für den File/FTP-Sender-Adapter besteht die Konfiguration aus fünf funktionalen Teilbereichen:

...

       1.      Der Name der Java-Klasse für den File/FTP-Sender-Adapter.

Geben Sie den Namen der Klasse folgendermaßen an:

classname=com.sap.aii.messaging.adapter.ModuleFile2XMB

Diese Angabe ist zwingend.

       2.      Die Versionsangabe für die Konfiguration.

version=30

Diese Angabe ist zwingend. Fehlt die Angabe, wird die Konfiguration als XI 2.0 Adapter-Konfiguration interpretiert. Andere Werte sind nicht zulässig und werden als Fehler ausgegeben.

       3.      Der Modus des File/FTP-Adapters.

Geben Sie den Modus des File/FTP-Sender-Adapters an. Erlaubte Werte sind

○       mode=FILE2XMB

Hier wird der Inhalt der Datei direkt zur Integration Engine geschickt.

○       mode=FILE2XMBWITHROWCONVERSION

Hier wird eine Textdatei mit identisch aufgebauten Zeilen erwartet, die in ein XML-Dokument konvertiert werden kann. Die für die Konvertierung notwendigen Angaben machen Sie in Schritt 7.

○       mode=FILE2XMBWITHSTRUCTURECONVERSION

Hier wird eine Textdatei mit komplexeren Dateistrukturen erwartet, die in ein XML-Dokument konvertiert werden kann. Eine solche Datei enthält unterschiedliche Zeilenformate in logischen Strukturen. Die für die Konvertierung notwendigen Angaben machen Sie in Schritt 8.

○       mode=FILE2XMBSTREAM

Hier wird ein spezielles Dateiformat erwartet, das eine vollständig serialisierte Nachricht der Integration Engine darstellt. Dieses Dateiformat kann vom File/FTP-Empfänger-Adapter im Modus XMBSTREAM2FILE erzeugt werden. Dieses Format eignet sich damit zum Zwischenspeichern kompletter Nachrichten der Integration Engine einschließlich aller für die Integration Engine spezifischen Parameter, wie sie unter Punkt 5 beschrieben werden. In diesem Modus werden daher nur noch die Parameter für die Anmeldung an der Integration Engine (nämlich XI.TargetURL, gegebenenfalls XI.User, XI.Password, XI.Client und XI.Language) aus der Konfiguration ausgewertet.

Der Vorschlagswert ist FILE2XMB.

       4.      Die Dispatcherklasse und die vom Dispatcher aufzurufenden User-Exits (optional)

Der File/FTP-Sender-Adapter bietet einen Dispatcher an, mit dem Sie Messages vor dem Verschicken konvertieren können. Die für den Dispatcher notwendigen Einstellungen werden anhand eines konkreten Beispiels erklärt.

       5.      Die Angaben für die Integration Engine

Geben Sie die vollständige Adresse (URL) der Integration Engine ein, an die die Message geschickt werden soll:

XI.TargetURL=http://IntegrationEngineHost:port/pipeline-arguments

Diese Angabe ist zwingend.

Für die Authentifizierung mit Zertifikat geben Sie eine Ziel-URL an, die das HTTPS-Protokoll unterstützt.

Die Adresse der Integration Engine kann auch dynamisch aus dem System Landscape Directory (SLD) ermittelt werden. Hierzu wird in der Konfiguration folgender Eintrag hinzugefügt:

XI.SLDConfiguration=SLDaccessor

In diesem Fall wird für das mit XI.SenderService angegebene System die URL des zugehörigen Integration Server im SLD ausgelesen und anstelle des unter XI.TargetURL angegebenen Wertes verwendet. Daher sollte hier folgendes angegeben werden:

XI.TargetURL=<fromSLD>

Damit der Zugriff funktioniert, muss der Dienst SLDaccessor für den Zugriff ins SLD konfiguriert sein, und die entsprechenden Einträge müssen im SLD gepflegt sein.

Ist der Integration Server nicht direkt, sondern über einen HTTP-Proxy-Server zu erreichen, müssen folgende Parameter gesetzt werden:

XI.proxyHost=<proxyHostname>

XI.proxyPort=<proxyPortnumber>

Hierbei ist <proxyHostname> der Host-Name des Proxy und <proxyPortnumber> der Port, auf dem der Proxy HTTP-Requests annimmt (z.B. 8080).

Wurde für die angegebene URL (HTTP-Service) in der Integration Engine eine Authentifizierung spezifiziert, sind die folgenden Angaben zwingend:

○       XI.User=<user-name>

○       XI.Password=<password>

Die Angaben müssen mit denen übereinstimmen, die Sie in der Transaktion SICF in der Integration Engine gemacht haben. Falls Sie keine oder eine ungültige Kombination von Benutzer und Kennwort angeben, wird jeder Übertragungsversuch in die Integration Engine mit Transport Exception: http-Error 401 – Unauthorized scheitern.

Der Benutzer muss im Integration Server über die Berechtigungen der Gruppe SAP_XI_APPL_SERV_USER verfügen.

Wurde für die angegebene URL (HTTPS-Service) in der Integration Engine eine Authentifizierung mit Zertifikat spezifiziert, sind die folgenden Angaben zwingend:

○       Geben Sie unter SSLcertificateden Pfad zum Schlüsselpaar an.

Geben Sie den Pfad relativ zum Installationsverzeichnis der Adapter-Engine an.

Das Schlüsselpaar muss als P12- oder PFX-Datei vorliegen.

○       Um die Schlüsselpaardatei zu sichern, können Sie für Parameter SSLcertificatePassword ein Kennwort angeben.

○       Um das Server-Zertifikat anhand des Zertifikats in der Zertifikatverwaltung zu überprüfen, geben Sie SSLauthentication=true an.

Soll bei der Anmeldung ein anderer Mandant bzw. eine andere Sprache als die Default-Werte der Integration Engine verwendet werden, können Sie zusätzlich die folgenden Parameter setzen:

○       XI.Client=<client-no>

○       XI.Language=<language-id>

Die folgenden Argumente können – außer im Modus FILE2XMBSTREAM – gesetzt werden und dienen der Identifikation der Adapter-Konfiguration beim Routing und Mapping in der Pipeline der Integration Engine. Dort ist auch die Bedeutung der einzelnen Argumente beschrieben.

○       XI.SenderParty=<sender party name>

○       XI.SenderService=<sender service name>

○       XI.InterfaceNamespace=<namespace URI>

○       XI.Interface=<name>

○       XI.ReceiverParty=<receiver party name>

○       XI.ReceiverService=<receiver service name>

Zwingend sind zumindest XI.SenderService sowie XI.Interface und XI.InterfaceNamespace. Der Empfänger wird in der Regel durch das Routing in der Integration Engine bestimmt. Diese Angabe ist nicht zwingend.

○       XI.QualityOfService=<QualityOfService>

Gibt an wie eine Message durch die Integration Engine verarbeitet werden soll. Erlaubte Werte sind:

■       XI.QualityOfService=BE (Best Effort: bedeutet synchrone Verarbeitung)

■       XI.QualityOfService=EO (Exactly Once: bedeutet asynchrone Verarbeitung mit garantierter einmaliger Ausführung)

■       XI.QualityOfService=EOIO (Exactly Once in Order: bedeutet asynchrone Verarbeitung über Queues, das heißt, garantierte einmalige Ausführung unter Beibehaltung der Reihenfolge aufeinanderfolgender Nachrichten)

Bei EOIO muss zusätzlich ein Queue-Name definiert werden:

○       XI.QueueId=<QueueName>

Dieser Queue-Name wird in der Integration Engine verwendet, um Nachrichten in der Reihenfolge ihres Eingangs zu bearbeiten.

       6.      Die Angaben für die Dateiauswahl und den Verarbeitungsmodus

Die folgenden Angaben sind zwingend:

○       file.type=BIN|TXT

Mit diesem Parameter geben Sie an, ob die Datei als Textdatei oder als Binärdatei gelesen werden soll. Bei einer Binärdatei werden die Daten unverändert übertragen, bei einer Textdatei kann mit dem Parameter file.encoding eine Codepage definiert werden (siehe unten). Voreingestellt ist die Codepage des Hosts, auf dem die Adapter-Engine läuft.

○       file.sourceDir=<directory_name>

Geben Sie das Verzeichnis an, in dem sich die zu verarbeitenden Dateien befinden.

Sie können den Namen absolut angeben oder relativ zum Arbeitsverzeichnis der Adapter-Engine. Verwenden Sie auf allen Plattformen (einschließlich Windows) einen Schrägstrich (/), um Verzeichnisnamen gemäß der Java-Spezifikation zu trennen.

○       file.sourceFileName=<filename>

Geben Sie den Namen der Datei an, die verarbeitet werden soll.

Der Name kann an beliebiger Stelle einen Platzhalter (*) enthalten, um so eine Liste von Dateien für die Verarbeitung auswählen zu können.

Gültige Beispiele für filename sind:

myFile.txt

my*.txt

*.txt

*File.*

*File*.*

my*le.*

Namen, die aus mehr als zwei Teilen bestehen, sind ebenfalls möglich.

○       file.pollInterval=

Geben Sie die Anzahl an Sekunden an, die der Adapter warten soll, wenn keine Dateien zur Verarbeitung gefunden werden.

Optional können Sie zusätzlich den folgenden Parameter angeben, um eine zusätzliche Wartezeit in Millisekunden anzugeben:

file.pollIntervalMsecs=

Ist file.pollInterval auf 0 gesetzt, lassen sich so sehr kurze, echtzeitnahe Verarbeitungszeiten erreichen.

Der Vorschlagswert für diesen Parameter ist 0.

Wenn kein wiederholter Aufruf stattfinden soll, müssen Sie beide Parameter auf 0 setzen (bzw. nur den Parameter file.pollInterval, wenn Sie für den Parameter file.pollIntervalMsecs keinen Wert angeben).

In diesem Fall verbleibt der Adapter zwar im Status GESTARTET muss aber über Anhalten/Starten bzw. Neu starten erneut gestartet werden, um einen erneuten Aufruf zu initiieren.

○       file.retryInterval=

Geben Sie die Anzahl an Sekunden an, die der Adapter warten soll, bis eine fehlerhaft verarbeitete Datei erneut verarbeitet wird.

Als Voreinstellung wird der Wert von file.pollInterval übernommen. Ist dieser Wert 0 (findet also keine Wiederholung der Dateiverarbeitung statt), wird auch keine erneute Verarbeitung von fehlerhaft verarbeiteten Dateien vorgenommen.

Ist file.retryInterval gleich 0, wird im Fehlerfall der Adapter beendet, auch wenn für file.pollInterval ein Wert größer 0 angegeben wurde. In diesem Fall verbleibt der Adapter zwar im Status GESTARTET, muss aber über Anhalten/Starten bzw. Neu starten erneut gestartet werden, um eine erneute Verarbeitung zu initiieren.

○       file.checkFileModificationInterval=<msecs>

Hiermit kann eine Wartezeit definiert werden (Vorschlagswert: 0), die der File/FTP-Adapter nach dem Einlesen der Datei abwartet, ob sich die Dateilänge noch nachträglich verändert. In diesem Fall wird der Einlesevorgang wiederholt. Dies ist sinnvoll, wenn die vom Adapter einzulesenden Dateien dynamisch erzeugt werden, ohne dass sie auf Betriebssystemebene gesperrt sind (beispielsweise Dateien, die von FTP-Servern empfangen werden). Ohne diese Behelfslösung kann der File/FTP-Adapter bei solchen Anwendungen mit Betriebssystemmitteln nicht erkennen, ob die Datei bereits vollständig erzeugt wurde.

○       file.logPollInterval=NO|YES

Im Protokoll des Adapters wird der Eintritt in die Warteschleife standardmäßig ausgegeben bei Warteschleifen, die länger als 5 Sekunden dauern. Dies kann zu entsprechend vielen Ausgaben im Protokoll führen. In solchen Fällen kann die Ausgabe im Protokoll (nicht die Warteschleife selbst) mit file.logPollInterval=NO abgeschaltet werden.

Bei Warteschleifen, die 5 Sekunden oder weniger dauern, kann die Ausgabe mit file.logPollInterval=YESaktiviert werden.

○       file.processingMode=<processingMode>

Geben Sie an, wie die Dateien verarbeitet werden sollen, nachdem ihr Inhalt erfolgreich zur Integration Engine gesendet wurde.

Fünf Verarbeitungsarten für processingMode sind möglich: delete, archive, archiveWithTimestamp, setAttribute oder test.

delete bedeutet, dass erfolgreich verarbeitete Dateien gelöscht werden sollen.

archive und archiveWithTimestamp bedeuten, dass erfolgreich verarbeitete Dateien in ein Archivverzeichnis geschoben werden.

Im Modus archive wird der Dateiname unverändert übernommen. Existiert bereits eine Datei gleichen Namens im Archivverzeichnis, wird sie überschrieben.

Im Modus archiveWithTimestamp wird dem Dateinamen ein Zeitstempel mit Datum und Uhrzeit vorangestellt. Das Format des Zeitstempels ist yyyyMMdd-hhMMss-SSS_, wobei yyyy eine Jahreszahl angibt und SSS die Millisekunden. Hierdurch können die Dateien unabhängig von ihrem Namen im Archivverzeichnis nach ihrem zeitlichen Eingang sortiert werden. Ein Überschreiben gleichnamiger Dateien wird somit ebenfalls verhindert.

Für beide Verarbeitungsarten muss das Archivverzeichnis über folgenden Parameter angegeben werden:

■       file.archiveDir=<archiveDir>

Dieser Parameter ist für diese Verarbeitungsarten zwingend.

setAttribute bedeutet, dass erfolgreich verarbeitete Dateien mit dem Attribut read-only versehen werden. Dies wiederum bedeutet, dass nur beschreibbare Dateien verarbeitet werden.

test bedeutet, dass keinerlei Verarbeitung auf erfolgreich versendete Dateien angewendet wird.

Dies hat zur Folge, dass die Dateien nach einem Neustart des File/FTP-Adapters, oder nach der in file.pollIntervalangegebenen Zeitspanne, erneut als neue Nachricht versendet werden. Dieser Modus eignet sich daher ausschließlich zum Testen von Konfigurationen des File/FTP-Adapters oder der Integration Engine und nicht für den Produktivbetrieb.

Die folgenden Angaben sind nicht zwingend:

○       file.processingLocked=YES|NO

Geben Sie hier an, ob auch durch andere Anwendungen gesperrte Dateien übertragen werden sollen. Voreingestellt ist NO, das heißt, es werden nur Dateien übertragen, die nicht gesperrt sind. Dies verhindert insbesondere, dass der Adapter unvollständige Dateien überträgt, die durch andere Anwendungen erzeugt oder übertragen werden. Den Wert YES sollten Sie daher nur angeben, wenn sichergestellt ist, dass solche Datenverluste nicht auftreten können.

○       file.processingOrder=<processingOrder>=byDate|byName

Geben Sie hier an, in welcher Reihenfolge Dateien verarbeitet werden sollen, wenn Sie bei der Angabe von file.sourceFileName Platzhalter verwendet haben und mehrere zu verarbeitende Dateien gefunden wurden.

Der Vorschlagswert ist byName, was bedeutet, dass die Dateien in alphabetischer Reihenfolge verarbeitet werden. Alternativ können Sie byDate angeben, in welchem Fall die Dateien in der Reihenfolge ihres Zeitstempels im Dateisystem verarbeitet werden, beginnend mit der ältesten Datei.

○       file.messageAttributes=<name,directory>

Um den Namen der bearbeiteten Datei und/oder den Namen des Verzeichnisses, aus dem die Datei stammt im Message-Header der XI Message abzulegen, setzen Sie den Parameter.

Sie können auch nur den Dateinamen oder den Verzeichnisnamen im Message-Header ablegen.

Weitere Informationen: Adapterspezifische Attribute im Message-Header

○       file.emtpyFileStop=true|false

Legen Sie fest, wie leere Dateien (Länge 0 Byte), die im Quellverzeichnis gefunden werden, behandelt werden sollen.

Der Vorschlagswert ist false. Findet der Adapter eine leere Datei im Quellverzeichnis, wird diese verarbeitet.

Setzen Sie den Wert auf true und XI.QualityOfService=EOIO, wird eine Fehlermeldung erzeugt und die Verarbeitung der Queue wird gestoppt.

Setzen Die den Wert auf  true und XI.QualityOfService=EO, wird die Verarbeitung der leeren Datei gestoppt, und eine Fehlermeldung wird erzeugt. Die leere Datei wird aus dem Quellverzeichnis gelöscht und in einem Verzeichnis abgelegt, das Sie mit Parameter file.badMsgDir festlegen.

○       file.badMsgDir=<valid path to directory to collect empty files>

Geben Sie den Pfad zum Verzeichnis an, in das leere Dateien gespeichert werden sollen. Dem Dateinamen jeder leeren Datei, die in dem Verzeichnis abgelegt wird, wird ein Zeitstempel hinzugefügt. Für jede hier abgelegte leere Datei wird eine Script-Datei erzeugt.

Um eine korrigierte Datei wieder mit ihrem ursprünglichen Namen in das Quellverzeichnis zur weiteren Verarbeitung zu kopieren, klicken Sie auf die Script-Datei. Die Script-Datei wird anschließend automatisch gelöscht.

○       file.execute=<operating system command>

Ein hier spezifiziertes Betriebssystemkommando wird nach erfolgreicher Verarbeitung einer Datei ausgeführt. Der Vorschlagswert ist eine leere Zeichenkette (kein Kommando).

Der aktuell prozessierte Dateiname kann mit dem Platzhalter %f (Dateiname) bzw. %F (absoluter Dateiname inklusive Pfad) im Betriebssystemkommando mitgegeben werden.

○       file.executeAfterAll=<operating system command>

Ein hier spezifiziertes Betriebssystemkommando wird nach erfolgreicher Verarbeitung aller Dateien ausgeführt, die in einem Durchlauf gefunden wurden. Der Vorschlagswert ist eine leere Zeichenkette (kein Kommando).

○       file.encoding=<codepage>

Dieser Parameter wird für das Einlesen von Textdateien verwendet. Standardmäßig wird hier die System-Codepage verwendet, die von der Konfiguration des installierten Betriebssystems abhängt. Diese finden Sie beispielsweise unter file.encoding bei den allgemeinen Systeminformationen des Menüeintrags Über Adapter Engine.

Bei XML-Textdokumenten, die in UTF-8 codiert sind, müssen Sie hier den Wert UTF-8 angeben. Textdateien, die weder in der System-Codepage noch in UTF-8 codiert sind, können nur gelesen werden, wenn die entsprechende Codepage in der Java-Laufzeitumgebung verfügbar ist. Der Dateiinhalt wird dann vor dem Versenden in die Codepage UTF-8 umgewandelt.

Erlaubte Werte für die Codepage sind die vorhandenen Charsets der Java-Laufzeit. Nach der Spezifikation von SUN für die Java-Laufzeit müssen mindestens die folgenden Standard-Charsets unterstützt sein:

Charsets der Java-Laufzeit

Charset	Beschreibung
US-ASCII	Sieben-Bit ASCII, auch bekannt als ISO646-US, oder Basic-Latin-Block des Unicode-Zeichensatzes
ISO-8859-1	ISO-Zeichensatz für westeuropäische Schriften (Latin Alphabet Nr. 1), auch bekannt als ISO-LATIN-1
UTF-8	Acht-Bit Unicode-Zeichendarstellung
UTF-16BE	16-Bit Unicode-Zeichendarstellung, big-endian Byte-Order
UTF-16LE	16-Bit Unicode-Zeichendarstellung, little-endian Byte-Order
UTF-16	16-Bit Unicode-Zeichendarstellung Byte-Order

Überprüfen Sie in der Dokumentation für Ihre Java-Laufzeit-Implemetierung, welche weiteren Charsets unterstützt werden.

XML-Textdokumente enthalten in der Regel ihre eigene Codepage-Beschreibung und sollten als Datei-Typ Binär behandelt werden.

Soll die Dateiauswahl nicht aus dem Dateisystem, sondern von einem FTP-Server erfolgen, sind zusätzlich folgende Angaben erforderlich:

○       ftp.host=<ftp-server>

Der Host-Name oder die IP-Adresse des FTP-Servers. Ist diese Angabe vorhanden, wird von einem FTP-Server-Zugriff ausgegangen. Die Angaben file.sourceDirund file.sourceFileName beziehen sich dann auf den FTP-Server. Folgende Angaben sind dann nicht möglich:

■       setAttributebei Parameter file.processingMode

■       byDate bei Parameter file.processingOrder.

○       ftp.port=<port-no.>

Die Port-Nummer des FTP-Servers. Die Angabe ist nicht zwingend; die Voreinstellung ist der Standard-Port für FTP-Server (21).

○       ftp.user=<user name>

○       ftp.password=<password>

Ein für den FTP-Server gültiger Benutzername. Die Angabe ist nicht zwingend; die Voreinstellung ist der Benutzer anonymous mit dem Kennwort anonymous.

○       ftp.connection=perFileTransfer|permanently

Mit dieser Angabe können Sie festlegen, ob für jeden Dateitransfer zum FTP-Server eine neue Verbindung geöffnet werden soll (Wert perFileTransfer) oder ob eine bestehende Verbindung permanent genutzt werden soll (Wert permanently). In diesem Fall wird die Verbindung automatisch wiederaufgebaut, falls sie server-seitig geschlossen wurde (zum Beispiel wegen Time-out). Vorschlagswert ist permanently.

○       ftp.mode=<Binary|Text>

Mit dieser optionalen Angabe können Sie den Übertragungsmodus der FTP-Verbindung auf Text oder Datentransfer setzen. Vorschlagswert ist der Payload-Typ des empfangenen Dokuments vom Integration Server.

 

       7.      Die Angaben für die Konvertierung in ein XML-Dokument im Modus FILE2XMBWITHROWCONVERSION

Haben Sie in Schritt 2 den Modus des File/FTP-Sender-Adapters auf FILE2XMBWITHROWCONVERSION gesetzt, wird eine Textdatei mit identisch aufgebauten Strukturen eines Typs erwartet, die standardmäßig zeilenweise angeordnet sind. Es ist aber auch die Angabe anderer Trennzeichen möglich, um die Strukturen zu trennen. Die Strukturen können in ein XML-Dokument konvertiert und anstelle der ursprünglichen Datei an die Integration Engine verschickt werden. Diese Konvertierung geschieht zusätzlich zu allen anderen Verarbeitungen, die in den vorherigen Abschnitten beschrieben werden.

Die Zeilen der Textdatei müssen entweder Trennzeichen enthalten oder über Spalten fester Länge verfügen oder beides. Namen für die Spalten können Sie entweder explizit in diesem Abschnitt angeben, oder sie können als Header-Zeile aus der Datei selbst gelesen werden.

Ansonsten können keine weiteren Metadaten (wie Spaltentypen oder Konvertierungsregeln für Spalten) angegeben werden. Solche Informationen müssen beim Mapping in der Pipeline der Integration Engine zur Verfügung gestellt werden. Mit der Konvertierung des File/FTP-Sender-Adapters von nicht-XML zu XML soll nur ein XML-Dokument für das Mapping in der Integration Engine erstellt werden.

Behandlung von Strukturabweichungen

Die Umwandlungsroutine geht grundsätzlich von konstanten Strukturen aus. Die Anzahl der Felder entspricht der Angabe im Parameter xml.fieldNamesoder der Anzahl und Länge der Felder der Angabe im Parameter xml.fieldFixedLengths.

Es findet keine Validierung der Strukturen statt. Es werden Ihnen jedoch einige unten beschrieben Parameter zur Verfügung gestellt, mit denen Sie das Verhalten der Umwandlungs-Routine bei Strukturabweichungen beeinflussen können.

Wenn Sie zulassen wollen, dass die zur Laufzeit gefundene Struktur von der konfigurierten Struktur abweichen kann, konfigurieren Sie die Parameter xml.missingLastFields und xml.additionalLastFields. Verwenden Sie die Parameter nicht, wird abhängig davon, ob Sie den Parameter xml.fieldFixedLengths konfiguriert haben, das Ergebnis der Umwandlung wie folgt aussehen:

○       Parameter xml.fieldFixedLengths ist nicht definiert.

Die Anzahl der Felder in der Eingangsstruktur wird durch den in xml.fieldSeparator angegebenen Wert definiert :

■       Enthält die Eingangsstruktur mehr Felder als in xml.fieldNames angegeben, wird die Umwandlung mit einer Fehlermeldung abgebrochen.

■       Enthält die Eingangsstruktur weniger Felder als in xml.fieldNames angegeben, wird die Umwandlung durchgeführt.

In der XML-Struktur fehlen die Felder ebenfalls

○       Parameter xml.fieldFixedLengths ist definiert

■       Enthält die Eingangsstruktur mehr Felder als in xml.fieldNames oder in xml.fieldFixedLengths angegeben, wird die Umwandlung durchgeführt.

Zusätzliche Felder in der Struktur werden ignoriert

■       Enthält die Eingangsstruktur weniger Felder als in xml.fieldNames angegeben, wird die Umwandlung mit einer Fehlermeldung abgebrochen.

Wenn nur das letzte Feld kürzer ist als definiert oder ganz fehlt, wird die Umwandlung durchgeführt. Der Inhalt des letzten Feldes wird wie vorgefunden in das XML-Element eingestellt. Der Wert kann also unvollständig oder leer sein.

Diese Verhalten können Sie mit den Parametern xml.missingLastFields und xml.additionalLastFields ändern. Verwenden Sie diese Parameter, ist eine definierte Überprüfung der Eingangstrukturen möglich und es werden wohl definierte Ausgangsstrukturen erzeugt.

Einen Teil der Funktion dieser Parameter können Sie auch durch den Parameter xml.lastFieldsOptional implementieren.

xml.lastFieldsOptional ist jedoch veraltet, verwenden Sie ihn nicht mehr.

Verwenden Sie den Parameter gemeinsam mit den Parametern xml.missingLastFields und xml.additionalLastFields, wird eine Fehlermeldung zur Laufzeit ausgegeben.

Die nachfolgend als zwingend markierten Argumente beziehen sich auf den Modus FILE2XMBWITHROWCONVERSION. Im Modus FILE2XMB müssen keine der nachfolgend aufgeführten Argumente gesetzt werden; vorhandene Argumente werden ignoriert.

Machen Sie die folgenden Angaben:

○       xml.processFieldNames=

Machen Sie eine Angabe zu den Feldnamen. Folgende Angaben sind möglich:

■       notAvailable bedeutet, dass keine Informationen zu Feldnamen verfügbar sind.

Bei notAvailable werden weder in der Konfiguration noch in der zu konvertierenden Datei Informationen zu Feldnamen vermutet. In diesem Fall erhalten die Spalten im XML-Dokument zur Identifizierung ein einfaches Zähler-Tag (<columnX> , X=0,1,2…).

■       fromFile bedeutet, dass sich die Informationen zu Feldnamen in der Header-Zeile der zu konvertierenden Datei befinden.

■       fromFileWithBlankLineentspricht fromFile; zusätzlich folgt der Header-Zeile eine Leer- oder Trennzeile, die übersprungen wird.

■       fromConfigurationbedeutet, dass keine Header-Informationen in der zu konvertierenden Datei vorliegen, sondern durch die aktuelle Konfiguration geliefert werden. Hierzu müssen Sie den Wert von xml.fieldNames= entsprechend setzen (siehe unten).

Diese Angabe ist zwingend.

○       xml.fieldFixedLengths=

Wenn Sie hier eine Angabe machen, wird eine Zeichenkette erwartet, die die Längen der Spalten der Datei als durch Kommata getrennte Argumente enthält. Geben Sie für die Spalten auch ein Trennzeichen an, darf die Länge des Trennzeichens nicht zur Spaltenlänge hinzuaddiert werden.

Die Angabe von xml.fieldFixedLengths= ist zwingend, wenn bei xml.fieldSeparator= keine Angabe gemacht wird.

○       xml.fieldSeparator=

Wenn Sie hier eine Angabe machen, wird erwartet, dass die Datei die angegebene Zeichenkette (ein oder mehrere Zeichen) als Trennzeichen zwischen den einzelnen Spalten enthält.

Haben Sie bei fieldFixedLengths= keine Angabe gemacht, ist dies die einzige Angabe zur Identifikation der einzelnen Spalten einer Reihe.

Haben Sie bei fieldFixedLengths= eine Angabe gemacht, wird die zusätzliche Länge des Trennzeichens berücksichtigt, aber keine zusätzlichen Konsistenzprüfungen durchgeführt.

Sie müssen zumindest xml.fieldFixedLengths oder xml.fieldSeparator spezifizieren.

○       xml.lastFieldsOptional=YES|NO (veraltet)

Dieser Parameter gibt an, ob bei einer Struktur mit festen Feldlängen, wie im Parameter xml.fieldFixedLengths definiert, die letzten Felder fehlen dürfen (YES) oder nicht (NO). Ohne Angabe ist der Wert NO vorbelegt.

Bei CSV Strukturen wirkt der Parameter nicht, hier werden fehlende Felder ignoriert.

○       xml.keepIncompleteFields=YES|NO(veraltet)

Der Parameter wird nur ausgewertet, wenn Sie eine Angabe zum Parameter xml.fieldFixedLengths machen.

■       Geben Sie NO an und das letzte in der Struktur gefundene Feld der Struktur ist kürzer als in xml.fieldFixedLengths angegeben, bricht die Verarbeitung der Struktur mit einer entsprechenden Fehlermeldung ab.

Dies ist der Vorgabewert.

■       Geben Sie YES an, wird das letzte gefundene Feld der Eingangsstruktur in die Ausgangsstruktur übernommen, auch wenn es kürzer ist als in xml.fieldFixedLengths angegeben.

Mit diesem Parameter steuern Sie nur das Verhalten der Umwandlungs-Routine für das letzte Feld einer Struktur.

Legen Sie das Verhalten zur Laufzeit für den Fall, dass die Struktur insgesamt weniger Felder enthält als in xml.fieldFixedLengths angegeben, über den Parameter xml.missingLastFields fest.

○       xml.enclosureSign=

Hier können Sie eine Zeichenkette angeben, die als Textbegrenzer wirkt. Text innerhalb solcher Textbegrenzer wird unverändert in die Zielstruktur übernommen, wobei im Standardfall die Textbegrenzer entfernt werden. In solchen Texten enthaltene Trennzeichen werden ignoriert.

Dieser Parameter ist optional. Voreingestellt ist der leere Wert (kein Textbegrenzer).

○       xml.enclosureSignEnd=

Falls es unterschiedliche Textbegrenzer für den Beginn und das Ende eines Textes gibt, können Sie hier den Textbegrenzer für das Textende angeben. Machen Sie keine Angabe, wird der Wert von xml.enclosureSign verwendet.

○       xml.enclosureSignEscape=

Hier können Sie eine Zeichenkette angeben, die den Textbegrenzer ersetzt, wenn dieser innerhalb eines von ihm begrenzten Textes vorkommt. Bei der Übernahme des Textes wird diese Zeichenkette dann durch den bei xml.enclosureSign angegebenen Wert ersetzt. Voreingestellt ist der leere Wert.

○       xml.enclosureSignEndEscape=

Hier können Sie eine Zeichenkette angeben, die den Textbegrenzer für das Textende ersetzt, wenn dieser innerhalb eines von ihm begrenzten Textes vorkommt. Bei der Übernahme des Textes wird diese Zeichenkette dann durch den bei xml.enclosureSignEnd angegebenen Wert ersetzt. Voreingestellt ist der leere Wert.

○       xml.enclosureConversione=YES|NO

Dieser Wert gibt an, ob die Textbegrenzer bei der Übernahme entfernt bzw. die Escape-Zeichen ersetzt werden sollen. Voreingestellt ist YES; bei NO werden die Zeichen unverändert übernommen.

Haben Sie xml.enclosureSign=“ und xml.enclosureSignEsc=““ angegeben, wird in Anführungszeichen vorhandener Text im Dokument unverändert übernommen und die Anführungszeichen werden entfernt.

Kommt im Text selber das Escape-Zeichen ““ für ein Anführungszeichen vor, wird es bei der Übernahme durch das Anführungszeichen ersetzt.

○       xml.endSeparator=

Machen Sie hier eine Angabe, wenn Sie eine zusätzliche Zeichenkette als Trennzeichen nach der letzten Spalte einer Reihe definieren möchten. Dieses wird beim Verarbeiten der letzten Spalte übersprungen (andernfalls würde es als Teil der letzten Spalte behandelt).

Der Vorschlagswert ist ein Zeilenumbruch, also kein explizites Trennzeichen nach der letzten Spalte. Statt dessen sind die Strukturen zeilenweise angeordnet.

○       xml.beginSeparator=

Machen Sie hier eine Angabe, wenn Sie eine zusätzliche Zeichenkette als Trennzeichen vor der ersten Spalte einer Reihe definieren möchten. Dieses wird beim Verarbeiten dieser Spalte übersprungen (andernfalls würde es als Teil der ersten Spalte behandelt).

Der Vorschlagswert ist eine leere Zeichenkette (also kein Trennzeichen vor der ersten Spalte).

Sonderzeichen in den Zeichenketten für Trennzeichen:

In allen Zeichenketten für Trennzeichen (xml.fieldSeparator, xml.beginSeparator, und xml.endSeparator) ist die Angabe von nicht-druckbaren ASCII-Zeichen möglich. Diese Zeichen können in der Form ´0xHH´ (einschließlich der Hochkommata) jeweils einzeln in die Zeichenketten eingefügt werden, wobei HH das als Hexadezimalwert kodierte Zeichen darstellt.

Zeichenketten für Trennzeichen in das XML Dokument einfügen:

Die mit xml.beginSeparator und xml.endSeparator spezifizierten Trennzeichen können auch als Felder in die Struktur des erzeugten XML-Dokuments eingefügt werden. Hierzu spezifizieren Sie Feldnamen mit den Angaben

xml.addBeginSeparatorAsField=<fieldname>

und/oder

xml.addEndSeparatorAsField=<fieldname>

Die Zeichenketten werden dann mit dem angegebenen Feldnamen am Beginn bzw. am Ende der Struktur eingefügt, so wie sie unter xml.beginSeparator und xml.endSeparator angegeben wurden, das heißt einschließlich der Definitionen von Sonderzeichen. Eine Umwandlung in die Sonderzeichen wird nicht vorgenommen, da solche Zeichen in XML-Dokumenten nicht erlaubt sind.

○       xml.fieldNames=

Wenn Sie fromConfiguration für processFieldNames= angegeben haben, ist diese Angabe zwingend. Eine Liste der Spaltennamen wird erwartet, deren Format von den folgenden Angaben abhängt:

Haben Sie für xml.fieldFixedLengths= einen Wert angegeben, wird eine Zeichenkette erwartet, die die Namen der Dateispalten als Argumente enthält, die durch Kommata getrennt sind (dies gilt auch, wenn Sie zusätzlich einen Wert für xml.comlumnSeparator= angegeben haben).

Haben Sie nur einen Wert für xml.fieldSeparator= angegeben, wird eine Zeichenkette erwartet, die die Namen der Dateispalten im gleichen Format enthält wie die Dateizeilen, was bedeutet, dass das gleiche Trennzeichen und eine eventuell für xml.endSeparator und/oder xml.beginSeparator zusätzlich angegebene Zeichenkette erwartet wird.

○       xml.fieldContentFormatting=trim|nothing

Haben Sie trim (die Voreinstellung) angegeben, werden alle führenden und nachfolgenden Leerzeichen eines gefundenen Wertes entfernt.

Haben Sie nothing angegeben, bleibt der Wert unverändert.

○       xml.structureTitle=<anyName>

Der hier angegeben Wert wird als Name der Struktur im XML-Schema übernommen. Die Voreinstellung ist row.

○       xml.documentName=<name>

Geben Sie einen Dokumentnamen an, wird er als Haupt-XML-Tag in die Message eingefügt. Die Voreinstellung ist resultset.

○       xml.documentNamespace=<namespace>

Der Namensraum wird, wenn angegeben, an den Namen des Dokuments angehängt.

Verwenden Sie folgende Parameter, wenn Sie das Verhalten der Umwandlungs-Routine für Eingangsstrukturen, die von der Konfiguration abweichen, beeinflussen wollen:

○       xml.missingLastFields=ignore|add|error

Hat die Eingangsstruktur weniger Felder als in der Konfiguration angegeben, wird die XML-Ausgangsstruktur wie folgt erstellt:

■       ignore

Die Ausgangsstruktur enthält nur die in der Eingangsstruktur vorhandenen Felder

■       add

Die Ausgangsstruktur enthält alle Felder aus der Konfiguration, die in der Eingangsstruktur nicht vorhandenen Felder sind leer.

■       error

Die Umwandlung wird aufgrund der unvollständigen Eingangsstruktur abgebrochen. Eine entsprechende Fehlermeldung wird ausgegeben

○       xml.additionalLastFields=ignore|error

Hat die Eingangsstruktur mehr Felder als in der Konfiguration angegeben, wird die XML-Ausgangsstruktur wie folgt erstellt:

■       ignore

Die Ausgangsstruktur enthält nur die in der Eingangsstruktur vorhandenen Felder

■       error

Die Umwandlung wird aufgrund der unvollständigen Eingangsstruktur abgebrochen. Eine entsprechende Fehlermeldung wird ausgegeben

Der Vorschlagswert ist ignore. Haben Sie den Parameter xml.fieldFixedLengths definiert, ist der Vorschlagswert error.

Haben Sie den Parameter xml.fieldFixedLengths definiert und Sie setzen keinen der beiden oben beschriebenen Parameter, arbeitet die Umwandlungs-Routine wie oben unter Behandlung von Strukturabweichungen beschrieben, abweichend von den Vorschlagswerten der beiden oben beschriebenen Parameter.

Erst wenn Sie einen der beiden Parameter setzen, wird auch der andere Parameter mit seinem Vorschlagswert ausgewertet.

SAP empfiehlt, für ein wohl definiertes Laufzeitverhalten bei variablen Eingangsstrukturen immer diese beiden Parameter zu setzen.

 

Das aus den beschriebenen Angaben konstruierte Dokument hat folgendes Aussehen:

<documentName>

<structureTitle>

<field-name1>field-value</field-name1>

<field-name2>field-value</field-name2>

<field-name3>field-value</field-name3>

</structureTitle>

<structureTitle>

<field-name1>field-value</field-name1>

<field-name2>field-value</field-name2>

<field-name3>field-value</field-name3>

</structureTitle>

</documentName>

Ein solches Dokument kann dann durch die Integration Engine weiterverarbeitet werden.

       8.      Die Angaben für die Konvertierung in ein XML-Dokument im Modus FILE2XMBWITHSTRUCTURECONVERSION

In diesem Modus können Sie Textdateien mit komplexeren Dateistrukturen in ein XML-Ausgangsformat konvertieren. Die Dateien enthalten unterschiedliche Zeilenformate in logischen Strukturen.

Es wird eine Datei erwartet mit einer oder mehreren logischen Strukturen (Recordsets). Eine beliebige Anzahl dieser Recordsets (einer, mehrere oder alle, die in der Datei gefunden werden) können als unabhängige Message an die Integration Engine verschickt werden.

Ein Recordset kann mehrere Typen von Unterstrukturen enthalten, die durch logische Namen identifiziert werden. Die Anzahl solcher Unterstrukturen in einem Recordset kann fest oder variabel sein. Das Format einer solchen Unterstruktur wird als fest vorausgesetzt und entspricht der Beschreibung des Zeilenformats in Schritt 7. Eine Unterstruktur muss immer in genau einer Zeile des Textdokuments dargestellt sein.

○       Angaben für Recordsets:

■       xml.recordsetStructure=<NameA,nA,nameB,nB,…>

Diese Zeichenkette gibt die Reihenfolge und die jeweilige Anzahl der (durch logische Namen identifizierten) Unterstrukturen an.

Hierbei ist nA=1,2,3,… oder * (für eine variable, beliebige Anzahl einschließlich 0). Gleiches gilt für nB etc.

■       xml.recordsetName=<tagName>

Der hier angegeben Wert wird als Name der Struktur im XML-Schema übernommen. Die Voreinstellung ist Recordset.

■       xml.recordsetNamespace=uri

Wird, falls angegeben, an den Namen des Recordset angehängt.

■       xml.recordsetsPerMessage=<noOfRecordsets>

1,…, * für ein komplettes Dokument in einer Message.

Gibt die Anzahl der Recordsets an, die zu einer Message gruppiert werden sollen. Ist die Anzahl der Recordsets in dem Dokument größer als die angegebene, erstellt der Adapter mehrere Messages aus einem Dokument. Die letzte dieser Message enthält dann womöglich weniger Recordsets als angegeben.

Wird Exactly Once als Quality-of-Service angegeben, wird sichergestellt, dass jede dieser Messages (also jeder Teil eines Dokuments, aus dem eine Message erstellt wird) genau einmal an die Integration Engine geschickt wird. Dies ist auch der Fall, wenn die Anwendung während der Erstellung der Messages unterbrochen und später wieder neu gestartet wird.

Wird die Datei mit dem Dokument vor dem Neustart der Anwendung geändert, wird sie wie eine neue Datei behandelt. Ein eventuell ausstehendes Exactly Once kann dann für diese Datei nicht mehr durchgeführt werden.

■       xml.documentName=<name>

Diese Angabe ist zwingend, wenn Sie recordsetsPerMessage auf einen Wert größer 1 oder auf * gesetzt haben.

Wird ein Dokumentname angegeben, wird er als Haupt-XML-Tag in die Message eingefügt. Besteht die erzeugte Message aus mehr als einem Recordset, ist diese Angabe zwingend, da ein XML-Dokument genau ein Haupt-Tag enthalten muss.

■       xml.documentNamespace=<namespace>

Der Namensraum wird, wenn angegeben, an den Namen des Dokuments angehängt.

■       xml.documentSkipFirstRows=<noOfRows>

Gibt an, wie viel Zeilen am Anfang des Dokuments übersprungen werden sollen. Die Voreinstellung ist 0.

■       xml.keyFieldName=<fieldname>

Haben Sie bei xml.recordsetStructure eine variable Anzahl von Unterstrukturen angegeben (also für mindestens eine Unterstruktur die Anzahl *), müssen die Unterstrukturen über ihren Inhalt vom Parser identifiziert werden. Dies bedeutet, dass ein Schlüsselfeld gesetzt werden muss, mit verschiedenen Konstanten für die verschiedenen Unterstrukturen.

Die Angabe eines Schlüsselfelds ist in diesem Fall zwingend und der Feldname muss in allen Unterstrukturen erscheinen.

Ist die Anzahl der Unterstrukturen in einer Struktur fest, wird die Angabe ignoriert.

■       xml.keyFieldType=CaseSensitiveString|CaseInsensitveString|Integer|Float

Haben Sie ein Schlüsselfeld angegeben, müssen Sie hier den Typ des Schlüsselfelds angeben, auf dessen Basis der Vergleich mit den vorgegebenen Werten stattfindet (siehe xml.NameA.keyFieldValue= unten).

■       xml.recordsetStructureOrder=asc|var

Anfang bzw. Ende von Recordsets, die eine variable Anzahl und Anordnung von Strukturen enthalten, wird wie folgt bestimmt:

Beim Wert asc (aufsteigend) wird die Reihenfolge der Strukturen des Recordsets als eindeutig angenommen. Sobald eine frühere Struktur auftritt, bedeutet dies den Beginn eines neuen Recordsets.

Beim Wert var (variabel) wird die Reihenfolge nicht als fest angenommen. Ein neues Recordset beginnt erst dann, wenn erstmals wieder eine Struktur auftritt, die mit fester Anzahl definiert ist. Sind alle Strukturen als variabel (*) definiert, wird das gesamte Dokument als ein einziges Recordset interpretiert.

Der Vorschlagswert ist asc.

○       Angaben zu Unterstrukturen:

Verwenden Sie hier die gleichen Angaben wie in Schritt 7 und fügen Sie den Namen der Unterstruktur dem Namen der jeweiligen Eigenschaft hinzu, getrennt durch einen Punkt nach dem XML-Präfix.

xml.NameA.fieldNames statt xml.fieldNames zur Angabe der Feldnamen von Unterstruktur NameA.

Änderungen gegenüber den Eigenschaften in Schritt 7:

■       xml.NameA.structureTitle=<anyName>

Die Voreinstellung ist hier nicht row, sondern der Strukturname aus xml.recordsetStructure. Die Voreinstellung dort ist NameA.

■       xml.NameA.processFieldNames=

Hier sollten Sie keine Angabe machen, da diese Eigenschaft in diesem Modus fest auf fromConfiguration steht. Dies bedeutet, dass sich die Definition der Unterstruktur in der Konfigurationsdatei befinden muss, und keine Strukturinformation in der Datei selbst übergeben werden kann.

■       xml.NameA.fieldNames=<listOfFieldnames>

Aus den genannten Gründen ist diese Angabe jetzt zwingend.

■       xml.NameA.keyFieldValue=<valueInSubstructureName>

Auch diese Angabe ist zwingend, wenn xml.keyFieldName= in der Definition des Recordset gesetzt ist.

■       xml.NameA.keyFieldInStructure=add|ignore

Hier können Sie angeben, ob das Schlüsselfeld der Unterstruktur zum XML-Dokument hinzugefügt werden soll (add) oder ignoriert wird (ignore). Voreinstellung ist add.

■       xml.NameA.endSeparator=

Auch wenn hier eine Angabe gemacht wird, muss danach ein Zeilenumbruch erfolgen, da Unterstrukturen immer als eine Zeile des Dokuments erwartet werden.

Das aus den beschriebenen Angaben konstruierte Dokument hat folgendes Aussehen:

<documentName>...

   <recordset>

<NameA>

<field-nameA1>field-value</field-nameA1>

<field-nameA2>field-value</field-nameA2>

<field-nameA3>field-value</field-nameA3>

</NameA>

<NameB>

<field-nameB1>column-value</field-nameB1>

<field-nameB2>column-value</field-nameB2>

<field-nameB3>column-value</field-nameB3>

</NameB>

   </recordset>

   ...

   <recordset>

...

   </recordset>

</documentName>...

Das Tag <documentName> wird ergänzt, wenn Sie für xml.documentName= eine Angabe gemacht haben. Eine solche Angabe ist zwingend, wenn die Message mehr als einen Recordset enthält. Die Anzahl an Recordsets wiederum ist abhängig von der Angabe bei xml.recordsetsPerMessage.

Ein solches Dokument kann dann durch die Integration Engine weiterverarbeitet werden.

       9.      Transport weiterer Dokumente innerhalb einer Nachricht zur Integration Engine

Es besteht die Möglichkeit, zusätzliche Dateiinhalte innerhalb einer Nachricht zur Integration Engine zu transportieren. Hierbei gelten folgende Regeln:

○       Die Dateien müssen alle im gleichen Verzeichnis stehen, das mit der Angabe unter file.sourceDir festgelegt wird.

○       Die Zusammengehörigkeit der Dateien, die transportiert werden sollen, wird über den Dateinamen festgelegt, der bis auf einen definierten Teil (zum Beispiel das Suffix) identisch sein muss.

○       Zusätzliche Dateiinhalte können nur unverändert, das heißt ohne die unter Punkt 5 und Punkt 6 beschriebenen Konvertierungsmöglichkeiten transportiert werden.

○       Nachrichten dieses Typs mit mehreren Payloads benötigen einen entsprechenden Empfänger, der solche Nachrichten verarbeiten kann.

Das Anfügen zusätzlicher Dateiinhalte geschieht mit den folgenden Angaben:

○       XI.AdditionalPayloads=<NameA, NameB, …>

Hier wird für jede gewünschte, zusätzliche Datei ein logischer Name definiert, der in den nachfolgenden Parametern verwendet wird.

○       file.NameA.namePart=<”Main-NamePart”=”Additional-NamePart”>

Hier wird angegeben, welcher Teil des ursprünglich gefundenen Dateinamens ersetzt werden soll, um den Namen der zusätzlichen Datei zu erzeugen.

Folgendes Beispiel erklärt die Verknüpfung von drei Dateien vom Typ text, pdf und doc zu einer Nachricht:

file.sourceFileName=x*.txt

Aufgrund dieser Angabe werden die Dateien x1.txt und x2.txt im angegebenen Verzeichnis gefunden.

XI.AdditionalPayloads=addaPDF, addaDOC

file.addaPDF.namePart=”.txt”=”.pdf”

file.addaDOC.namePart=”.txt”=”.doc”

Aufgrund dieser Angaben werden zur Datei x1.txt noch die Dateien x1.pdf und x1.doc im gleichen Verzeichnis gesucht. Die Inhalte dieser drei Dateien werden zu einer Nachricht an den Integration Engine zusammengefasst. Analog werden zur Datei x2.txt noch die Dateien x2.pdf und x2.docgesucht und verarbeitet.

○       file.NameA.optional=YES|NO

Hier wird angegeben, ob die zusätzliche Datei notwendig oder optional ist. Falls die Datei nicht gefunden wird, wird bei NO mit einer Fehlermeldung abgebrochen. Bei YES wird die Angabe ignoriert und die Nachricht ohne den zusätzlichen Dateiinhalt an den Integration Engine geschickt. Voreinstellung ist YES.

○       file.NameA.type=BIN|TXT

Gibt den Datentyp des Dokuments an.

Der Vorschlagswert ist BIN.

   10.      Das Verhalten des Adapters, wenn er angehalten wird.

file.stopMode=0|1|2

○       0 Die Verarbeitung wird sofort abgebrochen, wenn der Adapter angehalten wird.

○       1 Wird eine Datei verarbeitet, wird die Verarbeitung beendet und der Adapter wird angehalten.

○       2 Alle Dateien, die sich in der aktuellen Dateiliste befinden, werden verarbeitet. Dann wird der Adapter angehalten.

Der Vorschlagswert ist 0.