Self Referencing Code - How to get a Script to locate itself

[TylerTeter]

On the side I've been developing a script include for internal logging, essentially a way to do GlideRecord Inserts on a Child table of syslog. However besides making a standard for our own logging, I want to be able to have a script output whenever it logs, where the log came from. This would be immensely helpful in debugging processes, and visibility into other's code. Whether it came from a business rule, or script include, with both a table name of where the script is, and a sys_id, so I can construct a URL. Sure I could grab the table and sys_id myself and hard code it for every script - not that's not very friendly or maintainable.

In short I need a way for a script to tell where it lives, some kind of self reference. Are there any utility scripts in ServiceNow that I could use for this, or any ideas?

I know I've seen something surrounding scoped application logging, but much of our Dev is in the Global scope, and I'd like the solution to work for every scope.

Thanks,

Tyler

[Deepak Ingale1 · Accepted solution]

I think only script include provides the THIS operator via which we can say this.type and put it as source in logging.

Not aware of any other way by which we can have self referencing construct but for other scripts.

[TylerTeter]

Yeah Deepak, I believe you're correct that is only available for script includes, I don't know of other places that "this" object is valid, though I suppose I haven't really tested. I could derive the source location of a script include by doing a glide record lookup where name = this.type.

I was thinking for workflow scripts it would be possible since you have the workflow context object, and you could find the current executing activity, and eventually get there.

Email scripts you can narrow it down to the email object, and Business Rules, you can narrow it down to the table at least via the current object.

[Deepak Ingale1]

Hi Tyler,

If you create an object based class like script include, eg in UI actions or busienss rules, and use "type" as one of the "defined" property, you can just follow the way it works in script include. This class based model can work in client side scripts as well. However, it might be difficult to educate all the developers to follow this model for logging purpose

[TylerTeter]

Hi Deepak,

I kind of understand your idea, have some kind of class model for UI actions and business rules, or even for workflow scripts specifically, and by making that call to that Script Include would indicate that source was a UI action. Self referencing inside a script include is much easier, since I could even have something like a this.currentFunction variable that I could set inside the script include to narrow down to the function.

We actually have a Change UI Action Util class, so the idea really isn't that far fetched. However, educating developers and making sure they abide by the model will be difficult, and we're really aiming to simplify development not complicate it.

I wonder if there is some kind of Call Stack like functionality that exists within Javascript or ServiceNow in particular that I could utilize as well.