THIS WAS ORIGINALLY POSTED TO MY MAILING LIST. I'M POSTING IT HERE IN IT'S ENTIRETY AS A SAMPLE OF MY WEEKLY WORK.
JOIN 1050 OF YOUR PEERS ON MY MAILING LIST
"The best time to plant a tree was 20 years ago. The second best time is now" - Chinese Proverb
The inspiration for this missive came a few weeks back when I added a gs.log statement to troubleshoot something, then went into the syslog table to find it. It was around noon.
"I wonder why its taking so much time to lo-"
Just shy of a million records in the syslog before lunch! That makes the syslog ungroupable, unsearchable, unexportable, etc. It makes the syslog useless, which is a terrible thing. Useless syslogs means you can't use gs.log effectively. That seriously hamstrings both the scalability of your development, but also the sustainability of your solution.
HOW CAN WE PREVENT THIS?
For with newer ServiceNow instances, this is a peek into your future. Create your architectural & development standards today. In my Dev Standards & Vendor Expectations guides, I always state that gs.log statements should be commented out before code is moved to prod. Sure, sometimes there's good reason to keep gs.logs in prod, but that’s an architectural decision, not a dev/admin one.
HOW CAN WE FIX IT IF ITS ALREADY THIS BAD?
It's very inconvenient, but possible. The first step is finding all the places you could have gs.log statements that aren't commented out. There's a couple hundred places to check, but only a small handful of probable locations. You need to start searching places like business rules, script includes, workflow activities, script actions, scheduled jobs. You should also search places like UI Policies, Client Scripts, etc. I want to work on this daily, so I whipped up a quick report in just under 10 minutes.
"But Robert, that doesn't look like any report I've ever seen".
Well my friend, that's because its built in VIVIDCHARTS, the ServiceNow app for more chart types, easier dashboard builds, and greater aesthetic control. If you want to learn more, don't hesitate to contact me.
WHERE SHOULD I LOOK FOR UNCOMMENTED LOG STATEMENTS?
At minimum (tables: query)
- Business Rules: sys_script_list.do?sysparm_query=scriptLIKEgs.log
- Script Includes: sys_script_include_list.do?sysparm_query=scriptLIKEgs.log
- Mail Scripts: sys_script_email_list.do?sysparm_query=scriptLIKEgs.log&sysparm_list_mode=grid
- Script Actions: sysevent_script_action_list.do?sysparm_query=scriptLIKEgs.log&sysparm_list_mode=grid
- Scheduled Jobs: sysauto_script_list.do?sysparm_query=scriptLIKEgs.log&sysparm_list_mode=grid
- Inbound Email Actions: sysevent_in_email_action_list.do?sysparm_query=scriptLIKEgs.log&sysparm_list_mode=grid
- Workflow Activities: sys_variable_value_list.do?sysparm_query=valueLIKEgs.log&sysparm_list_mode=grid
WORKFLOW ACTIVITIES?
Yep. That's the table that stores the instance of activities that you drop into Workflow. LOADS of gs.log statements hiding out there for you older instances.
WHAT IF I WANT TO GO ***REALLY*** DEEP?
Any field where you can enter a script in ServiceNow is really just a field of type script. If you really want to go down the rabbit hole and learn a ton of stuff on the way, just search the dictionary table accordingly: sys_dictionary_list.do?sysparm_query=internal_type.labelSTARTSWITHscript&sysparm_view=
If you want to go deeper than that, try to figure out how to build a query that can somehow detect if the gs.log is commented or contained in a block comment. That way you won't waste any time working through objects who are already updated to comment out logs.
Now that you're the hero of the day, go reward yourself with GroundShark Coffee. The only brand I trust. Build like you mean it.
If you haven't already, please take my content survey.
I also have a Youtube Channel. Same type of content, just video form.
2 Comments
