CentraSite Documentation : Runtime Governance with CentraSite : Run-Time Governance Reference : Built-In Run-Time Actions Reference for APIs : Run-Time Actions Reference : 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 chosen 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 will not be 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 will be available again to send the request.
Input Parameters
Route To
URI. Mandatory. Enter the URLs of two or more endpoints in a pool to which the requests will be 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 chosen 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 will use the Message Transmission Optimization Mechanism (MTOM) to parse SOAP requests to the API.
SwA
Mediator will use the SOAP with Attachment (SwA) technique to parse SOAP requests to the API.
None
Default. Mediator will 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 will be 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 will timeout. If a value 0 is specified (or if the value is not specified), Mediator will use 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 will timeout. If a value 0 is specified (or if the value is not specified), Mediator will use 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 will use 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 will occur.
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 will use these properties to specify the following fields:
Value
Description
Client Certificate Alias
Mandatory. The client's private key to be used for performing SSL client authentication.
IS Keystore Alias
Mandatory. The keystore alias of the instance of Integration Server on which Mediator is running. This value (along with the value of Client Certificate Alias) will be 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). Note that Mediator will not 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/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).
Copyright © 2005-2015 Software AG, Darmstadt, Germany.
Product LogoContact Support   |   Community   |   Feedback