Back-End-Integration planen

Dieser Abschnitt enthält die folgenden Informationen zur Planung der Back-End-Integration mit WebSphere Business Integration Connect:

Welches Geschäftsprotokoll verwenden Sie?

Das Geschäftsprotokoll Ihrer Nachricht 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 vollständige Beschreibung der Geschäftsprotokolle finden Sie im Handbuch Verwaltung. Dieser Abschnitt enthält Informationen zur Integration, die sich speziell auf die folgenden Geschäftsprotokolle beziehen:

Web Services (SOAP)

Business Integration Connect kann Mitgliedern des Hubs die folgenden Web-Services zur Verfügung stellen:

Weitere Informationen, einschließlich darüber, wie Dokumentenflussdefinitionen für Web-Services eingerichtet werden, finden Sie im Handbuch Hub-Konfiguration.

cXML

Sie können cXML-Dokumente an Ihre Community-Teilnehmer senden oder von ihnen empfangen. Wenn Business Integration Connect 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. In einem synchronen Austausch generiert das Back-End-System eine Antwort, die von Business Integration Connect 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 Übersetzung für XML-Dokumente verwendet wird, wird die Antwort bei synchronen Anforderungs-/Antworttransaktionen mit dem Community-Teilnehmer asynchron an das Back-End-System zurückgegeben.

Weitere Informationen, einschließlich darüber, wie Dokumentenflussdefinitionen für cXML eingerichtet werden, finden Sie im Handbuch Verwaltung.

RosettaNet

Business Integration Connect bietet Unterstützung für RosettaNet 1.1 und 2.0, sofern sich die RosettaNet-Nachrichten in einem Back-End-Integrationspaket befinden (das heißt, sie müssen Header der Transportebene besitzen). Diese Nachrichten müssen das HTTP- oder JMS-Transportprotokoll verwenden. Der Header der Transportebene enthält Metainformationen, die nicht Teil des PIP (Partner Interface Process) sind, und gibt Business Integration Connect die Möglichkeit, die Nachricht entsprechend weiterzuleiten.

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-Serviceinhalt 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 Business Integration Connect 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

Da Business Integration Connect die Anwendung von dem Community-Teilnehmer trennt, der den RosettaNet-Service-Provider darstellt, stellt Business Integration Connect eine Ereignisbenachrichtigung zur Verfügung. Die Ereignisbenachrichtigung gibt Business Integration Connect zum Beispiel die Möglichkeit, die Anwendung zu benachrichtigen, wenn Business Integration Connect einen PIP nicht an den Teilnehmer senden kann. Die Anwendung kann dann eine Fehlerbehandlung durchführen.

Eine Nachricht zur Ereignisbenachrichtigung ist ein XML-Dokument, das Informationen über Ereignisse transportiert, die in Business Integration Connect oder in einer Anwendung aufgetreten sind. Diese Nachrichten haben die gleiche Struktur wie jede andere Nachricht, die in Business Integration Connect ein- oder ausgeht. Das heißt, sie enthalten einen Header der Transportebene und die Nutzinformationen (payload). Business Integration Connect kann so konfiguriert werden, dass Nachrichten zur Ereignisbenachrichtigung gesendet oder nicht gesendet werden, da diese Nachrichten optional sind.

In Tabelle 1 sind die Nachrichten zur Ereignisbenachrichtigung zusammengefasst, die von Business Integration Connect an Back-End-Systeme gesendet werden können.

Tabelle 1. Nachrichten zur Ereignisbenachrichtigung an das Back-End-System
Ereignisbedingung Ereignisbenachrichtigung

Business Integration Connect stellt ein RosettaNet-Dokument einem Community-Teilnehmer zu und erhält eine Empfangsbestätigung.

Ereignis 100

Business Integration Connect bricht einen PIP ab, indem eine Nachricht 0A1 generiert und dem Community-Teilnehmer zugestellt wird.

Ereignis 800

Business Integration Connect empfängt eine Ausnahmebedingung im Zusammenhang mit einer Empfangsbestätigung oder eine allgemeine Ausnahmebedingung vom Community-Teilnehmer.

Ereignis 900

Business Integration Connect kann eine Nachricht 0A1 an die Zielanwendung senden, wie dies auch für jeden anderen PIP geschieht, wenn über die Ausschlusslistenverwaltung das Senden dieser Nachrichten konfiguriert wurde. Siehe "Ausschlusslisten verwalten" im Handbuch Verwaltung.

Eine Anwendung kann eine Nachricht zur Ereignisbenachrichtigung an Business Integration Connect senden, um einen RosettaNet-PIP abzubrechen.

Struktur von Ereignisnachrichten

Eine Nachricht zur Ereignisbenachrichtigung besitzt einen Standardheader der Transportebene, dessen Feld 'x-aux-process-type' auf den Wert XMLEvent gesetzt ist. Allerdings verfügt der Teil der Nutzinformationen (payload) über eine spezielle Struktur, wie das Beispiel für ein XML-Schema in Abbildung 2 zeigt.

Abbildung 2. Beispiel eines XML-Schemas für eine Nachricht zur 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 2 sind die einzelnen Felder der Ereignisnutzinformationen beschrieben.

Tabelle 2. XML-Felder zur Ereignisbenachrichtigung
Feld Beschreibung
StatusCode Der Typ von Nachricht. Folgende Werte sind gültig:
  • 100 - Business Integration Connect hat das Dokument zugestellt und eine Empfangsbestätigung erhalten.
  • 800 - Die Anwendung hat den PIP abgebrochen.
  • 900 - Business Integration Connect hat eine Ausnahmebedingung bei der Empfangsbestätigung, eine allgemeine Ausnahmebedingung oder einen 0A1-Fehler-PIP vom Community-Teilnehmer empfangen.
StatusMessage Eine alphanumerische Beschreibung dieser Nachricht zur Ereignisbenachrichtigung.
EventMessageID Eine alphanumerische Kennung dieser bestimmten Nachricht zur 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 (payload) 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 Nachricht zur Ereignisbenachrichtigung

Abbildung 3 zeigt ein Beispiel für eine mit dem HTTP-Protokoll gesendete Nachricht zur Ereignisbenachrichtigung.

Abbildung 3. Beispiel für eine Nachricht zur 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>
 

Welche Art von Paket soll verwendet werden?

Der Pakettyp bestimmt das Format, in dem die Nachricht von Business Integration Connect an das Back-End-System gesendet wird.

Über die Community Console können Sie die Verbindung mit Ihren Community-Teilnehmern einrichten und den Pakettyp angeben, die zwischen Business Integration Connect und dem Back-End-System verwendet wird. Welcher Pakettyp dabei zu verwenden ist, hängt von folgenden Gesichtspunkten ab:

Weitere Informationen zur Einrichtung von Partnerverbindungen finden Sie im Handbuch Hub-Konfiguration.

Gültige Pakettypen für die Integration

Nicht alle Pakettypen sind gültig, wenn Sie Business Integration Connect zur Integration verwenden. In Tabelle 3 sind die Pakettypen aufgelistet, die relevant sind, wenn Business Integration Connect als Community Manager fungiert.

Tabelle 3. Relevante Pakettypen zur Back-End-Integration
Pakettyp Beschreibung
Kein Paket

Veranlasst Business Integration Connect, die Nachricht an das Back-End-System ohne Headerdaten zu senden.

Back-End-Integrationspaket

Fügt dem Nachrichtenheader zusätzliche Attribute hinzu und packt (optional) den Nachrichteninhalt in eine XML-Transporthülle

Anmerkung:
Andere Pakettypen (wie AS) stehen mit Business Integration Connect zur Verfügung. Für die Integration mit Back-End-Systemen werden jedoch nur die Typen 'Kein Paket' und 'Back-End-Integrationspaket' empfohlen.

Kein Paket

Wenn 'Kein Paket' festgelegt ist, wird von Business Integration Connect weder ein Header der Transportebene beim Senden einer Nachricht an ein Back-End-System hinzugefügt noch ein solcher Header beim Empfang einer Nachricht von einem Back-End-System erwartet. Stattdessen sendet Business Integration Connect die reine Nachricht an das Back-End-System. Informationen innerhalb des Dokuments steuern die Weiterleitung.

Back-End-Integrationspaket

Wenn ein Back-End-Integrationspaket verwendet wird, müssen Nachrichten, die an ein Back-End-System gesendet oder von einem Back-End-System empfangen werden, folgende Komponenten enthalten:

Der Header und die Nutzinformationen sind verbindlich, während Anhänge optional sind. In den folgenden Abschnitten werden die einzelnen Komponenten eines Dokuments beschrieben, das ein Back-End-Integrationspaket verwendet.

Inhalt des Headers der Transportebene

Der Header der Transportebene enthält Informationen, die von Business Integration Connect zur Verarbeitung und Weiterleitung der Nachricht an die korrekte Zieladresse verwendet werden. Der Header der Transportebene ist bidirektional, so dass alle Nachrichten, die in Business Integration Connect ein- und ausgehen, die verbindlichen Felder und alle relevanten optionalen Felder besitzen.

In Tabelle 4 sind die Felder des Headers der Transportebene aufgelistet.

Tabelle 4. Felder des Headers der Transportebene
Headerfeld Beschreibung Erforderlich?
x-aux-sender-id Kennung des Nachrichtenabsenders, zum Beispiel eine DUNS-Nummer. Ja
x-aux-receiver-id Kennung des Nachrichtenempfängers, zum Beispiel eine DUNS-Nummer. Ja
x-aux-protocol Protokoll des Nachrichteninhalts. Gültige Wert sind RNSC (RosettaNet Service Content), XMLEvent und Binary. Für Business Integration Connect hat der Wert in diesem Feld Vorrang vor jedem Protokollfeld in den Nutzinformationen. Ja
x-aux-protocol-version Version des Protokolls für den Nachrichteninhalt. Ja
x-aux-process-type Der auszuführende Prozess bzw. der Typ der gesendeten Nachricht. Bei RosettaNet-Nachrichten ist dies der PIP-Code, zum Beispiel 3A4. Bei Ereignisnachrichten hat dieses Feld den Wert 'XMLEvent', bei binären Nachrichten 'Binary'. Für Business Integration Connect hat der Wert in diesem Feld Vorrang vor jedem Prozessfeld in den Nutzinformationen. Ja
x-aux-process-version Version des Prozesses. Bei RosettaNet-Nachrichten ist dies die Versionsnummer des PIP. Ja
x-aux-create-datetime Gibt an, wann die Nachricht erfolgreich übergeben wurde (im WEZ-Zeitmarkenformat: CCYY-MM-DDThh:mm:ssZ).
x-aux-msg-id Die Kennung des Inhalts der Nutzinformationen (payload). Dies könnte zum Beispiel die Kennung der RNPIPServiceContent-Instanz bei einer RosettaNet-Nachricht oder eine proprietäre Dokumentkennung sein. Dieser Wert stellt zu Tracingzwecken die Verbindung der Nutzinformationen der Nachricht zu einer Komponente des Systems des Nachrichtenabsenders her.
x-aux-production Weiterleitung der Nachricht. Gültige Werte: Production, Test. Dieser Wert wird für Anforderungen in beide Richtungen eingetragen. Beachten Sie, dass bei einer Nachricht, die eine Antwort auf einen von einem Community-Teilnehmer eingeleiteten PIP in beide Richtungen ist, Business Integration Connect den Wert 'GlobalUsageCode' in der Anforderung verwendet und den Wert im Header der Transportebene ignoriert.
x-aux-system-msg-id Globale eindeutige Kennung (Global Unique Identifier - GUID) für die Nachricht, die zur Duplikatprüfung dient. Ja
x-aux-payload-root-tag Das 'root-tag'-Element der Nutzinformationen (payload). Für einen 3A4-RosettaNet-Serviceinhalt wäre der Wert dieses Felds zum Beispiel 'Pip3A4PurchaseOrderRequest'. Bei Nachrichten zur Ereignisbenachrichtigung wäre der Wert dieses Felds 'EventNotification'.
x-aux-process-instance-id Kennung, die Dokumente in einem Geschäftsprozess mit mehreren Nachrichten mit einer eindeutigen Prozessinstanz verbindet. Für RosettaNet muss dieser Wert für RosettaNet-Prozesse innerhalb der letzten 30 Tage eindeutig sein. Alle Nachrichten, die im Rahmen einer RosettaNet-Prozessinstanz ausgetauscht werden, einschließlich wiederholte Nachrichten, verwenden die gleiche Prozessinstanz-ID.
x-aux-event-status-code Statuscode für die Ereignisbenachrichtigung. Siehe das Feld 'StatusCode' in Struktur von Ereignisnachrichten.
x-aux-third-party-bus-id Kennung, zum Beispiel eine DUNS-Nummer der Partei, von der die Nachricht zugestellt wurde. Dieser Wert kann sich sowohl von 'x-aux-sender-id' als auch von 'x-aux-receiver-id' unterscheiden, wenn eine dritte Partei im Namen des Community-Eigners als Host für Business Integration Connect fungiert.
x-aux-transport-retry-count Anzahl der vor diesem Versuch nicht erfolgreichen Versuche, diese Nachricht zu übergeben. Wenn eine Nachricht beim ersten Versuch erfolgreich übergeben wird, erhält dieses Feld den Wert 0.
content-type Der Inhaltstyp der Nachricht.
content-length Die Länge der Nachricht (in Byte).

Anmerkung:
Aus Gründen der Kompatibilität mit IBM WebSphere MQ (ein JMS-Provider) werden in den Feldern einer Nachricht des JMS-Protokolls Unterstreichungszeichen anstelle von Silbentrennungsstrichen verwendet. In einer JMS-Nachricht gibt es zum Beispiel ein Feld 'x_aux_sender_id' anstatt eines Felds 'x-aux-sender-id'.

Tabelle 4 enthält eine Übersicht über die Headerinformationen der Transportebene. In den folgenden Abschnitten finden Sie Headerinformationen der Transportebene, die für bestimmte Geschäftsprotokolle spezifisch sind:

Header der Transportebene und eine RosettaNet-Nachricht 

In Tabelle 5 wird beschrieben, wo Business Integration Connect Werte für die Felder des Headers der Transportebene aus einer RosettaNet-Nachricht abruft.

Tabelle 5. Felder des Headers der Transportebene und RosettaNet-Inhalt
Headerfeld Quelle des Werts: RosettaNet 2.0 Quelle des Werts: RosettaNet 1.1
x-aux-sender-id
<(DeliveryHeader)>
   <messageSenderIdentification>
     <PartnerIdentification>
       <GlobalBusinessIdentifier>
 
<ServiceHeader>
   <ProcessControl>
     <TransactionControl>
       <ActionControl> or <SignalControl>
         <PartnerRouter>
           <fromPartner>
             <PartnerDescription>
               <BusinessDescription>
                 <GlobalBusinessIdentifier>
 
x-aux-receiver-id
<(DeliveryHeader)>
   <messageReceiverIdentification>
     <PartnerIdentification>
       <GlobalBusinessIdentifier>
 
<ServiceHeader>
   <ProcessControl>
     <TransactionControl>
       <ActionControl> or <SignalControl>
         <PartnerRouter>
           <toPartner>
             <PartnerDescription>
               <BusinessDescription>
                 <GlobalBusinessIdentifier>
 
x-aux-protocol Festgelegter Wert für RosettaNet: RNSC Wie für RosettaNet 2.0
x-aux-protocol-version Festgelegter Wert: 1.0 Wie für RosettaNet 2.0
x-aux-process-type

Der Quellen-XPath ist:

/ServiceHeader/ProcessControl/
 pipCode/GlobalProcessIndicatorCode 
 

Der Quellen-XPath ist:

/ServiceHeader/ProcessControl/
 ProcessIdentity/GlobalProcessIndicatorCode
 
x-aux-process-version

Der Quellen-XPath ist:

/ServiceHeader/ProcessControl/
 pipVersion/VersionIdentifier 
 

Der Wert der Versionskennung jedes PIP befindet sich in der zugehörigen PIP-Spezifikation.

Der Quellen-XPath ist:

/ServiceHeader/ProcessControl/
 ProcessIdentity/VersionIdentifier
 

Der Wert der Versionskennung jedes PIP befindet sich in der zugehörigen PIP-Spezifikation.

x-aux-payload- root-tag Name des PIP wie 'Pip3A4PurchaseOrderRequest' Wie für RosettaNet 2.0
x-aux-process-instance-id

Für Prozesse, die von einer Anwendung eingeleitet werden, ist der Wert die ID der Prozessinstanz. Für Prozesse, die von einem Community-Teilnehmer eingeleitet werden und die kein Pass-Through-Arbeitsablauf sind, ist der Wert die Prozess-ID in der einleitenden RosettaNet-Anforderung:

<ServiceHeader>
   <ProcessControl>
     <pipInstanceId>
       <InstanceIdentifier>
 
<ServiceHeader>
   <ProcessControl>
     <ProcessIdentity>
       <InstanceIdentifier> 
 
x-aux-msg-id
<(RNPipServiceContent)>
   <thisDocumentIdentifier>
     <ProprietaryDocumentIdentifier> 
 
Wie für RosettaNet 2.0
x-aux-production
<ServiceHeader>
   <ProcessIndicator>
     <GlobalUsageCode>
 
<Preamble>
   <GlobalUsageCode>
 

Header der Transportebene und eine AS2-Nachricht 

In Tabelle 6 wird beschrieben, wo Business Integration Connect Werte für die Felder des Headers der Transportebene aus einer AS2-Nachricht abruft.

Anmerkung:
Die Werte sind von der Groß-/Kleinschreibung abhängig.

Tabelle 6. Felder des Headers der Transportebene aus AS2-Inhalt
Headerfeld Quelle des Werts
x-aux-sender-id Wenn ein Community-Teilnehmer eine AS2-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird das AS2-Headerfeld für den Absender (From) in das Feld 'x-aux-sender-id' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS2-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-sender-id' der eingehenden Back-End-Integrationsnachricht als AS2-Headerwert für den Absender der AS2-Nachricht verwendet.
x-aux-receiver-id Wenn ein Community-Teilnehmer eine AS2-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird das AS2-Headerfeld für den Empfänger (To) in das Feld 'x-aux-receiver-id' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS2-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-receiver-id' der eingehenden Back-End-Integrationsnachricht als AS2-Headerwert für den Empfänger der AS2-Nachricht verwendet.
x-aux-protocol Wenn ein Community-Teilnehmer eine AS2-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird das Empfängerprotokoll (ToProtocol) der Teilnehmerverbindung in das Feld 'x-aux-protocol' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS2-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-protocol' der eingehenden Back-End-Integrationsnachricht zur Ermittlung des Absenderprotokolls (FromProtocol) der Teilnehmerverbindung verwendet.
x-aux-protocol-version Wenn ein Community-Teilnehmer eine AS2-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird die Empfängerprotokollversion (ToProtocolVersion) der Teilnehmerverbindung in das Feld 'x-aux-protocol-version' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS2-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-protocol-version' der eingehenden Back-End-Integrationsnachricht als Absenderprotokollversion (FromProtocolVersion) der Teilnehmerverbindung verwendet.
x-aux-process-type Wenn ein Community-Teilnehmer eine AS2-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird der Empfängerprozesscode (ToProcessCode) der Teilnehmerverbindung zum Festlegen des Felds 'x-aux-process-type' der Back-End-Integrationsnachricht verwendet, die an den Community Manager gesendet wird. Wenn eine AS2-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-process-type' der eingehenden Back-End-Integrationsnachricht als Absenderprozesscode (FromProcessCode) der Teilnehmerverbindung verwendet.
x-aux-process-version Wenn ein Community-Teilnehmer eine AS2-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird die Empfängerprozessversion (ToProcessVersion) der Teilnehmerverbindung in das Feld 'x-aux-process-version' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS2-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-process-version' der eingehenden Back-End-Integrationsnachricht als Absenderprozessversion (FromProcessVersion) der Teilnehmerverbindung verwendet.
x-aux-payload- root-tag Wenn ein Community-Teilnehmer eine AS2-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird, jedoch nur beim angepassten XML-Protokoll, der im XPATH angegebene Root-Tag aus der Nachricht herausgefiltert und im Feld 'x-aux-payload-root-tag' verwendet. Wenn eine AS2-Nachricht an einen Community-Teilnehmer ausgesendet wird, braucht dieses Feld in der eingehenden Back-End-Integrationsnachricht nicht festgelegt zu werden.
x-aux-process-instance-id Dieses wird für AS2 nicht verwendet.
x-aux-msg-id Wenn ein Community-Teilnehmer eine AS2-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird, jedoch nur beim angepassten XML-Protokoll, die im XPATH angegebene Doc-ID aus der Nachricht herausgefiltert und im Feld 'x-aux-payload-root-tag' verwendet. Wenn eine AS2-Nachricht an einen Community-Teilnehmer ausgesendet wird, braucht dieses Feld in der eingehenden Back-End-Integrationsnachricht nicht festgelegt zu werden.
x-aux-system-msg-id Wenn ein Community-Teilnehmer eine AS2-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird dieses Feld auf die intern generierte eindeutige Kennung (ID) für diese Nachricht gesetzt. Wenn eine AS2-Nachricht an einen Community-Teilnehmer ausgesendet wird, braucht dieses Feld in der eingehenden Back-End-Integrationsnachricht nicht festgelegt zu werden.
x-aux-production Dieses wird für AS2 nicht verwendet.

Header der Transportebene und eine AS1-Nachricht 

Tabelle 7 wird beschrieben, wo Business Integration Connect Werte für Felder im Header der Transportebene aus einer AS1-Nachricht abruft.

Anmerkung:
Die Werte sind von der Groß-/Kleinschreibung abhängig.

Tabelle 7. Felder des Headers der Transportebene aus AS1-Inhalt
Headerfeld Quelle des Werts
x-aux-sender-id Wenn ein Community-Teilnehmer eine AS1-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird die AbsenderID im Headerfeld "Subject: EmpfängerID;AbsenderID" der AS1-Nachricht in das Feld 'x-aux-sender-id' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS1-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-sender-id' der eingehenden Back-End-Integrationsnachricht als AbsenderID im Headerwert "Subject: EmpfängerID;AbsenderID" der AS1-Nachricht verwendet.
x-aux-receiver-id Wenn ein Community-Teilnehmer eine AS1-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird die EmpfängerID im Headerfeld "Subject: EmpfängerID;AbsenderID" der AS1-Nachricht in das Feld 'x-aux-receiver-id' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS1-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-receiver-id' der eingehenden Back-End-Integrationsnachricht als EmpfängerID im Headerwert "Subject: EmpfängerID;AbsenderID" der AS1-Nachricht verwendet.
x-aux-protocol Wenn ein Community-Teilnehmer eine AS1-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird das Empfängerprotokoll (ToProtocol) der Teilnehmerverbindung in das Feld 'x-aux-protocol' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS1-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-protocol' der eingehenden Back-End-Integrationsnachricht als Absenderprotokoll (FromProtocol) der Teilnehmerverbindung verwendet.
x-aux-protocol-version Wenn ein Community-Teilnehmer eine AS1-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird die Empfängerprotokollversion (ToProtocolVersion) der Teilnehmerverbindung in das Feld 'x-aux-protocol-version' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS1-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-protocol-version' der eingehenden Back-End-Integrationsnachricht als Absenderprotokollversion (FromProtocolVersion) der Teilnehmerverbindung verwendet.
x-aux-process-type Wenn ein Community-Teilnehmer eine AS1-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird der Empfängerprozesscode (ToProcessCode) der Teilnehmerverbindung in das Feld 'x-aux-process-type' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS1-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-process-type' der eingehenden Back-End-Integrationsnachricht als Absenderprozesscode (FromProcessCode) der Teilnehmerverbindung verwendet.
x-aux-process-version Wenn ein Community-Teilnehmer eine AS1-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird die Empfängerprozessversion (ToProcessVersion) der Teilnehmerverbindung in das Feld 'x-aux-process-version' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager gesendet wird. Wenn eine AS1-Nachricht an einen Community-Teilnehmer ausgesendet wird, wird das Feld 'x-aux-process-version' der eingehenden Back-End-Integrationsnachricht als Absenderprozessversion (FromProcessVersion) der Teilnehmerverbindung verwendet.
x-aux-payload- root-tag Wenn ein Community-Teilnehmer eine AS1-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird, jedoch nur beim angepassten XML-Protokoll, der im XPATH angegebene Root-Tag aus der Nachricht herausgefiltert und in das Feld 'x-aux-payload-root-tag' eingetragen. Wenn eine AS1-Nachricht an einen Community-Teilnehmer ausgesendet wird, braucht dieses Feld in der eingehenden Back-End-Integrationsnachricht nicht festgelegt zu werden.
x-aux-process-instance-id Dieses wird für AS1 nicht verwendet.
x-aux-msg-id Wenn ein Community-Teilnehmer eine AS1-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird, jedoch nur beim angepassten XML-Protokoll, die im XPATH angegebene Doc-ID aus der Nachricht herausgefiltert und im Feld 'x-aux-payload-root-tag' verwendet. Wenn eine AS1-Nachricht an einen Community-Teilnehmer ausgesendet wird, braucht dieses Feld in der eingehenden Back-End-Integrationsnachricht nicht festgelegt zu werden.
x-aux-system-msg-id Wenn ein Community-Teilnehmer eine AS1-Nachricht an Business Integration Connect Enterprise oder Advanced Edition sendet, wird dieses Feld auf die intern generierte eindeutige Kennung (ID) für diese Nachricht gesetzt. Wenn eine AS1-Nachricht an einen Community-Teilnehmer ausgesendet wird, braucht dieses Feld in der eingehenden Back-End-Integrationsnachricht nicht festgelegt zu werden.
x-aux-production Dieses wird für AS1 nicht verwendet.

Nutzinformationen

Die Nutzinformationen (payload) der Nachricht enthalten den eigentlichen Inhalt der Nachricht. Die Position der Nutzinformationen hängt vom Transportprotokoll ab, das die Nachricht sendet, wie Tabelle 8 zeigt.

Tabelle 8. Position der Nutzinformationen
Transportprotokoll Position der Nutzinformationen
HTTP-Protokollnachrichten Im Hauptteil der HTTP-Sendung
JMS-Protokollnachrichten Im Hauptteil der JMS-Nachricht
RosettaNet-Nachrichten Im Serviceinhalt (Service Content) aus dem PIP
Über AS2 gesendetes EDI-Dokument

Die EDI-Nachricht

Die Nutzinformationen werden nicht in eine XML-Hülle gepackt, sofern die Nachricht nicht auch mindestens einen Anhang besitzt. Informationen zur XML-Hülle und zu den Tags, die zur Umhüllung der Anhänge verwendet werden, finden Sie in Anhänge.

Die Nutzinformationen können Base64-codiert und in einer XML-Transporthülle enthalten sein, wenn einer der folgenden Fälle zutrifft:

Diese XML-Transporthülle umgibt das Dokument mit dem Root-Tag <transport-envelope>. Innerhalb dieses Root-Tags befindet sich ein <payload>-Tag, der die Nutzinformationen des Dokuments enthält. Wenn Anhänge vorhanden sind, ist jeder Anhang in einem <attachment>-Tag enthalten. Weitere Informationen zur Struktur dieser Tags finden Sie in Anhänge.

Business Integration Connect enthält die folgende W3C-XML-Schemadatei, in der die Struktur der XML-Transporthülle der Back-End-Integration beschrieben ist:

wbipackaging_v1.0_ns.xsd
 

Diese Schemadatei befindet sich im folgenden Verzeichnis auf dem Installationsdatenträger:

B2BIntegrate\packagingSchemas
 

Sie können ein beliebiges XML-Bearbeitungstool zur Überprüfung Ihres Back-End-Integrations-XMLs an dieser Schemadatei verwenden, um sicherzustellen, dass das Dokument gültig ist, bevor es an den Document Manager gesendet wird.

Anhänge

Sofern das Geschäftsnachrichtenprotokoll dies zulässt, kann jedes Dokument einen oder mehrere Anhänge haben. Wenn das Dokument Anhänge hat, muss es in eine XML-Transporthülle gepackt werden, wie in Nutzinformationen beschrieben. In Tabelle 9 werden die XML-Attribute in den payload- und attachment-Tags beschrieben.

Tabelle 9. XML-Attribute der payload- und attachment-Tags
XML-Attribut Beschreibung Erforderlich?
Content-Type Gibt den MIME-Typ/-Subtyp an, wie 'text/xml' oder 'image/gif'. Ja
Encoding Gibt die Codierung an. Da der Anhang und die Nutzinformationen in der Base64-Codierung vorliegen müssen, ist "Base64" der einzige gültige Wert für dieses Attribut. Nein

Abbildung 4 zeigt ein Beispiel für ein Dokument in einer XML-Transporthülle, das Nutzinformationen und einen Anhang enthält.

Anmerkung:
Der Namespace in diesem Beispiel ist erforderlich:
xmlns="http://www.ibm.com/websphere/bcg/2003/v1.0/wbipackaging"
 

Abbildung 4. Beispiel einer XML-Transporthülle für Nutzinformationen und einen Anhang

<?xml version="1.0" encoding="utf-8"?>
 <transport-envelope
     xmlns="http://www.ibm.com/websphere/bcg/2003/v1.0/wbipackaging">
 
  <payload encoding="base64" contentType="application/xml">
     ...Base64-codierte XML-Nachricht...
   </payload>
 
  <attachment encoding="base64" Content-Type="text/xml">
     ...Base64-codierter XML-Anhang...
   </attachment>
 
</transport-envelope>
 
Anmerkung:
Zur Verarbeitung von Dokumenten, die mit dem WebSphere InterChange Server in die XML-Transporthülle gepackt wurden, stellt Business Integration Connect die den Attachment-Data-Handler zur Verfügung. Weitere Informationen finden Sie in Dokumente mit Anhängen verarbeiten.

Welcher Pakettyp funktioniert mit Ihren Dokumenten?

Dokumente in bestimmten Geschäftsprotokollen können nur bestimmte Typen von Paketen verwenden. Zum Beispiel kann ein RosettaNet-Dokument nur verarbeitet werden, wenn der Pakettyp 'Back-End-Integration' angegeben wurde. Eine vollständige Liste darüber, welche Dokumenttypen welchen Pakettypen zugeordnet werden können, finden Sie in Tabelle 15 und Tabelle 20.

Beispiel für ein Back-End-Integrationspaket über HTTP

Abbildung 5 zeigt ein Beispiel einer Nachricht aus Business Integration Connect, die mit Hilfe des HTTP-Transportprotokolls an eine Anwendung gesendet wird. Beachten Sie, dass die Nachricht keinen Anhang enthält.

Abbildung 5. Beispielnachricht mit dem HTTP-Transportprotokoll

POST /sample/receive HTTP/1.1
 Host: sample. COM
 Content-Type: application/xml
 Content-Length: nnn 
 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: RNSC
 x-aux-protocol-version: 1.0
 x-aux-process-type: 3A4
 x-aux-process-version: V02.00
 x-aux-payload-root-tag: Pip3A4PurchaseOrderRequest
 x-aux-msg-id: 1021358129419
 x-aux-system-msg-id: 2
 x-aux-production: Production
 x-aux-process-instance-id: 123456
 x-aux-transport-retry-count: 0
 

<?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE Pip3A4PurchaseOrderRequest SYSTEM
      "3A4PurchaseOrderRequestMessageGuideline_v1_2.dtd">
 <Pip3A4PurchaseOrderRequest>
 

   <PurchaseOrder>
       ...
    </PurchaseOrder>
       ... 
 

   <thisDocumentIdentifier>
       <ProprietaryDocumentIdentifier>1021358129419
       </ProprietaryDocumentIdentifier>
    </thisDocumentIdentifier>
    <GlobalDocumentFunctionCode>Request</GlobalDocumentFunctionCode>
 

</Pip3A4PurchaseOrderRequest>
 

Welches Nachrichtentransportprotokoll soll verwendet werden?

Wenn das Back-End-System und WebSphere Business Integration Connect einander Nachrichten senden, müssen beide Seiten das gleiche Nachrichtentransportprotokoll verwenden. Das Nachrichtentransportprotokoll definiert das Kommunikationsprotokoll, in dem die Nachrichten gesendet werden.

Business Integration Connect kommuniziert mit einem Back-End-System über die zuhörige Back-End-Integrationsschnittstelle. In Tabelle 10 sind die Transportprotokolle aufgeführt, die von dieser Back-End-Integrationsschnittstelle unterstützt werden.

Tabelle 10. Von Business Integration Connect unterstützte Transportprotokolle
Transportprotokoll Weitere Informationen in
HTTP oder HTTPS HTTP-Transportprotokoll
Dateisystemdateien Dateisystemprotokoll für Enterprise und Advanced Edition
JMS JMS-Protokoll

In Tabelle 15 und Tabelle 20 finden Sie Informationen darüber, welche Transportprotokolle für eine bestimmte Kombination aus Nachrichteninhalt und Back-End-Integrationspaket gültig sind.

HTTP-Transportprotokoll

Zum Senden von Nachrichten mit einem HTTP-Protokoll verwendet Business Integration Connect das Protokoll HTTP/S 1.1. Zum Empfangen von Nachrichten aus Back-End-Systemen unterstützt Business Integration Connect die beiden HTTP/S-Versionen 1.0 und 1.1.

Die HTTP-Nachricht kann die Attribute des Integrationspakets enthalten. Ob diese Attribute enthalten sind, hängt wie folgt vom Pakettyp ab, der der Teilnehmerverbindung zugeordnet ist:

Ablauf

Wenn HTTP- oder HTTPS-Nachrichten zwischen Business Integration Connect und einer Anwendung zum asynchronen Austausch hin- und hergesendet werden, erfolgt dies in folgenden Schritten:

  1. Das Quellensystem (Business Integration Connect oder das Back-End-System) übergibt eine HTTP-Nachricht an das Zielsystem unter Angabe einer spezifischen URL-Adresse.
  2. Das Zielsystem empfängt die Nachricht und sendet die Empfangsbestätigung der Protokollebene, HTTP 200 oder 202, um die Änderung des Eigentumsrechts zu signalisieren. Das Quellensystem ignoriert den Hauptteil dieser Empfangsbestätigungsnachricht. Wenn während dieser Verarbeitung ein Fehler auftritt, sendet das Zielsystem eine Nachricht HTTP 500 zurück an das Quellensystem.
  3. Wenn Business Integration Connect das Zielsystem ist (d. h., wenn Business Integration Connect eine Nachricht empfängt), nimmt es die Nachricht auf und gibt die Verbindung zum Quellensystem frei.
  4. Das Zielsystem kann dann die Nachricht asynchron verarbeiten.

Wenn der Austausch synchron erfolgt (z. B. bei einem SOAP- oder cXML-Dokument), wird zusammen mit der Nachricht HTTP 200 eine Antwort in derselben HTTP-Verbindung zurückgegeben.

Nachrichten mit dem HTTP-Protokoll senden und empfangen

Zum Senden einer Nachricht an Business Integration Connect über das HTTP-Protokoll führt ein Back-End-System die folgenden Schritte aus:

  1. Es erstellt die Nachricht.

    Das Attribut 'Content-Type' im Header der Transportebene gibt die Codierung an, die für die Nachricht verwendet wird.

  2. Es packt die Nachricht entsprechend dem Pakettyp, der für die Verbindung festgelegt ist.

    Für das Back-End-Integrationspaket fügt das Back-End-System die Attribute des Protokollheaders hinzu, die für Business Integration Connect erforderlich sind.

  3. Es übergibt die Nachricht an die URL-Adresse, die von Business Integration Connect zum Empfang solcher Nachrichten verwendet wird.
  4. Wenn der Austausch synchron stattfindet, wartet das Back-End-System auf den Empfang einer Antwort über dieselbe Verbindung, die für die Anforderung verwendet wurde.

Zur Aktivierung des HTTP-Nachrichtenaustauschs in dieser Richtung verwenden Sie die Anzeige 'Zieldetails' der Community Console, um ein Ziel für eingehende Dokumente zu definieren. Weitere Informationen finden Sie in Dokumente vom Back-End-System empfangen.

Zum Empfang einer Nachricht von Business Integration Connect über das HTTP-Protokoll führt ein Back-End-System die folgenden Schritte aus:

  1. Es ist für eine Nachricht unter einer bestimmten URL-Adresse empfangsbereit.
  2. Wenn eine Nachricht empfangen wird, verarbeitet es die Nachricht:
  3. Wenn der Austausch synchron stattfindet, gibt das Back-End-System eine Antwort über dieselbe Verbindung zurück, die für die Anforderung verwendet wurde.

Zur Aktivierung des HTTP-Nachrichtenaustauschs in dieser Richtung verwenden Sie die Anzeige 'Gateway' der Community Console, um ein Gateway für ausgehende Dokumente zu definieren. Weitere Informationen finden Sie in Dokumente an das Back-End-System senden.

JMS-Protokoll

Das JMS-Protokoll basiert auf dem Java Message Service (JMS) und übermittelt Nachrichten über transaktionsorientierte, persistente JMS-Warteschlangen, die zum Beispiel von IBM WebSphere MQ bereitgestellt werden. Das JMS-Protokoll unterstützt die folgenden JMS-Nachrichtentypen:

Beim JMS-Protokoll sendet das sendende System eine JMS-Nachricht an das empfangende System unter Verwendung einer Enqueue-Operation. Das empfangende System erhält die Nachricht aus der Warteschlange, nimmt die Nachricht auf und führt anschließend die Dequeue-Operation aus, um die Nachricht aus der Warteschlange zu entfernen. Von diesem Zeitpunkt an kann das empfangende System die Nachricht asynchron verarbeiten.

Die JMS-Nachricht kann Attribute des Integrationspakets enthalten. Ob diese Attribute enthalten sind, hängt wie folgt vom Pakettyp ab, der der Teilnehmerverbindung zugeordnet ist:

Mit Ausnahme von Binärnachrichten unterstützt Business Integration Connect das Senden und Empfangen von JMS-Nachrichten mit beiden Pakettypen. Binärnachrichten, die aus einer Anwendung empfangen werden, müssen das Back-End-Integrationspaket verwenden. Dies gilt umgekehrt jedoch nicht, da Business Integration Connect das Senden binärer Nachrichten an die Anwendung mit beiden Pakettypen unterstützt.

Nachrichten mit dem JMS-Protokoll senden

Zum Senden einer Nachricht an Business Integration Connect über das JMS-Protokoll führt ein Back-End-System die folgenden Schritte aus:

  1. Es erstellt die Nachricht.

    Das Headerattribut content_type legt den Inhaltstyp für die Nachricht fest, und das Headerattribut content_length gibt die Länge der Nachricht (in Byte) an.

  2. Es packt die Nachricht entsprechend dem Pakettyp, der für die Verbindung festgelegt ist.

    Für das Back-End-Integrationspaket fügt die Anwendung die erforderlichen JMS-Headerattribute hinzu.

  3. Es sendet die Nachricht an die JMS-Warteschlange, die vom Back-End-System zum Senden von Nachrichten an Business Integration Connect verwendet wird.

Zur Aktivierung des JMS-Nachrichtenaustauschs in dieser Richtung verwenden Sie die Anzeige 'Zieldetails' der Community Console, um ein Ziel für eingehende Dokumente zu definieren. Weitere Informationen finden Sie in Dokumente vom Back-End-System empfangen.

Nachrichten mit dem JMS-Protokoll empfangen

Zum Empfang einer Nachricht von Business Integration Connect über das JMS-Protokoll führt ein Back-End-System die folgenden Schritte aus:

  1. Es ist für eine Nachricht in der JMS-Warteschlange empfangsbereit.
  2. Wenn eine Nachricht empfangen wird, verarbeitet es die Nachricht:

Zur Aktivierung des JMS-Nachrichtenaustauschs in dieser Richtung verwenden Sie die Anzeige 'Gateway' der Community Console, um ein Gateway für ausgehende Dokumente zu definieren. Weitere Informationen finden Sie in Dokumente an das Back-End-System senden.

Dateisystemprotokoll für Enterprise und Advanced Edition

Über das Dateisystemprotokoll kann Business Integration Connect Nachrichten senden, indem es sie in eine definierte Verzeichnisstruktur platziert. Business Integration Connect empfängt Nachrichten, indem es sie aus der Verzeichnisstruktur liest. Das Dateisystemprotokoll unterstützt folgende Merkmale:

Nachrichten mit dem Dateisystemprotokoll senden

Zum Senden einer Nachricht an Business Integration Connect mit dem Dateisystemprotokoll sollte eine Anwendung die folgenden Schritte ausführen:

  1. Sie sollte die Nachrichtendatei in einem temporären Verzeichnis erstellen.
  2. Wenn die Datei bereit ist, sollte sie die Datei in das Verzeichnis versetzen, das von Business Integration Connect regelmäßig abgefragt wird.

Zur Aktivierung des Nachrichtenaustauschs über ein Dateisystem in dieser Richtung verwenden Sie die Anzeige 'Zieldetails' der Community Console, um ein Ziel für eingehende Dokumente zu definieren. Das Ziel der Nachricht bestimmt das Verzeichnis, das von Business Integration Connect abgefragt wird. Wenn Sie ein Ziel erstellen, erstellt Business Integration Connect ein Verzeichnis 'Documents' und zugehörige Unterverzeichnisse für das Ziel wie folgt:

<dokumentstammverzeichnis>
     Documents
         Production
         Test
       <andere zieltypen>
 

Business Integration Connect fragt die Verzeichnisse 'Documents' und die zugehörigen Unterverzeichnisse regelmäßig ab, um Nachrichtendateien zu erkennen. Wenn eine Nachricht gefunden wird, nimmt Business Integration Connect die Nachricht auf und löscht die Nachrichtendatei aus dem Verzeichnis. Anschließend verarbeitet Business Integration Connect die Nachricht in üblicher Weise. Informationen zur Erstellung eines Ziels finden Sie im Handbuch Hub-Konfiguration.

Nachrichten mit dem Dateisystemprotokoll empfangen

Zum Empfangen von Nachrichten mit dem Dateisystemprotokoll sollte eine Anwendung folgende Schritte ausführen:

  1. Sie sollte das entsprechende Verzeichnis regelmäßig auf Nachrichtendateien überprüfen.
    Anmerkung:
    Temporäre Dateien (d. h. solche mit den Erweiterungen .tmp oder .tmp1) sollten ignoriert werden. Die Anwendung darf solche temporären Dateien auf keinen Fall aufnehmen oder löschen.
  2. Wenn eine Nachricht vorhanden ist, muss die Anwendung diese aufnehmen.
  3. Sie sollte die Nachricht aus dem Verzeichnis löschen.
  4. Sie sollte die Nachricht verarbeiten.

Zur Aktivierung des Nachrichtenaustauschs über ein Dateisystem in dieser Richtung verwenden Sie die Anzeige 'Gateway' der Community Console, um ein Gateway für ausgehende Dokumente zu definieren. Business Integration Connect platziert die Nachrichtendatei in das Verzeichnis 'Documents', das vom Gateway definiert wird. Durch die Definition des Zielverzeichnisses über das Gateway kann jede Teilnehmerverbindung ein anderes Verzeichnis haben. Informationen zu Gateways finden Sie im Handbuch Hub-Konfiguration.

Wie greifen Sie auf Ihre Back-End-Anwendung zu?

Business Integration Connect bietet die Möglichkeit der Integration mit vielen verschiedenen Back-End-Anwendungen. In der Regel erfolgt der Zugriff auf eine Back-End-Anwendung über ein Back-End-System, wie zum Beispiel einen Integrationsbroker. Die Integration mit Hilfe der in Tabelle 11 aufgelisteten Back-End-Systeme wird in diesem Handbuch behandelt.

Tabelle 11. Unterstützte Back-End-Systeme für Business Integration Connect
Back-End-System Weitere Informationen in
WebSphere InterChange Server Einführung in die InterChange Server-Integration
WebSphere Business Integration Message Broker Mit WebSphere Business Integration Message Broker integrieren
WebSphere Data Interchange Mit WebSphere Data Interchange integrieren

Copyright IBM Corp. 1997, 2004