Error Handling for Web Services

Error handling detects and prevents a run-time error which occurs while executing a skill, typically due to an invalid response from API call. This feature helps ensure that the end-user knows the exact reason why the error occurred. 

Using the error handling feature, you can add a rule by adding several conditions to define an error message. The error message will be processed only when it matches all the set conditions, any condition, or custom criteria specified. The custom message appears in the Debug Log and also in the chat window while executing the skill.

For example, in previous versions of Luma the generic message "I'm currently unable to complete your request. Please contact your Luma administrator" was shown for all errors. Now, using error-handling a custom message will be displayed conveying the actual error such as "The mandatory field Description is missing".

Error handling can be accessed from the Webservices page and also at the Skill level. You can override either of the messages.

Define Error Message

1. To navigate to the Error Handling section, on the Bot dashboard click Skills.
   The skills list appears. 
2. Select a specific skill, click Fulfillment, and then click Webservices.
3. Select the webservice connector.
4. Click Error Handling.
   
   
5. Click Override to override the error message specified in the Webservices page. 
   Note: The subsequent fields are enabled only if the Override check box is selected.
   
6. Select one of the following options to define a rule to parse the error message. The error message will be parsed only if the specified conditions are validated:
   - Match any conditions below: one of the specified conditions must match to parse the error message.
   - Match all conditions below: all the conditions specified must be validated to parse the error message.
   - Define custom criteria: you can define your custom criteria based on the given conditions to parse the error message, if validated.
   For example, 1 and 2 or 3. 1st and second conditions must match or only the third condition must match. You can enter only numbers, and, or, (,)

7. Specify @webservice.StatusCode in the Key field followed by an operator. These are the list of operators available (==, !=, >=, <=, >, <). When you type '@' in the Key field, a list of conversation variables are populated such as webservice, context, resp, and so on.
   @webservice is one of the conversation variables used for webservices. For more information, see Conversation Variables.

8. Specify the response code or status code in the Value field.
   

   Status codes are issued by a server in response to a client's request made to the server. And the response must contain an entity describing or containing the result of the action. There are a list of status codes such as 500, 400, and 200. According to the requirement you can specify the status code for which you want to define a custom message.
   For example, response code 200 represents a success message. This class of status codes indicates the action requested by the client was received, understood, accepted and processed successfully.

9. Click the icon if you want to add another condition. You can specify multiple conditions and create a rule such as all the conditions, any one of the conditions, or specific conditions must match to parse the custom error message.
   Click the icon to delete a condition.

10. Specify the message that you want to display to the end-user for a specific error, while executing a skill. If you want to parse a specific message, you must follow these:
     - For SOAP connectors, you must prefix 'resp.//' followed by the actual message which must be parsed. For example, '@resp.//.cod.401.message'.
     - For Rest connectors, you must prefix 'resp.' followed by the actual message that must be parsed. For example, '@resp.cod.401.message' (as shown in the Debug log in the image below).
    Response variables are used in a web service to return information to a request.
    

    Note

    If you don't prefix the conversation variable '@resp' for the message, a generic message will be displayed and the actual error message will not be parsed. 

    For more information, see Conversation Variables.
    
    The highlighted area displays the response code and the actual error message.

11. To handle no data condition for Null messages in custom connectors such as the below:

     { 
        "result": [] 
    }

    Using the Json path expression ${@resp.result[*].length()} you can specify this condition and evaluate the rule to show the appropriate message through Error Handling.