handle rest connector exception in an Activity step
we have a number of REST API calls that are made from our 7.3.1 server as part of a larger Marketing application.
they are all called via Activities which can be invoked due to receipt of an event stream, or possibly via an agent that is processing from a queue.
I have read over most of the posts I could find on this topic, and there does not appear to be a good answer to the problem of the REST Connector receiving an Exception within the provided OOB Pega code, when called from an Activity
in all of the Activities, the Connect-REST step has a jump step with a StepStatusFail, but this code is never reached when the connector receives an exception condition.
multiple ERRORS are logged with an accompanying stack trace, but without the ability to catch the ERROR in the calling Activity and handle it appropriately, the exceptions often cause the calling Agent to fall over due to the exception.
we now monitor our log files very closely, and track agent failures; so we are both aware of the frequency of the occurrence, and can restart failed agents, but ideally we need to handle the exception conditions in our code.
from the stack trace we can follow the path:
Activity>invoke
Activity>pyinvokerestconnector
and the internal RESTConnector methods
invoke/perform/executeRequest/invokeRest/mapResponsBody/mapInboundData
but what we need is the Pega approved way to handle these exceptions, either
we have a number of REST API calls that are made from our 7.3.1 server as part of a larger Marketing application.
they are all called via Activities which can be invoked due to receipt of an event stream, or possibly via an agent that is processing from a queue.
I have read over most of the posts I could find on this topic, and there does not appear to be a good answer to the problem of the REST Connector receiving an Exception within the provided OOB Pega code, when called from an Activity
in all of the Activities, the Connect-REST step has a jump step with a StepStatusFail, but this code is never reached when the connector receives an exception condition.
multiple ERRORS are logged with an accompanying stack trace, but without the ability to catch the ERROR in the calling Activity and handle it appropriately, the exceptions often cause the calling Agent to fall over due to the exception.
we now monitor our log files very closely, and track agent failures; so we are both aware of the frequency of the occurrence, and can restart failed agents, but ideally we need to handle the exception conditions in our code.
from the stack trace we can follow the path:
Activity>invoke
Activity>pyinvokerestconnector
and the internal RESTConnector methods
invoke/perform/executeRequest/invokeRest/mapResponsBody/mapInboundData
but what we need is the Pega approved way to handle these exceptions, either
a) in our Activity directly, OR
b) by overriding the OOB code in the appropriate place so that we can return to the Activity with a status code that we can use to control the flow, and not have our Agents die off simply because an API call failed.
by the number of posts on this topic, this is an obvious sore point for a lot of developers, surely there must be a proper solution available to us.
Ford Motor Company
CA
I was hoping for quick action on this topic, but that has not happened.
we make 10's of thousands of API calls a day, and typically just get a handful of Exceptions on the calls, but on occasion the counts are high, and we get a variety of Exception types ...
for example pulling from our log files on a daily basis we see something like the following ...
while we can certainly guess at the root cause for some of these, we would like to be able to handle the Exception in our code, and not just have things fall over.
I was hoping for quick action on this topic, but that has not happened.
we make 10's of thousands of API calls a day, and typically just get a handful of Exceptions on the calls, but on occasion the counts are high, and we get a variety of Exception types ...
for example pulling from our log files on a daily basis we see something like the following ...
while we can certainly guess at the root cause for some of these, we would like to be able to handle the Exception in our code, and not just have things fall over.
| API | Class | Error | Count |
| CheckAvailability | MyCo-Int-Connect-REST | NoRouteToHostException | 2 |
| RetrieveConsumerInfoByID | MyCo-Int-Connect-REST | UnknownHostException | 2 |
| http | 1 | ||
| SearchByRadius | MyCo-Int-Connect-REST | UnknownHostException | 2 |
| TransactionalVisitorService | MyCo-Int-TransactionalVisitorService | SocketTimeoutException | 10 |
| CheckAvailability | MyCo-Int-Connect-REST | UnknownHostException | 2 |
| RetrieveConsumerInfoByID | MyCo-Int-Connect-REST | UnknownHostException | 2 |
| SearchByRadius | MyCo-Int-Connect-REST | UnknownHostException | 2 |
| SocketTimeoutException | 1 | ||
| CustomerProfile | MyCo-Int-CustomerProfile-CustomerProfileAPI | SocketTimeoutException | 8 |
| IDHub | MyCo-Int-IDHub-IDHubAPI | SocketTimeoutException | 4 |
| InboundMappingException | 1 | ||
| CustomerByGuid | MyCo-Int-RetrieveID-CustomerByGuidAPI | SocketTimeoutException | 198 |
| InboundMappingException | 3 | ||
| RewardPoints | MyCo-Int-RewardPoints-RewardPointsAPI | EOFException | 65 |
when we do get a valid response back we can track that separately and handle the issue based on returnCode
API ReturnCode Count CustomerByGuid 500 47
Of course we are working with our API providers to see if they can make the API's more robust, but exceptions will still occur on occasion, and we need to be able to control that within the Pega code and, again, not just fall over.
is there anyone in Pega Engineering following this thread?