Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Highlighted
Dilyan Honored Contributor.
Honored Contributor.
777 views

(OMi) Support Tip: Deduplication of Events based on attributes & usage of EPI scripts

In case a user does a deduplication of Events based on attributes and at the same time uses an EPI script (on step: Before Storing Events) to change the value of any of the attributes used for deduplication, this will cause deduplication to work not as expected.

 

If you have enabled:

Admin > Platform > Infrastructure Settings > Application=Operations Management > Operations Management - Duplicate Events Suppression Settings > Detect Duplicate Events by Identical Attributes=True

 

And then build an EPI script and added it in following EPI step:

Admin > Operations Management > Event Automation > Event Processing Customizations > EPI Step: Before Storing Events  

 

If the purpose of the script is to change an Event Attribute, for example replaces an IP address with DNS name in the Title of the event, then what happens is the following:

 

  1. An Event A is received with title "192.168.189.209 node down"
  2. Before the event is being stored in IMDB its title is being modified by the EPI script to "ahrt.hp.com node down"
  3. New event B with same title is received from same node "192.168.189.209 node down"
  4. Deduplication steps is reached in Event Pipeline and note that EPI step "Before Storing Events" is few steps after the Deduplication step in the Event Pipeline.
  5. Then what happens is that there is an event A stored in IMDB with already customized title "ahrt.hp.com node down" and for event B the title "192.168.189.209 node down" is still the original one at this step.
  6. Comparison on Title attribute along with others attributes (depending on "Infrastructure Settings > Operations Management - Duplicate Events Suppression Settings" configuration) is done and when Event B is compared to Event A the titles are not equal, hence event B is not considered as duplicate to event A.
  7. Then eventually "Before Storing Events" pipeline steps is reached and the title of Event B is also modified to "ahrt.hp.com node down", however the Deduplication step has been passed already and both events remains as separate, when they should have been duplicated.

 

The logs would not tell you that both events are having different Title and that they are not considered as duplicate because of that difference, the logs have info only about the original Event Title, whatever is modified in step "Before Storing Events" can only be seen in the IMDB.

 

When planning to apply EPI scripts you need to take in consideration the above example and other similar use cases, figure out on which EPI step would be best to apply the script, having in mind what the script will do for you and what steps of the Event Pipeline are executed prior and after EPI step and how the EPI script will affect these steps.

Here below is sumariazed screen shot of the Event Pipeline (it is made up for 9.2x but it applies to 10.x as well):

Regards,
Dilyan Angelov

Micro Focus Support
If you find this or any post resolves your issue, please make sure to mark it as an accepted solution.
If you liked the reply then please show this with KUDOs.
Labels (1)
2 Replies
Rabobank_NL Super Contributor.
Super Contributor.

Re: (OMi) Support Tip: Deduplication of Events based on attributes & usage of EPI scripts

Hi Dylian,

 

It's a nice picture and a good tip. What we face in a reality depends a lot on order of rules. In our environment we have a lot of different customization rules (user group assigment, EPI in 2 points, SBEC, run-book automation, forwarding), and sometimes we see, that somehow they overlap or make some changes to the event, where changes in previous or next step are not taken into account. So we face some unexpected effects and extra incidents in Service Manager.

 

It's also difficult to troubleshoot, because some interfaces update event without letting it know in Event history (SM sync or OO flows), and rules leave only partial trace in event history or log files. For instance, SM back sync gives only information about process ID (probably on SM side), but not event ID or which field it's trying to change, so we have to troubleshoot on basis of timestamps.

 

Also from the log files I see, that some event updates fail, because something else was busy with this event ("Data on the server has been modified in the background"). No retry is assumed in this case. It happens quite regularly.

 

Do you know the way to build in retry of some event pipeline steps or set a pause of some 5 seconds in between particular pipeline steps?

 

Thanks in advance.

Svetlana

Rabobank_NL Super Contributor.
Super Contributor.

Re: (OMi) Support Tip: Deduplication of Events based on attributes & usage of EPI scripts

BTW excuses for misspelling your name..

 

Looking at the picture once more, I wonder if the similar picture is available about order of automation steps (user group assigments, time-based automation, run-books, forwarding, notifications). We've got several of them, and the order of execution doesn't always look consequent.

 

Do you have any tips on this?

 

Regards,
Svetlana

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.