• 0 Vote(s) - 0 Average
  • 5
  • 4
  • 3
  • 2
  • 1
Thread Modes

REST Action Failures
#1
We have configured a new REST service/connection/resource and added a REST Action for it in one of our EasyVista workflows. The API is working and has been successfully communicating with the external system, but occasionally we will run into an issue where a user that we have defined in EasyVista is not found in the other system and the API will return an error code:
Code:
{
   "code": -1,
   "message": "Invalid recipient id"
}
We can fix these as they occur, but the issue we are running into is that the EasyVista workflow is not seeing this as an API failure, so it is not taking the "red line" route to inform us of the failure; it's treating it like the API was successfully processed ("green line").

Does anyone know what error code must be returned for EasyVista to see it as a failed API call?
Sarah Schumacher
Service Desk Tool Administrator

#2
(07-19-2019, 09:49 AM)sarahschumacher Wrote: We have configured a new REST service/connection/resource and added a REST Action for it in one of our EasyVista workflows. The API is working and has been successfully communicating with the external system, but occasionally we will run into an issue where a user that we have defined in EasyVista is not found in the other system and the API will return an error code:
Code:
{
   "code": -1,
   "message": "Invalid recipient id"
}
We can fix these as they occur, but the issue we are running into is that the EasyVista workflow is not seeing this as an API failure, so it is not taking the "red line" route to inform us of the failure; it's treating it like the API was successfully processed ("green line").

Does anyone know what error code must be returned for EasyVista to see it as a failed API call?

The REST steps in EasyVista aren't cognizant of HTTP header codes, i.e. 400,401, etc. The only time the red line triggers is if the external interface is offline and even that is spotty. I've had to setup a variable in the REST action step to capture the HTTP body and then use a conditional step to query for something in that variable to indicate an error occurred. In this case, you'd query if the #[VAR.APIresponse]# is like '%code": -1%' to see if it failed.
cmiller, proud to be a member of EV CONNECT FORUM since Oct 2015.

#3
(07-19-2019, 01:21 PM)cmiller Wrote:
(07-19-2019, 09:49 AM)sarahschumacher Wrote: We have configured a new REST service/connection/resource and added a REST Action for it in one of our EasyVista workflows. The API is working and has been successfully communicating with the external system, but occasionally we will run into an issue where a user that we have defined in EasyVista is not found in the other system and the API will return an error code:
Code:
{
   "code": -1,
   "message": "Invalid recipient id"
}
We can fix these as they occur, but the issue we are running into is that the EasyVista workflow is not seeing this as an API failure, so it is not taking the "red line" route to inform us of the failure; it's treating it like the API was successfully processed ("green line").

Does anyone know what error code must be returned for EasyVista to see it as a failed API call?

The REST steps in EasyVista aren't cognizant of HTTP header codes, i.e. 400,401, etc. The only time the red line triggers is if the external interface is offline and even that is spotty. I've had to setup a variable in the REST action step to capture the HTTP body and then use a conditional step to query for something in that variable to indicate an error occurred. In this case, you'd query if the #[VAR.APIresponse]# is like '%code": -1%' to see if it failed.

Thank you, Chris. The variable and conditional step approach seems like it will work for us.
Sarah Schumacher
Service Desk Tool Administrator






Users browsing this thread: 1 Guest(s)