Für die Hubkonfiguration benötigte Informationen

Sie benötigen einige Informationen über die Typen der Austauschvorgänge, an denen Community Manager teilnimmt, um den Hub zu konfigurieren. Sie benötigen z. B. die folgenden Informationen:

Wenn Sie diese Informationen ermittelt haben, können Sie mit der Konfiguration des Hubs beginnen.

Nachdem Sie den Hub definiert haben, können Sie Ihre Teilnehmer mit den Informationen, wie z. B. IP-Adresse und DUNS-Nummern, definieren, die Sie von den Teilnehmern erhalten haben. Wie zuvor angemerkt, definieren Sie auch Community Manager als einen speziellen Typ von Hubteilnehmer.

Übersicht über Transporte

Dokumente können von Teilnehmern an WebSphere Partner Gateway (den Hub) über eine Vielzahl von Transporten gesendet werden. Ein Teilnehmer kann Dokumente über öffentliche Netze unter Verwendung von HTTP, HTTPS, JMS, FTP, FTPS, FTP-Scripting, SMTP oder ein Dateiverzeichnis senden. Ein Teilnehmer kann Dokumente unter Verwendung des FTP-Scripting-Transports über VAN (Value Added Network - Mehrwertnetz), einem privaten Netz, senden. Sie können auch Ihren eigenen Transport erstellen.

Anmerkung: Wenn der Transport Dateiverzeichnis zwischen einem Teilnehmer und dem Hub verwendet wird, sollte sich der Administrator um alle sicherheitsrelevanten Themen kümmern.

Ebenso sendet der Hub Dokumente an Back-End-Anwendungen über eine Vielzahl von Transporten. Die am meisten verwendeten Transporte zwischen dem Hub und Back-End-Anwendungen sind HTTP, HTTPS, JMS und Dateiverzeichnis.

Abb. 2 zeigt die verschiedenen Transporte, die verwendet werden können.

Abbildung 2. Transporte, die von WebSphere Partner Gateway unterstützt werden
Diese Abbildung zeigt die Transporte, die im vorangegangen Abschnitt aufgelistet wurden, welche zwischen dem Teilnehmer und dem Hub und zwischen dem Hub und dem Community Manager-Back-End-System verwendet werden können.

Der Transporttyp, mit dem Dokumente gesendet und empfangen werden, beeinflusst das Einrichten von Zielen und Gateways. Ein Ziel ist ein Einstiegspunkt in den Hub. Es ist der Ort, an dem Dokumente, die von Teilnehmern oder Back-End-Anwendungen gesendet wurden, auf dem Hub empfangen werden. Ein Gateway ist ein Einstiegspunkt in den Computer des Teilnehmers oder des Back-End-Systems. Es ist der Ort, an den der Hub Dokumente sendet. Sie müssen einiges an Konfigurationsarbeit leisten, wie in Die Konfiguration des Hubs vorbereiten beschrieben, um die Verwendung der Transporte FTP, FTPS, FTP-Scripting, JMS und Dateiverzeichnis vorzubereiten.

Übersicht über Dokumentenflussdefinitionen

Wenn Sie den Austausch von Dokumenten zwischen den Teilnehmern und Community Manager definieren, geben Sie mehrere Dinge bezüglich des Dokuments an:

Das Paket des Dokuments, das Protokoll des Dokuments und der Dokumentenfluss bilden gemeinsam die Dokumentenflussdefinition. Die Dokumentenflussdefinition gibt dem Hub Informationen darüber, wie das Dokument zu verarbeiten ist. Angenommen, Sie verwenden z. B. die folgende vom System bereitgestellte Dokumentenflussdefintion:

Der Hub extrahiert die AS-Headerinformationen (und verwendet sie, um die Quelle und das Ziel des Dokuments zu ermitteln). Er weiß, an welcher Stelle im Dokument er bestimmte Informationen, aufgrund ihrer Position im Dokument, findet. Den drei Teilen der Dokumentenflussdefinition sind Attribute zugeordnet. Sie können die vom System bereitgestellten Attribute ändern bzw. ihnen etwas hinzufügen.

Paket

Das Paket stellt Informationen bereit, die die Übertragung des Dokuments betreffen. Wie im vorherigen Abschnitt erwähnt, verwendet der Hub im Falle eines AS-Pakets die Informationen im AS-Header, um die Quelle und das Ziel für das Dokument zu ermitteln. Wenn ein Teilnehmer einen RosettaNet-PIP (PIP - Partner Interface Process) an Community Manager sendet, wird der PIP als RNIF gepackt.

Abb. 3 zeigt die Pakettypen, die für Dokumente festgelegt werden können, die zwischen dem Hub und einem Community-Teilnehmer und zwischen dem Hub und einer Back-End-Anwendung ausgetauscht werden

Abbildung 3. Pakettypen für Dokumente
Diese Abbildung zeigt Pakete RNIF, AS und None zwischen dem Teilnehmer und dem Hub verwendet werden und dass die Pakete Backend Integration und None zwischen dem Hub und dem Community Manager-Back-End-System verwendet werden.

Pakete sind bestimmten Protokollen zugeordnet. Ein Teilnehmer muss z. B. ein RNIF-Paket angeben, wenn er ein RosettaNet-Dokument an den Hub sendet.

Backend Integration

Wie in Abbildung Abb. 3 gezeigt wird, ist Backend Integration nur zwischen dem Hub und der Back-End-Anwendung verfügbar. Wenn Sie das Paket Backend Integration angeben, werden Dokumenten, die vom Hub an das Back-End-System gesendet werden, bestimmte Headerinformationen hinzugefügt. Ebenso muss eine Back-End-Anwendung Headerinformationen hinzufügen, wenn sie Dokumente mit dem Paket Backend Integration an den Hub sendet. Das Paket Backend Integration und die Anforderungen an die Headerinformationen werden im Handbuch Unternehmensintegration beschrieben.

AS

Das Paket AS ist nur zwischen Teilnehmern und dem Hub verfügbar. Das Paket AS kann für Dokumente verwendet werden, die mit den Standards AS1 oder AS2 konform sind. AS1 ist ein Standard, der für das sichere Übertragen von Dokumenten über SMTP verwendet wird, und AS2 ist ein Standard, der für das sichere Übertragen von von Dokumenten über HTTP oder HTTPS verwendet wird. Dokumente, die von einem Teilnehmer mit dem Paket AS gesendet wurden, haben entweder AS1- oder AS2-Headerinformationen. An einen Teilnehmer gesendete Dokumente, der AS1- oder AS2-Header erwartet, müssen (auf dem Hub) als Paket AS gepackt werden.

None

Das Paket None kann verwendet werden, um Dokumente zwischen dem Hub und Teilnehmern sowie zwischen dem Hub und einer Back-End-Anwendung zu senden und zu empfangen. Es werden keine Headerinformationen hinzugefügt (oder erwartet), wenn ein Dokument als Paket None gepackt wird.

RNIF

Das Paket RNIF wird auf dem Installationsdatenträger bereitgestellt. Sie laden das Paket RNIF (zusammmen mit den PIPs, die Sie austauschen wollen) wie in RosettaNet-Dokumente beschrieben hoch. Das Paket RNIF wird verwendet, um RosettaNet-Dokumente vom Teilnehmer an den Hub bzw. vom Hub an den Teilnehmer zu senden.

N/A

Einige Dokumentenflüsse enden entweder in WebSphere Partner Gateway oder sie stammen intern von WebSphere Partner Gateway. Für Dokumentenflüsse, die in WebSphere Partner Gateway enden, ist kein Paket erforderlich. Dokumen- tenflüsse, die intern von WebSphere Partner Gateway stammen, verfügen über kein Quellenpaket. Deshalb wird für solche Dokumentenflüsse das Paket N/A angegeben.

Bei den meisten Übertragungen in einer Richtung zwischen dem Teilnehmer und Community Manager (oder umgekehrt) empfängt WebSphere Partner Gateway ein Dokument von einem Teilnehmer und sendet es an Community Manager. Wenn Sie in WebSphere Partner Gateway die Teilnehmerverbindung erstellen, geben Sie das Paket an, in dem WebSphere Partner Gateway das Dokument empfangen wird, sowie das Paket, das WebSphere Partner Gateway verwenden wird, um das Dokument zu senden. In Abb. 4 fließt ein als AS gepacktes Dokument von einem Teilnehmer zur Community Manager-Back-End-Anwendung. Das Dokument wird dem Community Manager-Gateway ohne Transportheader übermittelt. In Abb. 4 ist dem Austausch von Dokumenten eine Aktion zugeordnet.

Abbildung 4. Typische Einwegverbindung
Diese Abbildung zeigt, wie ein Dokument von einem Teilnehmer durch den Hub und zum Gateway fließt, das für Community Manager definiert ist.

Bestimmte Protokolle beziehen jedoch mehrere Aktivitäten mit ein, wie z. B. Umschlagsentfernung und Transformation, einige dieser Aktivitäten stellen Zwischenschritte im Gesamtaustausch dar. Wenn z. B. ein Teilnehmer einen EDI-Austausch an den Hub mit Community Manager als Endziel sendet, wird der Umschlag des Austauschs entfernt und die einzelnen EDI-Transaktionen werden verarbeitet. Dem ursprünglichen EDI-Austausch ist ein Paket zugeordnet, wenn er vom Teilnehmer gesendet wird. Da jedoch der Austausch selbst Community Manager nicht übermittelt wird (sein Umschlag wird im Hub entfernt und keine weitere Verarbeitung des Austauschs erfolgt), wird der Austausch nicht gepackt. Wenn Sie die Interaktion für den Schritt zum Entfernen des Umschlags definieren, geben Sie daher ein Paket für die Sendeseite ein, aber für die Empfangsseite geben Sie N/A an.

Der Prozess für das Definieren der Dokumentenflussdefinitionen, die für einen EDI-Austausch erforderlich sind, wird in EDI-Dokumentenflüsse konfigurieren beschrieben.

Protokolle

Die folgenden Protokolle werden vom System bereitgestellt:

Wenn Sie die Pakete RNIF hochladen, erhalten Sie außerdem die zugeordneten Protokolle (RosettaNet und RNSC). RosettaNet ist das zwischen dem Teilnehmer und dem Hub verwendete Protokoll. Es wird dem Paket RNIF zugeordnet. RNSC ist das zwischen dem Hub und der Community Manager-Back-End-Anwendung verwendete Protokoll. Es wird dem Paket Backend Integration zugeordnet.

Für EDI-Transaktionen bzw. XML- oder ROD-Dokumente, die transformiert werden, importieren Sie eine Transformationszuordnung vom Data Interchange Services-Client. Im Data Interchange Services-Client werden Wörterbücher für das Protokoll definiert, das dieser Transformation zugeordnet ist. Ein Wörterbuch enthält Informationen zu allen EDI-Dokumentdefinitionen, EDI-Segmenten, zusammengesetzten EDI-Datenelementen und EDI-Datenelementen, die den EDI-Standard ausmachen. Detaillierte Informationen zu einem bestimmten EDI-Standard finden Sie in den entsprechenden Handbüchern der jeweiligen EDI-Standards. Informationen zum Data Interchange Services-Client finden Sie im Mapping Guide oder in der Onlinehilfe, die mit dem Data Interchange Services-Client bereitgestellt wird.

Anmerkung: Die Sender- und Empfänger-IDs müssen Teil der ROD-Dokumentdefinition sein, die der Transformationszuordnung zugeordnet ist. Die Informationen, die zum Ermitteln des Dokumenttyps und der Wörterbuchwerte nötig sind, müssen ebenso in der Dokumentdefinition vorhanden sein. Stellen Sie sicher, dass der Zuordnungsexperte des Data Interchange Services-Clients diese Anforderungen kennt, wenn er die Transformationszuordnung erstellt.

Sie können angepasste Protokolle erstellen, um genau zu definieren, wie ein Dokument strukturiert sein soll. Bei XML-Dokumenten können Sie ein XML-Format definieren, wie in Angepasste XML-Dokumente beschrieben.

Dokumentenfluss

Das Dokument selbst kann in einer Vielzahl von Formaten vorliegen. Es gibt die folgenden vom System bereitgestellten Dokumentenflüsse und ihnen zugeordneten Protokolle:

Die folgende Liste beschreibt weitere Dokumenttypen und die Quelle ihrer Definition:

Sie können ebenfalls Ihre eigenen Dokumentenflüsse erstellen, wie in Angepasste XML-Dokumente beschrieben.

Copyright IBM Corp. 2003, 2005