· Mar 3, 2023

Limiting IRIS error notifications


I have an issue I could use a little help with. The other day, there was a connection problem with a client, and when trying to update information, we received 75 email notifications that there was a connection problem. I have looked in documentation, and the items on managed alerts might be a solution. However, I know some places have a system where then limit the number of messages of a particular error sent via the Ens.alert process/operation. I'm trying to determine what text should be considered for a message to be "identical". For example, if there's a problem with a request for member 100, and the same issue occurs with member 200, I would like to count that as one problem, not two.

Has anyone had experience with this, and come up with a good solution for this?  I'd appreciate the feedback.

Product version: IRIS 2022.1
$ZV: IRIS for Windows (x86-64) 2022.1 (Build 209_0_21912U) Mon Sep 19 2022 17:04:56 EDT [Health:3.5.0]
Discussion (2)2
Log in or sign up to continue

The included IsRecentManagedAlert() method expects a recent alert to have 100% identical SourceConfigName and AlertText values. Probably not suitable for your application.

Unfortunately, I haven't run into a scenario such as you describe where errors from multiple business hosts must be aggregated into one.

I can envision a solution where you would identify this group of business hosts under a single Managed Alert Group, log activity for alerts in that group to a table or global via Ens.Alert's routing rule, and check the table/global for prior activity from that alert group in the in that same rule for the desired time span. Matches could then be suppressed.

Since Managed Alert Groups aren't a property of Ens.AlertRequest, you would need to interrogate the business host (production item) for its membership from the rule.

 So you'd need to create a table/global, write some methods (in a class extending Ens.Rule.FunctionSet) to query your custom table/global for prior alerts and log the current alert, then configure a routing rule to check for the existence of prior activity on the selected Alert Group, log the current activity, and suppress or send the alert based on your criteria.