Gateways verwalten die Transportinformationen, die für die korrekte Weiterleitung von Dokumenten zu ihrem Ziel innerhalb der Hub-Community sorgen. Das ausgehende Transportprotokoll legt fest, welche Informationen während der Gatewaykonfiguration verwendet werden. Informationen zum Erstellen von Gateways finden Sie im Handbuch Hub-Konfiguration.
Führen Sie die folgenden Schritte aus, um Gateways anzuzeigen und zu bearbeiten:
Sie können den Gateway auch löschen, indem Sie auf Löschen
klicken.
Tabelle 4. Anzeige "Gateway-Details"
Parameter | Beschreibung |
---|---|
Gateway-Name
|
Name des Gateways. Anmerkung: Der Gateway-Name ist ein benutzerdefiniertes Feld mit
freiem Format. Zwar ist die Eindeutigkeit der Namen nicht zwingend
erforderlich, der Benutzer sollte aber unterschiedliche Namen für die
einzelnen Gateways verwenden, um potenzielle Unklarheiten zu vermeiden.
|
Status
|
Gibt an, ob der Gateway aktiviert oder inaktiviert ist. Falls er
inaktiviert ist, schlägt die Verarbeitung von Dokumenten fehl, die über diesen
Gateway geleitet werden.
|
Online / Offline
|
Gibt an, ob der Gateway online oder offline ist. Falls er offline
ist, werden die Dokumente in eine Warteschlange gestellt, bis der Gateway in
den Onlinestatus gesetzt wird.
|
Beschreibung
|
Optionale Beschreibung des Gateways.
|
Gateway-Konfiguration
|
|
Transport
|
Protokoll für die Weiterleitung von Dokumenten (siehe "Erforderliche Daten für die Gatewaykonfiguration").
|
Ziel-URI
|
Uniform Resource Identifier (URI) des Teilnehmers.
|
Benutzername
|
Benutzername für sicheren Zugriff durch die Teilnehmer-Firewall.
|
Kennwort
|
Kennwort für sicheren Zugriff durch die Teilnehmer-Firewall.
|
Wiederholungszahl
|
Maximale Anzahl der Versuche des Systems, ein Dokument zu senden, bevor
dieser Vorgang fehlschlägt. Der Standardwert ist 3.
|
Wiederholungsintervall
|
Anzahl der Sekunden, die das System anhält, bevor es erneut versucht, ein
Dokument zu senden, das zuvor nicht erfolgreich gesendet werden konnte.
Der Standardwert ist 300 (5 Minuten).
|
Anzahl Threads
|
Anzahl Threads, die für die Weiterleitung eines Dokuments zugeordnet
wurden. Der Standardwert ist 3. Dieser Parameter steht
ausschließlich den Hubadmin-Benutzern zur Verfügung.
|
Client-IP prüfen
|
Prüft die IP-Adresse des sendenden Partners, bevor das Dokument verarbeitet
wird.
|
Client-SSL-Zertifikat prüfen
|
Prüft und vergleicht das digitale Zertifikat des sendenden Partners mit der
DUNS-Nummer, die dem Dokument zugeordnet ist, bevor das Dokument verarbeitet
wird.
|
Autom. Warteschlange
|
Wenn aktiviert, werden Dokumente in ein temporäres Depot gestellt, wenn der
Gateway gerade offline ist. Wenn inaktiviert und der Gateway gerade
offline ist, wird das Dokument nicht weitergeleitet und ein Fehler tritt
auf.
|
Authentifizierung erforderlich
|
Wenn aktiviert, werden Benutzername und Kennwort mit JMS- oder
SMTP-Nachrichten übermittelt.
|
JMS-Factory-Name
|
Name der Javaklasse, den der JMS-Provider verwendet, um eine Verbindung zu
der JMS-Warteschlange herzustellen.
|
JMS-Nachrichtenklasse
|
Die Nachrichtklasse.
|
JMS-Nachrichtentyp
|
Der Typ der JMS-Nachricht.
|
Provider-URL-Paket
|
Name von Klassen oder JAR-Dateien, mit denen Java die JMS-Kontext-URL
verstehen kann.
|
JMS-Warteschlangenname
|
Name der Warteschlange, in der JMS-Nachrichten gespeichert werden.
|
JMS-JNDI-Factory-Name
|
Factory-Name, mit dem die Verbindung zum Namensservice hergestellt
wird.
|
Verbindungszeitlimit
|
Anzahl der Sekunden, die ein Socket geöffnet bleibt, wenn kein Datenverkehr
auftritt. Der Standardwert ist 120 (2 Minuten).
|
Führen Sie die folgenden Schritte aus, um die für das System konfigurierten Standardgateways anzuzeigen und sie zu bearbeiten:
Wenn Sie einen Gateway nicht mehr benötigen, können Sie die folgende Prozedur ausführen, um ihn zu löschen. Es wird kein Warnhinweis angezeigt, bevor Sie eine Gatewaykonfiguration löschen. Stellen Sie daher sicher, dass Sie eine Gatewaykonfiguration nicht mehr benötigen, bevor Sie sie löschen.
Wenn Sie einen Transport nicht mehr benötigen, können Sie die folgende Prozedur ausführen, um ihn zu löschen.
Wenn die Zustellung eines Dokuments an einen Teilnehmergateway fehlschlägt, versucht Business Integration Connect erneut, das Dokument zuzustellen. Jeder wiederholte Versuch wird als Wiederholung (retry) bezeichnet. Die Wiederholungsfunktionalität ist auf zwei verschiedenen Ebenen in Business Integration Connect vorhanden: Transport und Gateway.
Transportwiederholungen sind integrierte Wiederholungen der unteren Ebene, die jedesmal angewendet werden, ungeachtet der Gatewayspezifikation. Der Grund für die Wiederholungen der unteren Ebene besteht darin, dass in den Netzwerken, über die die Zustellung versucht wird, vorübergehende Fehler auftreten, insbesondere im Internet. Daher ist das Zustellsystem so konzipiert, dass automatische Wiederholungen durchgeführt werden, ohne dass der Benutzer zur Definition der Wiederholungsparameter explizit aufgefordert wird. Die Anzahl der Transportwiederholungen (bcg.delivery.gwTransportMaxRetries) und das Zeitintervall zwischen den Wiederholungen (bcg.delivery.gwTransportRetryInterval) sind in der Dokumentverwaltungsdatei BCG.Properties definiert und gelten für alle Gateways. Als Standardwert sind drei Wiederholungen im Abstand von je drei Sekunden festgelegt.
Gatewaywiederholungsparameter (Anzahl der zulässigen Wiederholungen und Zeitintervall zwischen Wiederholungen) werden vom Benutzer in den Gatewaymerkmalen konfiguriert. Normalerweise ist das Wiederholungsintervall bedeutend länger, als die oben beschriebenen integrierten Transportwiederholungen. Dahinter steht die Absicht, dem Benutzer ausreichend Zeit zu lassen, das Problem zu beheben, welches die Zustellung verhindert. So kann z. B. der Ziel-Web-Server inaktiv sein, oder die Ziel-URL ist nicht korrekt. Das Einstellen der Parameterwerte erfordert die Einschätzung des Benutzers, was für jeden einzelnen Gateway sinnvoll sein könnte.
Business Integration Connect führt für jede (benutzerdefinierte) Gatewaywiederholung automatisch die Transportwiederholungen aus. Wenn z. B. drei Gatewaywiederholungen angegeben wurden, sieht das Wiederholungsmuster des Systems folgendermaßen aus:
Erster Versuch schlägt fehl
Gatewaywiederholung 1 schlägt fehl
Gatewaywiederholung 2 schlägt fehl
Gatewaywiederholung 3 schlägt fehl
Dokumentzustellung fehlgeschlagen
Jeder fehlgeschlagene Zustellversuch generiert ein Warnereignis, das in der Community Console zu sehen ist.
Der ausgewählte Transporttyp bestimmt die Daten, die für die Einrichtung des Gateways erforderlich sind. Die mit einem "X" markierten Felder erfordern Konfigurationsdaten, mit einem "O" markierte Felder sind optional.
Transport | HTTP | HTTPS | FTP | FTPS | JMS | Dateiverzeichnis | SMTP |
---|---|---|---|---|---|---|---|
Ziel-URI
|
X
|
X
|
X
|
X
|
|
X
|
X
|
Benutzername
|
O
|
O
| O | O |
O
|
O
|
O
|
Kennwort
|
O
|
O
| O | O |
O
|
O
|
O
|
Wiederholungszahl
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
Wiederholungsintervall
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
Anzahl Threads
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
Client-IP prüfen
|
O
|
O
|
O
| O |
|
|
|
Client-SSL-Zertifikat prüfen
|
|
O
|
|
|
|
|
|
Autom. Warteschlange
|
O
|
O
|
O
| O |
O
|
|
O
|
Authentifizierung erforderlich
|
|
|
|
|
O
|
|
O
|
JMS-Factory-Name
|
|
|
|
|
X
|
|
|
JMS-Nachrichtenklasse
|
|
|
|
|
X
|
|
|
JMS-Nachrichtentyp
|
|
|
|
| O |
|
|
Provider-URL-Paket
|
|
|
|
| O |
|
|
JMS-Warteschlangenname
|
|
|
|
|
X
|
|
|
JMS-JNDI-Factory-Name
|
|
|
|
|
X
|
|
|
Verbindungszeitlimit
|
X
|
X
|
X
|
|
|
|
|
Anmerkungen: