RosettaNet HTTPS Connector

Verwendung

Der RosettaNet-Standard dient als Basis für den weltweiten Datenaustausch zwischen Firmen mit Schwerpunkt im Bereich Supply-Chain-Management.

Für mehr Informationen über das RosettaNet Protokoll, siehe:

Funktionsumfang

Der RosettaNet Connector unterstützt die folgenden Funktionalitäten:

  • RosettaNet Implementation Framework (RNIF) V2.0 RNIF beschreibt den Aufbau der XML-Nachrichten, das Vorgehen beim Ver- und Entpacken der Nachrichten, die unterstützen Protokolle, Sicherheitsanforderungen und die Fehlerbehandlung.

  • Asynchrones Empfangen von Nachrichten über HTTP(S)

  • Entpacken empfangener Nachrichten, Syntax-Check der Nachrichten und Konvertierung in ein eigenes XML-Format

  • Archivierung von Nachrichten

  • Erzeugen einer gültigen RosettaNet-Nachricht aus einer im Workflow aufbereiteten PIP-Nachricht
    RosettaNet Partner Interface Processes (PIP) definieren Geschäftsprozesse zwischen Geschäftspartnern.

  • Asynchroner Versand von Nachrichten und Empfangsbestätigungen über HTTP(S).

  • Erzeugung und Kontrolle der verwendeten Nachrichten-IDs entsprechend dem RNIF.

Struktur und Austausch von RosettaNet-Nachrichten

Struktur

Die folgende Abbildung zeigt die Struktur einer RosettaNet Business Message:

  • Header

    XML-Metadaten mit Informationen über die Nachricht. Jede Nachricht muss alle Headerteile genau einmal enthalten. Der Header hat folgende Struktur:

    • Preamble Header

      Version des RosettaNet Implementation Framework (RNIF), zu dem die Nachricht konform ist. Die aktuelle Version ist RNIF 2.0.

    • Delivery Header

      Identifiziert den Absender und den Empfänger. Enthält einen Datums- und Zeitstempel. Alle an der Weiterleitung einer Business-Nachricht-Beteiligten, also der Absender, der Empfänger und mögliche Zwischenstationen, benutzen diese Informationen für das Routing.

    • Service Header

      Informationen über den Partner Interface Process (PIP) als ID, die PIP-Instanz als ID und die Prozessaktivität.

  • Payload

    Enthält die eigentlichen Nachrichten und ist XML-kodiert.

    • Service Content

      Gibt an, ob die Nachricht eine action message oder eine signal message ist. Die Prozessaktivität einer action message wird im PIP angegeben. Die signal messages sind Empfangsbestätigungen bzw. Fehlermeldungen.

    • Attachments

      Wenn die Nachricht eine action message ist, kann diese einen oder mehrere Anhänge enthalten.

Alle Teile einer Business-Message sind im MIME/S-MIME-Nachrichtenformat komprimiert.

Bestätigungen

Der Empfang von RosettaNet-Nachrichten wird durch Bestätigungen bzw. Fehlermeldungen signalisiert. Empfangsbestätigungen können synchron oder asynchron versendet werden.

Transportprotokolle

Für den Nachrichtentransport können die Protokolle HTTP und HTTPS benutzt werden.

Asynchroner Nachrichtenaustausch

Grundsätzlich unterstützt das PIP-Modell den asynchronen Nachrichtenaustausch, der wie folgt abläuft:

  1. Geschäftspartner A schickt eine RosettaNet-Nachricht an Geschäftspartner B. Diese Nachricht enthält eine sog. PIP-ID, über welche die Nachricht eindeutig identifiziert werden kann.

  2. B speichert eine Kopie der Nachricht, um den Erhalt nachweisen zu können.

  3. B sendet eine Bestätigung an A.

  4. Nun gibt es zwei Möglichkeiten:

    • A erhält die Bestätigung.

    • A erhält keine Bestätigung innerhalb des vereinbarten Zeitraums. Dann sendet A die Nachricht noch einmal:

      B empfängt die Nachricht. B überprüft, ob die Nachricht vorher bereits empfangen wurde, weil B sicherstellen muss, dass Nachrichten exakt einmal verarbeitet werden. Dazu wird die PIP-ID der eingegangenen Nachricht mit allen PIP-IDs vorher eingegangener Nachrichten verglichen.

Behandlung von Anhängen (Attachments)

Um bei einem Output Connector RosettaNet-Attachments zu verwenden, müssen diese Attachments durch drei durchnummerierte Workflowvariablen beschrieben sein (X), beginnend bei 0:

  • RNAttachment.X, Typ: base64Binary

    enthält die Daten des Attachments

  • RNAttachmentContent-ID.X, Typ: xs:string

    enthält die eindeutige Identifikation (unique identifier) des Attachments, die Sie z.B. mittels com.inubit.ibis.xsltext.Misc generieren lassen können.

  • RNAttachmentContent-Type.X, Typ: xs:string

    MIME-Content-Type des Attachments, z.B. text/xml.

Bei einem Input Connector können Sie Anhänge in das Dateisystem schreiben.

Beispiel-Workflow: RosettaNet-Nachrichten erzeugen

module guide 1166 0

Der abgebildete Workflow erzeugt eine RosettaNet-Nachricht und übergibt diese mithilfe des Workflow Connectors SendRosettaNetMessage zum Versenden an den nächsten Workflow.

Siehe Beispiel-Workflow: RosettaNet-Nachrichten versenden.

Die Daten für die RosettaNet-Nachricht werden aus dem unternehmenseigenen ERP-System geladen und mithilfe von XSLT Convertern in die RosettaNet-Struktur überführt:

  1. Der XSLT Converter Create PIP-specific Payload erstellt die PIP-spezifische Nachricht (Payload).

  2. Der XSLT Converter Create Headers erzeugt die Header

Der Zeitstempel wird durch die Java Methode jHelper:getDateTime("yyyyMMdd’T’HHmmss.SSS’Z'") gesetzt. Dem Element GlobalProcessIndicatorCode wird die PIP-ID zugewiesen, die für diese Nachricht vorgeschrieben ist (z.B.: 4A5). In der letzten Zeile wird der Payload durch einfaches Kopieren hinzugefügt.

Beispiel-Workflow: RosettaNet-Nachrichten versenden

module guide 1167 0

Der abgebildete Workflow versendet die RosettaNet-Nachricht und empfängt die Bestätigung über den Eingang der Nachricht. Wenn die Business Message das letzte Mal gesendet wurde und immer noch keine Bestätigung für die Nachricht eingegangen ist, dann wird der Fehlerausgang angesteuert.

Nachricht versenden

Der Output Connector RN-Output-CUT erhält eine RosettaNet Business Message als Eingangsnachricht und verarbeitet diese wie folgt:

  1. Der Präambel Header wird hinzugefügt. Er enthält die RNIF-Version.

  2. Der Delivery Header und der Service Header wurden im XSLT Converter erstellt, der RosettaNet Output Connector fügt diesen Headern die noch fehlenden Informationen hinzu. Die fehlenden Informationen werden den Konfigurationsdaten übernommen, die beim Anlegen des Connectors angegeben wurden. Zusätzlich wird der Instanz-Identifier erzeugt und hinzugefügt.

  3. Die für jede Nachricht generierte ID wird in der Indexdatei ListofGeneratedIds.xml im Arbeitsverzeichnis gespeichert.

Danach sendet der Output Connector die Nachricht an den Empfänger und hält sie so lange im Workflow, bis die Bestätigung eingegangen ist.

Fehler-E-Mail versenden

Der Fehlerausgang wird angesteuert, wenn die Business Message das letzte Mal gesendet wurde und immer noch keine Bestätigung für die Nachricht eingegangen ist. Dann wird über das Mail Connector Modul eine Nachricht gesendet, welche darüber informiert, dass das Versenden der Business Message fehlgeschlagen ist.

Demultiplexer DistributeRNOutput

Zusätzlich wird die Nachricht dem Demultiplexer übergeben, der die Nachricht entweder an ein Dummy-Modul oder an den Multiplexer WaitUntilAcknowlegde weiterleitet:

  • Wenn der XPath /RosettaNetConnector/AcknowledgeReceived nicht leer ist, dann erhält das Dummy-Modul die Eingangsnachricht. Das bedeutet, dass die Nachrichtenbestätigung am Output Connector angekommen und keine weitere Aktion notwendig ist.

  • Wenn der XPath /RosettaNetConnector/Retry leer ist, dann erhält der Multiplexer WaitUntilAcknowledge die Eingangsnachricht. Dies bedeutet, dass die Bestätigung zu dieser Nachricht noch nicht empfangen wurde.

Splitter Modul

Das Splitter-Modul empfängt eine Bestätigung, die vom Input Connector Workflow weitergeleitet wurde, und gibt die Bestätigung an einen Mail-Connector und an den nachfolgenden Demultiplexer weiter.

Multiplexer WaitUntilAcknowledge

Der Multiplexer erhält Nachrichten aus dem Demultiplexer DistributeRNOutput sowie Bestätigungsnachrichten aus dem Splitter und wertet beide aus.

Dazu werden die Instanz-ID und die PIP-Nummer der beiden Nachrichteneingänge verglichen. Wenn diese identisch sind, wird eine Nachricht an den Output Connector weitergeleitet, mit der eine vorher verschickte Business Message bestätigt wird. Damit muss diese Business Message nicht mehr im Output Connector vorgehalten werden.

Der Workflow Send RosettaNet Message ist damit beendet.

Beispiel-Workflow: Nachrichten empfangen und Bestätigung senden

module guide 1168 1

Der abgebildete Workflow empfängt RosettaNet-Nachrichten und leitet diese abhängig von ihrem Inhalt weiter.

Nachrichteneingang

Der RosettaNet Input Connector am Anfang des Workflows ist als Listener konfiguriert und wartet auf Nachrichten. Wenn eine RosettaNet Business Message von einem Geschäftspartner gesendet wird, dann führt der Connector folgende Schritte aus:

  • Speichert die Nachricht im angegebenen Arbeitsverzeichnis,

  • prüft anhand der /<PIP>/*.msg-Dateien im Arbeitsverzeichnis des Moduls, ob die eingegangene Nachricht schon einmal gesendet wurde (wenn ja, dann erzeugt der Connector eine entsprechende XML-Nachricht),

  • sendet sofort (synchron) eine Empfangsbestätigung,

  • leitet die Nachricht an das Demultiplexer Modul weiter.

    Empfangsbestätigungen können auch asynchron versendet werden, z.B. nachdem das wartende Backend-System die RosettaNet-Nachricht erhalten hat. Dazu aktivieren Sie im Input Connector (siehe Dialog Asynchrone Empfangsbestätigung im RosettaNet Connector) den Versand asynchroner Bestätigungen und fügen einen Output Connector in den Workflow (siehe Dialog Empfangsbestätigungen) ein. Der Output Connector versendet die Bestätigung und sollte daher an einer Position im Workflow eingefügt werden, an der das wartende Backend-System den Empfang der RosettaNet-Nachricht bestätigt hat.

Bedingte Weitergabe

Der nachfolgende Demultiplexer prüft den Inhalt der Nachricht und leitet diese an eines der nachfolgenden Module weiter:

  • Process_PIP4A3

    Wenn im Service Header im Element RosettaNetXML/ServiceHeader/ProcessControl/pipCode/GlobalProcessIndicatorCode der Code 4A3 vorkommt, dann wird die Nachricht zur weiteren Verarbeitung an den Workflow Connector Process_PIP_4A3 weitergeleitet.

  • Deliver_Acknowledge

    Wenn in der Nachricht der XPath /RosettaNetConnector/AcknowledgeReceived existiert, dann handelt es sich bei der Nachricht um eine Bestätigungsnachricht, die zur weiteren Verarbeitung an den Workflow Connector Deliver_Acknowledge weitergeleitet wird.

Der verbundene Workflow enthält den RosettaNet Output Connector, der die Nachricht gesendet hat. Dieser Output Connector wertet die Bestätigungsnachricht aus, um festzustellen, zu welcher Nachricht die Bestätigung gehört. Mit dieser Bestätigung ist klar, dass die Nachricht nicht erneut gesendet werden muss.

  • Dummy

    Wenn die Nachricht die Zeichenkette /RosettaNetConnector/MessageAlreadyProcessed enthält, dann wird die Nachricht an das Dummy-Modul übergeben und nicht weiter verarbeitet.
    An Stelle des Dummys könnte auch z.B. ein Mail Connector stehen, der einen Administrator von dem erneuten Eintreffen einer bereits gesendeten Nachricht informiert. Wichtig ist, dass eine bereits gesendete Nachricht kein zweites Mal verarbeitet wird.

Dialogbeschreibungen

Beachten Sie die Rechtschreibung, wenn Sie Werte aus der Spezifikation übernehmen, weil in RosettaNet-Nachrichten bei allen Bezeichnungen und Werten zwischen Groß- und Kleinschreibung unterschieden wird!

Dialog RosettaNet Connector Eigenschaften

RosettaNet Connector Eigenschaften, Register Allgemein

In diesem Register werden alle Daten angegeben, die für Business Messages zwischen zwei Geschäftspartnern immer gleich sind.

Arbeitsverzeichnis

  • Pfad

    Der Auswählen-Button öffnet einen Dateiexplorer zum Anzeigen der empfangenen und erzeugten Nachrichten. In diesem Verzeichnis wird auch die Datei gespeichert, in der alle erzeugten Instance Identifier enthalten sind. Ein Instance Identifier ist eine Zeichenkette, mit der jede Nachricht im Kontext zweier Geschäftspartner eindeutig gekennzeichnet wird.

    Für den RosettaNet Input und Output Connector müssen Sie dasselbe Arbeitsverzeichnis angeben.

DTD Konfiguration

Mit der Auswahl der DTDs wird der syntaktische Aufbau der Nachrichten-Header bestimmt.

Die benötigten DTDs können von den Seiten des RosettaNet Konsortiums heruntergeladen werden (ZIP-Datei des aktuellen RNIF V2.0).

  • Präambel DTD: Preamble_MS_V02_00.dtd

  • Delivery Header DTD: DeliveryHeader_MS_V02_00.dtd

  • Service Header DTD: ServiceHeader_MS_V02_00.dtd

  • Receipt Ack. DTD: AcknowledgmentOfReceipt_MS_V02_00.dtd

  • Exception DTD: Exception_MS_V02_00.dtd

  • NoF DTD: 0A1_MS_V02_00_FailureNotification.dtd

Um eine bereits geladene Datei zu aktualisieren, müssen Sie eine Datei mit einem anderen Namen laden. Wenn Sie eine Datei mit demselben Namen laden, dann wird die vorhandene Datei nicht ersetzt.

Identifikation

  • Ihre DUNS: Geben Sie Ihre eigene DUNS Nummer an. Eine DUNS-Nummer dient der eindeutigen Identifikation von Geschäftspartnern.

    Sie erhalten eine DUNS-Nummer bei der Dun & Bradstreet Corporation unter https://www.dnb.com/de-de/produkte-services/dun-bradstreet/dnb-duns-nummer.

  • Partner-DUNS: Geben Sie die DUNS Nummer Ihres Geschäftspartners an.

  • Location ID: Die Location-ID ist eine frei wählbare alphanumerische Zeichenkette in einem beliebigen Format. Sie kann z.B. benutzt werden, um eine spezielle Niederlassung des Geschäftspartners zu bezeichnen. Auf die Location-ID einigen sich die Geschäftspartner untereinander.

Nachrichtenarchiv aufräumen

  • Nachrichten löschen (nach Tagen)

    Die Angabe legt fest, nach wie viel Tagen die IDs der bereits empfangenen RosettaNet-Nachrichten aus dem Dateisystem gelöscht werden.

    Die IDs werden in einer XML-Datei gespeichert. Bei einer sehr großen Anzahl von Nachrichten kann diese Datei so groß werden, dass die Performance beeinträchtigt wird. Deswegen werden die IDs regelmäßig gelöscht.

Verzögerung der Sendewiederholung

  • Sendewiederholungsverzögerung

    Wartezeit in Sekunden, die der Connector aktiv wartet, bis er eine Nachricht erneut sendet, Standard: 30 Sekunden.

Das Produkt aus Sendewiederholungsverzögerung und Anzahl der Sendewiederholungen (siehe Sendewiederholungen im Abschnitt Register Neuer PIP) sollte in jedem Fall kleiner gewählt werden als der Timeout des Connectors (Register System Connector Eigenschaften).

Behandlung von Anhängen

  • Anhänge ins Dateisystem speichern

    (nur beim Input Connector)

    Wenn markiert, dann werden Attachments nach dem Empfang automatisch in Variablen abgelegt. Für jedes Attachment werden drei Variablen erstellt; wenn mehrere Attachments vorhanden sind, dann werden die Variablen durchnummeriert (X), beginnend bei 0:

  • RNAttachment.X

    Inhalt des Attachments, base64-kodiert und komprimiert

  • RNAttachmentContent-Type.X

    MIME-Type des Attachments, z.B. application/xml

  • RNAttachmentContent-ID.X

    ID des Attachments; kann genutzt werden, um das Attachment in einem RosettaNet-Dokument zu referenzieren.

Fehlerbehandlung

(nur beim Input Connector)

  • Individuell

    Wählen Sie diese Option, wenn Sie die Fehlerbehandlung im Workflow selbst durchführen wollen. Bei aktivierter Option wirft der Workflow einen Fehler und Sie können diesen behandeln.

  • Signal (Exception)

    Bei aktivierter Option sendet der Konnektor eine RosettaNet-Signalnachricht mit dem entsprechenden Fehler und der Workflow läuft erfolgreich durch, ohne einen Fehler zu werfen.

Register NoF

(nur Output Connector)

Zum Erstellen einer Notification of Failure (NoF). Ein NoF ist im Prinzip ein PIP0A1 und wird im Fehlerfall versendet, z.B. bei Timeouts innerhalb des Datenaustauschprozesses oder falls Nachrichten nicht verarbeitet werden können.

Die Feldnamen sprechen für sich.

Register Neuer PIP

Alle Partner Interface Processes (PIPs) sind von RosettaNet spezifiziert, um zu garantieren, dass Sender und Empfänger genormte Nachrichten austauschen.

Ein PIP besteht aus einem von acht möglichen Clustern, jeder Cluster besteht aus einem oder mehreren Segmenten und jedes Segment enthält ein oder mehrere PIP-Beschreibungen. Für jeden PIP gibt es eine Spezifikation. PIPs können für einen Request oder eine Response ausgelegt sein oder auch beide Aktionen unterstützten. Die Struktur der Aktionen ist in einer DTD bzw. einem XML Schema. beschrieben

PIP-Definitionen stehen als Dokumentationspaket (welches u.a. die DTDs bzw. Schemas enthält) auf den Seiten von RosettaNet zur Verfügung und können von dort heruntergeladen werden.

PIP Einstellungen

  • PIP Bezeichnung

    Ein PIP-Bezeichner wie z.B. 3A2 setzt sich folgendermaßen zusammen:

  • Zahl (0..7), die das Cluster spezifiziert (3=Order Management)

  • Großbuchstabe (A..D), der das Segment angibt (A=Quote and Order Entry)

  • Maximal zweistellige Zahl (aus dem Intervall 1..20), das den PIP angibt (2=Request Price and Availability)

  • PIP Version

    Wird verwendet zur Überprüfung, ob die Nachricht gültig ist. Es wird ein reiner Zeichenkettenvergleich durchgeführt.

    Es gibt Geschäftspartner, die sich darauf einigen, bei langen Release- oder Versionsangaben die letzten vier Stellen nicht anzugeben. Verwendet einer der Partner die Release- oder Versionsnummer ohne die letzten vier Stellen und der andere mit den letzten vier Stellen, würde die Nachricht als ungültig erkannt.

    Die zugrundeliegende PIP Version steht in der RosettaNet Spezifikation.

  • DTD/Schema

    Zum Laden der DTD bzw. des XML Schemas, welche die Aktion des PIP beschreibt.

    Geben Sie zusätzlich an, ob Sie eine DTD oder ein XML Schema laden.

  • Input Connector

    Wählen Sie die Request-DTD bzw. das entsprechende Schema aus, damit eingehende Anfragen auf Korrektheit überprüft werden können.

  • Output Connector

    Mit der DTD/dem Schema wird die Ausgangsnachricht auf Korrektheit überprüft.

    Um eine bereits geladene Datei zu aktualisieren, müssen Sie eine Datei mit einem anderen Namen laden. Wenn Sie eine Datei mit demselben Namen laden, dann wird die vorhandene Datei nicht ersetzt!

  • Nachweisbarkeit der Empfangsbestätigung

    (Nur Input Connector)

    Wenn markiert, dann wird eine Hash-Summe über die Originalnachricht erzeugt und mit der Empfangsbestätigung zurückgesendet. Damit ist nachweisbar, dass die Originalnachricht beim Empfänger angekommen ist.

  • Sendewiederholungen

    • Input Connector

      Die Anzahl der Sendewiederholungen ist für jeden PIP in der Tabelle 3-3 einer PIP Spezifikation unter Retry Count angegeben. Für den PIP 3A2 ist zum Beispiel der Wert 3 angegeben.

    • Output Connector

      Die Anzahl der Sendewiederholungen ist für jeden PIP in der Tabelle 3-3 einer PIP Spezifikation unter Retry Count angegeben. Für den PIP 3A2 ist der Wert z.B. 3.

  • Rollenname Absender/Rollenname Empfänger

    (Nur Output Connector)

    Die Rollennamen sind in der Spezifikation des jeweiligen PIPs festgelegt. Üblicherweise sind die Rollen in der Tabelle 3-1 der PIP Spezifikation zu finden.

    Für den PIP 3A2 z.B. ist der Rollenname des Absenders Customer und der des Empfängers Product Supplier.

  • Servicename Absender/Servicename Empfänger

    (Nur Output Connector)

    Die Bezeichnungen sind von RosettaNet spezifiziert und für jeden PIP festgelegt. Für den PIP 3A1 sind die Werte z.B. in der Tabelle 4-1 zu finden.

  • Business Aktivität

    Die Bezeichnungen für Business Activities sind von RosettaNet spezifiziert und für jeden PIP festgelegt. Üblicherweise ist die Bezeichnung für eine Business Activity in der Tabelle 3-1 der PIP Spezifikation zu finden. Für den PIP 3A2 ist dies z.B. Request Price and Availability.

  • Business Aktion

    Die Bezeichnungen sind von RosettaNet spezifiziert und für jeden PIP festgelegt. Üblicherweise ist die Bezeichnung für eine Business Action in der Tabelle 4-2 der PIP Spezifikation zu finden. Für den PIP 3A2 ist dies z.B. je nach Aktion entweder Price and Availability Request Action oder Price and Availability Response Action.

  • Verwendungszweck

    (Nur Output Connector)

    Fügt dem Service Header der Nachricht einen Hinweis über die Art der Nachricht hinzu (<GlobalUsageCode>Test</GlobalUsageCode> oder <GlobalUsageCode>Production</GlobalUsageCode>). RosettaNet spezifiziert nicht, wie ein Geschäftspartner mit diesem Element verfahren muss.

Dialog Asynchrone Empfangsbestätigung im RosettaNet Connector

(nur Input Connector)

Asynchroner Versand der Empfangsbestätigung

Dialog S/MIME-Konfiguration im RosettaNet Connector - Eingangsnachricht

(Input Connector)

In diesem Dialog geben Sie die Informationen an, die nötig sind, um verschlüsselte und/oder signierte Eingangsnachrichten zu entschlüsseln bzw. zu prüfen.

Sie benötigen eine Keystore-Datei, die Ihren privaten Schlüssel und den öffentlichen Schlüssel Ihres Geschäftspartners enthält.

Keystore-Konfiguration

Klicken Sie auf den Button, um Ihren Keystore zu laden.

S/MIME-Entschlüsselung

Zum Aktivieren/Deaktivieren der Entschlüsselung.

  • Alias

    Zur Auswahl des Alias, unter dem der benötigte private Schlüssel im Keystore gespeichert ist.

  • Passwort

    Passwort für den gewählten Schlüssel.

S/MIME-Signaturprüfung

Zum Aktivieren/Deaktivieren der Signaturprüfung.

  • Alias

    Zur Auswahl des Alias, unter dem der benötigte öffentliche Schlüssel im Keystore gespeichert ist.

Dialog Verbindungsdaten für Geschäftsnachrichten

(Input Connector)

Grundkonfiguration

  • Server-URL

    URL und Port des Servlets, welches auf RosettaNet-Nachrichten wartet.

Authentifizierung

  • Authentifizierung erforderlich

    Markieren Sie diese Option, wenn der Server eine Authentifizierung fordert. Geben Sie dann den Account ein, den der Connector für die Authentifizierung verwenden soll.

  • Benutzername

    Benutzername für die Authentifizierung.

  • Passwort

    Passwort für die Authentifizierung.

HTTP Header-Konfiguration

Über den Header können Informationen wie z.B. Dateigröße, HTTP-Server- und User-Agent-Kennung oder MIME-Typ zwischen Client und HTTP-Server übertragen werden.

Der Button Header Liste öffnet einen Dialog, in dem Sie Name-Wert-Paare als Header definieren können.

Informationen über zulässige Header finden Sie in der HTTP-Spezifikation, siehe https://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf.

Dialog Empfangsbestätigungen

(Output Connector)

Ein Output Connector zum Versand asynchroner Empfangsbestätigungen kann an einer beliebigen Stelle in dem Workflow platziert werden, der die RosettaNet Nachrichten empfängt.

Die nötigen Daten holt sich der Output Connector aus einer Variablen, die von dem RosettaNet-Input Listener am Anfang des Workflows gefüllt wurde.

Siehe Beispiel-Workflow: Nachrichten empfangen und Bestätigung senden.

Versand der Empfangsbestätigung

  • Versand der Empfangsbestätigung

    Wenn markiert, dann werden asynchrone Empfangsbestätigungen versendet.

Dialog S/MIME-Konfiguration im RosettaNet Connector - Ausgangsnachricht

In diesem Dialog geben Sie die Informationen an, die nötig sind, um Ausgangsnachrichten zu verschlüsseln bzw. zu signieren.

Sie benötigen eine Keystore-Datei, die Ihren privaten Schlüssel enthält.

Keystore-Konfiguration

Klicken Sie auf den Button, um Ihren Keystore zu laden.

S/MIME-Verschlüsselung

Zum Aktivieren/Deaktivieren der Verschlüsselung.

  • Alias

    Zur Auswahl des Alias, unter dem der private Schlüssel, der zum Verschlüsseln verwendet wird, im Keystore gespeichert ist.

  • Verschlüsselungsverfahren

    Zur Auswahl des Verschlüsselungsverfahrens.

  • Payload Container verschlüsseln/Payload verschlüsseln

    Siehe RNIF Core Specification (https://xml.coverpages.org/RNIF-Spec020000.pdf), Seite 43 ff.

S/MIME Signierung

Zum Aktivieren/Deaktivieren der Signierung.

  • Alias

    Zur Auswahl des Alias, unter dem der private Schlüssel, der zum Signieren verwendet wird, im Keystore gespeichert ist.

  • Passwort

    Passwort für den privaten Schlüssel.

  • MIC Verfahren

    Zur Auswahl des Message Integrity Check-Verfahrens. Mit diesem Verfahren wird eine Prüfsumme über die Ausgangsnachricht erstellt. Anhand dieser Prüfsumme kann der Empfänger prüfen, ob die Ausgangsnachricht unverändert eingetroffen ist.

Dialog Verbindungsdaten für Empfangsbestätigungen

(Input Connector)

Grundkonfiguration

  • Server-URL

    URL und Port des Servlets, welches auf RosettaNet-Nachrichten wartet.

  • SSL

    Der Button öffnet den Dialog SSL-Konfiguration.

Authentifizierung

  • Authentifizierung erforderlich

    Markieren Sie diese Option, wenn der Server eine Authentifizierung fordert. Geben Sie dann den Account ein, den der Connector für die Authentifizierung verwenden soll.

  • Benutzername

    Benutzername für die Authentifizierung.

  • Passwort

    Passwort für die Authentifizierung.

HTTP Header-Konfiguration

Über den Header können Informationen wie z.B. Dateigröße, HTTP-Server- und User-Agent-Kennung oder MIME-Typ zwischen Client und HTTP-Server übertragen werden.

Der Button Header Liste öffnet einen Dialog, in dem Sie Name-Wert-Paare als Header definieren können.

Informationen über zulässige Header finden Sie in der HTTP-Spezifikation, siehe https://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf.

Verbindungstest

  • Verbindung testen

    Zum Testen, ob die Verbindung mit Ihren Angaben erfolgreich aufgebaut werden kann.

Dialog RosettaNet Verbindungsdaten im RosettaNet Connector

(Output Connector)

Grundkonfiguration

  • Server-URL

    URL des Servers, mit dem sich der Konnektor verbinden soll.

  • SSL

    Dient zum Konfigurieren der Server- bzw. Client-Authentifizierung und öffnet den Dialog, siehe Dialog SSL-Konfiguration.

Authentifizierung

  • Authentifizierung erforderlich

    Markieren Sie diese Option, wenn der Server eine Authentifizierung fordert. Geben Sie dann den Account ein, den der Connector für die Authentifizierung verwenden soll.

  • Benutzername

    Benutzername für die Authentifizierung.

  • Passwort

    Passwort für die Authentifizierung.

HTTP Header-Konfiguration

Über den Header können Informationen wie z.B. Dateigröße, HTTP-Server- und User-Agent-Kennung oder MIME-Typ zwischen Client und HTTP-Server übertragen werden.

Der Button Header Liste öffnet einen Dialog, in dem Sie Name-Wert-Paare als Header definieren können.

Informationen über zulässige Header finden Sie in der HTTP-Spezifikation, siehe https://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf.

Verbindungstest

  • Verbindung testen

    Zum Testen, ob die Verbindung mit Ihren Angaben erfolgreich aufgebaut werden kann.

Press Esc to exit full screen
Modal image placeholder
Press Esc to exit full screen