Welches Geschäftsprotokoll wird verwendet?

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:

Web-Services (SOAP)

WebSphere Partner Gateway kann Mitgliedern der Hub-Community die folgenden Web-Services zur Verfügung stellen:

Weitere Informationen hierzu sowie Informationen zum Festlegen der Dokumen- tenflussdefinitionen für Web-Services finden Sie im Handbuch Hub-Konfiguration.

cXML

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:

Anmerkung: Wenn die Konvertierung für XML-Dokumente verwendet wird, wird die Antwort bei synchronen Aufforderungs-/Antworttransaktionen mit dem Community-Teilnehmer asynchron an das Back-End-System zurückgegeben.

Weitere Informationen hierzu sowie Informationen zum Festlegen von Doku- mentenflussdefinitionen für cXML finden Sie im Handbuch Hub-Konfiguration.

EDI

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.

Dokumentenfluss von der Back-End-Anwendung zum Teilnehmer

Eine Back-End-Anwendung kann folgende Dokumenttypen versenden:

Dokumentenfluss vom Teilnehmer zur Back-End-Anwendung

Ein Teilnehmer kann die folgenden Dokumenttypen senden:

Funktionsbestätigungen

Eine Funktionsbestätigung gibt an, dass ein EDI-Austausch empfangen wurde. Sie wird vor dem Versenden immer in einen Umschlag eingefügt.

Anmerkung: Funktionsbestätigungen gelten nur für die Austauschelemente, die von WebSphere Partner Gateway aus dem Umschlag entfernt oder von WebSphere Partner Gateway generiert wurden. Für Austauschelemente, die lediglich über WebSphere Partner Gateway weitergeleitet wurden, gelten Funktionsbestätigungen hingegen nicht.

Für von WebSphere Partner Gateway empfangene Austauschelemente gilt Folgendes:

Für von WebSphere Partner Gateway generierte Austauschelemente gilt Folgendes:

RosettaNet

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.

Ereignisbenachrichtigung

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.

Tabelle 2. Ereignisbenachrichtigungen an das Back-End-System
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.

Struktur von Ereignisnachrichten

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.

Abbildung 11. XML-Schema für eine Ereignisbenachrichtigung
<?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.

Tabelle 3. XML-Felder zur Ereignisbenachrichtigung
Feld Beschreibung
StatusCode Der Typ der Nachricht. Folgende Werte sind gültig:
  • 100 - WebSphere Partner Gateway hat das Dokument zugestellt und eine Empfangsbestätigung erhalten.
  • 800 - Die Anwendung hat den PIP abgebrochen.
  • 900 - WebSphere Partner Gateway hat eine Ausnahmebedingung bei der Empfangsbestätigung, eine allgemeine Ausnahmebedingung oder einen 0A1-Fehler-PIP vom Community-Teilnehmer empfangen.
StatusMessage Alphanumerische Beschreibung dieser Ereignisbenachrichtigung.
EventMessageID Alphanumerische Kennung dieser speziellen Ereignisbenachrichtigung.
BusinessObjectID Das Feld 'x-aux-msg-id' im Header der Transportebene der Nachricht, die von diesem Benachrichtigungsereignis betroffen ist. Dies stellt die Verbindung zu den Nutzinformationen der ursprünglichen Nachricht zu diesem Ereignis her.
GlobalMessageID Das Feld 'x-aux-system-msg-id' im Header der Transportebene der Nachricht, die dieses Benachrichtigungsereignis verursacht hat.
Timestamp

Gibt im WEZ-Zeitmarkenformat an, wann das Ereignis aufgetreten ist:

CCYY-MM-DDThh:mm:ssZ

Dies schließt die Bruchteilgenauigkeit von Sekunden (...ss.ssssZ) mit ein. Die Datumszeitmarke muss dem Datentyp des XML-Schemas für 'dateTime' (w3.org/TR/2001/REC-xmlschema-2-20010502#dateTime) entsprechen.

Beispiel für eine Ereignisbenachrichtigung

Abb. 12 zeigt ein Beispiel für eine mit dem HTTP-Protokoll gesendete Ereignisbenachrichtigung.

Abbildung 12. Beispiel für eine Ereignisbenachrichtigung über HTTP
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>

Copyright IBM Corp. 2003, 2005