Dieser Abschnitt enthält die folgenden Informationen zur Planung der Back-End-Integration mit WebSphere Business Integration Connect:
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:
Business Integration Connect kann Mitgliedern des Hubs die folgenden Web-Services zur Verfügung stellen:
Sie müssen Ihrem Community-Teilnehmer die öffentliche WSDL zur Verfügung stellen, die von Business Integration Connect 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. Business Integration Connect fungiert als Proxy. Es empfängt eine SOAP-Nachricht vom Teilnehmer und ermittelt den entsprechenden privaten Web-Service. Anschließend ruft es den privaten (vom Community Manager bereitgestellten) Web-Service mit Hilfe der gleichen 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. Business Integration Connect macht den Web-Service für den Community Manager über die Web-Service-URL-Adresse verfügbar, die in der Konsole beim Hochladen des Web-Service 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. Business Integration Connect fungiert als Proxy. Es empfängt eine SOAP-Nachricht vom Community Manager und ermittelt den entsprechenden Web-Service sowie 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, einschließlich darüber, wie Dokumentenflussdefinitionen für Web-Services eingerichtet werden, finden Sie im Handbuch Hub-Konfiguration.
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:
Weitere Informationen, einschließlich darüber, wie Dokumentenflussdefinitionen für cXML eingerichtet werden, finden Sie im Handbuch Verwaltung.
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.
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.
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:
|
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. |
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>
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.
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
|
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.
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.
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). |
|
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.
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.
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. |
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:
Ein Dokument mit Anhängen muss in eine XML-Transporthülle gepackt werden. Weitere Informationen zur Formatierung von Anhängen finden Sie in Anhänge.
Wenn ein Dokument unabhängig von etwaig enthaltenen Anhängen in eine XML-Transporthülle gepackt werden soll, setzen Sie die Markierung für die Back-End-Integrationshülle in der Anzeige der B2B-Funktionalität des Profils auf 'Ja'. Wählen Sie zum Beispiel Folgendes aus, um diese Markierung im Profil des Hub-Operators zu setzen:
Profil > Hub Operator > B2B-Funktionalität
Klicken Sie für Back-End-Integration auf Bearbeiten, um die Umhüllungsmarkierung zu sehen.
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.
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
Abbildung 4 zeigt ein Beispiel für ein Dokument in einer XML-Transporthülle, das Nutzinformationen und einen Anhang enthält.
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>
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.
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>
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.
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:
EDI, SOAP und cXML-Nachrichten müssen 'Kein Paket' verwenden.
RosettaNet-Nachrichten müssen das Back-End-Integrationspaket verwenden.
Wenn HTTP- oder HTTPS-Nachrichten zwischen Business Integration Connect und einer Anwendung zum asynchronen Austausch hin- und hergesendet werden, erfolgt dies in folgenden Schritten:
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.
Zum Senden einer Nachricht an Business Integration Connect über das HTTP-Protokoll führt ein Back-End-System die folgenden Schritte aus:
Das Attribut 'Content-Type' im Header der Transportebene gibt die Codierung an, die für die Nachricht verwendet wird.
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.
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:
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.
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.
Zum Senden einer Nachricht an Business Integration Connect über das JMS-Protokoll führt ein Back-End-System die folgenden Schritte aus:
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.
Für das Back-End-Integrationspaket fügt die Anwendung die erforderlichen JMS-Headerattribute hinzu.
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.
Zum Empfang einer Nachricht von Business Integration Connect über das JMS-Protokoll führt ein Back-End-System die folgenden Schritte aus:
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.
Ü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:
Zum Senden einer Nachricht an Business Integration Connect mit dem Dateisystemprotokoll sollte eine Anwendung die folgenden Schritte ausführen:
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.
Zum Empfangen von Nachrichten mit dem Dateisystemprotokoll sollte eine Anwendung folgende Schritte ausführen:
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.
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 |