Find your people. Pick a challenge. Ship something real. The CreatorCon Hackathon is coming to the Community Pavilion for one epic night. Every skill level, every role welcome. Join us on May 5th and learn more here.

Event Management CI binding issue for mixed host and non-host CI classes in event rules

surasub
Tera Contributor

3 weeks ago

Hi Team,

I’m facing a CI binding issue in ServiceNow Event Management and would appreciate guidance on the best scalable design.

Scenario

We receive ProdMon database events where the Node field contains the CI identifier value (for example: tstmuse2azsql01).

The same logical CI identifier can exist in:

  • Hardware class (cmdb_ci_hardware extended classes)
  • Non-host classes (for example cmdb_ci_cloud_database)
  • potentially many more non-host CI classes in future

The goal is to ensure the alert CI always binds correctly, even when the event node does not belong to a hardware class.

 

Current configuration

I currently have 2 event rules:

Rule 1 — Hardware binding

  • Order: 100
  • Binding type: CI Identification
  • Class: Hardware
  • Criterion: name = Node

This works correctly for hardware CIs.

 

Rule 2 — Fallback for non-host CIs

  • Order: 200
  • Binding type: CI field matching
  • CI Type: Configuration Item / dynamic target class
  • Node: ${node}
  • Manual attribute: name = ${node}

This rule is intended as fallback for non-host CI classes.

 

Observed behavior

Case 1 — CI exists in both hardware + non-host class

If the CI identifier exists in both classes:

  • the hardware rule (100) binds successfully
  • alert CI gets populated
  • works as expected

Case 2 — CI exists only in non-host class

If the CI exists only in a non-host class:

  • alert gets created
  • CI remains empty
  • fallback rule does not populate CI

Case 3 — Remove Node from fallback rule

If I clear Node in the order 200 rule:

  • non-host CI binding starts working
  • BUT mixed-class scenario breaks
  • hardware + non-host precedence no longer behaves correctly

What I need help with

I’m looking for the recommended scalable OOB design for this use case.

Main challenge:

  • I cannot create separate event rules for every possible CI class
  • future classes may grow into hundreds/thousands
  • need one reusable fallback approach

Questions

  1. What is the best OOB way to bind non-host CIs dynamically?
  2. How should Node field precedence be handled when hardware and non-host classes share the same identifier?
  3. Is Event Field Mapping + dynamic CI Type the correct scalable pattern here?
  4. Has anyone implemented a generic fallback event rule for mixed CI classes?

Would really appreciate any community best practices or proven patterns.

Thanks in advance!

0 Helpfuls
  • 332 Views
1 REPLY 1

chris_f
Giga Expert

3 weeks ago

 

Ill attempt to help but i dont visit here often.

 

Youre not giving us all the info.

Does rule 1 and 2 have filters that are mutually exclusive?

Does rule 1 have 'apply additional' ticked? Presumably so if youre describing rule 2 as a fall back.

 

I believe your rule 2 is doing the binding.

Rule 1 doesnt bind, it passes to rule 2 (if apply is ticked above. You havent told us, but surely must be).

 

If you have NODE in the compose, it will use that typically. 

Your rule 1 does nothing.

Your rule 2 does everything

 

Case 1 - binds because of node value

case 2 - fails because node value looks at hardware cis  and cant find your service etc.

case 3 - You remove node, so it looks up using name and finds your service/other Ci type.

 

Thats my take anyway.

 

If you have a node value in your event rule, it doesnt ever seem to find non hardware CIs like services etc. I guess thats why it says to clear the node value in the binding page, when you choose 'CI field matching'

 

I think you also expect ticking apply other rules, to give you a fall back - I did too, it seems logical. 

However, it seems to just mean that the last rule is used for binding.  Rule 2in your case, hence why you have the strange behaviour.

 

I think your solution is probably going to require: 

Event field mappings 

and is there any way you can get the event sender/source to send in more information? 

 

If not, I think a scripted event field mapping will let you run your logic of something like

'Search cmdb_ci by name using $node' and return its ci_type and name on the additional_info object.

Then just have the 1 rule I think?

 

Or perhaps you can just have 1 rule, running on cmdb_ci table, and setup a identifier in ci class manager for name? 

 

Im a bit unclear by your event source really. It seems your source wont tell you what Ci type it is at all? 

So all you have is a name? but name in cmdb isnt a unique field 

 

maybe in your cmdb it is, and you can just have 1 rule that uses name for cmdb_ci? 

 

If you add more details to your post we can maybe help 

0 Helpfuls