Dynamically set the Response timeout in Connectors
Hi All,
We are invoking a REST service from our application which is having issues with handling the load of requests and its taking longer time to response .Since the timeout is configured at our end we see a lot of time out exception.Atleast for now there are no plans to fix the issue on the REST service side.This service gets called from various places and as a work around we want to set the timeout dynamically .For example when invoked from a Batch requestor we want it to be 5 mins and when invoked from a browser requestor we want it to be 30 seconds.When i see the pyInvokeRESTConnector activity its directly taking the timeout value from the rule form.We can of course override the pyInvokeRESTConnector to get the service name and based on the requestor type we can set the timeout within the Java step but just wanted to check if this is recommended and if Pega has any plans to make it dynamic in the future releases.
Thanks
Accepted Solution
Pegasystems Inc.
CA
Your argument makes sense. Having said that, I don't think we need to add a new parameter to the Connect-* activity method. If we keep adding everything as a parameter, there won't be an end to it. I think the simpler option would be to make the timeout field configurable in such a way that would allow user to enter a literal/GRS/Parameter reference/Property reference. This should work for you right? But this would fall under "enhancement" category.
Pegasystems Inc.
CA
Which version of Pega are you using? 7.1.8 supports specifying response timeout via Global Resource Settings (GRS) syntax.
JP Morgan Chase
IN
Hi Praneeth,
Thanks for the clarification , We are 7.1.6.So if we can use GRS how can we differentiate different requestor types and set the timeout .I was thinking if the timeout can also be one of the parameter when we use Connect-REST in an activity like the End Point URL so that we can override the value.Please let me know your comments.
Thanks
Pegasystems Inc.
CA
GRS syntax takes this form: =<DataPageName>.<propertyRef>
You can populate different values onto this property based on the requestor type. This should suffice for your use case and adding timeout as a parameter to the Connect-REST activity method doesn't add any more value, the way I see it.
By the way, just to reiterate, GRS support for timeout was added only in 7.1.8. Since you are on 7.1.6, upgrade is the best option. If you can't, then overriding pyInvokeRESTConnector the way you suggested, though not recommended, is the way forward. But you must ensure that you remove your version of the activity when you upgrade in future so that you don't lose out on the improvements done since 7.1.6.
Pegasystems Inc.
CA
You can find more information on GRS on PDN. https://pdn.pega.com/integration/how-to-reduce-maintenance-of-service-rules-and-listeners-with-global-resource-settings
JP Morgan Chase
IN
I would still see a value adding timeout to Connect-REST in activity.In the Connect-REST we can refer DataPage.PropertyName and based on the requestor type we will have different value but this would result in refreshing the declare page.Instead if we have a declare page with a page group we can set different subscripts based on requestor type and have the value of browser requestor page group subscript value by default on Connect-REST rule form and then if we have any option to pass the timeout as parameter we can override the value in the rule form with the same declare page using different subscript.Please let me know your comments.
Pegasystems Inc.
CA
GRS syntax is not restricted to data pages. You have reference any top-level page. So, you could create your page group property inside this top-level page and reference the subscript via a parameter. Something like this in your connect rule form:
=TopLevelPage.PageGroup(Param.BrowserType).timeout
You could populate this PageGroup property on TopLevelPage before calling the connector in your activity based on the requestor type.
Let me know if this helps.
JP Morgan Chase
IN
With this approach we end up creating the page again which is equivalent to refreshing a declare Page which we want to avoid..What i meant was to create a Declare Page at Node/requestor level and reuse.The example i mentioned is just one use case.We have a lot of headless application where we use Pega and all the operations happen through services which internally call other connectors.Also in headless applications most of the processing happens through agents or batch requestors. Each service may be a different business SLA based on application and we might want to have different timeouts for batch processing/services/application based timeout etc.So if we have the End Point URL as param of Connect- in activity then why not time outs.Please let me know if my argument makes sense.
Accepted Solution
Pegasystems Inc.
CA
Your argument makes sense. Having said that, I don't think we need to add a new parameter to the Connect-* activity method. If we keep adding everything as a parameter, there won't be an end to it. I think the simpler option would be to make the timeout field configurable in such a way that would allow user to enter a literal/GRS/Parameter reference/Property reference. This should work for you right? But this would fall under "enhancement" category.