Plekton Error Handling Framework v1.0
Save Time, Effort, Money
The Plekton Error Handling Framework is a collection of application-components that facilitate the handling of errors produced by any Mule application. This includes both technical and business errors.
MuleSoft is one of the biggest contributors in the integration world that provides a complete API eco-system. With its huge popularity, organizations are building hundreds of API endpoints over a short period of time. Each of these APIs have one thing in common: they need to handle errors. The objective of the Plekton Error Handling Framework is to centralize the error handling mechanism and to provide operation units facility to identify and configure the error handling rule. The current framework incorporates replaying, email notification and support ticket creation features.
Why do you need it?
- Reduces development effort and hours, which eventually saves money.
- Separates error handling logic from the application, making maintenance simpler.
- Enhances the agility of the team to bring new products and features as the team does not need to consider error handling.
- Gives better visibility as to why an error occurred.
- Enables replay of an asynchronous process (ETL, batch etc) by itself. It can be used to resolve intermittent network errors.
- Has the ability to send an email with the error details to your center for enablement (C4E).
- Has the ability to create an issue ticket by itself and assign it to a group in the center for enablement (C4E).
- It’s very easy to install, easy to manage and easy to customize.
- Error handling rules are configurable.
Main working principle:
Whenever an error occurs, the application forwards the error to an asynchronous service named service-error-orchestrator. Based on a set of configurable error handling rules, the error-orchestrator-service can send the error to service-replay, service-email-notification and/or service-issue-ticket.
Collect the original HTTP client request and error context and send it to queue_errors.
Listen for messages from queue_errrors and then, based on the configurable rule, send the error message to queue_errors_replay, queue_errors_email, and/or queue_errors_issue_ticket.
Service-replay, service-email-notification, service-issue-ticket:
Our team is working on v2.0.
The key features of the next version:
- Centralized logic using the database.
- Persisting error history in the database.
- Producing error reports.
- Extended configuration facility.
- Focused on the operation team user perspective.
- Adding delay between replays
- Adding GUI to monitoring and report.