Module 10: Handling Errors

About

¹.

Objectives

• Handle messaging errors at the application, flow, and processor level
• Handle different types of errors, including custom errors
• Use different error scopes to either handle an error and continue execution of the parent flow or propagate an error to the parent flow
• Set the success and error response settings for an HTTP Listener
• Set reconnection strategies for system errors

Notes

Intro

Errors can be handled at different levels:

• Application level

• Flow level

• Processor level

At the end of this module, you should be able to

• Handle messaging errors at the application, flow, and processor level

• Handle different types of errors, including custom errors

• Use different error scopes to either handle an error and continue execution of the parent flow or propagate an error to the parent flow

• Set the success and error response settings for an HTTP Listener

• Set reconnection strategies for system errors

Reviewing the default handling of messaging errors

Topic video

• Handling messaging errors

  
  Handling Messaging Errors

  • When an event is being processed through a Mule flow that throws an error

    • Normal flow execution stops
    • The event is passed to the first processor in an error handler
  • This is flow level error handling

• Default error handler behaviour

  
  Default Error Handler

  • If there is no error handler defined, a Mule default error handler is used

    • Implicitly and globally handles all messaging errors thrown in Mule applications
    • Stops execution of the flow and logs information about the error
    • Cannot be configured

• Information about the error

  
  Error Object

  • When an error is thrown, an error object is created

  • Two of its properties include

    • error.description - a string
    • error.errorType - an object

  • Error types are identified by a namespace and an identified

    
    Error Types

• Error types follow a hierarchy

  
  Error Types Hierarchy

  • Each error type has a parent

    • => MULE:CLIENT_SECURITY => MULE:SECURITY
    • VALIDATION:INVALID_BOOLEAN => VALIDATION:VALIDATION => MULE:VALIDATION
  • The error type ANY is the most general parent, and the highest messaging error

• Error type hierarchy reference

  
  Error Type Hierarchy Reference

• Information returned from HTTP Listeners

  • By default, for a success response

    • The payload
    • A status code of 200

  • By default, for an error response

    • The error description
    • A status code of 500
  • You can override these values for an HTTP Listener

• Walkthrough 5-1: Explore default error handling

  • Explore information about different types of errors in the Mule Debugger and the console
  • Review the default error handling behaviour
  • Review and modify the error response settings for an HTTP Listener

Creating error handlers

Topic video

• Creating error handlers

  • Error handlers can be added to

    • An application (outside of any flows)
    • A flow
    • A sselection of one or more event processors

  • Adding error handler scopes

    • Each error handler can contain one or more error handler scopes

      • On Error Continue
      • On Error Propagate
  • Each error scope can contain any number of event processors

• Two types of error handling scopes

  • On Error Propagate

    • All processors in the error handling scope are executed

    • At the end of the scope

      • The rest of the flow that threw the error is not executed
      • The error is rethrown up to the next level and handled there
    • An HTTP Listener returns an error response

  • On Error Continue

    • All processors in the error handling scope are executed

    • At the end of the scope

      • The rest of the flow that threw the error is not executed
      • The event is passed up to the next level as if the flow execution had completed successfully
      • An HTTP Listener returns a successful response
    • An HTTP Listener returns a successful response

  • Error handling scenario 1

    
    Error Handling Scenario 1

  • Error handling scenario 2

    
    Error Handling Scenario 2

  • Error handling scenario 3

    
    Error Handling Scenario 3

  • Error handling scenario 4

    
    Error Handling Scenario 4

  • Error handling scenario 5

    
    Error Handling Scenario 5

  • Error handling scenario 6

    
    Error Handling Scenario 6

Handling errors at the application level

Topic video

• Defining a default error handler for an application

  • Add an error handler outside a flow

    
    Specify Default Error Handler

    • Typically, put it in the global configuration file

  • Specify this handler to be the appliction’s default error handler

    
    Specify Default Error Handler

  • Walkthrough 5-2: Handle errors at the application level

    • Create a global error handler in an application
    • Configure an application to use a global default error handler
    • Explore the differences between the On Error Continue and On Error Propagate scopes
    • Modify the default error response settings for an HTTP Listener

Handling specific types of errors

Topic video

• Adding multiple error handler scopes

  

  • Each error handler can contain one or more error handler scopes

    • Any number of On Error Continue and/ or On Error Propagate

  • Each error handler scope specifies when it should be executed

    • The error is handled by the first error scope whose condition evaluates to true

• Specifying scope execution for specific error types

  
  Specify Error Types

  • Set the type to ANY (the default) or one or more types of errors

• Specifying scope execution upon a specific condition

  • Set the when condition to a Boolean DataWeave expression

    • error.errorType.namespace == ‘HTTP’
    • error.errorType.identifier == ‘UNAUTHORIZED’
    • error.cause.message contains ‘request unauthorized’
    • error.cause.class contains ‘http’

• Walkthrough 5-3: Handle specific types of errors

  • Review the possible types of errors thrown by different processors
  • Create error handler scopes to handle different error types

Handling errors at flow level

Topic video

• Defining error handlers in flows

  
  Defining Error Handlers in Flows

  • All flows (except subflows) can have their own error handlers
  • Any number of error scopes can be added to a flow’s error handler
  • Subflows do not have error handling, and errors therein are handled by the calling flow

• Which error scope handles an error?

  • If a flow has an error handler

    • The error is handled by the first error scope whose condition evaluates to true

    • If no scope conditions are true, the error is handled by the Mule default error handler NOT any scope in an application’s default error handler

      • The Mule default error handler propagates the error up the execution chain where there may or may not be handlers

  • If a flow does not have an error handler

    • The error is handled by a scope in an application’s default error handler (the first whose scope condition is true, which may propagate or continue) otherwise it is handled by the Mule default error handler

• Error handling scenario 1

  
  Error Handling Scenario 1

• Error handling scenario 2

  
  Error Handling Scenario 2

• Error handling scenario 3

  
  Error Handling Scenario 3

• Error handling scenario 4

  
  Error Handling Scenario 4

• Error handling scenario 5

  
  Error Handling Scenario 5

• Walkthrough 5-4: Handle errors at the flow level

  • Add error handlers to a flow
  • Test the behaviour of errors thrown in a flow and by a child flow
  • Compare On Error Propagate and On Error Continue scopes in a flow
  • Set an HTTP status code in an error handler and modify an HTTP Listener to return it

Extras

• Error Handling Explained | Lightboard Series

<!--list-separator-->

-  Is just like error handling in programming languages like Java

<!--list-separator-->

-  When an error occurs in a flow

    <!--list-separator-->

    -  Execution stops

    <!--list-separator-->

    -  Looks for how to handle the error

        <!--list-separator-->

        -  If there is a predefined error handler, it will handle the error using the set conditions

        <!--list-separator-->

        -  If there is no error handler defined, it will fall back to the caller, e.g. the HTTP Listener, Flow Reference, Try Scope, etc., and the caller itself becomes an error

<!--list-separator-->

-  There are two types of error handling scopes

    <!--list-separator-->

    -  On Error Continue

        <!--list-separator-->

        -  Swallows or deal with the error

        <!--list-separator-->

        -  Converts the error into what appears like a success to the caller

        <!--list-separator-->

        -  Happy path: 200 OK, and payload is returned

    <!--list-separator-->

    -  On Error Propagate

        <!--list-separator-->

        -  It rethrows the error after executing the lines of code in the scope

        <!--list-separator-->

        -  It doesn't deal with the error, it just rethrows it, and the caller becomes an error

        <!--list-separator-->

        -  It's like an unhandled error, and someone has tod deal with it further up

        <!--list-separator-->

        -  Unhappy path: 500 error, and error description

<!--list-separator-->

-  The error handling tries to find a matching condition using the filters in the filters, using different error types

<!--list-separator-->

-  Multiple flows calling other flows/ nesting of calls

    <!--list-separator-->

    -  Focus on where the error occurs, that's where execution stops, and an error is looked for

    <!--list-separator-->

    -  If there is no error handler, and there's no global default defined for the application, it will bubble up and the caller becomes an error if it's On Error Propagate, and success if it's an On Error Continue

    <!--list-separator-->

    -  If no error handler is not defined where it was suppossed to have been defined, e.g. in Try scope or Flow error handling section, and you define a global default error handler, it will fall back to that, it's only there if there is **no error handler defined at all**, not after default in the sense that it's a fall back after it has tried to handle the errors

<!--list-separator-->

-  Always start where the error occurs and reduce the problem down

Handling errors at processor level

Topic video

• Handling errors at the processor level

  
  Try Scope Error Handling

  • For more fine grain error handling of elements within a flow, use the Try scope
  • Any number of processors can be added to a Try scope
  • The Try scope has its own error handling section to which one or more error scops can be added

• Error handling behaviour in the Try scope

  • On Error Propagate

    • All processors in the error handling scope are executed

    • At the end of the scope

      • The rest of the Try scope is not executed
      • If a transaction is being handled, it is rolled back
      • The error is rethrown up the execution chain to the parent flow, which handles the error
    • An HTTP Listener returns an error response

  • On Error Continue

    • All processors in the error handling scope are executed
    • It swallows up the error and returns a success

    • At the end of the scope

      • The rest of the Try scope is not executed
      • If a transaction is being handled, it is committed
      • The event is passed up to the parent flow, which continues execution
    • An HTTP Listener returns a successful response

  • Try scope: Error handling scenario 1

    
    Try Scope Error Handling: Scenario 1

  • Try scope: Error handling scenario 2

    
    Try Scope Error Handling: Scenario 2

  • Try scope: Error handling scenario 3

    
    Try Scope Error Handling: Scenario 3

  • Walkthrough 5-5: Handle errors at the processor level

    • Wrap the Flow Reference in each branch of a Scatter-Gather in a Try scope
    • Use an On Error Continue scope in each Try scope error handler to provide a valid response so flow execution can continue

Mapping errors to custom error types

Topic video

• Mapping errors for more granular error handling

  • If an app has two HTTP Request operations that call different REST services, a connectivity failure on either produces the same error

    • Makes it difficult to identify the source of the error in the Mule application logs
  • To differentiate between these two errors, you can map each connectivity error to different custom error types
  • These custom error types enable you to differentiate exactly where an error occurred

• Mapping errors to custom error types

  • For each module operation in a flow, each possible error type can be mapped to a custom error type

  • You assign a custom namespace and identifier to distinguish them from other existing types within an application

    • Define namespaces related to the particular Mule application name or context

      • CUSTOMER namespaces for errors with a customer aggregation API
      • ORDER namespace for errors with an order processing API
    • Do not use existing module names
    • Identifiers and namespaces must consist only of capital leters and underscores

  • Walkthrough 5-6: Map an error to a custom error type

    
    Mapping an Error to a Custom Error Type

    • Map a module error to a custom error type for an application
    • Create an event handler for the custom error type

Reviewing and integrating with APIkit error handling

Topic video

• Error handling generate by APIkit

  • By default, interfaces created with APIkit have error handlers with multiple On Error Propagate scopes that handle APIkit errors

    • The error scopes set HTTP status codes and response messages

  • The main routing flow has six error scopes

    
    Error Handling Generated by APIkit

    • APIKIT:BAD_REQUEST > 400
    • APIKIT:NOT_FOUND > 404
    • APIKIT:METHOD_NOT_ALLOWED > 405
    • APIKIT:NOT_ACCEPTABLE > 406
    • APIKIT:UNSUPPORTED_MEDIA_TYPE > 415
    • APIKIT:NOT_IMPLEMENTED > 501

• Integrating with APIkit error handling

  • You can modify the APIkit error scopes and add additional scopes

  • You also need to make sure the error handling in the application works as expected with the new interface router

    • On Error Continue

      • Event in implementation is not passed back to main router flow

    • On Error Propagate

      • Error in implementation is propagated to main router flow

        • Payload and variables are propagated as well

      • Walkthrough 5-7: Review and integrate with APIkit error handlers

        • Review the error handlers generated by APIkit
        • Review settings for the APIkit Router and HTTP Listener in the APIkit generated interface
        • Connect the implementation to the interface and test the error handling behaviour
        • Modify implementation error scopes so they work with the APIkit generated interface

Handling system errors

Topic video

• Applications can have two types of errors

  • Messaging errors

    • Thrown within a flow whenever a Mule event is involved

  • System errors

    • Thrown at the system-level when no Mule event is involved

    • Errors that occur

      • During application start-up
      • When a connection to an external system fails

    • Handled by a system error handling strategy

      • Non configurable
      • Logs the error and for connection failures, executes the reconnection strategy

• Reconnection strategies

  
  Reconnection Strategies

  • Set for a connector (in Global Elements Properties) or for a specific connector operation (in Properties view)

• Walkthrough 5-8: Set a reconnection strategy for a connector

  • Set a reconnection strategy for the Web Service Consumer connector

Summary

An application can have system or messaging errors

System errors are thrown at the system level and involve no event

• Occur during application start-up or when a connection to an external system fails

• Non-configurable, but logs the error and for connections, executes any reconnection strategy

Messaging errors are thrown when a problem occurs within a flow

• Normal flow execution stops and the event is passed to an error handler (if one is defined)

• By default, unhandled errors are logged and propagated

• HTTP Listeners return success or error responses depending upon how the error is handled

• Subflows cannot have their own error handlers

Messaging errors can be handled at various levels

• For an application by defining an error handler outside any flow and then configuring the application to use it as the default error handler

• For a flow, by adding error scopes to the error handling section

• For one or more processors, by encapsulating them in a Try scope that has its own error handling section

Each error handler can have one or more error scopes

• Each specifies for what error type or condition for which it should be executed

An error is handled by the first error scope with a matching condition

• On Error Propagate rethrows the error up the execution chain

• On Error Continue handles the error and then continues execution of the parent flow

Error types for module operations can be mapped to custom error types

• You assign a custom namespace and identifier to distinguish them from other existing types within an application

• Enables you to differentiate exactly where an error occurred, which is especially useful when examining logs

By default, interfaces created with APIkit have error handlers with multiple On Error Propagate scopes that handle APIkit errors

• The error scopes set HTTP Status codes and response messages

• You can modify these error scopes and add additional scopes

• Use On Error Continue in implementation to not pass event back to main router

• Use On Error Propagate in implementation to propagate error to main router flow

Test your knowledge

Anki

Links

• Anypoint Platform Development: Fundamentals - Part 2 Building Mule applications with Anypoint Platform

References