IntegrationHUB ETL and business rules on cmdb_rel_ci

Amar_Be
Kilo Sage

Hi,

 

I'm using the IntegrationHub ETL (IHETL) to update CIs and create relationships.

The CIs are updated correctly and the relationships created as expected.

But the Business rules defined on the table cmdb_rel_ci are not triggered by the IHETL when the relationships are created.

 

I've created a very simple test BR that just log the action that triggered the BR.

When the relationships is created manually, the BR is triggered.

When the BR is on a CI class (cmdb_ci_ups, for instance), it is triggered by the IHETL.

But when it is on the CI relationship class, IHETL do not trigger the business rules.

 

I'm on Washington release.

Does anyone have an idea on the cause or solution of this issue?

1 ACCEPTED SOLUTION

I've reached out to ServiceNow Support, and they have directed me to KB0694512 which confirms that this has happened for a long time (since Jakarta in fact), and gives the system property to use to enable workflow.

@Amar_Be I do agree that it seems odd to make it standard behaviour that business rules shouldn't run in this situation, which makes it different to every other situation when a CI relationship record is created/updated/deleted.  But at least there is a workaround we can use if we want.

View solution in original post

10 REPLIES 10

Sandeep90
ServiceNow Employee
ServiceNow Employee

Its not that its disabled completely but its not enabled by default, if you want that behavior you can enable it to run BRs even on relationships inserts/updates. 

I've reached out to ServiceNow Support, and they have directed me to KB0694512 which confirms that this has happened for a long time (since Jakarta in fact), and gives the system property to use to enable workflow.

@Amar_Be I do agree that it seems odd to make it standard behaviour that business rules shouldn't run in this situation, which makes it different to every other situation when a CI relationship record is created/updated/deleted.  But at least there is a workaround we can use if we want.

Thank you mbourla,

 

I've also have a case opened at the support, since 1 weeks.

They are still investigating... 🤔

 

I will update the CI creation process to have the code executed on the newly created relationships.

 

Hi again @Sandeep90 - you proposed having the BR on the CIs instead of the relationship.  Last week I did see that when my integration created a relationship, the parent CI had its sys_updated_on and sys_updated_by updated.  I didn't check the child CI.  I worked out that although the ETL map hadn't made any changes to the parent CI (because it was just creating the relationship to it), IRE had set last_discovered and discovery_source, and that is why the CI had been flagged as being updated.

 

However, if I try it again today, it's creating new relationships but is not updating last_discovered and discovery_source.  I don't understand why the behaviour has changed since last week - maybe it's because originally the discovery_source was empty and got set, whereas now it's already correct so there's no change to it.  But that means I can't use a BR on the CIs instead of on the relationship.

 

We're reluctant to use that system property glide.identification_engine.insert_relation_disable_workflow, in case it degrades system performance for other integrations or discovery that create relationships.  So I'm going to have to use some other approach that doesn't involve business rules.

 

But if I've misunderstood anything, and I can indeed have the BR on the CI, please let me know.

 

Thanks

Michael

Sandeep90
ServiceNow Employee
ServiceNow Employee

We always update the CI using glide record so it should run everytime, again you can use the BRs on relationships but just be cautious on how you implement it and restrict the scope of when it runs to only to your scenario.