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.
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.
@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.
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.
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.
@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)
@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 ?
@TanyaS58 in 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.
@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.
@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.
@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?
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.
@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.
@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.
@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.
