Global exception Alerts in webMethods

Overview

In the world of complex integrations, seamless data flow between systems is critical. But what happens when something goes wrong? An unexpected failure in any of your integrations can disrupt business operations and cause significant delays. That’s why it is always essential to have an alerting system.

When an interface exception occurs, it’s not just a glitch—it’s a call to action. Having a system that instantly detects and alerts you to these exceptions allows you to respond swiftly and efficiently, minimizing downtime and preventing cascading failures across your processes. While we can write email alert logic in individual interfaces to send notifications or create tickets with exception details, it’s more efficient to have a single code base that handles exception notifications. This approach requires no changes to existing or new integrations. Whenever an exception occurs and control passes to the catch block, our centralized code base will receive the exception details automatically.

This article explores how to set up real-time exception alerts across multiple integrations in webMethods, ensuring you stay ahead of potential disruptions and maintain control over your operations.

Prerequisite

• Basic understanding of webMethods flow service.

Configuration for Exception notification

• Update Extended settings
  webMethods provides the ability to register an exception handler service, which will receive all exceptions that occur in any flow service. To control this behavior, we need to update the watt.server.event.exception.async extended property.This property specifies whether event handlers for exception, error, or journal events are invoked asynchronously or synchronously. When set to true, the Integration Server invokes the event handlers (services) that subscribe to exception events asynchronously. When set to false, the Integration Server invokes the event handlers synchronously. By default, this parameter is set to true, Please check official documentation for more information.
  • Login to the webmethods Administration page.
  • Navigate to the ‘Extended Settings page’ under the Settings tab.
  • Search for ‘watt.server.event.exception.async‘ extended property and set the value to false.
  • Restart your integration so the changes take effect.
• Create a service to handle Exception Event
  • Open webMethods Designer and navigate to your server.
  • Create a package.
  • Create a flow service in your package.
  • In the Input/Output section of your flow service look for the Specification Reference section and insert the Input using ‘pub.event:exception‘ specification, this will refer to necessary inputs which the service will receive in runtime.
  • Invoke ‘pub.flow:getCallingService‘ service inside your service.
  • Invoke ‘pub.flow:debugLog‘ service and log ‘Service : %svcName% Error : %error%‘, and make sure that you have checked the variable substitution option.
  • As part of this article, we will log only the error and the service name where the exception occurred. Once we have this information, we can create a framework to send notifications. Additionally, we can control which services should trigger notifications, who should receive them, and which parameters to collect from the pipeline—all of this can be managed within the framework.
• Register Event Handler
  • Navigate to Designer, switch to the Service Development perspective, right-click on the server, and go to the Properties section.
  • Select “Exception Event” from the drop-down menu, then choose the service you created in the previous step. Make sure to enable it, apply the changes, and close it.
    
    
  • Now, if any service throws an exception, the exception details will be received in our registered service, even if the service implements a try-catch block.
  • We have created a service to test the Exception event listener, let’s run it.
  • Testing result :

Conclusion

We will come up with a few more articles to create a framework that allows us to specify alert criteria, with alerts being sent based on the specified criteria. Please see the video below for an overview.

Hope you have enjoyed this article! 🙂