Layer7 API Management

Hi,

i have few questions regarding the "connection" tab in HTTP(s) routing properties, which i could not figure out based on docops. 

1. does the fail over strategy of "ordered/random sticky with fail over" assigns a single backend server(from list of urls / ips) to a particular user, based on their HTTP session or IP address , ensuring that all future requests for the same session are sent to the same server  ?
2. if so, does this sticky session mechanism will work when routing to HTTPs backend servers ? 
3. can i input a context var containing a list of URLs or IPs instead of hard coding it in the assertion ? 

your response will be much appreciated,

thanks, 

1. I do not believe this is how it was designed. I do not believe it keeps a list of users/sessions as part of it's logic.
2. N/A
3. This is something I need to test in my lab, but off the top of my head - yes, you can use context variables for the URLs list.

Hi Dustin,

1. based on your answer above, so what does the fail over strategy of "ordered/random sticky with fail over"  does ? how it works and maintains sticky / session affinity ? 

2. so i cannot use sticky session / session affinity when routing to HTTPs backend ? only HTTP ? 

thanks, 

Sorry, I just realized I confused "sessions" with users too and thought you meant "user sessions". To clarify, as I understand it, it tracks based on TCP session ID which is how session affinity works across pretty much any product that communicate over TCP. In other words, it is done at the TCP layer, not the user application layer. Yes, you can use this with HTTPS.

Reference: Create Routing Strategy Assertion - CA API Gateway - 9.3 - CA Technologies Documentation 

In response to your questions:

• does the fail over strategy of "ordered/random sticky with fail over" assigns a single backend server(from list of urls / ips) to a particular user, based on their HTTP session or IP address , ensuring that all future requests for the same session are sent to the same server Response: There are 2 parts to this. First the assertion will take the first server list for ordered and gather any one from the list for random. The second part is the alignment to a connection in the pool is based on security context to ensure that userA coming through the policy does not use a pooled connections for userX.
• if so, does this sticky session mechanism will work when routing to HTTPs backend servers ? Response: Yes. Same construct as the write-up above. The security context may then also relate to Client Mutual authentication at a protocol level and the other piece is the username in the payload of the message or the header.
• can i input a context var containing a list of URLs or IPs instead of hard coding it in the assertion ? Response: Yes you can user context variables. I would look to use Dustin's suggestion for Routing Strategy.

Sincerely,

Stephen Hughes

 CA Support

Hi Stephen / Dustin,

As suggested, I have tried to configure a context variable/CWP  for the Route via HTTP(s) assertion that would take a list of URLs instead of having to set them manually hard coded via the connection tab. However, 

When setting it to a multi valued context variable (containing multiple URLs)  all the values get set as a single URL during execution and fails. 

I was really hoping to be able to populate the multiple urls property via a single parameter/cluster property that is a list, and same for multiple IPs as a list since currently it's the main request of our customer.

i found an older communities post with a similar question as mine : Route via HTTP(s) assertion 

Hopefully you can walk me through for resolving it. 

Thanks Guys for the clarification. this information is very helpful