Michael Gosselin · Mar 3

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]
0 86
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.

Thanks, Jeff; that's a good basic guideline. I'll try that out on my system to see how it works. It probably needs more fleshing out.