I have created a DSP page which is in turn calling few flow services to obtain and display a GUI.
The access to the DSP page and flow services has been restricted to a customized ACL.
I have two integration servers working in cluster, and the DSP page is accessed via a load balancer which is diverting the HTTP call to any of the clustered integration server in round robin fashion.
The issue is that whenever I try to access the DSP page, it multiple times prompt for user credentials. I tried to call the DSP page directly from the Integration server (by passing load balancer) and it work fine, however this issues is only when calls are coming via load balancer.
I am suspecting that Integration server is using “Default” user to make subsequent calls to flow services in side the DSP page. To verify this, I added “Default” user in my ACL group and it stopped asking me multiple times user credentials. But why is this happening only when I am coming via load balancer.
It isn’t IS using “Default” for subsequent calls. It’s probably the configuration of your load balancer
You need to configure the load balancer to use sticky sessions–once you’re logged in the LB needs to direct you to the same IS each time until you log out (or the session expires).
There are a number of ways this can be done. Probably the preferable way is for the LB to use the cookie that is exchanged between IS and the client. Chat with your network folks (or whomever manages/configures the LB) to get the configuration that’s needed.
Thanks for the response Rob, you have rightly pointed that our load balancer are not configured to maintain sticky session. Rather we have got the sticky session behaviour removed from LB by choice couple of months back.
When LB was configured to maintain sticky session it was directly routing calls from one single IP to only one internal server, because it was maintaining the session based on IP and since we are integrating with many EAI and B2B systems we were unable to guarantee that the source system will allow cookies, so cookies based sticky session was not maintained. So in that case LB was not properly sharing the load and we then removed the sticky session to balance the multiple HTTP calls from one single IP between all Integration Server behind the LB. It’s been couple of month since we have made this change.
We have several web services being accessed via these LBs. All of these web services are allowed to accessed by a custom ACL (Basic Authentication) only and make calls to several internal flow/java services, however I have not noticed any issue there. However these web services are exposed from multiple integration servers “not in cluster”. Only LB routes the calls to any of the integration server hosting the web service.
Where as in case of my DSP page there is two way load sharing, ie. LB and then 2 IS are in cluster (is it a problem?).
I am not very sure how the DSP page and invoke calls inside the DSP page is behaving. My understanding with sticky session is that it will maintain the session between the subsequent http calls. However the issue with my DSP page is that it is using “Default” user for each invoke calls inside the DSP page (so its not two different HTTP call). I believe that once a HTTP connection is established with IS and DSP started executing its a single http connecting till the end of DSP execution and any invoke call inside the DSP should use the same credential as the DSP page. How the sticky session behaviour of LB will come to the picture here?
Your description of the expected behavior of a DSP page matches mine, but it clearly isn’t doing the right thing. Probably time to get wM tech support involved to take a look.