Working With Dynamic Routing

The gateway can route a message to multiple back-end servers, using common failover strategies to route to a dynamic list of IP addresses. The IP addresses are stored in a context variable.
gateway83
The 
CA API Gateway
can route a message to multiple back-end servers, using common failover strategies to route to a dynamic list of IP addresses. The IP addresses are stored in a context variable.
During dynamic routing, the Gateway receives feedback for all the routes that were attempted, including both successful and unsuccessful routes. This feedback is stored in context variables, which are available to the rest of the policy execution.
In a policy, always use these assertions in the following order:
The following illustration shows how dynamic routing can be used in a policy.
Dynanic_routing_example.png
The following are highlights of the workflow.
  1. The Create Routing Strategy Assertion retrieves the input for executing the strategy (started by the Run Assertions for Each Item Assertion in line 9). Route List and their properties are entered through the Create Routing Strategy Properties fields.
    The Create Routing Strategy assertion must always precede Execute Routing Strategy and Process Routing Strategy Result assertions. 
  2. The Execute Routing Strategy Assertion in line 15 exercises the
    ${strategy}
    by automatically populating the Routing Strategy Prefix field. The method in which the route is selected depends on the type of strategy set in the Create Routing Strategy.
  3. The Route Variable Name is then passed to the Route via HTTP(S) Assertion (line 18). The URL field in the [
    Target
    ] tab of the HTTP(S) Routing Properties is automatically populated with the Route Variable Name. The Execute Routing Strategy sets the
    ${feedbackList.current.route}
    for the Process Routing Strategy to collect other feedback (for example, a
    .reasonCode
    ) on that particular current.route.
  4. The Process Routing Strategy Result Assertion (line 28) collects other feedback about the route, whether it has passed or failed.
    From this step, there are two outcomes:
    • If the HTTP(S) Routing fails, the current.route is replaced with next route on the list (selected by the Execute Routing Strategy), and the process loops back to the Execute Routing Strategy. The looping continues until the Execute Routing Strategy exhausts the routeList or the route succeeds.
    • If the HTTP(S) Routing succeeds, the policy exits the loop with the working route ${<
      route
      >} and its collected feedback from the Process Route Strategy.