Is there an option to stop all Requestors at once,instead of going one by one in SMA.We have multiple JVM's and during deployment we have to first knock the browser requestor sessions one by one on all JVM's which is a time consuming and tedious manual ef
Is there an option to stop all Requestors at once,instead of going one by one in SMA.We have multiple JVM's and during deployment we have to first knock the browser requestor sessions one by one on all JVM's which is a time consuming and tedious manual effort.This has to be done every time we do release as new code can interfere with their BAU processing..if it is still underway.
Accepted Solution
Capgemini
IN
Requestors on all nodes can be stopped, if we get the above java code run on individual nodes. That can be done using soap/rest where the soap uri should change based on a node list.
Say for example:
if you have a list like this
node(1)-https:<yourserver>:1234/prweb/PRSOAPServlet
node(2)-https:<yourserver>:2345/prweb/PRSOAPServlet
node(3)-https:<yourserver>:3456/prweb/PRSOAPServlet
You can loop over this list and call the connect soap method. That connect soap will call the same service but the endpoint uri would change based on this loop. This way you would be able to run your java code(in the service activity) on each node.
We had a crude way of building this list. We stored the nodes as comma separated string in a DSS and then parsed that to a value list.
Would be great to learn a way to get that list dynamically somehow instead of storing it.
Pegasystems Inc.
IN
- RULE-OBJ-LISTVIEW CODE-PEGA-REQUESTOR REQUESTORSONLINE!ALL will get the list of online requestors
- activity similar to RULE-OBJ-ACTIVITY EMBED-REQUESTOR PZSTOPREQUESTOR (Pega-LP-SystemSettings:07-10-15) on each page may help in knocking off the requestors...
JP Morgan Chase
US
Thanks Phani,we are in PRPC V 5.5 in which we do not have that activity to close the requestor session.Probably available in PRPC V 7.1+
Do we know,if any out of box methods in my prpc version?
Pegasystems Inc.
IN
sorry shyam - I'm not aware of any activity/public API on older versions ...please find below screenshot of the activity in 7.1.9.
can we attempt tracing/F12/fiddler at SMA to find the rule being called to stop the requester?
Please share your thoughts/comments, Thank you!
psahukaru
Pegasystems Inc.
IN
- learnt from Ravi Kumar Pisupati that neither of the suggested attempts worked to stop the requester...
- but again, could we please try for this instance/use case as well & share the observations, Thank you!
- issuing Requestor-Stop/Thread-Stop method on retrieved pxResults
- deleting the requestor instance? Obj-Delete on pxResult?
- call OOTB logoff for each result
- it could be referring js scripts or some internal onClick event calls to stop the requestor from SMA when accessed/attempted.
Will be looking forward for community/GCS thoughts/comments, Thank you!
psahukaru
GovCIO
US
Yes Phani Sahukaru. All options were tried to build the logic using V62 but no luck. We need to check the process on how the logic is built for each requestor stop in SMA. I tried using fiddler too but I didn't see the Pega code from my observation. If any GCS expert who can help us, that would be great.
Thanks,
Ravi Kumar Pisupati.
Updated: 6 Jan 2016 2:57 EST
Capgemini
IN
You can try putting this java code in any activity and ensure it gets executed on node where you want to stop the requestors. This step has to be executed for each requestor and that list will be available using the OOTB listview CODE-PEGA-REQUESTOR REQUESTORSONLINE.
Java code :
String result = (String)com.pega.pegarules.priv.management.MBeanManagement.executeMBeanOperation(aMBeanName, aOperationName, aParam1, aParam2, aParam3);
aParam1 should be the property value stored in pxClientConnection. This will be available from the listview for each requestor.
aMBeanName (MBean Name)has to be "com.pega.pegarules.management.RequestorManagement"
aOperationName(Operation Name) should be "StopRequestor".
This has worked for us in v6.3. Should work in v6.2 as well. Please let us know the results.
Updated: 6 Jan 2016 11:12 EST
GovCIO
US
Thanks Prasoon. The java code is working with the given params except aparam2, aparam3 are to be blank.Need to test the scenarios by changing the logic.
Thanks,
Ravi Kumar.
JP Morgan Chase
US
Thanks Prasoon,Ravi and Phani!!
it was a healthy discussion and we were able to configure this code to work for multiple nodes using this code by calling soap service for all such nodes in a single activity activity and iterating it over all such JVM's.
Thanks!
Shyam
Updated: 6 Jan 2016 11:20 EST
GovCIO
US
I need to say "Thanks" to Prasoon to help me in writing the code. Until his reply, I was struggling to build the code as I mentioned above. It is nice learning for me too.
Shyam Ranjan - Please let us know the progress of this fix on a multi-node environment. If possible, please send the steps/screenshots for handling this using SOAP service mentioned by you.
Thanks,
Ravi Kumar.
Accepted Solution
Capgemini
IN
Requestors on all nodes can be stopped, if we get the above java code run on individual nodes. That can be done using soap/rest where the soap uri should change based on a node list.
Say for example:
if you have a list like this
node(1)-https:<yourserver>:1234/prweb/PRSOAPServlet
node(2)-https:<yourserver>:2345/prweb/PRSOAPServlet
node(3)-https:<yourserver>:3456/prweb/PRSOAPServlet
You can loop over this list and call the connect soap method. That connect soap will call the same service but the endpoint uri would change based on this loop. This way you would be able to run your java code(in the service activity) on each node.
We had a crude way of building this list. We stored the nodes as comma separated string in a DSS and then parsed that to a value list.
Would be great to learn a way to get that list dynamically somehow instead of storing it.
JP Morgan Chase
US
This is the exact approach we used,we iterated the activity over a data table ..wherein we stored all the JVM details-Ravi,i hope this answers your question
GovCIO
US
Thanks Shyam Ranjan and Prasoon Nalin.