Consider a target operation group SG1 containing three target operations as
A,
B, and
C. The Core Engine routes the incoming facade operation requests (for example, Request 1-n) to the
SG1 target operation group based on the routing key. The Core Engine selects the target operation within the
SG1 target operation group based on the type of the target operation group, which are defined as follows:
If the target operation group type for the SG1 target operation group is defined as LoadBalanced
, the Core Engine uses the
LoadBalanced routing algorithm
. For the LoadBalanced
routing algorithm type, the Core Engine picks up a random target operation that is a part of this target operation group. The Core Engine distributes the requests evenly over a large number of requests.
When the Core Engine routes the client requests (Request 1-n) to SG1 target operation group with the LoadBalanced target operation group type, the target operation is selected as follows to process the client requests:
If the target operation group type for the SG1 target operation group is defined as RoundRobin
, the Core Engine uses the RoundRobin
routing algorithm
. For the RoundRobin
routing algorithm type, the Core Engine selects the target operation in a RoundRobin fashion. This means that the Core Engine rotates through the list of target operations one at a time to process the client requests.
Figure RoundRobin Routing illustrates the
SG1 target
operation group with RoundRobin type.
When the Core Engine routes the client requests to SG1 target operation group, the target operation from the SG1 target operation group is selected as follows to process the client request:
Figure Weighted RoundRobin shows the
SG1 target operation group containing three target operations (target operation A, target operation B, and target operation C) with
Weighted RoundRobin type. Target operation A is assigned weight value as
5, Target operation B is assigned weight value as
2, and Target operation C is assigned weight value as
3.
When the Core Engine routes any facade request to the SG1 target operation
group, the Core Engine processes the request in the following way:
For a target operation group of RoundRobin With Failover type, the Core Engine selects the target operation as per the RoundRobin algorithm. See
RoundRobin for details. After the target operation is selected, the Core Engine checks the health of the target operation using the HealthCheck reference functionality of TIBCO API Exchange Gateway. See
HealthCheck for Reference.
For a target operation group of Weighted RoundRobin With Failover type, the Core Engine selects the target operation as per the assigned weight to the target operations. See Weighted RoundRobin for details. After the target operation is selected, the Core Engine checks the health of the target operation using the HealthCheck functionality. See
HealthCheck for Reference for details. If the target operation is available, the facade request is forwarded to this target operation. If the target operation is not available, the Core Engine finds an alternate target operation based on the weight assigned to the remaining target operations in the target operations group. This process continues until a target operation is found within the target operations group that is running. The facade request is routed to the available target operation for processing.
For the SG1 target operation group with Sticky Resource Affinity
type
, consider the following configuration:
RoundRobin Routing
Algorithm
To use the Sticky Resource Affinity routing algorithm, define a sticky routing key. The sticky routing key is derived in a XSLT transformation file as part of the parsing step in the request processing pipeline of a facade operation. You can upload the XSLT file for a facade operation configuration in the Config UI. The Core Engine retrieves the sticky key from the transformation. See StickyResourceAffinity Target Operation Group Configuration.
