How to configure exception handling in Connect REST when source is within pega.
Hi I have a use case like whenever a user enters a customer ID the customer details are populated on the screen and this is being done by a CONNECT REST,now the requirement is :When we get any error while fetching customer details, change the status to “Pending-Investigation” put the case to one work queue. After an hour case should automatically re-queued via queue processor and hit the connect REST and update the case status. Upon successful response from API case should move to next stage or process without manual intervention.
How to configure this requirement as I am fetching customer details with a data type using CONNECT RSET.
Please find attachment of the existing Connector configuration.
Accepted Solution
Updated: 15 Apr 2024 3:11 EDT
Bits in Glass
IN
@TanyaS58 is browsing of cases required? This api exception handling is for case by case right? If you are doing browsing, all the cases will fetch same list.
You don't have to do browse and all.
Wait shape-> use background processing shape for calling QP -> point this connecter to work queue(here you can set status as pending-......).
Then in the QP activity hit api, set response , check using decision shape, then based on response code it will either move to wait shape or next positive path.
Note- you can avoid wait shape if you are using dedicated queue processor.
Maantic Inc
IN
If the source is a data type in the same environment, then why is a connect REST required. Integration is a very expensive action resource wise. Your requirement can be easily implemented using report definitions sources from a data page.
Cognizant
IN
@SohamM95 my lead has actually asked to configure this requirement by using integration like on entering the customer ID ,the customer name and address should be populated.
For Which I am using Connect REST(Get method)but for error handling scenario i am not getting the configuration part.
Maantic Inc
IN
Pega OOTB sets pyHTTPResponseCode as 200 if there's a successful response. You can use this property value and add your logic to handle the exception.
If Pega is not automatically setting it, then you can use this property to set as 200 when you see there's a successful response coming from the connect REST, in the response data transform.
Updated: 10 Apr 2024 8:10 EDT
Cognizant
IN
@SohamM95 Actually i am progressing with a different approach as I am not sure why even after comparing with pyHTTPResponseCode my updateStatus activity was not working so i stored the response in a param and then used call Update status it worked.
Bits in Glass
IN
@TanyaS58 its not a good design approach to handle exception, you are not supposed to change status using activity in this approach. You need to configure this status on the assignment where your case will be staying when you requeue to the queue processor.
Updated: 10 Apr 2024 9:07 EDT
Cognizant
IN
@Anoop Krishna bascially what my lead suggested was to add a wait shape so that the case can stay in a deferred queue for an hour and after that the QP can requeue it so this is what i am not understanding how to configure this part.As first we need to change the status and then make it wait for an hour and then run the QP to requeue it so thats why I am updating the status on the UI first when the service is not fetching the results.
Updated: 10 Apr 2024 7:01 EDT
Bits in Glass
IN
@TanyaS58in the flow where you are hitting api, based on the response is successful or not, you need to either route it to Dedicated QP or advance the flow.
For that keep a decision shape, if code! =200, set time = 1 hour and then direct it to QP(background processing shape) and route it to a work queue where case will be staying until the next api call. Again api will be hit after 1 hour if it fails again comes to QP. The other connector of decision shape should be connected to next shape ( proceed with the flow as the api is successful).
In your QP activity, after your api hit, call resumeflow so that it will now decide based on the response where to go, to next shape to proceed or QP and stay in Work queue.
Updated: 10 Apr 2024 8:39 EDT
Cognizant
IN
@Anoop Krishna what I am doing now is after the status is updated to Pending Investigation then based on the status i am calling a decision shape to check the status and then proceed to either different assignment or a subprocess,in the subprocess i am calling a wait shape followed by a utility now if the case is having pyStatusWork=Pending-Investigation it will move to wait shape and after that the utility is having an activity configured so it will browse the cases having status as Pending Investigation,now i am not getting how to call the QP so that it re queue these cases and re hit the API andupdate the status to Register Complaint and process to next stages automatically.
Accepted Solution
Updated: 15 Apr 2024 3:11 EDT
Bits in Glass
IN
@TanyaS58 is browsing of cases required? This api exception handling is for case by case right? If you are doing browsing, all the cases will fetch same list.
You don't have to do browse and all.
Wait shape-> use background processing shape for calling QP -> point this connecter to work queue(here you can set status as pending-......).
Then in the QP activity hit api, set response , check using decision shape, then based on response code it will either move to wait shape or next positive path.
Note- you can avoid wait shape if you are using dedicated queue processor.
Updated: 10 Apr 2024 11:40 EDT
Cognizant
IN
@Anoop Krishna I couldn’t understand this approach as by using wait shape the case will be in deferred work queue and after that we need to re update the case status from pending investigation to register complaint so i feel by browsing we will have a list of those cases and then again we will update there case status and this all needs to be done via QP.
So as per my understanding you want me to use a run in background shape post wait shape?and in that subprocess shape that i am using beside the decision shape in that connector I should set the status to pending-investigation (as from decision shape pega was not allowing to use a wait shape from its outgoing connector)
Updated: 10 Apr 2024 13:14 EDT
Cognizant
IN
@Anoop Krishna no we dont have separate case type.how I am calling api is on the Customer ID section in the action set i am using on change then post value and a refresh where i am calling an activity to map the customer name and address from Datapage (that is sourced by the connector)
Also as you have mentioned above that to avoid using a dedicated QP if i am using wait shape then how by using standard QP this requirement will be satisfied?
Updated: 10 Apr 2024 13:27 EDT
Bits in Glass
IN
@TanyaS58 okay then browsing cases not required, this exceptional handling flow is each case. Each of your case will hit api and pass through this exceptional handling flow.
Yes if you are wait shape, standard QP is enough.
For updating status you can either configure in any of the assignment shape or use updatestatus shape in the flow. The status update can be handled in your way but ensure that you are following best practice.
Cognizant
IN
@Anoop Krishna but I am still not getting one thing is that what logic do I need to go within the QP activity:1)how to call the connector (do i need to call the same data page that is sourced by the connector) and how will we the flow resume to the normal scenario when the API is successful and that update case status do i need to use after background processing shape?
Bits in Glass
IN
1. Yes call same dpage to hit api.
2. In the activity if api response is successful, then call resumeflow activity. Till then case will stay in work queue.
Once resumed, based on your decision shape the flow will be proceeded.
Cognizant
IN
@Anoop Krishna thanks for answering promptly I will try this approach and post here
Cognizant
IN
@Anoop Krishna have created a separate query section for the continuation of this issue:
https://support.pega.com/question/does-standard-queue-processor-does-not-support-tickets please go through this link
Cognizant
IN
@Anoop Krishna and also one more thing since i am using wait shape so whatever cases that are failing api and then status is changing to Pending investigation and that case stays in deferred wq for an hour and after that the same case will be reprocessed via qp everytime so thats why looping we are not using?
Bits in Glass
IN
@TanyaS58 yes right, api exceptional handling and case status update is handled at each case level. There is no dependency on other cases, so not required to browse cases. Whether api is successful or not with our design approach will be decided at each case level.
Pegasystems Inc.
CA
I am wondering why we need to use connect-REST even if the source is part of the same application. We can leverage the data pages to retrieve the data from the application.
Updated: 10 Apr 2024 11:42 EDT
Cognizant
IN
@RameshSangili have been asked to do so otherwise would not have used it and I am using the data page which is sourced by the connector.
Updated: 10 Apr 2024 14:30 EDT
Pegasystems Inc.
CA
I believe your lead asked you to do this because a different team is currently building the API. In the meantime, he wants to accomplish the development activities with the data type to move forward.
If you intend to do a change stage after API is successful, then it's fine.
If you intend to proceed to the next assignment(select Department Type) after the API is successful, you may have to use setTicket on the assignment shape. Once the API is successful, call the ticket from the queue processor activity.
If the API has an error, you trigger the ticket in the QP activity to route it back to the Assignment with SLA configured with the ticket.
Subprocess: (Assignment with SLA and APIError Ticket configured -> Dedicated QP -> Assignment (work queue) - If the API fails, then invoke APIError Ticket to reroute back and wait for the SLA to expire. Please note: Tickets can't be configured on Wait shape.
Also, please consider Anoop's suggestion to add a Work queue after you queue to the QP.
If you want to avoid configuring tickets in your flow, you have to make flow changes.
I hope this helps!
Thanks,
Updated: 12 Apr 2024 9:44 EDT
Pegasystems Inc.
GB
@TanyaS58 has your original question 'How to configure exception handling in Connect REST when source is within pega.' been answered?
I believe @SohamM95 provided the answer on how exception handling works in the architecture, @Anoop Krishna helped answer how to call the connector. Then . @RameshSangili provided some insight on new scenarios for your design.
Your follow up question Does the standard Queue Processor does not support tickets? gets into the nitty gritty on how you can design a solution but I thought this first question was on how to debug the results of connect rest? Please clarify what has not been answered here.
If the original question is not answered, please can you reply to the user if you are expecting any further help ?
Cognizant
IN
@MarijeSchillern no my original question is not resolved