Software AG Products 10.7 | Using CentraSite | Runtime Governance | Run-Time Policy Management | Built-In Run-Time Actions Reference (CentraSite Business UI) | Built-in Actions for Run-Time Policies (CentraSite Business UI) | Load Balancing and Failover Routing
 
Load Balancing and Failover Routing
If you have a native API that is hosted at two or more endpoints, you can use the Load Balancing and Failover Routing to distribute requests among the endpoints.
Requests are distributed across multiple endpoints. The requests are intelligently routed based on the round-robin execution strategy. The load for a service is balanced by directing requests to two or more services in a pool, until the optimum level is achieved. The application routes requests to services in the pool sequentially, starting from the first to the last service without considering the individual performance of the services. After the requests have been forwarded to all the services in the pool, the first service is selected for the next loop of forwarding.
Load-balanced endpoints also have automatic failover capability. If a load-balanced endpoint is unavailable (for example, if a connection is refused), then that endpoint is marked as down for the number of seconds you specify in the Timeout field (during which the endpoint is not used for sending the request), and the next configured endpoint is tried. If all the configured load-balanced endpoints are down, then a failure is sent back to the client. After the timeout expires, each endpoint marked is available again to send the request.
Input Parameters
Route To
(URI). Type the URLs of two or more endpoints in a pool to which the requests are routed. The application routes the requests to endpoints in the pool sequentially, starting from the first to the last endpoint without considering the individual performance of the endpoints. After the requests have been forwarded to all the endpoints in the pool, the first endpoint is selected for the next loop of forwarding.
Enter the URL of the endpoint to route the request to. For example:
http://mycontainer/creditCheckService
To specify additional endpoints, use the plus button next to the field to add rows.
Click the Configure Endpoint Properties icon (next to the field) if you want to configure a set of properties for the endpoints individually.
Alternatively, Mediator offers Local Optimization capability if the native API is hosted on the same Integration Server as Mediator. With local optimization, API invocation happens in-memory and not through a network hop.
local://<Service-full-path>
OR
local://<server>:<port>/ws/<Service-full-path>
For example:
local://MyAPIFolder:MyLocalAPI
which points to the endpoint API MyLocalAPI which is present under the folder MyAPIFolder in Integration Server.
Note:
Local Optimization is not applicable to REST based APIs.
Configure Endpoint Properties  (icon)
(Optional). This icon displays the Endpoint Properties dialog box that enables you to configure a set of properties for the Mediator to route incoming requests to the native API as follows:
SOAP Optimization Method
(Only for SOAP-based APIs). Mediator can use the following optimization methods to parse SOAP requests to the native API:
Value
Description
MTOM
Mediator uses the Message Transmission Optimization Mechanism (MTOM) to parse SOAP requests to the API.
SwA
Mediator uses the SOAP with Attachment (SwA) technique to parse SOAP requests to the API.
None
(Default). Mediator does not use any optimization method to parse the SOAP requests to the API.
Note:
Keep the following points in mind:
*Bridging between SwA and MTOM is not supported. If a client sends a SwA request, Mediator can only forward SwA to the native API. The same is true for MTOM, and applies to responses received from the native API. That is, a SwA or MTOM response received by Mediator from a native API is forwarded to the client using the same format it received.
*When sending SOAP requests that do not contain a MTOM or SWA attachment to a native API that returns an MTOM or SWA response, the request Accept' header must be set to multipart/related. This is necessary so Mediator knows how to parse the response properly.
HTTP Connection Timeout
(Number). (Optional). The time interval (in seconds) after which a connection attempt timeouts. If a value 0 is specified (or if the value is not specified), Mediator uses the value specified in the Connection Timeout field (in the Integration Server Administrator, go to Settings > Extended). Default: 30 seconds.
Read Timeout
(Number). (Optional). The time interval (in seconds) after which a socket read attempt timeouts. If a value 0 is specified (or if the value is not specified), Mediator uses the value specified in the Read Timeout field (in the Integration Server Administrator, go to > Settings > Extended.). Default: 30 seconds.
SSL Configuration
(Optional). To enable SSL client authentication that Mediator uses to authenticate incoming requests for the native API, you must specify values for both the Client Certificate Alias field and the IS Keystore Alias field. If you specify a value for only one of these fields, a deployment error occurs.
Note:
SSL client authentication is optional; you may leave both fields blank.
Prerequisite: You must set up the key alias and keystore properties in the Integration Server. For the procedure, see webMethods Integration Server Administrator’s Guide.
You uses these properties to specify the following fields:
Value
Description
Client Certificate Alias
The client's private key to be used for performing SSL client authentication.
IS Keystore Alias
The keystore alias of the instance of Integration Server on which Mediator is running. This value (along with the value of Client Certificate Alias) is used for performing SSL client authentication.
WS Security Header
(Only for SOAP-based APIs). Indicates whether Mediator should pass the WS-Security headers of the incoming requests to the native API.
Value
Description
Remove processed security headers
(Default). Removes the security header if it is processed by Mediator (that is, if Mediator processes the header according to the API's security run-time policy). Mediator does remove the security header if both of the following conditions are true: 1) Mediator did not process the security header, and 2) the mustUnderstand attribute of the security header is 0 or false).
Pass all security headers
Passes the security header, even if it is processed by Mediator (that is, even if Mediator processes the header according to the API's security action).