Proposed Method for Modifying OOTB Script Includes

[codycotulla]

Proposed Method for Modifying OOTB Script Includes

I have a method that I plan to use for modifying OOTB script includes. I'm looking for feedback on the method. What do you see as the upsides or downsides of this approach?

Sometimes we need to modify OOTB script includes

First, I'll acknowledge that the standard answer when it comes to modifying OOTB script includes is that OOTB script includes should not be modified. However, there are situations when we need to modify an OOTB script include. Here is a common example. There is a method in the OOTB script include that is called from multiple places in other OOTB scripts. You need to make a change to that method. In this case, if you can either modify all of the other OOTB scripts, or modify the method in OOTB script include. In this case, modifying the OOTB script include is the right thing to do.

Modifying OOTB Script Includes

This approach is a modified version of the pattern that ServiceNow uses when they have a base read-only script include usually with an "SNC" suffix, and a customizable script include without the "SNC" suffix. For an example, see the ActivityUtilsSNC and ActivityUtils script includes in your developer instance.

There are three steps.

Step 1:

Rename the OOTB Script Include and then create a new script include with the original script include name

1. Open the OOTB Script Include you want to customize.
2. Add the suffix "OOTB" to the script include name. save the record.
   (This is the only change that you need to make to the OOTB script record. When you change the record name, the name change automatically cascades through the script.)
3. If necessary, open the OOTB script include again.
4. Remove the OOTB suffix from the name, and do an insert and stay to create a new script include record.
   
   Now you have the original script include record with a different name. And a new script include record with the original OOTB script include name.
   
   At this point, any new or existing calls to the script include will go to the new script include.
   
   Note: The reason we do an insert and stay to create the new script include is so that all existing settings in the OOTB script include are set in the new script include.

Example (modifying the AbstractAjaxProcessor script include)

1. Open the AbstractAjaxProcessor script include.
2. Change the name to AbstractAjaxProcessorOOTB, and save the record.
3. Reopen the AbstractAjaxProcessorOOTB if it is not already open.
4. Change the name to AbstractAjaxProcessor, then Insert and Stay to create a copy of the record.
5. Remove the "OOTB" suffix (so that it has the original name), then insert and stay.

Now any calls to the AbstractAjaxProcessor will go to the new script include. All GlideAjax calls will go to the new script include.

Step 2

Make the new script include record extend the OOTB script include.

1. Open the new script include record (the one that has the name of the original script include).
2. Remove everything but the type from the prototype.
   Example using the AbstractAjaxProcessor

AbstractAjaxProcessor.prototype = {
    type: "AbstractAjaxProcessor"
}​

• Update the prototype so that it extends the renamed OOTB script include
  Example using the AbstractAjaxProcessor

AbstractAjaxProcessor.prototype = Object.extendsObject(global.AbstractAjaxProcessorOOTB,{
    type: 'AbstractAjaxProcessor',
  }
);​

• Save the record.

 Now all existing calls to the script include will go to the script include you created, and will use the methods in the original script include.

Step 3:

Add your custom code to the new script include record.

• Override methods that you need to override.
• Add new functions
• ...

Upgrades will be Easier with this Approach

In the past, when I've made changes to OOTB script includes, I've made my changes in the script include record. Then when ServiceNow released a new version of the script include, I would have to compare the new version with my customized version and try to reconcile the two. This method was time consuming and error-prone.

 

With this method, I will only need to do the following when ServiceNow makes a change to an OOTB Script Include that I've customized.

1. Revert to the upgrade version of the script include.
2. Rename the script include so that the name has the OOTB suffix.
   Now I will have retained my customizations and be using the latest functionality provided by ServiceNow.
3. Next, compare the new version of the OOTB script include with the previous version to see if ServiceNow made any changes that will impact my customizations.
4. Finally, update my customizations in the separate script include if necessary.

That's it. Please let me know if you have any questions and what you think of this approach.

Thanks, Cody

[Mark Roethof]

I have to look for the document, though will come back on this. Though like 10 years ago indeed it was like don't touch out-of-the-box, deactivate, create your own, etc.. Already a few years ago ServiceNow themselves changed that approach and best practice. Instead, do update out-of-the-box.

Don't get me wrong or whatever, though sounds like you are running on legacy experience.

[Mark Roethof]

"Additionally, in the past, the best practice strategy for updating baseline scripts was to make a copy of
the record you want to update, make the original record inactive, and change the script in the copy.
This complicated the upgrade process since there were two records to maintain for each change.
Instead, the new best practice from ServiceNow is to modify the baseline record itself. The record will be available for review and revert as a skipped file during upgrade".

Just did a very quick google search and within seconds found this in the Business-smart customization document.