Zu verwendender Pakettyp
Der Pakettyp bestimmt das Format, in dem die Nachricht von WebSphere Partner Gateway an das
Back-End-System gesendet wird. Außerdem wird durch den Pakettyp das Format angegeben, in dem das Back-End-System die Nachricht an WebSphere Partner Gateway sendet.
Über die Community Console können Sie die Verbindung mit Ihren Community-Teilnehmern einrichten
und den Pakettyp angeben, der zwischen WebSphere Partner Gateway und dem Back-End-System verwendet wird.
Welcher Pakettyp dabei zu verwenden ist, hängt von folgenden Gesichtspunkten ab:
- Welche Pakettypen sind für die Verwendung bei einem Back-End-System zulässig?
- Welche Pakettypen sind für eine Nachricht in einem bestimmten Geschäftsprotokoll zulässig?
Weitere Informationen zur Einrichtung von Partnerverbindungen finden Sie im Handbuch Hub-Konfiguration.
Nicht alle Pakettypen sind gültig, wenn Sie WebSphere Partner Gateway zur Integration
verwenden. In Tabelle 4 sind alle Pakettypen aufgelistet, die relevant sind, wenn WebSphere Partner Gateway Dokumente oder Nachrichten mit einer Back-End-Anwendung des Community Managers austauscht.
Tabelle 4. Relevante Pakettypen zur Back-End-Integration
Pakettyp |
Beschreibung |
Kein
Paket |
Weist das System an, die Nachricht ohne Headerdaten an das Back-End-System oder den Hub zu senden. |
Back-End-Integrationspaket |
Fügt dem Nachrichtenheader zusätzliche Attribute hinzu und fügt (optional)
den Nachrichteninhalt in einen XML-Transportumschlag ein. |
Anmerkung: Mit WebSphere Partner Gateway stehen auch andere Pakettypen (wie AS) 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 WebSphere Partner Gateway 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
WebSphere Partner Gateway die reine Nachricht an das Back-End-System. Informationen innerhalb des
Dokuments steuern das Routing.
Back-End-Integrationspaket
Wenn der Pakettyp 'Back-End-Integrationspaket' verwendet wird, enthalten Nachrichten, die an ein
Back-End-System gesendet oder von diesem empfangen werden, folgende Komponenten:
- Header der Transportebene,
der Metainformationen zur Nachricht enthält (erforderlich)
- Nutzinformationen, die
den eigentlichen Nachrichteninhalt enthalten (erforderlich)
- Anhang (optional)
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 WebSphere
Partner Gateway zur Verarbeitung und zum Routing der Nachricht an die korrekte Zieladresse verwendet werden.
Der
Header der Transportebene ist bidirektional, so dass alle Nachrichten, die von WebSphere Partner Gateway empfangen bzw. gesendet
werden, über die verbindlichen Felder und alle relevanten optionalen Felder verfügen.
In Tabelle 5 sind die Felder des Headers der Transportebene
aufgelistet.
Tabelle 5. 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 WebSphere Partner Gateway hat der Wert in diesem Feld Vorrang vor allen Protokollfeldern 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 WebSphere Partner Gateway hat der
Wert in diesem Feld Vorrang vor allen Prozessfeldern 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. 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 |
Routing der Nachricht. Gültige Werte: Production
und 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,
WebSphere Partner Gateway 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. Für einen
3A4-RosettaNet-Service-Content wäre der Wert dieses Felds zum Beispiel
'Pip3A4PurchaseOrderRequest'. Bei Ereignisbenachrichtigungen 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 wiederholter 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 WebSphere Partner Gateway 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. |
|
x-out-file-name |
Der ursprüngliche Dateiname von Nachrichten, die über JMS gesendet werden und für die der Pakettyp 'Back-End-Integrationspaket' verwendet wird. (Vgl. hierzu Anmerkung 2.) |
|
content-type |
Der Inhaltstyp der Nachricht. |
|
content-length |
Die Länge der Nachricht (in Byte). |
|
Anmerkungen:
- Aus Gründen der Kompatibilität mit IBM WebSphere MQ (ein JMS-Provider) werden in
den Feldern einer Nachricht des JMS-Protokolls Unterstreichungszeichen an Stelle von
Silbentrennungsstrichen verwendet. In einer JMS-Nachricht gibt es zum Beispiel ein
Feld 'x_aux_sender_id' anstatt eines Felds 'x-aux-sender-id'.
-
Wenn als Ziel 'HTTP' und als Paket als 'Kein Paket' angegeben ist, wird der ursprüngliche Dateiname in den HTTP-Headern als "Content-Disposition: attachment;po.xml" angegeben.
Wenn als Ziel 'JMS' und als Pakettyp 'Back-End-Integration' angegeben ist, wird der ursprüngliche Dateiname als
'x-out-file-name' zu den anderen 'x-aux-*'-Headern hinzugefügt.
Tabelle 5 enthält eine Übersicht zu den Headerinformationen
der Transportebene. Die folgenden Abschnitte enthalten Informationen zu Headern der Transportebene, die speziell für bestimmte Geschäftsprotokolle gelten:
In Tabelle 6 wird beschrieben, wo
WebSphere Partner Gateway Werte für die Felder des Headers der Transportebene aus einer
RosettaNet-Nachricht abruft.
Tabelle 6. 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> |
In Tabelle 7 wird beschrieben, wo WebSphere Partner Gateway
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 7. Felder des Headers der Transportebene aus AS2-Inhalt
Headerfeld |
Quelle des Werts, wenn ein Community-Teilnehmer eine
AS/2-Nachricht an den Hub sendet: |
Quelle des Werts, wenn eine AS2-Nachricht an einen Community-Teilnehmer gesendet wird: |
x-aux-sender-id |
Das AS2-Headerfeld für den Absender (From) wird in das Feld
'x-aux-sender-id' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager
gesendet wird. |
Das Feld 'x-aux-sender-id' der eingehenden Back-End-Integrationsnachricht wird
als AS2-Headerwert für den Absender der AS2-Nachricht verwendet. |
x-aux-receiver-id |
Das AS2-Headerfeld für den Empfänger (To) wird in das Feld
'x-aux-receiver-id' der Back-End-Integrationsnachricht eingetragen, die an den Community Manager
gesendet wird. |
Das Feld 'x-aux-receiver-id' der eingehenden Back-End-Integrationsnachricht wird
als AS2-Headerwert für den Empfänger der AS2-Nachricht verwendet. |
x-aux-protocol |
Das Empfängerprotokoll (ToProtocol) der
Teilnehmerverbindung wird in das Feld 'x-aux-protocol' der Back-End-Integrationsnachricht eingetragen,
die an den Community Manager gesendet wird. |
Das Feld 'x-aux-protocol' der eingehenden Back-End-Integrationsnachricht wird zur
Ermittlung des Absenderprotokolls (FromProtocol) der Teilnehmerverbindung verwendet. |
x-aux-protocol-version |
Die Version des Empfängerprotokolls (ToProtocolVersion) der
Teilnehmerverbindung wird in das Feld 'x-aux-protocol-version' der Back-End-Integrationsnachricht eingetragen,
die an den Community Manager gesendet wird. |
Das Feld 'x-aux-protocol-version' der eingehenden Back-End-Integrationsnachricht wird
als Wert für die Version des Empfängerprotokolls der Teilnehmerverbindung verwendet. |
x-aux-process-type |
Die Prozesscode des Empfängers (ToProcessCode) der
Teilnehmerverbindung wird in das Feld 'x-aux-process-type' der Back-End-Integrationsnachricht eingetragen,
die an den Community Manager gesendet wird. |
Das Feld 'x-aux-process-type' der eingehenden Back-End-Integrationsnachricht wird
als Wert für den Prozesscode des Absenders (FromProcessCode) der Teilnehmerverbindung verwendet. |
x-aux-process-version |
Die Version des Empfängerprozesses (ToProcessVersion) der
Teilnehmerverbindung wird in das Feld 'x-aux-process-version' der Back-End-Integrationsnachricht eingetragen,
die an den Community Manager gesendet wird. |
Das Feld 'x-aux-process-version' der eingehenden Back-End-Integrationsnachricht wird
als Wert für die Version des Empfängerprozesses (ToProcessVersion) der Teilnehmerverbindung verwendet. |
x-aux-payload- root-tag |
Nur beim angepassten XML-Protokoll wird der im
XPATH angegebene Root-Tag aus der Nachricht herausgefiltert und im Feld 'x-aux-payload-root-tag'
verwendet. |
Bei eingehenden Back-End-Integrationsnachrichten muss für dieses Feld kein Wert angegeben werden. |
x-aux-process-instance-id |
Dieses wird für AS2 nicht verwendet. |
Dieses wird für AS2 nicht verwendet. |
x-aux-msg-id |
Nur beim angepassten XML-Protokoll wird die in
XPATH angegebene Doc-ID aus der Nachricht herausgefiltert und im Feld 'x-aux-msg-id'
verwendet. |
Bei eingehenden Back-End-Integrationsnachrichten muss für dieses Feld kein Wert angegeben werden. |
x-aux-system-msg-id |
Dieses Feld wird auf die intern generierte eindeutige
Kennung (ID) für diese Nachricht gesetzt. |
Bei eingehenden Back-End-Integrationsnachrichten muss für dieses Feld kein Wert angegeben werden. |
x-aux-production |
Dieses wird für AS2 nicht verwendet. |
Dieses wird für AS2 nicht verwendet. |
In Tabelle 8 wird beschrieben, wo WebSphere Partner Gateway
Werte für die Felder des Headers der Transportebene aus einer AS1-Nachricht abruft.
Anmerkung: Die Werte sind von der Groß-/Kleinschreibung abhängig.
Tabelle 8. Felder des Headers der Transportebene aus AS1-Inhalt
Headerfeld |
Quelle des Werts, wenn ein Community-Teilnehmer eine
AS/1-Nachricht an den Hub sendet: |
Quelle des Werts, wenn eine AS/1-Nachricht an einen Community-Teilnehmer gesendet wird: |
x-aux-sender-id |
Die AbsenderID im Headerfeld
"Subject: EmpfängerID;AbsenderID" der AS1-Nachricht
wird in das Feld 'x-aux-sender-id' der Back-End-Integrationsnachricht eingetragen, die an den Community
Manager gesendet wird. |
Das Feld 'x-aux-sender-id' der eingehenden Back-End-Integrationsnachricht wird als
AbsenderID im Headerwert "Subject:
EmpfängerID;AbsenderID" der AS1-Nachricht
verwendet. |
x-aux-receiver-id |
Die EmpfängerID im Headerfeld
"Subject: EmpfängerID;AbsenderID" der AS1-Nachricht
wird in das Feld 'x-aux-receiver-id' der Back-End-Integrationsnachricht eingetragen, die an den
Community Manager gesendet wird. |
Das Feld 'x-aux-receiver-id' der eingehenden Back-End-Integrationsnachricht wird als
EmpfängerID im Headerwert "Subject:
EmpfängerID;AbsenderID" der AS1-Nachricht
verwendet. |
x-aux-protocol |
Das Empfängerprotokoll (ToProtocol) der
Teilnehmerverbindung wird in das Feld 'x-aux-protocol' der Back-End-Integrationsnachricht eingetragen,
die an den Community Manager gesendet wird. |
Das Feld 'x-aux-protocol' der eingehenden Back-End-Integrationsnachricht wird als
Wert des Absenderprotokolls (FromProtocol) der Teilnehmerverbindung verwendet. |
x-aux-protocol-version |
Die Version des Empfängerprotokolls (ToProtocolVersion) der
Teilnehmerverbindung wird in das Feld 'x-aux-protocol-version' der Back-End-Integrationsnachricht eingetragen,
die an den Community Manager gesendet wird. |
Das Feld 'x-aux-protocol-version' der eingehenden Back-End-Integrationsnachricht wird
als Wert für die Version des Empfängerprotokolls der Teilnehmerverbindung verwendet. |
x-aux-process-type |
Die Prozesscode des Empfängers (ToProcessCode) der
Teilnehmerverbindung wird in das Feld 'x-aux-process-type' der Back-End-Integrationsnachricht eingetragen,
die an den Community Manager gesendet wird. |
Das Feld 'x-aux-process-type' der eingehenden Back-End-Integrationsnachricht wird
als Wert für den Prozesscode des Absenders (FromProcessCode) der Teilnehmerverbindung verwendet. |
x-aux-process-version |
Die Version des Empfängerprozesses (ToProcessVersion) der
Teilnehmerverbindung wird in das Feld 'x-aux-process-version' der Back-End-Integrationsnachricht eingetragen,
die an den Community Manager gesendet wird. |
Das Feld 'x-aux-process-version' der eingehenden Back-End-Integrationsnachricht wird
als Wert für die Version des Empfängerprozesses (ToProcessVersion) der Teilnehmerverbindung verwendet. |
x-aux-payload- root-tag |
Nur beim angepassten XML-Protokoll wird der im
XPATH angegebene Root-Tag aus der Nachricht herausgefiltert und im Feld 'x-aux-payload-root-tag'
festgelegt. |
Bei eingehenden Back-End-Integrationsnachrichten muss für dieses Feld kein Wert angegeben werden. |
x-aux-process-instance-id |
Dieses wird für AS1 nicht verwendet. |
Dieses wird für AS1 nicht verwendet. |
x-aux-msg-id |
Nur beim angepassten XML-Protokoll wird die in
XPATH angegebene Doc-ID aus der Nachricht herausgefiltert und im Feld 'x-aux-msg-id'
verwendet. |
Bei eingehenden Back-End-Integrationsnachrichten muss für dieses Feld kein Wert angegeben werden. |
x-aux-system-msg-id |
Dieses Feld wird auf die intern generierte eindeutige
Kennung (ID) für diese Nachricht gesetzt. |
Bei eingehenden Back-End-Integrationsnachrichten muss für dieses Feld kein Wert angegeben werden. |
x-aux-production |
Dieses wird für AS1 nicht verwendet. |
Dieses wird für AS1 nicht verwendet. |
Nutzinformationen
Die Nutzinformationen der Nachricht enthalten den eigentlichen Inhalt der
Nachricht. Die Position der Nutzinformationen hängt vom Transportprotokoll ab, mit dem die Nachricht gesendet wird, wie Sie in Tabelle 9 sehen.
Tabelle 9. Position der Nutzinformationen
Transportprotokoll |
Position der Nutzinformationen |
HTTP-Protokollnachrichten |
Hauptteil der HTTP-Sendung |
JMS-Protokollnachrichten |
Hauptteil der JMS-Nachricht |
RosettaNet-Nachrichten |
Service-Content aus dem PIP |
EDI |
EDI-Umschlag |
ROD- oder XML-Dokument |
ROD- oder XML-Dokument |
Wenn eine der beiden folgenden Bedingungen gilt, können die Nutzinformationen im Base64-Format codiert und in einem XML-Transportumschlag enthalten sein:
- Wenn das Dokument einen Anhang enthält
Ein Dokument mit Anhängen muss in einen XML-Transportumschlag eingefügt
werden. Weitere Informationen zur Formatierung von Anhängen finden Sie unter
Anhänge.
- Wenn Sie für die Umschlagsmarkierung für das Back-End-Integrationspaket 'Ja' angeben
Wenn ein Dokument unabhängig davon, ob es Anhängen enthält oder nicht, in einen
XML-Transportumschlag eingefügt werden soll, müssen Sie die Markierung für den
Back-End-Integrationsumschlag in der Anzeige für die B2B-Funktionalität des Profils auf 'Ja' setzen. Um diese Markierung z. B. im Profil des Community Managers zu definieren, müssen Sie die folgenden Arbeitsschritte ausführen:
- Klicken Sie auf Kontenadmin > Profile.
- Geben Sie den Namen des Community Managers ein (oder führen Sie eine Suchoperation für alle Teilnehmer aus).
- Klicken Sie auf das Symbol Details anzeigen neben dem Namen des Community Managers.
- Klicken Sie auf B2B-Funktionalitäten.
- Klicken Sie auf das Symbol Bearbeiten neben Back-End-Integration.
- Legen Sie für Umschlagsmarkierung die Einstellung Ja fest.
Dieser XML-Transportumschlag 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 unter Anhänge.
WebSphere Partner Gateway enthält die folgende W3C-XML-Schemadatei, in der die Struktur des
XML-Transportumschlags 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 enthält, muss es in einen XML-Transportumschlag eingefügt werden. Weitere Informationen hierzu finden Sie im Abschnitt Nutzinformationen. In Tabelle 10 werden die XML-Attribute in den Tags payload und
attachment beschrieben.
Tabelle 10. XML-Attribute der Tags payload und attachment
XML-Attribut |
Beschreibung |
Erforderlich? |
Content-Type |
Gibt den MIME-Typ/-Subtyp an, z. B. '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 |
Abb. 13 zeigt ein Beispiel für ein Dokument in einem
XML-Transportumschlag, 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 13. Beispiel eines XML-Transportumschlags 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">
...Im Base64-Format codierte XML-Nachricht...
</payload>
<attachment encoding="base64" Content-Type="text/xml">
...Im Base64-Format codierter XML-Anhang...
</attachment>
</transport-envelope>
Anmerkung: Zur Verarbeitung von Dokumenten, die mit WebSphere Interchange Server in den XML-Transportumschlag
eingefügt wurden, stellt WebSphere Partner Gateway den Attachment-Data-Handler zur Verfügung. Weitere Informationen finden Sie im Abschnitt
Dokumente mit Anhängen verarbeiten.
Welcher Pakettyp eignet sich für Ihre Dokumente?
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 12, Tabelle 13 und Tabelle 14.
Beispiel für ein Back-End-Integrationspaket über HTTP
Abb. 14 zeigt ein Beispiel einer Nachricht, die über das HTTP-Transportprotokoll von WebSphere Partner Gateway an eine Anwendung gesendet wird.
Beachten Sie, dass die Nachricht keinen Anhang enthält.
Abbildung 14. 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>
