execution plan script not running

[haldroid]

Is anyone using the Script field in the Execution Plan form? To see this option, you may have to enable the script field by personalizing the form layout (see Scriptable Assignment of Execution Plans on the wiki). If I put in a gs.log statement and run a catalog request that has a working execution plan, the log output never shows up.

[Jace Benson]

Anytime there's something just not working and it's server side, I check two places, warnings and errors. Chances are there's an issue with the script.

On another note, execution plans are dated... Before workflow was around I used execution plans but as soon as I could I switched all the items using execution plans to workflow because they are just easier.

[haldroid]

The script was

gs.log('hello');

btw.

I wonder if execution plan scripts are just a feature that once worked but escaped regression testing and are now broken.

If execution plans are deprecated, ServiceNow should flag them as such and save folks some time. Or have they done so and I missed it?

My take on graphical workflow editors is that drag-and-drop, node-based programming is too limiting for enterprise-grade PaaS. I see no advantage to using a GUI to create simple if-then-else control flows when program text is more readily scaled, refactored, extended, version controlled, and in general more accessible to software engineering tools.

[Jace Benson]

Service-now has not said officially that execution plans are legacy or depreciated but some of their staff and I lean that way because there were issues with Execution plans and some were fixed with Workflows.

I know when I was administering Service Catalog, prior to workflow there were at least a few bugs that could not be solved and feature enhancements we're recorded, like controlling the order of the stages for like ordered execution plan tasks (at the time the order was based on order so if you had three 100 order tasks, they then would order by sys_id). I don't know other issues that may exist or have existed.

Right now the closest to that is the following;

• Mark Stanger posting, "Workflow hasn't replaced execution plans entirely, but its use is normally encouraged over execution plans because it also adds the ability to manage approvals, email notifications, rollbacks, etc. through the workflow mechanism. Execution plans are strictly for task generation and ordering of those tasks." (source)
• Mark Stanger posting, "Almost always use workflow instead of execution plans
  Service Catalog - Execution Plans Vs Workflow">Service Catalog - Execution Plans Vs Workflow
  Execution plan vs. workflow">Execution plan vs. workflow" (Workflow/Execution Plan">source)
• James Grinter posting, "I can't see any specific documentation that directly addresses that question, but start here:
  http://wiki.service-now.com/index.php?title=ITIL_Request_Fulfillment_Management#Fulfilling_the_Request
  and read the part about Execution plan and Workflow, then read the Workflow Overview
  http://wiki.service-now.com/index.php?title=Workflow_Overview
  This earlier Community discussion also has discussion about the two and their merits.
  Service Catalog - Execution Plans Vs Workflow">Service Catalog - Execution Plans Vs Workflow" (Execution plan vs. workflow">source)

I've gone ahead and added a talk page to Service Catalog Fulfillment so hopefully someone give something official.

With that being said, you're script should still work. The entire script is

gs.log('hello');

?

I just tried this on a demo and it worked for me.

[haldroid]

Thanks for gathering the weight of testimony. Goes along with the hurt we've been experiencing regarding catalog request notifications and approvals with exec plans. Will review.

The gs.log('hello'); I'm referring to is in the script section of an execution plan for a catalog request. To clarify prior postings, requesting the item that uses this plan works fine, with or without the script. Adding the gs.log('hello'); script (and variations logging other things) produces zero log output and that is 100% reproducible in our (Berlin Patch 1) dev instance. Is the execution plan script where you tried your log statement? We use gs.log liberally while developing and it generally proves helpful to aid understanding and fill in gaps in wiki documentation.