top of page



How to integrate Solace PubSub+ Cloud with MuleSoft - Negative Scenario (Error Handling)

GitHub repository with the Mule project can be found at the end of the post.

In my previous post (How to integrate Solace PubSub+ Cloud with MuleSoft), I explained the happy path of the Solace PubSub+ and MuleSoft Integration. In this post, let us see how we can handle an error efficiently.

Even though the error handling logic varies depending on use cases, business requirements, organizational processes, etc. I believe the core approach to error handling for message-based integrations would more or less remain the same for different applications.

The most common approach consists of the following steps:

  1. In case of an error, the error is captured in the error handler logic.

  2. Enrich the message with additional information that could be later used for reprocessing.

  3. Keep track of the “deliveryCount” and other useful information in the “User Properties.”

  4. Publish the message to an Error Topic for retrying.

  5. Process the message from the error queue and depending on the “redelivery_count” attribute, either route it back to the source queue or the dead letter queue (or Dead Message Queue). Further reprocessing can happen by the operations team.

Let us see how I have implemented the above approach in the following use case. Before that, please take a look at my previous blog post on how to publish the message to the Solace Topic using the JMS “Publish” connector.

1) The message is received by the “On New Message” JMS Connector. The incoming message is transformed in the “Request Transformation” component, While attempting to create the Salesforce Account using the “Create” connector, there is an error (in case the account already exists). The choice router validates if a successful response is received from SFDC. In case of failure, an error is thrown.

(Note that you can also add an “Until Successful” block around the “Create” SFDC connector to retry for a specified amount of time before throwing an error.)

The error is caught in the “On Error Propagate” error handler and invokes the “processSFDCError” flow.

In case of Salesforce Connectivity error, then the error is thrown in the “Create” SFDC connector and caught in the “SFDC:ERROR” (On Error Propagate) as the error mapping is done in the connector level as shown in the following screenshot.

2) The message is published to the Error Topic as shown in the following screenshot:

Note that I am capturing the “DELIVERYCOUNT”, “EXCEPTIONDETAILS” and “TIMESTAMP” in the “User Properties” field.