Contents

Exception Handling for APIs. ................................................................................................................... 2

Standard Response Format ................................................................................................................. 2
Sample Response ............................................................................................................................ 2
Sample error codes and error messages ........................................................................................ 2
Implementation in Mule 4 .................................................................................................................. 3
Creating Global exception strategy................................................................................................. 3
Adding exception for the main flow. .............................................................................................. 4
Sample Code Snippet .......................................................................................................................... 5
Code for Mule 4 .............................................................................................................................. 5
Exception Handling for Emails. ............................................................................................................... 7
Design Diagram ................................................................................................................................... 7
Description .......................................................................................................................................... 7
 Exception Handling for APIs.
Standard Response Format
This section defines what the normal error output should look like except in the case when
consumer needs it to be in different format.

Sample Response
{

“errorCode”: “STS-400-INVALID_REQUEST”,

“errorMsg”: “Input Request is not valid. Please verify and try again.”

Sample error codes and error messages

Following table defines the HTTP codes, errorCode and errorMsg for the different request response
scenarios.

HTTP Code Error Code in Resp. Error Msg in Resp. Used When Comment
400 STS-400- Use default APIKit Input validation
INVALID_REQUEST message Error by APIkit
400 STS-400- Request have When parsing
INVALID_FORMAT invalid format the input fails
<exception>
400 STS-400- Request is invalid In Case any
BAD_REQUEST <exception> other expected
error comes
while
processing the
request. ex.
missing
information
404 STS-400-NOT_FOUND Record <id> not Unable to find
found. the requested
resource in the
system
500 STS-500- Unable to connect When unable to
CONNECTION_ERROR with <system> connect to the
endsystem
500 STS-500- Unexpected When there is
INTERNAL_ERROR exception is some
<exception> unexpected
failure during
the process.
Implementation in Mule 4
Creating Global exception strategy
Create the below mentioned error handler.

Set the dataweave code as shown below.

Mark the exception strategy created above as global by creating a configuration as show in the
image below.
Adding exception for the main flow.
As mentioned above for mule 3 code, the same logic is added in mule 4 with the help of request-
reply scopes. Taking the similar dataweave transformation code as sample. Find below the
screenshot of the same in mule 4.

Please not the use of try scope and error handlers “On Error Propagate” and “On Error Continue”.
The dataweave in error handling part is configured as shown below.

Additionally the variable httpStatus is also set as shown below.

 This variable is used in the listener component of http listener as shown below and is used to give
the final response status.

Sample Code Snippet

Code for Mule 4
As the code for mule 4 was larger, hence it is in two snippets. Snippet 1/2.

<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:http="http://www.mulesoft.org/schema/mule/http"
xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-
ee.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-
http.xsd">
<http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config"
doc:id="f627ea5c-95a4-4349-ae3f-8028ddc8088d" >
<http:listener-connection host="0.0.0.0" port="8081" />
</http:listener-config>
<configuration doc:name="Configuration" doc:id="aa3a59a0-00fc-4259-adca-4050ac74109e"
defaultErrorHandler-ref="sample-exception-handlingError_Handler" />
<flow name="sample-exception-handlingFlow" doc:id="a26e53ca-6b79-4c01-a04d-79b94018721d" >
<http:listener doc:name="Listener" doc:id="177149ab-742f-41d3-abcd-2aeec26f4804" config-
ref="HTTP_Listener_config" path="/api">
<http:response statusCode="#[vars.httpStatus default 500]" />
</http:listener>
<try doc:name="Try" doc:id="042d5041-66f4-4706-ad72-a0340f571f53" >
<ee:transform doc:name="Sample Transformation" doc:id="4ca9bb40-ca2f-4681-a3a9-
4f13dc131dde" >
<ee:message >
<ee:set-payload ><![CDATA[%dw 2.0
output application/java
---
"Sample Transformation"]]></ee:set-payload>
 Snippet 2/2

<ee:transform doc:name="Create Success Response" doc:id="942090b9-3149-451b-af57-b8e01747cb24">

<ee:message>
<ee:set-payload><![CDATA[%dw 2.0
output application/json
---
{
errorCode: "STS-200-SUCCESS",
errorMsg: "Request processed Successfully."
}]]></ee:set-payload>
</ee:message>
<ee:variables>
<ee:set-variable variableName="httpStatus"><![CDATA[%dw 2.0
output application/java
---
200]]></ee:set-variable>
</ee:variables>
</ee:transform>
<error-handler >
<on-error-continue enableNotifications="true" logException="true" doc:name="On
Error Continue" doc:id="ae8cb68f-01a2-41de-8f97-7fa1e546bab8" >
<logger level="INFO" doc:name="Log Error" doc:id="f62b65b1-ba1f-47f8-a719-
c4fe88fb5688" message="In Error Handling || Error is #[error] || Final Response is #[payload]"/>
</on-error-continue>
</error-handler>
</flow>
<error-handler name="sample-exception-handlingError_Handler" doc:id="77683ce6-cd3a-46a6-afb5-
8b4f3466c906" >
<on-error-propagate enableNotifications="true" logException="true" doc:name="On Error
Propagate" doc:id="34e275ef-2a56-424c-9bc3-e8ef1c81050f" >
<ee:transform doc:name="Create global error message" doc:id="f7bd2f62-09b1-4d9d-
9cff-da30a98d5a23" >
<ee:message >
<ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
{
errorCode: "STS-500-INTERNAL_ERROR",
errorMsg: error.errorMessage
}]]></ee:set-payload>
</ee:message>
</ee:transform>
</on-error-propagate>
</error-handler>
</mule>
 Exception Handling for Emails.
Design Diagram

* Things below the red line represents the error handling

Description
The system API will be response for passing the appropriate error message with the complete
information of error to the consumer API. Which can be either a process API or an Experience API.

If All three types of APIs are involved. Experience, Process and System the email logic should be
placed in process API.

So Process/Experience API can have two kind of failure scenarios either an exception while call the
system API. Or a partial success. If there is exception in the process as shown above, It will be
handled to read the error, log it and then create the appropriate email API request and call the email
API to send the email.

In case of partial success, Read the response of system API. And create the request for email API
using the failed records and send the required information to the email API to trigger the email.