doug_schulze
ServiceNow Employee
ServiceNow Employee

We all may be familiar with the process of transferring from patterns to probes that I outline here

 

This process executes scripts that will build appropriate relationships that the full Identification and Reconciliation Engine (IRE) expects so not to create duplicate records.  This is because in the old world of probes and sensors we would really only coalesce on the primary class (compute, network gear, etc) record and look at references for the supporting CI's that base class record contained.

In the world of patterns that was changed to now have the requirement to actually identify many supporting components through their own identifiers that the probes and sensors didn't require previously.  If we look at the current hardware identifier in London we can actually discern between the two worlds. Identifier Entries and Related Entries.

 

  

If we focus on Identifier Entries tab you can consider this what the Probes and sensors would use to identify the base class device. Related entries were/are not used for probes and sensors  So anything extended from Hardware would use these Identifier Entry rules to match on say, the compute records name only, and do its magic that Tom and Aleck always meant for us. Was a good day, we could rely on just the hardware rule, modify it for everything 'south' of hardware or even create a custom rule for a class that had special handling requirements as we did in the "horse-drawn discovery" days. All was good.

Moving to patterns

Well now came along our Patterns and their special requirements to need their own identification rules.  Items such as identifying items in the Serial Number table (cmdb_serial_number) or the Switch Forwarding Table (discovery_switch_fwd_table) for network gear.  This is required when building References or relationships in patterns among other things such as hosting and containment rules. We'll leave the latter out of the conversation for they really only come into play when you're creating brand new classes so we will focus on things we mess with 99.100% of the time, OOB classes. But it is important to remember the entire payload goes through the IRE, a process that promotes the accuracy and integrity of the CMDB.

We can see an example pattern step where these rules would be looked for in the Windows OS server pattern. If you look real close you will see on the form, the blank space on the right (in white font) it says this step needs an identifier rule (kidding, its not there and why I write)

 

 

So Imagine this scenario.

You have been doing discovery for the past 8 years and you are ready to switch over to patterns knowing that's the direction ServiceNow is going in its development. You have contacted support, they have run the appropriate scripts, disabled your probes in the classifiers and enabled the OOB patterns to do the good work from here on out. 

NOTE:  Probes and Sensors aren't going anywhere completely, it's just that all future development is focused on patterns. As of current builds, you will still need your Active Connections and Installed software probe enabled.  The patterns do not collect this information, so keep them enabled.

But what you didn't think of was that you had maybe modified your OOB hardware identifier or had created an identifier for a child class from hardware.  Maybe you didn't want to use the serial number table to be evaluated in the BASE CLASS identification, so you removed it or disabled it.  Well when that windows server pattern runs you are going to get an error in the pattern log that reads 

"Relation and/or reference table cmdb_serial_number is not a known CI Type. Check the discovery logs for more details". 

This should be your first clue that there is something amiss and where we start talking about the Related Entries tab of our identifier.

 

These items do NOT measure the Base Class identification, they are there to support the pattern requirements in building the references and relationships and their identification requirements.

So you might be thinking, hey Doug, that's a great screenshot but our scenario we're talking about the serial number table not being needed in our Windows Server (class) identification I don't see anything about serial number table in that list.....

Well, reader, that is an astute observation. That is because that serial number table identifier is OOB over on the Identifier Entries tab. Here's where the plot twists.  Patterns will use the Identifier Entries tab for the base class device identification.  THEN use the Related Entries tab in combination with the Identifier Entries when looking for reference/relation identification rules.

So in our scenario when you see an error like that (or more appropriately, take the good admin steps beforehand) all you have to do is move that serial number table rule over to the Related Entries tab (if you do not want it used in your base class identification) and Voila!.

But what about custom identifiers I created?  You may ask. Well as you go through the process of the transition just remember to be sure to add the entries you see in the OOB hardware Related Entries tab to your custom identifier.  KEEP your primary class rule (Identifier Entries) intact, but add these others to the Related Entries. 

Now as we all have some level of common sense, we know if you have a custom identifier for say your Windows Servers, Switch forwarding rules aren't going to come into play and aren't going to be needed.. But the rule of Doug says to keep things consistent.  One constant is, of course, our Serial Number table example.

Hope this helps de-mystify one aspect of the IRE.

 

 

 

Comments
bernyalvarado
Mega Sage

Hi Doug, great article!! As a heads up... it appears that you added/uploaded some images that appear to be broken in the article.

Thanks,

Berny

doug_schulze
ServiceNow Employee
ServiceNow Employee

Fixed.. TY my friend.. 

bernyalvarado
Mega Sage

anytime buddy! 🙂

robertgeen
Tera Guru

Great article that should be a mandatory read for anyone doing Discovery/Service Mapping work. Great as always Doug!

DuaneNMore
Kilo Guru

SO because of a peculiar problem with SAP HANA and virtualization of SusE Linux I created an identificatoin rule for Linux, Name, Serial_number. I encountered the problem described above, and foolishly I thought it would only apply to related_entries that were invloved in identification, so I added a related Entry in my Linux Identification Rule: 

find_real_file.png

I ran a quick Discovery and got back a "Identification sections in pattern failed: section: discovery, error: Relation and/or reference table discovery_net_arp_table is not a known CI Type. Check the discovery logs for more details.. " error. 

Does this mean that in order to have a custom identification rule, I am going to have to make a create a Related Entry for Everything in the Linux Pattern and called Pattern Libraries that has a relation_reference pattern step? I am going to need to make one for Memory Modules, Storage, Red Hat Cluster, Network ARP Tables, Installed Software, and Network? Aren't these defined in Related Lists somewhere or something?

Also for a test I tried to set the Pattern Active=False for some of the Libraries. Rather than just skip it, it fails and says it can't find it. 

 

 

 

doug_schulze
ServiceNow Employee
ServiceNow Employee

Duane, this "should" only come into play when moving over to patterns but as you are seeing. Yes, it seems that would be the path to take. If you add all the related entries that you find in the 'Hardware' rule including the network arp table that you see at the bottom...As I mention in the post... keep it all consistent!

 

find_real_file.png

mikemorales
Kilo Guru

Hey Doug,


Great article, greatly appreciate the information!  I just wanted to point out that the referenced kb on HI is currently not available due to You do not have sufficient privileges to access this knowledge item.  Just wanted to let you know.  I am going to open a HI ticket to see about gaining access at the same time.

 

https://hi.service-now.com/kb_view.do?sysparm_article=KB0694477

 

Thank you!

Mike

doug_schulze
ServiceNow Employee
ServiceNow Employee

Thanks Mike, yeah thats on purpose as we get the methods locked down as per the update at the top.  Hang tight, we will have it all worked out soon.  And (shameless plug) you can look forward to my Probes to Patterns Lab at K19 🙂

johnnyjava
Kilo Guru

I knew when I made this identifier entry on cmdb_ci_ip_switch that it wouldn't be this simple.

So glad this convo was here.

-J

P.S. - Stacked Switches are fun. I recommend overriding the name on hardware rule since they all tend to have the same name. Also I recommend NOT allowing the Pattern to add the Serial to the name, esp if your Networking team already had their own way of naming switches within the stack.

BachAF
Tera Contributor


Awesome article @doug.schulze Thank you very much for sharing the knowledge. We ran into similar issues as soon as we migrated Discovery from probe to pattern like the below errors:
"to fix Reference between discovery_net_arp_table to cmdb_ci_win_server
2021-08-19 20:46:51: Relation and/or reference table discovery_net_arp_table is not a known CI Type. Check the discovery logs for more details."


"Ref/Rel between discovery_net_arp_table and Linux CI
2021-08-20 07:36:16: Relation and/or reference table discovery_net_arp_table is not a known CI Type. Check the discovery logs for more details."

Your well-written article saved us tremendous troubleshooting time.

Much appreciated.

Bachtiar

chanyuk
Tera Explorer

Hi Doug,

 

I am unable to view the image in your post.   Could you please update the original article with the images?

doug_schulze
ServiceNow Employee
ServiceNow Employee

Yeah, can't control community team changes and will see what I can do to add additional images but hope the narration can get you by until I can.

Casey F
Tera Contributor

@chanyuk Realized it's been a while, but stumbled on this thread as well. 

I found Doug's YouTube channel which has a section referencing this post - starting around 40minutes in as well as a lot more detail around everything regarding probes to patterns. 

Related Video: https://www.youtube.com/watch?v=SNfydRlTb4o

This should have a lot of the examples you're looking for and for others needing the images, etc.

@doug_schulze if I'm off-base here, definitely let me know -> i'll edit the post!

Version history
Last update:
‎01-16-2019 10:10 AM
Updated by: