How to stop a Before-Query Business Rule running on child tables

oacp · ‎11-04-2016

I have a before-query business rule that runs on the IT Service table. However, since Service Component is a child table of the IT Service table it is running on Service Component as well and subsequently blocks all the data since the query in the BR is only set up to align with IT Services.

Since I don't have access to 'current' in a before-query business rule, I cannot specify in the condition that the BR should only run if the current table is the IT Service table since you can only really mention user or session specific details in the condition field.

How can I stop the before-query business rule running on the child table?

LaurentChicoine · ‎11-04-2016

Hi Olivia,

You have access to current.getTableName() inside a query business rule.

So you can add a condition on your query business rule to only run on that parent table using current.getTableName() == 'name_of_table'

Also if you want to see all of your records of Service Component when in IT Service table you should simply add a OR condition to include other tables by making a condition including every records where sys_class_name is not IT Service. In encoded query or with an addOrContion('sys_class_name', '!=', 'name_of_table')

View solution in original post

Yadin · ‎05-24-2020

Ah ok, I see. so when I change the print to be "true" instead of the value, then I do get an expected results. So we return to why does this work reliably in the background script test, but not in the transform map. The fact that it is seemingly random instead of just working or failing is the most baffling part.

Yadin · ‎05-24-2020

one other question... you don't have an else in your example... is SN behaving oddly simply because of using an else?

if(check2.hasNext()){
return source.u_computername;
}
else return "";

Can I remove else and just have the return and it still works the same way as you indicate? Why would else mess it up?

Yadin · ‎05-24-2020

Well I think this is more complicated... there seems to be a business rule that is what is actually causing the problem. It seems to fire erratically and seemingly erroneously. I'm assuming it's failing to consider the parent child relationships properly and stoping the import (again randomly, not all the time for further unknown reasons) or certain rows when there is a duplicate, but it's thinking it will create a cyclic reference.

"Operation against file was aborted by Business Rule 'Validate Duplicate Of CI. Business Rule Stack:Validate Duplicate Of CI"

The only guess I have is that when the reference is trying to be written it's not honoring a strict reference to the table and sometimes tries to look at the extended table as well and reference the wrong record. Very odd that this is so unreliable.

So, perhaps the real question is, how does one make a reference field honor the reference strictly to the parent and not look at extended tables thereby creating a loop? Or do I have to get more fancy perhaps and instead of just referencing the name actually lookup the sys_id of the duplicate and use that? hmmm...

Yadin · ‎05-24-2020

Well that didn't work either. In the end, looks like I have to disable business rules in the transform map because whatever this rule is it's very unreliable in the results. Once I turn them off, everything acts the way it's supposed to in the first place.

Appreciate your help, got me testing enough things to find the answer I needed!