Question
Amerigroup Corporation
US
Last activity: 29 Jul 2015 21:02 EDT
What is the guest URL syntax to be used for the Load balancer Probes?
With Pega 7, What is the guest PRPC URL syntax to be used for the Load balancer Probes? The ones we used for Pega 6 are not working.
what were you using in 6?
Amerigroup Corporation
US
/prweb/PRServletLDAP1/oO9O9iMscyJc_fy6LnBDXO9xEtRpDxfL3At36r8Aw8k%5B*/!Guest?
Accepted Solution
Updated: 29 Jul 2015 21:02 EDT
Pegasystems Inc.
US
Are you sure that is the URL you were using in 6? Do you have some sort of handler in your PRServletLDAP1 custom authentication activity to return some value if the URL contained the string "Guest". The URL is going to first be processed by the custom authentication activity and that is why I am thinking you have some sort of handler in it. This is a good thing because an unauthenticated requestor is removed real quick, i think 2 minutes, so your not leaving load balancer probe requestors out there for too long.
This part of your URL is not static: oO9O9iMscyJc_fy6LnBDXO9xEtRpDxfL3At36r8Aw8k%5B*
This is a hash that is built based on your AccessGroup as defined in your PRPC node names browser requestor type instance. The hash will have changed when you upgraded as new PRPC ruleset versions are now in use and this is probably causing your problems now, or at least one of your problems.
Typically you never want to save a URL with a hard coded AccessGroup hash as it's derived. Standard user login to /prweb/PRServlet will redirect you to the proper URL with the default browser type AccessGroup hash. However, I bet the load balancer probe wont follow redirects so you have to put add the hash.
Just access the standard PRPC login page and check to see if this hash matches. If not use the new one in PRPC 7.
Also want to understand your objective for this better:
Are you sure that is the URL you were using in 6? Do you have some sort of handler in your PRServletLDAP1 custom authentication activity to return some value if the URL contained the string "Guest". The URL is going to first be processed by the custom authentication activity and that is why I am thinking you have some sort of handler in it. This is a good thing because an unauthenticated requestor is removed real quick, i think 2 minutes, so your not leaving load balancer probe requestors out there for too long.
This part of your URL is not static: oO9O9iMscyJc_fy6LnBDXO9xEtRpDxfL3At36r8Aw8k%5B*
This is a hash that is built based on your AccessGroup as defined in your PRPC node names browser requestor type instance. The hash will have changed when you upgraded as new PRPC ruleset versions are now in use and this is probably causing your problems now, or at least one of your problems.
Typically you never want to save a URL with a hard coded AccessGroup hash as it's derived. Standard user login to /prweb/PRServlet will redirect you to the proper URL with the default browser type AccessGroup hash. However, I bet the load balancer probe wont follow redirects so you have to put add the hash.
Just access the standard PRPC login page and check to see if this hash matches. If not use the new one in PRPC 7.
Also want to understand your objective for this better:
You want to built a request that will trigger some sort of result from PRPC used to determine if a node is available for use. You will then automate the request in the load balancer configuration to run at "X" interval and it can mark nodes up or down based on the results of that request?
How often is interval for the load balancer probe?