Backend-Farm-Abschnitt

Der Backend-Farm-Abschnitt legt die Eigenschaften einer Backend-Serverfarm fest. Eine Backend-Serverfarm ist eine Gruppe von homogenen Backend-Servern. Ein Client, der eine Anforderung über die Relay Server-Farm stellt, muss die Backend-Serverfarm angeben, an die die Anforderung gerichtet ist. Für jede Backend-Serverfarm ist ein eigener Backend-Farm-Abschnitt vorhanden.

Dieser Abschnitt ist durch das Schlüsselwort backend_farm gekennzeichnet.

Eigenschaften im Backend-Farm-Abschnitt

Die folgenden Eigenschaften können in einem Backend-Farm-Abschnitt festgelegt werden:

active_cookie Gibt an, ob ein Cookie gesetzt ist, um die Client-Server-Affinität zu bewahren.

yes Dies ist die Standardeinstellung. Um die Client-Server-Affinität zu bewahren, fügt der Relay Server einen HTTP-Standardbefehl zum Setzen eines Cookies mit einem systemeigenen Cookie-Namen in die Antwort ein.
no Es ist kein aktives Cookie gesetzt. Verwenden Sie diese Option, wenn die Backend-Farm eine sitzungslose Browseranwendung bedient. Dies gilt beispielsweise, wenn die Backend-Farm einen sitzungslosen SQL Anywhere-Webdienst bereitstellt.

Um beste Ergebnisse zu erzielen, setzen Sie dieses Steuerelement wie folgt:

Backend-Servertyp	active_cookie-Einstellung	active_header-Einstellung
MobiLink	no	yes
SQL Anywhere	no	no

Bei einem Backend mit MobiLink-Server sollte es keine Probleme geben, wenn sowohl active_cookie als auch active_header auf "yes" gesetzt werden. Wenn beide auf "yes" gesetzt werden, können jedoch redundante Sitzungsinformationen in jede HTTP-Anforderung bzw. -Antwort in einer Sitzung eingefügt werden. Um kumulative Datenübertragungskosten potenziell zu sparen, können Sie möglicherweise active_cookie auf "no" setzen. Testen Sie alle Netzwerkszenarien, um sich zu vergewissern, ob die gewählten Einstellungen für die Anweisungen in allen Fällen funktionieren.

active_header Gibt an, ob ein Header gesetzt ist, um die Affinität der Client-Server-Sitzung zu bewahren.
- yes Dies ist die Standardeinstellung. Um die Client-Server-Sitzungsaffinität zu bewahren, fügt der Relay Server einen systemeigenen Header in die Antwort ein, falls Zwischenstationen den active_cookie-Wert manipulieren.
- no Es wird kein systemeigener Header gesetzt. Durch Aktivieren dieser Option können Sie das Verkehrsaufkommen verringern, wenn die Backend-Farm nur Browseranwendungen bedient oder wenn das aktive Cookie für alle Clients dieser Backend-Farm gut funktioniert.
renew_overlapped_cookie Wenn ein Clientgerät ein Standard-Cookie für mehrere gleichzeitige Verbindungen gemeinsam nutzt, können Timeout-Fehler auftreten. Dieses Problem wird im Relay Server-Log angezeigt.
- yes (Standardwert.) Wenn renew_overlapped_cookie auf "yes" gesetzt ist, erkennt Relay Server die Cookieüberlappung für die Farm, bei der diese Eigenschaft explizit aktiviert ist, und erneuert das überlappende Cookie durch Erstellen einer neuen Affinitätsbindung. Die Anforderung für die Erneuerung wird immer noch an denselben Backend-Server geleitet, aber nicht über dieselbe Backend-Verbindung wie die laufende Anforderung, mit der sie sich überlappt, sondern über eine neue Backend-Verbindung, die erstellt wird.
- no Diese Option muss auf "no" gesetzt werden, wenn dieses Verhalten nicht erwünscht ist.
backend_security Gibt die Sicherheitsstufe an, die von einem Outbound Enabler in der Backend-Serverfarm verlangt wird, um Verbindungen mit der Relay Server-Farm herzustellen. Die folgenden Werte können angegeben werden:
- on Gibt an, dass alle Verbindungen von der Backend-Farm mit HTTPS hergestellt werden müssen.
- off Gibt an, dass alle Verbindungen von der Backend-Farm mit HTTP hergestellt werden müssen.
Diese Eigenschaft ist optional. Wenn keine Werte angegeben sind, können HTTP oder HTTPS für die Verbindung benutzt werden.
client_security Gibt die Sicherheitsstufe an, die die Backend-Serverfarm von ihren Clients verlangen soll. Die folgenden Werte können angegeben werden:
- on Legt fest, dass Clients sich über HTTPS verbinden müssen.
- off Legt fest, dass Clients sich über HTTP verbinden müssen.
Diese Eigenschaft ist optional. Wenn kein Wert angegeben ist, können sich Clients über HTTP oder HTTPS verbinden.
description Geben Sie eine benutzerdefinierte Beschreibung mit einer maximalen Länge von 2048 Zeichen ein. Diese Eigenschaft ist optional.
enable Gibt an, ob Verbindungen von dieser Backend-Serverfarm zugelassen werden sollen. Die möglichen Werte sind:
- Ja Lässt Verbindungen von dieser Backend-Serverfarm zu.
- Nein Lässt keine Verbindungen von dieser Backend-Serverfarm zu.
Der Standardwert ist Yes. Diese Eigenschaft ist optional.
id Der Name, der der Backend-Serverfarm zugeordnet ist, maximal 2048 Zeichen lang.
forward_x509_identity Das SAP NetWeaver Gateway bietet mehrere Möglichkeiten zur Authentifizierung von Clients, einschließlich Weiterleitung des X.509-Zertifikats durch vertrauenswürdige Vermittler. Wenn diese Eigenschaft auf "yes" gesetzt ist, kann der Relay Server weitergeleitete Client-Identitätsinformationen von einem vertrauenswürdigen Vermittler extrahieren und mit HTTP-Headern an das SAP NetWeaver Gateway oder den Web Dispatcher weiterleiten. Die Standardeinstellung ist "no".

forwarder_certificate_issue Falls eine Kette von SAP-Vermittlern vorhanden ist, sind die Header für die Client-Identität möglicherweise bereits in der Anforderung enthalten. Möglicherweise wird jedoch nicht allen Clients die Berechtigung als Vermittler erteilt. Das Standardverhalten ist deshalb, dass die vorhandenen Header durch die Identität des Vermittlers ersetzt werden. Um die Berechtigung für einen Weiterleitenden zum Weiterleiten anderer Clientidentitäten zu erteilen, können Sie forwarder_certificate_issuer=match-string und forwarder_certificate_subject=match-string setzen, wobei match-string anhand einer serialisierten Form des entsprechenden kombinierten Namensfelds im Zertifikat geprüft wird. Sie können ein Fragezeichen (?) verwenden, um nach Übereinstimmungen für ein beliebiges Zeichen zu suchen, und ein Sternchen (*) für Übereinstimmungen mit einer beliebigen Zeichenfolge. Verwenden Sie "\" als führendes Escapezeichen für ?, * oder \, wenn Sie nach einer literalen Übereinstimmung suchen müssen.

Beispiel:

forwarder_certificate_issuer = 'CN = quicksigner, OU = security department, O = my org, L = my city, S = my state, C = my country'

forwarder_certificate_subject Falls eine Kette von SAP-Vermittlern vorhanden ist, sind die Header für die Client-Identität möglicherweise bereits in der Anforderung enthalten. Möglicherweise wird jedoch nicht allen Clients die Berechtigung als Vermittler erteilt. Das Standardverhalten ist deshalb, dass die vorhandenen Header durch die Identität des Vermittlers ersetzt werden. Um die Berechtigung für einen Weiterleitenden zum Weiterleiten anderer Clientidentitäten zu erteilen, können Sie forwarder_certificate_issuer=match-string und forwarder_certificate_subject=match-string setzen, wobei match-string anhand einer serialisierten Form des entsprechenden kombinierten Namensfelds im Zertifikat geprüft wird. Sie können ein Fragezeichen (?) verwenden, um nach Übereinstimmungen für ein beliebiges Zeichen zu suchen, und ein Sternchen (*) für Übereinstimmungen mit einer beliebigen Zeichenfolge. Verwenden Sie "\" als führendes Escapezeichen für ?, * oder \, wenn Sie nach einer literalen Übereinstimmung suchen müssen.

Beispiel:

forwarder_certificate_subject = 'CN = mySapWD??.my.com, OU = Sybase, O = SAP, *'

max_client_buffer Es kann vorkommen, dass Shared Memory-Ressourcen aufgrund von Problemen mit übermäßigem Puffern von Serverantworten erschöpft werden. Dies kann an einer großen Anzahl von Clients, langsamen Lesevorgängen der Clients oder großen HTTP-Antworten liegen. max_client_buffer = memory size erlaubt Ihnen, einen Höchstwert für die Speicherpuffergröße für jeden Client anzugeben. Der Standardwert ist 1 MB. Der Höchstwert ist 4 GB.
verbosity Sie können den Parameter verbosity auf folgende Stufen setzen:
- 0 Nur Fehler protokollieren. Verwenden Sie diese Protokollierungsstufe für das Deployment. Dies ist die Standardeinstellung.
- 1 Anforderungsprotokollierung. Alle HTTP-Anforderungen werden in die Logdatei geschrieben.
- 2 Anforderungsprotokollierung. Bietet eine detailliertere Ansicht der HTTP-Anforderungen.
- 3 oder höher Ausführliche Protokollierung. Dies wird in erster Linie für den technischen Support verwendet.
Fehler werden unabhängig von der Protokollstufe angezeigt, während Warnungen nur bei einer höheren Protokollstufe als 0 angezeigt werden.

Siehe auch

Kommentieren Sie diese Seite in DocCommentXchange.