Use case: Exception Handler in financial transactions

Context

Imagine that a company's finance department needs to confirm whether each transaction processed by the payment system was successfully completed.

To do this, they rely on the following tools: the bank's API (REST module), the database, and Skyone Studio.

Unexpected issues may arise in any operation, such as payment authorization failures or inconsistent information. However, the finance department must verify each transaction, ensuring that payments are processed correctly and that the team is notified in case of errors. This facilitates monitoring and optimizes operational management.

In this documentation, we will explain how to use the "Exception Handler" feature to handle scenarios where the integration flow needs to continue even if some items encounter errors. Additionally, we will cover how to properly notify errors that occur throughout the flow execution.

Business Rule

When the REST module returns status code 422, it means the information is inconsistent.

When the REST module returns status code 400, the execution is expected to be terminated.

Technical Dictionary

HTTP Status code 422: Unprocessable Entity

HTTP Status code 400: Bad Request

Scenario without Exception Handler

Even if the status code indicates an error, by default, the platform does not consider it as such in REST cases. As a result, the transaction is inserted into the completed payments database, creating an inconsistency with the actual information.

Scenario with Exception Handler

With the "Exception Handler" functionality, any HTTP error will be captured and handled. By creating two independent Exception Handlers, we can differentiate the treatment: in the case of a 422 error, the system simply skips to the next transaction in the list, while in the case of a 400 error, the flow is interrupted.

Configuring the Exception Handler in Practice

After contextualizing our case, it's time to set up our flow.

Notice in the image below that we have a flow consisting of:

  • Webhook Trigger: The starting point and entry for the list of transactions to be processed by our flow.

  • Loop For: A tool module that facilitates the processing of lists of information.

  • REST Module: Validates the bank transaction, which will come as an element of the Loop For.

  • PostgreSQL: Records the completed payments.

When clicking on "Exception Handlers", we should click on "Add Exception Handler". The following screen will be displayed:

Based on the business rules mentioned above, we will add two Exception Handlers:

Status code 422: Unprocessable Entity

In "Handler General Settings", fill in the necessary details:

  • Handler Name: Unprocessable Entity

  • Handler Availability: Flow

Next, we will create a rule. To do this, click on "Add Rule" and fill in the following fields:

  • Rule Name: Status code 422

  • Attempts: 0

  • Waiting Time: 0

  • Regex code: "status": 422

  • Rule notifications: Local and Email

  • Message: Transaction not processed

  • Send parameters in the message? Yes

  • Final action: Continue loop

We finish the configuration by clicking "Save".

Status code 400: Bad Request

In "Handler General Settings", fill in the necessary details:

  • Handler Name: Transaction Bad Request

  • Handler Availability: Flow

Next, we will create a rule. To do this, click on "Add Rule" and fill in the following fields:

  • Rule Name: Status code 400

  • Attempts: 1

  • Waiting Time: 1s

  • Regex Code: "status": 400

  • Rule Notifications: Local and Email

  • Message: An error occurred during the transaction process.

  • Send parameters in the message? Yes

  • Final Action: Stop

We finish the configuration by clicking "Save".

Adding Exception Handler to the Component

After the Exception Handlers are created, it's time to activate them in the component. In this example, we will activate the Exception Handlers in the "Validate Financial Transaction" module. To do this, simply click "edit" on this component.

Next, on the left-hand side, you will see that the previously created rules appear in the "Exception Handlers" section.

For our use case, we will activate the newly created "Exception Handlers" and organize them in the following order:

  1. Unprocessable Entity

  2. Transaction Bad Request

Execution Result

After everything is set up, we run our flow. In "Logs", we can check the execution result.

  • Unprocessable Entity

  • Transaction Bad Request

Last updated