Running Fix Scripts from Update Set

[epam]

                        If you use Fix Scripts you know that after transferring an application or Update Set we have to manually run them. It is often inconvenient to go to the Fix Scripts table, look for necessary scripts, run each one and wait. Moreover, it is so boring to repeat those actions when you have more than a few scripts. Not mentioning the case when you must execute a fix script and forget to do it at all

It would be easier to have a single interface to run all the necessary scripts. In addition, it is much more convenient to be able to access it directly from the Update Set form after the update set is commited.

WHAT WE WANT

Let us create a form that will be opened by 'Run Fix Scripts' button. The button will be visible after a user successfully commits an Update Set and only for admin users.

The form should have a table containing all active fix scripts and useful information (e.g. Description). A user should have an option to select scripts he wants to run. In addition, we need to be able to select how to run the scripts (async or in order).

The last thing we need is a log field with results of script execution.

So our solution should work and look like the diagram below:

WHAT WE DO

We implement all our logic in one UI Action and one UI Page. The first step is to add new button 'Run Fix Scripts' on the Retrieved Update Set form.

The button is simple; it is just calling the 'GlideDialogWindow' component for the 'dialog_fix_scripts_update_set' page and passing the sys_id of Retrieved Update Set that we work in.

Next step is to create the 'dialog_fix_scripts_update_set' UI Page. Add a form with the '<g:ui_form>' tags and write some client code. Html and client code are too big to include in the post so please refer to the attached Update Set.

To run the scripts we used the system processor 'ScriptFixXMLHttpProcessor'. The necessary parameters are: sysparm_sys_id (sys_id of Fix Script), sysparm_script_name (script name), sysparm_background (should be 'false' to get results output).

We implement the 'How to Run' flag with two options: 'Asynch' and 'In Order'. The second option is used when it is necessary to run scripts in a certain order. For example, one script provides data for another. In that case the process will be cancelled if one of the scripts throws an exception.

WHAT WE GOT

As a result, we got a simple and effective solution for running Fix Scripts.

It saves time and provides ability to control the process from one form. There are many ways to optimize or extend the described solution. Nothing is ideal in the world so you can improve the code for your needs.

SOURCES

• (1)       http://wiki.servicenow.com/index.php?title=Fix_Scripts                    
• (2)       http://wiki.servicenow.com/index.php?title=GlideDialogWindow_API_Reference
• (3)       http://wiki.servicenow.com/index.php?title=UI_Pages
• (4)       Update Set 'RunFixScriptsFromUpdateSet.xml' in the attachments

[kevinanderson]

I really like this post, and I would like to see service now implement this kind of solution as an official part of the platform.   I think with jakarta update set batching, automating the fix script execution as a part of an update set commit is even more important now, so as to allow those update sets with fix script requirements to remain in the batch (where sequence of the update set commit and   fix script execution is important).

I have created an enhancement request FTASK34468 in HI for this to be considered as a platform feature going forward.

[blaine2]

Only generally useful part of this seems to be ability to select multiple fix scripts and have them run synchronously one after the other, to save the work of going from screen to screen to select and execute them individually.  (I explain below why this this isn't just unuseful for asynchronous invocations, but dangerous).  This functionality would be more consistent with UI, more intuitive, and applicable to more use cases by implementing it as a normal list UI Action on the sys_script_fix listing page.  Clicking on a sys_script_fix.list favorite one time after applying an update set is neither inconvenient nor difficult.

If there were to be a Update-Set-specific interface for triggering the fix scripts, then the fix scripts to run should be well-defined beforehand, not left for some admin to guess, based on hints and unenforceable descriptions and such.  Since which fix scripts need to be run for healthy US application are Update-Set-specific, the scripts-to-run could be specified in a field of the sys_update_set record itself, thereby enforcing correct promotion behavior rather than hoping for it.  (We use a custom sys_update_set field for enforcing target release label, and that works great).

As made clear by the OOTB warnings, one should be careful with fix scripts, and the executions should almost always be checked carefully afterwards.  It would greatly discourage error checking by making it very difficult to check fix script outputs by running many of them asynchronously as encouraged by the description above with sysparm_background=true.  For example, consider 20 scripts to run, and 3 of them generate source com.glide.ui.ServletErrorListener messages (or if you have sloppy developers, 3 of them generate source "*** Script" messages).  Good luck figuring out which of the 20 fix scripts are ultimately responsible for the errors.

For environment promotions, where this type of thing would be more useful, we generally want to understand and handle each error encountered before proceeding.  Where there are interdependencies among fix scripts, this is required.  That's just not doable with a system where you run multiple scripts asynchrously.  Even for synchronous you would need execution to pause and wait for confirmation between each script execution, and that's something that's awkward and difficult to do with SN platform.