The backend farm section specifies the properties of a backend server farm. A backend server farm is a group of homogeneous backend servers. A client making a request through the Relay Server farm must specify the backend server farm it is targeting. There is one backend farm section for each backend server farm.
This section is identified by the backend_farm keyword.
The following properties can be specified in a backend farm section:
active_cookie Specifies whether or not a cookie is set to retain client-server affinity.
yes This is the default setting. To maintain client-server session affinity, the Relay Server injects a standard HTTP set-cookie command with a proprietary cookie name in the response.
no An active cookie is not set. Use this option when the backend farm is serving a sessionless browser application. For example, when the backend farm is providing a sessionless SQL Anywhere web service.
For best results, set this control as follows:
Backend server type | active_cookie setting | active_header setting |
---|---|---|
MobiLink | no | yes |
SQL Anywhere | no | no |
For a MobiLink server back end, setting both active_cookie and active_header to yes should always work. However, setting both to yes may put redundant session information in every HTTP request/response in a session. To potentially save on cumulative on-the-wire byte charges, you may be able to set either active_cookie to no. You should test all network scenarios to make sure the chosen settings work in all cases.
active_header Specifies whether or not a header is set to maintain client-server session affinity.
yes This is the default setting. To maintain client-server session affinity, the Relay Server injects a proprietary header in the response in case intermediaries tamper with the active_cookie.
no A proprietary header is not set. Setting this option cuts down on traffic volume if the backend farm is serving only browser applications, or if the active_cookie is working well for all the clients of this backend farm.
renew_overlapped_cookie In the case where a client is sharing a standard cookie across multiple concurrent connections, timeout errors can occur. This issue appears in the Relay Server log.
yes (Default.) When renew_overlapped_cookie is set to yes, the Relay Server detects the cookie overlap for the farm that has this property explicitly turned on and renews the overlapping cookie by creating a new affinity binding. The request with the renewal is still routed to the same backend server, but not the same backend connection as the ongoing request that it overlaps with, but rather a new backend connection is created instead.
no This should be set to no if this behavior is not desired.
backend_security Specifies the level of security required of an Outbound Enabler in the backend server farm to connect to the Relay Server farm. The possible values are:
on Indicates that all connections from the backend farm must by made using HTTPS.
off Indicates that all connections from the backend farm must be made using HTTP.
This property is optional. If no value is specified, either HTTP or HTTPS can be used to connect.
client_security Specifies the level of security the backend server farm requires of its clients. The possible values are:
on Indicates that clients must connect using HTTPS.
off Indicates that clients must connect using HTTP.
This property is optional. If no value is specified, clients can connect using either HTTP or HTTPS.
description Enter a custom description to a maximum of 2048 characters. This property is optional.
enable Specifies whether to allow connections from this backend server farm. Possible values are:
Yes Allow connections from this backend server farm.
No Disallow connections from this backend server farm.
The default is Yes. This property is optional.
id The name assigned to the backend server farm, to a maximum of 2048 characters.
forward_x509_identity The SAP NetWeaver Gateway provides several means of authenticating clients, including X.509 certificate forwarding through trusted intermediaries. When this property is set to yes, Relay Server can extract forwarded client identity information from a trusted forwarder and forward it to the SAP NetWeaver Gateway or Web Dispatcher using HTTP headers. The default setting is no.
forwarder_certificate_issue In the case where a chain of SAP intermediaries exists, the client identity headers may already be present in the request. However, not all clients may be granted permission to act as forwarders. The default behavior, therefore, is to replace the existing headers with the identity of the forwarder. To grant permission for a forwarder to forward other client identities, you can set forwarder_certificate_issuer=match-string and forwarder_certificate_subject=match-string, where match-string is checked against a serialized form of the corresponding compound name field in the certificate. You can use ? to match any character and * to match any string. Use \ as the leading escape character for ?, *, or \ if they need to be matched literally.
For example:
forwarder_certificate_issuer = 'CN = quicksigner, OU = security department, O = my org, L = my city, S = my state, C = my country' |
forwarder_certificate_subject In the case where a chain of SAP intermediaries exists, the client identity headers may already be present in the request. However, not all clients may be granted permission to act as forwarders. The default behavior, therefore, is to replace the existing headers with the identity of the forwarder. To grant permission for a forwarder to forward other client identities, you can set forwarder_certificate_issuer=match-string and forwarder_certificate_subject=match-string, where match-string is checked against a serialized form of the corresponding compound name field in the certificate. You can use ? to match any character and * to match any string. Use \ as the leading escape character for ?, *, or \ if they need to be matched literally.
For example:
forwarder_certificate_subject = 'CN = mySapWD??.my.com, OU = Sybase, O = SAP, *' |
max_client_buffer On occasion, shared memory resources can become exhausted due to issues with excessive buffering of server responses, which can include large numbers of clients, slow-reading clients, or large HTTP responses. max_client_buffer = memory size, allows you to specify a limit on the memory buffer size for each client. The default value is 1 MB. The maximum value is 4 GB.
verbosity You can set verbosity to the following levels:
0 Log errors only. Use this logging level for deployment. This is the default.
1 Request logging. All HTTP requests are written to the log file.
2 Request logging. Provides a more detailed view of HTTP requests.
3 or higher Detailed logging. Used primarily for Technical Support.
Errors are displayed regardless of the log level specified, and warnings are displayed only if the log level is greater than 0.
![]() |
Discuss this page in DocCommentXchange.
|
Copyright © 2014, SAP AG or an SAP affiliate company. - SAP Sybase SQL Anywhere 16.0 |