Error using GlideRecord.operation() function

Fabio Mira
Giga Expert

Hello

I'm trying to perform a simple test to understand the operation() method of the GlideRecord Server Scoped object in my PDI.

According to the documentation this method would be used to identify if the GlideRecord object is suffering an "insert", "update" or "delete" event.

I made a simple BR, just to log the information, in a table of my application scoped with the following configuration:

     When: Before
     Insert: True
     Delete: True
     Update: True
     Script:

(function executeRule(current, previous /*null when async*/) {

	gs.info("***DEBUG previous.getTableName()" + previous.getTableName());
	gs.info("***DEBUG current.getTableName()" + previous.getTableName());
	gs.info("***DEBUG previous.getUniqueValue()" + previous.getUniqueValue());
	gs.info("***DEBUG current.getUniqueValue()" + previous.getUniqueValue());
	gs.info("***DEBUG previous.operation()" + previous.operation());
	gs.info("***DEBUG current.operation()" + current.operation());
		
})(current, previous);

In this version of code there is a warning from Rhino informing that the property "operation" cannot be executed because it is an object, exploding the following record in the syslog:

com.glide.script.RhinoEcmaError: Cannot call property operation in object [object GlideRecord]. It is not a function, it is "object".
sys_script.f5212186875c11109efdfcc5dabb35ee.script : Line(7) column(0)
5: gs.info("***DEBUG previous.getUniqueValue()" + previous.getUniqueValue());
6: gs.info("***DEBUG current.getUniqueValue()" + previous.getUniqueValue());
==> 7: gs.info("***DEBUG previous.operation()" + previous.operation());
8: gs.info("***DEBUG current.operation()" + current.operation());
9:
10: })(current, previous);

Here is an image with the entire log of the node that performed the transaction:

find_real_file.png

Trying to understand what is happening, I redid the script parsing this supposed object to String:

(function executeRule(current, previous /*null when async*/) {

	gs.info("***DEBUG previous.getTableName()" + previous.getTableName());
	gs.info("***DEBUG current.getTableName()" + previous.getTableName());
	gs.info("***DEBUG previous.getUniqueValue()" + previous.getUniqueValue());
	gs.info("***DEBUG current.getUniqueValue()" + previous.getUniqueValue());
	gs.info("***DEBUG previous.operation()" + previous.operation.toString());
	gs.info("***DEBUG current.operation()" + current.operation.toString());

})(current, previous);

To my surprise the script is executed without any alert or error in the syslog or in the node log, however it permanently displays the value of 'insert' as shown in the log below, regardless of whether I perform an insert, update or delete on the BR table.

The image below the transaction log when I performed a direct delete from the record list:

find_real_file.png

Does anyone have any idea what is going on?
Is there a documentation error? Or is my PDI behaving abnormally? Or am I doing something wrong?

Thanks

2 REPLIES 2

Allen Andreas
Administrator
Administrator

Hi @Fabio Mira 

I just tested this myself (this is a common way users are able to identify the action of the BR, so it's been working for years and years). I created a problem business rule with the following settings:

find_real_file.png

find_real_file.png

And did two tests.

1) Update to Problem category

2) Brand new problem record was created

These were the log outputs:

find_real_file.png

Perhaps check all your settings, then remove all the other lines of code and try it very simple like what I've done. Check scopes and all that and see if it works. You could even try with problem table as well like I did and see if it works out?

Please mark reply as Helpful/Correct, if applicable. Thanks!


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

long5001
Tera Contributor

This is an old thread, but I ran into this issue myself and the problem was that my table had a column called 'operation' and ServiceNow was getting confused. Dropped the column and the problem went away.