Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
We are trying to setup a virtual proxy that will load balance to a rim node only (for use for specific clients). For that we need a prefix that has a slash character ("path1/path2").
This works when accessing the URL directly. But we will need to access the QPS for getting a ticket with that virtual proxy with a Slash from the rim node.
The QPS API doesn't seem to work with a prefix that has a slash though for some reason, with the error message "No matching endpoint found".
https://server:4243/qps/path1/ticket -> works
https://server:4243/qps/path1/path2/ticket -> doesn't work
The virtual proxy that will be used by default would be under the above scheme:
https://server:4243/qps/path1/
If that matters in any way.
Am i missing something?
Thank you
Hello Clemens,
I hope all is well. To answer your question, yes. It matters; it's part of the API spec. However, If your goal is to segment your audience to a preferred node for per-customer computing, I would recommend the following:
1) Abandon the path-based routing in this approach, allowing the Layer 7 balancing to operate in a lightweight and agnostic way to the client context.
2) Because you're using ticketing, you have additional options around session claims that you can leverage, with a matching engine load balancing rule, to send the users' session compute to the appropriate engine node and stream combination for each customer:
&
Note that in your case, it might make sense to assign something like this, for example, if you provide a group claim attribute list in the ticket backend POST for each user session federated into Qlik:
Load Balancing Rule
node.@Customer=resource.stream.@Customer
Security Rule (App,Read)
user.group=resource.stream.@Customer
3) If you're trying to identify the node the user might have begun their session with (e.g., SP initiated) and better determine where to get the Qlik Proxy Ticket from at your ticket broker level, set the authentication module to redirect uri to your endpoint/listener, per: https://help.qlik.com/en-US/sense-admin/February2023/Subsystems/DeployAdministerQSE/Content/Sense_De.... Qlik will send the internal server name and virtual proxy client-side as query string parameters.
Hello Clemens,
I hope all is well. To answer your question, yes. It matters; it's part of the API spec. However, If your goal is to segment your audience to a preferred node for per-customer computing, I would recommend the following:
1) Abandon the path-based routing in this approach, allowing the Layer 7 balancing to operate in a lightweight and agnostic way to the client context.
2) Because you're using ticketing, you have additional options around session claims that you can leverage, with a matching engine load balancing rule, to send the users' session compute to the appropriate engine node and stream combination for each customer:
&
Note that in your case, it might make sense to assign something like this, for example, if you provide a group claim attribute list in the ticket backend POST for each user session federated into Qlik:
Load Balancing Rule
node.@Customer=resource.stream.@Customer
Security Rule (App,Read)
user.group=resource.stream.@Customer
3) If you're trying to identify the node the user might have begun their session with (e.g., SP initiated) and better determine where to get the Qlik Proxy Ticket from at your ticket broker level, set the authentication module to redirect uri to your endpoint/listener, per: https://help.qlik.com/en-US/sense-admin/February2023/Subsystems/DeployAdministerQSE/Content/Sense_De.... Qlik will send the internal server name and virtual proxy client-side as query string parameters.