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.
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.
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.
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.
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.
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
Pakete sind bestimmten Protokollen zugeordnet. Ein Teilnehmer muss z. B. ein RNIF-Paket angeben, wenn er ein RosettaNet-Dokument an den Hub sendet.
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.
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.
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.
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.
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.
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.
Die folgenden Protokolle werden vom System bereitgestellt:
Das Protokoll Binary kann mit den Paketen AS, None und Backend Integration verwendet werden. Ein binäres Dokument enthält keine Daten über die Quelle oder das Ziel des Dokuments.
Diese EDI-Protokolle können mit den Paketen AS oder None verwendet werden. Wie in N/A beschrieben, geben Sie das Paket N/A an, falls die EDI-Transaktion oder der EDI-Austausch vom Hub stammt bzw. dort endet. X12 und EDIFACT sind EDI-Standards, die für den Austausch von Daten verwendet werden. EDI-Consent bezieht sich auf andere Inhaltstypen als X12 oder EDIFACT.
Anforderungen des Protokolls Web Service können nur mit dem Paket None verwendet werden.
cXML-Dokumente können nur mit dem Paket None verwendet werden.
XMLEvent ist ein besonderes Protokoll, mit dem Ereignisbenachrichtigungen für Dokumente bereitgestellt werden, die von und zur Back-End-Anwendung fließen. Es kann nur mit dem Paket Backend Integration verwendet werden. Dieses Protokoll wird im Handbuch Unternehmensintegration beschrieben.
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.
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.
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.