CI Reconciliation rules for manual entry

[cloudyrobert]

I'm trying to use CI reconciliation rules to prevent users from manually updating a field that ServiceNow Discovery has set with a value. Mostly, I'm trying to understand how this works so that we can implement it for actual business cases, but take the example of IP. Let's say I want to prevent manual updates to a Windows Server's IP if the value has been set by Discovery. I've got this set up:

• Reconciliation Rules
• • Data source: ServiceNow
  • • Apply to all attributes: checked
    • Set to active w/ no filter condition
  • Data source: Manual Entry
  • • Attributes: Assignment group, Assigned to
    • Set to active w/ no filter condition
• Data Precedence Rules
• • Data source: ServiceNow
  • • Priority 100 & active
  • Data source: Manual Entry
  • • Priority 200 & active

It seems to do nothing. I can update the IP of a Windows Server manually with no problems. What am I missing?

[Abbey2]

Thanks Michael, any chance you can share a snippet of the custom BR used here?

Thanks.

[mbourla]

Hi Abbey,

Can’t really do a snippet but in case it’s of use here’s the code. As .txt files in case .js files aren’t allowed. There’s a business rule and a script include.

• Business rule “SP Apply Datasource Management” : this runs before insert and update on cmdb_ci. Have attached the description which contains more info, and the actual code. It calls function applyDatasourcePrecedence() in the script include.
  
  
• Script Include “sp_CMDBIntegrationUtils” : this contains the code to apply precedence to manual updates. Actually, it is also applied in another situation too, when I needed to have a transform map to process data where the OOTB CI Identifier was not independent so I couldn’t use it. There’s actually more in that script include (yes, it’s probably too long) but I’ve taken out the additional functions that don’t apply here.

As I mentioned in my previous reply in this thread, on reflection I should have done this differently. I am using the datasource precedence records and reconciliation definitions that IRE itself uses, to decide which fields the user can modify. It would have been better to assemble the input JSON from the fields on the CI form, call the scripted IRE API, see which fields weren’t actually modified and so were blocked by IRE, and display some suitable message to the user for those blocked ones.

Also I have just recently found that in Paris the datasource precedence rules have been deprecated, and are replaced by the Priority on the reconciliation definitions. I found that because upgrading to Paris caused all but one of the datasource precedence rules to be made inactive. I raised a HI ticket, the response being that datasource precedence rules aren’t used any more. It is in the Paris release notes, but isn’t very conspicuous.

So I will now either need to update my code to use the Priority on the reconciliation rules, or change the whole approach. For the moment I’ve left the datasource precedence rules active (ServiceNow said they are ignored in Paris so it doesn’t matter if they are active or inactive), and luckily my code for controlling precedence for manual CI updates still works for now.

Hope this is of use.

Regards
Michael

P.S. In case you were wondering what the “SP” at the beginning of the names is, we have branded our ServiceNow instance as “Spark”. That’s what all our users know it as, and we prefix names of business rules etc with “SP”.

[mbourla]

This is an old thread now, but an update from me... previously I mentioned that I had implemented reconciliation for manual updates to CIs by emulating what IRE itself does.  At that time I thought it might have been better to get the business rule to call the scripted IRE to do the reconciliation, instead of me replicating the equivalent functionality.  That's what I've now done - the business rule assembles the IRE input payload to include all the changed fields, creates any necessary reconciliation rules for those fields if they don't already exist, calls IRE, and tells the user if any field updates were blocked by IRE because a higher precedence (i.e. lower Priority) source last updated that field,.  Finally it ensures ServiceNow doesn't go ahead and itself do the CI update again (but without doing .setAbortAction(true) because that always displays "Invalid update" which I didn't want to happen).

[Chris Hagy]

I would be interested to see any updated code you use to accomplish that as I think it would be very helpful to some situations we have as well.

[mbourla]

Hi Chris,

Here's the business rule. For completeness, I've copied the Description from the BR in at the top of the code. 

It should work for anyone pretty much as-is, but one thing to note is that we split up our IRE reconciliation rules so that each attribute is listed on the rule on the table where that attribute is defined.  That's because rules on child tables always take precedence over rules on parent tables, which leads to valid updates being blocked just because that attribute happens to be listed on a reconciliation rule on a child table.  It's a strange design I think.  But to avoid that we always make sure each attribute only ever appears on rules for the same table, namely the table where that attribute.  If that isn't what you do, then function _ensureReconRulesExist() isn't going to work as-is for you.

Regards
Michael