Das von Ihrer Nachricht verwendete Geschäftsprotokoll bestimmt das Dokumentformat. Das Geschäftsprotokoll ist für viele Entscheidungen relevant, die Sie beim Planen der Integration mit einem Back-End-System treffen müssen. Die Auswahl des Geschäftsprotokolls bestimmt die Paketerstellungsmethode, die Sie verwenden müssen und die wiederum die verwendbaren Nachrichtentransportprotokolle beeinflusst.
Eine umfassende Beschreibung der verfügbaren Geschäftsprotokolle finden Sie im Handbuch Hub-Konfiguration. Der vorliegende Abschnitt enthält Informationen zur Integration, die sich speziell auf die folgenden Geschäftsprotokolle beziehen:
WebSphere Partner Gateway kann Mitgliedern der Hub-Community die folgenden Web-Services zur Verfügung stellen:
Sie müssen Ihrem Community-Teilnehmer die öffentliche WSDL zur Verfügung stellen, die von WebSphere Partner Gateway generiert wird. Es ist wichtig zu beachten, dass die URL-Adresse, mit der der Community-Teilnehmer den Web-Service aufruft, die öffentliche Web-Service-URL-Adresse ist, die beim Hochladen des Web-Service angegeben wurde. WebSphere Partner Gateway fungiert als Proxy. Es empfängt eine SOAP-Nachricht vom Community Manager und ermittelt den entsprechenden privaten Web-Service. Anschließend ruft es den privaten (vom Community Manager bereitgestellten) Web-Service mit Hilfe derselben SOAP-Nachricht auf. Die vom Community Manager gelieferte Antwort wird dann an den Teilnehmer zurückgegeben.
Es ist wichtig zu beachten, dass die gleiche Web-Service-Schnittstelle von mehreren Partnern bereitgestellt werden kann. WebSphere Partner Gateway macht den Web-Service für den Community Manager über den Web-Service-URL verfügbar, der beim Hochladen des Web-Services in der Community Console angegeben wurde. Zusätzlich muss der Community Manager den URL-Parameter bereitstellen, um den Empfängerpartner zu identifizieren. Weitere detaillierte Informationen finden Sie im Handbuch Hub-Konfiguration. WebSphere Partner Gateway fungiert als Proxy. Es empfängt eine SOAP-Nachricht vom Community Manager und ermittelt den entsprechenden Web-Service und den Empfängerpartner. Dann ruft es den vom Partner bereitgestellten Web-Service mit Hilfe der gleichen SOAP-Nachricht auf. Die vom Partner gelieferte Antwortnachricht wird dann an den Community Manager zurückgegeben.
Weitere Informationen hierzu sowie Informationen zum Festlegen der Dokumen- tenflussdefinitionen für Web-Services finden Sie im Handbuch Hub-Konfiguration.
Sie können cXML-Dokumente an Ihre Community-Teilnehmer senden oder von ihnen empfangen. Wenn WebSphere Partner Gateway ein cXML-Dokument von einem Community-Teilnehmer empfängt, wird das Dokument geprüft und übersetzt (falls angegeben), bevor es an das Back-End-System auf dem Community Manager gesendet wird. Beachten Sie, dass die Übersetzung nicht für synchrone cXML-Nachrichten zu verwenden ist. Bei einem synchronen Austausch generiert das Back-End-System eine Antwort, die von WebSphere Partner Gateway an den Community-Teilnehmer zurückgegeben wird (falls für die Nachricht zutreffend).
Ein Back-End-System am Community Manager, das ein cXML-Dokument senden muss, hat zwei Möglichkeiten:
Weitere Informationen hierzu sowie Informationen zum Festlegen von Doku- mentenflussdefinitionen für cXML finden Sie im Handbuch Hub-Konfiguration.
WebSphere Partner Gateway empfängt EDI-Dokumente von Teilnehmern, die über ein VAN (Value Added Network) oder das Internet auf dieses Produkt zugreifen. EDI-Dokumente, die an ein VAN gesendet oder von einem VAN empfangen wurden, arbeiten mit dem FTP-Scripting-Transport. Der FTP-Scripting-Transport kann auch zum Senden oder Empfangen von Dokumenten über das Internet verwendet werden. Weitere Informationen zum FTP-Scripting-Transport finden Sie im Handbuch Hub-Konfiguration.
Ein EDI-Dokument erreicht und verlässt den Hub in einem EDI-Umschlag, der auch als Austausch (Interchange) bezeichnet wird. Der Austausch enthält einzelne EDI-Transaktionen oder Gruppen von Transaktionen.
Wird der EDI-Austausch über den Hub ausgeführt, ohne dass hierbei der Umschlag entfernt wird, erstellen Sie eine Verbindung zwischen dem Hub und dem Community Manager.
Wird der Umschlag des EDI-Austausches entfernt, dann unterscheidet sich die Vorgehensweise bei der Erstellung von Interaktionen und Verbindungen von der bei anderen Geschäftsprotokollen angewendeten Prozedur. Der Umschlag des Austauschs muss entfernt und die einzelnen Transaktionen müssen verarbeitet werden. Normalerweise werden die Transaktionen in ein anderes Format konvertiert. Dazu dient eine Transformationszuordnung, die vom Data Interchange Services-Client importiert wird. EDI-Transaktionen, die in XML- oder ROD-Dokumente (Record Oriented Data) konvertiert werden, werden direkt an den Community Manager oder den Teilnehmer gesendet. Transaktionen, die in andere EDI-Formate konvertiert werden, werden zuerst mit einem Umschlag versehen und dann an den Community Manager oder den Teilnehmer gesendet.
Eine Back-End-Anwendung kann folgende Dokumenttypen versenden:
WebSphere Partner Gateway entfernt den Umschlag der einzelnen EDI-Transaktionen und setzt diese individuellen Transaktionen um. Wenn die Transaktionen ins EDI-Format umgesetzt werden, fügt das System diese in einen Umschlag ein und leitet sie dann an den Teilnehmer weiter. Die Back-End-Anwendung kann die Pakettypen 'Kein Paket' und 'Back-End-Integrationspaket' verwenden und den Austausch über eine Vielzahl von Transportpro- tokollen versenden, die in Tabelle 13 aufgelistet sind.
In Abb. 6 ist ein EDI-X12-Austausch dargestellt, der aus drei Transaktionen besteht, deren Umschlag entfernt wird. Die Transaktionen werden ins EDIFACT-Format umgesetzt und dann wieder in einen Umschlag eingefügt und an den gewünschten Teilnehmer gesendet.
Alle Transaktionen verfügen über eine zugehörige Transformationszuordnung, in der definiert ist, wie die Transaktion transformiert wird. Die Transaktion kann in eine einzelne Transaktion oder (bei Verwendung einer Zuordnungsverkettung während der Zuordnungserstellung) in mehrere Transaktionen transformiert werden.
Wird die Transaktion in ein XML- oder ROD-Dokument umgesetzt, dann leitet das System dieses auf der Basis der in der zugehörigen Teilnehmerverbindung definierten Konfigurationseinstellungen weiter.
Abb. 7 zeigt einen EDI-X12-Austausch, dessen Umschlag entfernt und der anschließend in XML-Dokumente transformiert wird, die dann an den Teilnehmer gesendet werden.
Die Transaktion kann in ein einzelnes Dokument oder (bei Verwendung einer Zuordnungsverkettung während der Zuordnungserstellung) in mehrere Dokumente transformiert werden.
WebSphere Partner Gateway setzt das Dokument in eine EDI-Transaktion um, fügt diese in einen Umschlag ein und sendet sie an den Teilnehmer. Die Back-End-Anwendung kann die Pakettypen 'Kein Paket' und 'Back-End-Integrationspaket' verwenden und das Dokument über eine Vielzahl von Transportprotokollen versenden, die in Tabelle 13 aufgelistet sind.
Abb. 8 zeigt ein XML-Dokument, das in X12-Transaktionen transformiert und dann wieder in einen Umschlag eingefügt wird.
Ein Dokument kann hierbei in mehrere Transaktionen transformiert werden (wenn bei der Zuordnungserstellung die Zuordnungsverkettung eingesetzt wurde). Die Transaktionen können anschließend in Umschläge für unterschiedliche Austauschelemente eingefügt werden.
Abb. 9 zeigt ein XML-Dokument, das in drei X12-Transaktionen transformiert wird. Hierbei werden zwei der Transaktionen in denselben Umschlag eingefügt. Die dritte Transaktion erhält einen separaten Umschlag.
Wird das Dokument in ein XML- oder ROD-Dokument umgesetzt, dann leitet das System dieses auf der Basis der in der zugehörigen Teilnehmerverbindung definierten Konfigurationseinstellungen weiter.
WebSphere Partner Gateway teilt die Dokumente auf und setzt diese um. Wenn die Dokumente in EDI-Transaktionen umgesetzt werden, fügt WebSphere Partner Gateway diese Transaktionen in einen Umschlag ein und sendet dann den Umschlag an den Teilnehmer. Wenn den XML- oder ROD-Dokumenten Stapelverarbeitungs-IDs zugeordnet wurden, versucht WebSphere Partner Gateway, die EDI-Transaktionen (als Stapelverarbeitungselemente) in einem Umschlag zu versenden. Die Back-End-Anwendung kann die Pakettypen 'Kein Paket' und 'Back-End-Integrationspaket' verwenden und das Dokument über eine Vielzahl von Transportprotokollen versenden, die in Tabelle 13 aufgelistet sind.
Abb. 10 zeigt eine Gruppe von XML-Dokumenten, die aufgeteilt werden. Auf diese Weise werden mehrere separate XML-Dokumente erstellt. Die XML-Dokumente werden in X12-Transaktionen transformiert, die Transaktionen anschließend in Umschläge eingefügt.
Abb. 10 zeigt, wie die Dokumente aufgeteilt und die transformierten Transaktionen dann gemeinsam in einen Umschlag eingefügt werden. Um die Aufteilung von Dokumenten zu ermöglichen, müssen Sie für das Ziel, an das die Dokumente gesendet werden sollen, eine entsprechende Aufteilungsroutine (den sog. Splitter Handler) konfigurieren. Im vorliegenden Fall wird der XML Splitter Handler verwendet. Beim XML Splitter Handler muss die Option BCG_BATCHDOCS auf den Standardwert ON gesetzt werden, damit das dargestellte Szenario gilt. BCG_BATCHDOCS dient zur Zuordnung einer Stapelverarbeitungs-ID zu den XML-Dokumenten, so dass die resultierenden Transaktionen in denselben Umschlag eingefügt werden können. Weitere Informationen zum XML Splitter Handler und zum Attribut BCG_BATCHDOCS finden Sie im Handbuch Hub-Konfiguration.
Werden die Dokumente in andere XML- oder ROD-Dokumente umgesetzt, erfolgt das Routing auf der Basis der Konfigurationseinstellungen, die in der Teilnehmerverbindung der Dokumente festgelegt sind.
WebSphere Partner Gateway teilt die Datei in mehrere separate Austauschelemente auf. Anschließend werden die Austauschelemente aus den Umschlägen entfernt und in einzelne Transaktionen aufgeteilt und dann umgesetzt. Wenn die Dokumente in EDI-Transaktionen umgesetzt werden, fügt WebSphere Partner Gateway diese Transaktionen in einen Umschlag ein und sendet dann den Umschlag an den Teilnehmer. Die Back-End-Anwendung kann die Pakettypen 'Kein Paket' und 'Back-End-Integrationspaket' verwenden und das Dokument über eine Vielzahl von Transportprotokollen versenden, die in Tabelle 13 aufgelistet sind.
Werden die Dokumente in XML- oder ROD-Dokumente umgesetzt, erfolgt das Routing auf der Basis der Konfigurationseinstellungen, die in der Teilnehmerverbindung der Dokumente festgelegt sind.
Ein Teilnehmer kann die folgenden Dokumenttypen senden:
WebSphere Partner Gateway entfernt den Umschlag der einzelnen EDI-Transaktionen und setzt diese Transaktionen um. Wenn die Transaktionen ins EDI-Format umgesetzt werden, fügt das System diese in einen Umschlag ein und leitet sie dann an die Back-End-Anwendung weiter. Die Back-End-Anwendung kann die Pakettypen 'Kein Paket' und 'Back-End-Integrationspaket' verwenden und die Transaktionen über eine Vielzahl von Transportprotokollen versenden, die in Tabelle 14 aufgelistet sind.
Werden die Transaktionen in XML- oder ROD-Dokumente umgesetzt, erfolgt das Routing auf der Basis der Konfigurationseinstellungen, die in der Teilnehmerverbindung der Transaktionen festgelegt sind.
WebSphere Partner Gateway setzt das Dokument in eine EDI-Transaktion um, fügt diese in einen Umschlag ein und sendet den Umschlag an die Back-End-Anwendung. Hierbei kann der Pakettyp 'Kein Paket' oder 'Back-End-Integra- tionspaket' verwendet werden.
Wird das Dokument in ein XML- oder ROD-Dokument umgesetzt, dann leitet das System dieses auf der Basis der in der zugehörigen Teilnehmerverbindung definierten Konfigurationseinstellungen weiter.
WebSphere Partner Gateway teilt die Dokumente auf und setzt diese um. Wenn die Dokumente in EDI-Transaktionen umgesetzt werden, fügt WebSphere Partner Gateway diese Transaktionen in einen Umschlag ein und sendet dann den Umschlag an die Back-End-Anwendung. Wenn den XML- oder ROD-Dokumenten Stapelverarbeitungs-IDs zugeordnet wurden, versucht WebSphere Partner Gateway, die EDI-Transaktionen (als Stapelverarbeitungselemente) in einem Umschlag zu versenden. Hierbei kann der Pakettyp 'Kein Paket' oder 'Back- End-Integrationspaket' verwendet werden.
Werden die Dokumente in andere XML- oder ROD-Dokumente umgesetzt, erfolgt das Routing auf der Basis der Konfigurationseinstellungen, die in der Teilnehmerverbindung der Dokumente festgelegt sind.
WebSphere Partner Gateway teilt die Datei in mehrere separate Austauschelemente auf. Anschließend werden die Austauschelemente aus den Umschlägen entfernt und in einzelne Transaktionen aufgeteilt und dann umgesetzt. Wenn die Dokumente in EDI-Transaktionen umgesetzt werden, fügt WebSphere Partner Gateway diese Transaktionen in einen Umschlag ein und sendet dann den Umschlag an die Back-End-Anwendung. Hierbei kann der Pakettyp 'Kein Paket' oder 'Back-End-Integrationspaket' verwendet werden.
Werden die Dokumente in XML- oder ROD-Dokumente umgesetzt, erfolgt das Routing auf der Basis der Konfigurationseinstellungen, die in der Teilnehmerverbindung der Dokumente festgelegt sind.
Eine Funktionsbestätigung gibt an, dass ein EDI-Austausch empfangen wurde. Sie wird vor dem Versenden immer in einen Umschlag eingefügt.
Für von WebSphere Partner Gateway empfangene Austauschelemente gilt Folgendes:
Für von WebSphere Partner Gateway generierte Austauschelemente gilt Folgendes:
WebSphere Partner Gateway unterstützt das Senden und Empfangen von Dokumenten, die den Standards RosettaNet 1.1 und 2.0 entsprechen. Wenn ein Teilnehmer eine RosettaNet-Nachricht an den Hub sendet, dann muss auf der Zieleinheit der Teilnehmerverbindung als Pakettyp 'Back-End-Integrationspaket' angegeben sein. Der Hub konvertiert die Nutzinformationen der Nachricht ins RNSC-Format und sendet die Nachricht an das Back-End-System. Da der Pakettyp 'Back-End-Integrationspaket' verwendet wird, fügt der Hub Header der Transportebene zur Nachricht hinzu. Die Nachricht wird anschließend über das HTTP- oder das JMS-Transportprotokoll übertragen. Der Header der Transportebene enthält Metainformationen, die nicht Teil des PIP (Partner Interface Process) sind, und gibt WebSphere Partner Gateway die Möglichkeit, die Nachricht entsprechend weiterzuleiten.
Wenn das Back-End-System des Community Managers eine RNSC-Nachricht an den Hub sendet, muss auf der Quelleneinheit der Teilnehmerverbindung der Pakettyp 'Back-End-Integrationspaket' angegeben worden sein. Das Back-End- System muss in diesem Fall auch die Header der Transportebene bereitstellen.
Nehmen Sie zum Beispiel an, eine Anwendung will eine Nachricht an einen Community-Teilnehmer unter Verwendung von RosettaNet über HTTP senden. Die Anwendung stellt den RosettaNet-Service-Content bereit und fügt den Header der Transportebene hinzu. Der Header gibt unter anderem den Community-Teilnehmer, der die Anforderung verarbeiten soll, den PIP, der gesendet wird, sowie die Version des PIP an. Diese Informationen geben WebSphere Partner Gateway die Möglichkeit, den richtigen PIP an den Community-Teilnehmer zu senden.
Informationen zur Einrichtung der RosettaNet-Unterstützung und zur Konfiguration von PIPs finden Sie im Handbuch Hub-Konfiguration.
WebSphere Partner Gateway führt RNIF-PIP-Prozesse mit Community-Teilnehmern für die Back-End-Anwendungen des Community Managers aus. Aus diesem Grund stellt WebSphere Partner Gateway einen Mechanismus zur Ereignisbenachrichtigung bereit, um die Back-End-Anwendung über verschiedene Aspekte der Ausführung des RNIF-PIP-Prozesses zu informieren. Die Ereignisbenachrich- tigung ermöglicht es WebSphere Partner Gateway z. B., die Anwendung darüber zu informieren, ob ein PIP an den Teilnehmer gesendet werden kann oder nicht. Bei Bedarf kann die Anwendung dann geeignete Fehlerbehebungsmaßnahmen durchführen.
Eine Ereignisbenachrichtigung ist ein XML-Dokument, das Informationen über Ereignisse transportiert, die in WebSphere Partner Gateway oder in einer Anwendung aufgetreten sind. Diese Nachrichten weisen die gleiche Struktur wie alle anderen Nachrichten auf, die von WebSphere Partner Gateway gesendet oder empfangen werden. Dies bedeutet, dass sie einen Header der Transportebene und die Nutzinformationen enthalten. WebSphere Partner Gateway kann so konfiguriert werden, dass Ereignisbenachrichtigungen gesendet oder nicht gesendet werden, da diese Nachrichten optional sind.
In Tabelle 2 sind die Ereignisbenachrichtigungen zusammengefasst, die von WebSphere Partner Gateway an Back-End-Systeme gesendet werden können.
Ereignisbedingung | Ereignisbenachrichtigung |
---|---|
WebSphere Partner Gateway stellt ein RosettaNet-Dokument einem Community-Teilnehmer zu und erhält eine Empfangsbestätigung. |
Ereignis 100 |
WebSphere Partner Gateway bricht einen PIP ab, indem eine Nachricht 0A1 generiert und dem Community-Teilnehmer zugestellt wird. |
Ereignis 800 |
WebSphere Partner Gateway empfängt eine Ausnahmebedingung im Zusammenhang mit einer Empfangsbestätigung oder eine allgemeine Ausnahmebedingung vom Community-Teilnehmer. |
Ereignis 900 |
WebSphere Partner Gateway kann 0A1-Nachrichten an die Zielanwendung senden, wie dies auch für jeden anderen PIP geschieht, wenn über die Ausschlusslistenverwaltung das Senden dieser Nachrichten konfiguriert wurde. Weitere Informationen hierzu finden Sie im Abschnitt zur Verwaltung von Ausschlusslisten im Handbuch Verwaltung.
Eine Anwendung kann eine Ereignisbenachrichtigung an WebSphere Partner Gateway senden, um einen RosettaNet-PIP abzubrechen.
Eine Ereignisbenachrichtigung verfügt über einen Standardheader der Transportebene, dessen Feld 'x-aux-process-type' auf den Wert XMLEvent gesetzt ist. Allerdings verfügen die Nutzinformationen der Nachricht über eine bestimmte Struktur, die in dem in Abb. 11 dargestellten XML-Schema gezeigt wird.
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace= "http://www.ibm.com/websphere/bcg/2003/v1.0/xmleventnotification" xmlns:evntf= "http://www.ibm.com/websphere/bcg/2003/v1.0/xmleventnotification" elementFormDefault="qualified">
<!-- EventNotification version 1.0 document element --> <xsd:element name="EventNotification"> <xsd:complexType> <xsd:all> <xsd:element ref="evntf:StatusCode"/> <xsd:element ref="evntf:StatusMessage"/> <xsd:element ref="evntf:EventMessageID"/> <xsd:element ref="evntf:BusinessObjectID"/> <xsd:element ref="evntf:GlobalMessageID"/> <xsd:element ref="evntf:Timestamp"/> </xsd:all> </xsd:complexType> </xsd:element>
<!-- StatusCode element --> <xsd:element name="StatusCode"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="100"/> <xsd:enumeration value="800"/> <xsd:enumeration value="900"/> <xsd:enumeration value="901"/> <xsd:enumeration value="902"/> <xsd:enumeration value="903"/> <xsd:enumeration value="904"/> </xsd:restriction> </xsd:simpleType> </xsd:element>
<!-- StatusMessage element --> <xsd:element name="StatusMessage"> <xsd:simpleType> <xsd:restriction base="xsd:string"/> </xsd:simpleType> </xsd:element>
<!-- EventMessageID element --> <xsd:element name="EventMessageID"> <xsd:simpleType> <xsd:restriction base="xsd:string"/> </xsd:simpleType> </xsd:element>
<!-- BusinessObjectID element --> <xsd:element name="BusinessObjectID"> <xsd:simpleType> <xsd:restriction base="xsd:string"/> </xsd:simpleType> </xsd:element>
<!-- GlobalMessageID element --> <xsd:element name="GlobalMessageID"> <xsd:simpleType> <xsd:restriction base="xsd:string"/> </xsd:simpleType> </xsd:element>
<!-- Timestamp element --> <xsd:element name="Timestamp"> <xsd:simpleType> <xsd:restriction base="xsd:dateTime"/> </xsd:simpleType> </xsd:element> </xsd:schema>
In Tabelle 3 sind die einzelnen Felder der Ereignisnutzinformationen beschrieben.
Abb. 12 zeigt ein Beispiel für eine mit dem HTTP-Protokoll gesendete Ereignisbenachrichtigung.
POST /builderURL HTTP/1.1 Content-Type: application/xml Content-length: 250 x-aux-sender-id: 000000001 x-aux-receiver-id: 000000002 x-aux-third-party-bus-id: 000000003 x-aux-create-datetime: 2002-10-28T23:05:02Z x-aux-protocol: XMLEvent x-aux-protocol-version: 1.0 x-aux-process-type: XMLEvent x-aux-process-version: 1.0 x-aux-payload-root-tag: evntf:EventNotification x-aux-msg-id: 98732 x-aux-system-msg-id: 12345 x-aux-production: Production x-aux-process-instance-id: 3456 x-aux-event-status-code: 100 x-aux-transport-retry-count: 0
<?xml version="1.0" encoding="UTF-8"?> <evntf:EventNotification xmlns:evntf= "http://www.ibm.com/websphere/bcg/2003/v1.0/xmleventnotification"> <evntf:StatusCode>100</evntf:StatusCode> <evntf:StatusMessage>The message was delivered</evntf:StatusMessage> <evntf:EventMessageID>12345</evntf:EventMessageID> <evntf:BusinessObjectID>34234</evntf:BusinessObjectID> <evntf:GlobalMessageID>98732</evntf:GlobalMessageID> <evntf:Timestamp>2001-01-31T13:20:00Z</evntf:Timestamp> </evntf:EventNotification>