Outbound Enabler

Der Outbound Enabler wird auf demselben Computer wie der Backend-Server ausgeführt. Er hat folgenden Zweck:

Öffnen einer abgehenden Verbindung zu der Relay Server-Farm, die in der DMZ ausgeführt wird, vom Computer im Unternehmens-LAN aus.
Weitergabe von Clientanforderungen vom Relay Server an den Backend-Server und Weitergabe von Antworten des Backend-Servers an den Client über den Relay Server.

Wenn der Outbound Enabler startet, stellt er eine HTTP-Anforderung, um die Liste der in der Farm laufenden Relay Server abzurufen. Hierzu wird der Server-URL verwendet, der der Webserver-Erweiterungskomponente des Relay Servers zugeordnet ist. Der Server-URL kann direkt einem Relay Server oder einem Lastverteiler zugeordnet werden. Wenn der Server-URL einem Lastverteiler zugeordnet wird, leitet der Lastverteiler die Anforderung an einen der Relay Server weiter, die in der Farm ausgeführt werden. Der Relay Server, der die Anforderung vom Outbound Enabler empfängt, gibt die Verbindungsinformationen für alle Relay Server in der Farm zurück. Der Outbound Enabler erstellt dann zwei abgehende Verbindungen, so genannte Kanäle, für jeden zurückgegebenen Relay Server. Ein Kanal, der so genannte Up-Kanal, wird während einer HTTP-Anforderung mit einer grundsätzlich endlosen Antwort erstellt. Die Antwort ist ein kontinuierlicher Datenstrom von Clientanforderungen vom Relay Server an den Outbound Enabler. Der zweite Kanal, der so genannte Down-Kanal, wird mithilfe einer HTTP-Anforderung mit einer grundsätzlich endlosen Länge des Inhalts erstellt. Die Anforderung besteht aus einem kontinuierlichen Datenstrom von Serverantworten an Clientanforderungen.

Wenn der Outbound Enabler eine Clientanforderung auf dem Up-Kanal von einem der verbundenen Relay Server empfängt, gibt er sie an den Backend-Server weiter, den der Outbound Enabler bedient. Wenn eine Antwort vom Backend-Server empfangen wurde, wird sie auf dem Down-Kanal an den Relay Server weitergeleitet, von dem die betreffende Anforderung empfangen wurde.

Hinweis

Die folgenden Backend-Server werden für die Verwendung mit dem Relay Server unterstützt:

Afaria
Mobile Office
MobiLink
Mobile Office
SQL Anywhere
Unwired Server
Sybase Unwired Platform

Weitere Informationen dazu, welche Backend-Server unterstützt werden, finden Sie in der Lizenzvereinbarung oder auf der Seite mit den SQL Anywhere-Komponenten nach Plattform. Siehe [external link] http://www.sybase.com/detail?id=1061806 .

Outbound Enabler-Syntax

rsoe [ option ]+

rsoe @{ filename | environment-variable } ...

Parameter

Optionen Die folgenden Optionen können für den Outbound Enabler verwendet werden. Optionen, die Standardwerte enthalten, sind optional. Als Minimum muss der Outbound Enabler die Verbindungszeichenfolge für den Relay Server (-cr), die Farm (-f) und den Servernamen (-id) übergeben. Wenn ein Sicherheitstoken konfiguriert ist, muss dieses ebenfalls angegeben werden (-t).

rsoe-Optionen Beschreibung

@data

Liest Optionen aus der angegebenen Umgebungsvariablen oder Konfigurationsdatei. Wenn Sie Kennwörter oder andere Informationen in einer Konfigurationsdatei schützen möchten, können Sie das Dienstprogramm zum Verschleiern von Dateien verwenden. Siehe Dienstprogramm zum Verschleiern von Dateien (dbfhide).

-cr "connection-string"

Gibt die Relay Server-Verbindungszeichenfolge an. Das Format der Relay Server-Verbindungszeichenfolge ist eine durch Semikola getrennte Liste von Name-Wert-Paaren. Die Name-Wert-Paare bestehen aus Folgendem:

host IP-Adresse oder Hostname des Relay Servers. Der Standardwert ist localhost.
Siehe host.
port Der Port, an dem der Relay Server auf Daten wartet. Diese Angabe ist erforderlich.
Siehe port.
http_userid Benutzer-ID für die Authentifizierung. Optional. Sehen Sie in der Dokumentation für Ihren Webserver (oder Proxy) nach, wie Sie die HTTP-Authentifizierung einrichten.
Siehe http_userid.
http_password Kennwort für die Authentifizierung. Optional. Sehen Sie in der Dokumentation für Ihren Webserver (oder Proxy) nach, wie Sie die HTTP-Authentifizierung einrichten.
Siehe http_password.
http_proxy_userid Benutzer-ID für die Proxy-Authentifizierung. Optional. Sehen Sie in der Dokumentation für Ihren Webserver (oder Proxy) nach, wie Sie die HTTP-Authentifizierung einrichten.
Siehe http_proxy_userid.
http_proxy_password Kennwort für die Proxy-Authentifizierung. Optional. Sehen Sie in der Dokumentation für Ihren Webserver (oder Proxy) nach, wie Sie die HTTP-Authentifizierung einrichten.
Siehe http_proxy_password.
proxy_host Gibt den Hostnamen oder die IP-Adresse des Proxy-Servers an. Optional.
Siehe proxy_host.
proxy_port Legt die Portnummer des Proxyservers fest. Optional.
Siehe proxy_port.
url_suffix URL-Pfad zur Servererweiterung des Relay Servers. Erforderlich.
Standardmäßig erfordert der RSOE, dass url_suffix angegeben wird.

Siehe url_suffix.
https 0 – HTTP (Standard)
1 – HTTPS

Standardmäßig startet MobiLink das TCP/IP-Kommunikationsprotokoll. Beim Start von MobiLink für die Verwendung mit dem RSOE müssen Sie das für Ihre RSOE-Konfiguration erforderliche Kommunikationsprotokoll starten. Wenn Sie beispielsweise HTTPS als Backend-Server-Sicherheit angeben, muss MobiLink mit HTTPS gestartet werden. Siehe mlsrv12-Option -x.

Wenn der Parameter "https=1" in der Option -cs enthalten ist, wird der Standardport auf 443 geändert.

Für https=1 können auch folgende Optionen angegeben werden:

tls_type RSA oder ECC.
certificate_name Feld für den allgemeinen Namen des Zertifikats.
certificate_company Feld für den Organisationsnamen des Zertifikatausstellers.
certificate_unit Feld für die Organisationseinheit des Zertifikatausstellers.
identity Stellt die Anmeldedaten für eine gegenseitig authentifizierte TLS-Verbindung zwischen dem Outbound Enabler und dem Backend-Server bereit. Beachten Sie, dass die gegenseitige Authentifizierung für den Backend-Server erforderlich ist.
identity_password Stellt die Anmeldedaten für eine gegenseitig authentifizierte TLS-Verbindung zwischen dem Outbound Enabler und dem Backend-Server bereit. Beachten Sie, dass die gegenseitige Authentifizierung für den Backend-Server erforderlich ist.
fips "yes" oder "no".

trusted_certificates Eine Datei mit einer Liste von vertrauenswürdigen Stammzertifikaten.

Wenn der Backend-Server, und nur der Backend-Server, überprüft werden soll, setzen Sie diese Eigenschaft auf backend_server_public_cert_filename.

trusted_certificates=backend_server_public_cert_filename

Wenn unter Windows trusted_certificate nicht festgelegt ist, wird der Zertifikatsspeicher des Betriebssystems verwendet.

Siehe Netzwerkprotokolloptionen des MobiLink-Clients.

-cs "connection-string"

Legt den Host und den Port fest, die für die Verbindung zum Backend-Server verwendet werden. Der Standardwert ist "host=localhost;port=80".

Um periodische Backend-Serverstatusanforderungen zu aktivieren, fügen Sie der Option -cs den status_url-Parameter hinzu. Der Parameter status_url wird im Format status_url=/your-status-url angegeben.

Das folgende Beispiel zeigt, wie Sie status_url mit -cs angeben.

-cs "host=localhost;port=80;status_url=/getstatus/"

Verwenden Sie die Option -d, um die Frequenz der Backend-Serverstatusanforderungen festzulegen.

-d Sekunden

Gibt an, wie häufig Verfügbarkeit-Pings und Statusanforderungen an den Backend-Server gesendet werden. Der Standardwert beträgt 5 Sekunden.

-dl

Verwenden Sie diese Option, um Logmeldungen in der Relay Server Outbound Enabler-Konsole anzuzeigen. Standardmäßig werden Logmeldungen für die Ausführlichkeitsstufen 1 und 2 nicht angezeigt.

-f Farm

Gibt den Namen der Farm an, zu der dieser Backend-Server gehört.

-id ID

Gibt den dem Backend-Server zugewiesenen Namen an.

-oDatei

Gibt die Datei zur Protokollierung von Ausgabemeldungen an.

-oq

Verhindert, dass das Fehlerfenster angezeigt wird, falls beim Start ein Fehler auftritt.

-os

Setzt die Maximalgröße der Meldungslogdateien. Die minimale Größenbegrenzung beträgt 10 kB.

-ot

Kürzt die Logdatei und schreibt anschließend Meldungen hinein.

-q

Bewirkt die Ausführung beim Start in einem minimierten Fenster.

-qc

Schließt das Fenster nach Abschluss des Vorgangs.

-s

Stoppt den Outbound Enabler.

-t token

Gibt den Sicherheitstoken an, der an den Relay Server übergeben werden muss.

-uc

Startet den RSOE im Shell-Modus. Dies ist die Standardeinstellung. Gilt für Unix und Mac OS X.

Sie können nur jeweils eine der Optionen -uc, -ui, -um oder -ux angeben. Wenn Sie die Option -uc angeben, wird der RSOE auf dieselbe Weise gestartet wie bei früheren Versionen der Software.

-ud

Weist den RSOE an, als Daemon abzulaufen. Diese Option gilt nur für UNIX-Plattformen.

-ui

Startet den RSOE im Shell-Modus, wenn keine verwendbare Anzeige verfügbar ist. Diese Option wird unter Linux mit X Window-Serverunterstützung verwendet.

Wenn die Option -ui angegeben ist, versucht der Server, eine verwendbare Anzeige zu finden. Wenn keine gefunden wird, z.B. weil der X Window-Server nicht läuft, startet der RSOE im Shell-Modus.

-ux

Unter Linux wird das Meldungsfenster des RSOE geöffnet, in dem Meldungen angezeigt werden.

Wenn die Option -ux angegeben ist, muss der RSOE in der Lage sein, eine verwendbare Anzeige zu finden. Wenn er keine findet, weil z.B. die DISPLAY-Umgebungsvariable nicht eingestellt ist oder der X Window-Server nicht läuft, schlägt der Start des RSOE fehl.

Um das Meldungsfenster des RSOE im dialogfreien Modus auszuführen, verwenden Sie -q.

Unter Windows erscheint das Meldungsfenster des RSOE automatisch.

-v Stufe

Legt die Ausführlichkeitsstufe für die Protokollierung fest. Die Stufe kann 0, 1, 2 oder höher sein (wobei höhere Stufen hauptsächlich vom technischen Kundendienst verwendet werden):

0 Nur Fehler protokollieren. Verwenden Sie diese Protokollierungsstufe für das Deployment.
1 Protokollierung auf Sitzungsebene. Dies ist eine Ansicht einer Synchronisationssitzung von einer höheren Ebene.
2 Protokollierung auf Anforderungsebene. Bietet eine detailliertere Ansicht der HTTP-Anforderungen.
3 oder höher Ausführliche Protokollierung. Wird in erster Linie für den technischen Kundendienst verwendet.

Die Stufen 1 und 2 werden nur die in die Logdatei geschrieben und nicht angezeigt. Um alle Logmeldungen anzuzeigen, verwenden Sie den Parameter -dl.

Dienstprogramm zum Verschleiern von Dateien (dbfhide)

Syntax

dbfhide original-configuration-file encrypted-configuration-file

Option	Beschreibung
original-configuration-file	Gibt den Namen der Originaldatei an.
encrypted-configuration-file	Gibt einen Namen für die neue verschleierte Datei an.

Der Relay Server und der Outbound Enabler erkennen, dass eine Konfigurationsdatei mithilfe von dbfhide verschleiert wurde, und verarbeiten sie.

Dieses Dienstprogramm akzeptiert nicht den @data-Parameter zum Einlesen von Optionen aus einer Konfigurationsdatei.

Integrierter Outbound Enabler (empfohlen für MobiLink)

Mit dem neuen oe-Protokoll für die Option -x für mlsrv12 können Sie einen integrierten Outbound Enabler anstelle der Standalone-Version des Outbound Enablers verwenden, die mit dem rsoe-Befehl aufgerufen wird. Der integrierte Outbound Enabler bietet folgende Vorteile:

Verminderte Verwendung von Systemressourcen, vor allem Sockets.
Bereitstellung einer einzelnen, integrierten Logdatei. Zeilen, die aus dem integrierten Outbound Enabler in das Log des MobiLink-Servers ausgegeben wurden, haben das Präfix <OE>.
Deployment wird vereinfacht.
Verfügbarkeitsprüfungen zwischen den Outbound Enabler und dem MobiLink-Server entfallen.

Weitere Hinweise zur Verwendung des integrierten Outbound Enablers finden Sie unter mlsrv12-Option -x.

Deployment-Hinweise

Beachten Sie bei der Verwendung des Outbound Enablers folgende Überlegungen:

Outbound Enabler als Dienst Der Outbound Enabler kann mithilfe des Dienstprogramms für Dienste als Dienst eingerichtet und verwaltet werden.
Authentifizierung Sie können keine einfache oder Digest-Authentifizierung verwenden. Die Programmdatei rsoe.exe unterstützt keine einfache oder Digest-Authentifizierung mit Webservern, unabhängig vom Webservertyp oder dem Betriebssystem.

Siehe auch

Outbound Enabler als Dienst

Kommentieren Sie diese Seite in DocCommentXchange.