Have you ever come across a situation where you wished to make tiny bit changes to the OOTB/original code base so that it would address your million dollar story? And then you actually went ahead and did those changes to that code base? Things must have appeared pretty smooth at least for sometime after that? What were the consequences you faced? Remember upgrades? Most of the times, ‘tiny bit’ are not the only changes which are required. In order to address certain requirements, let’s say on a process level - you realise that you need to change/append good amount of current functionality at code level.
A prominent example in my experience is implementing Change management module for customers. They come up with their own workflows for various types of changes, they may even have their own change types defined. Development teams either end up creating new code modules or modify the OOB code without consideration. Both these approaches require attention to detail along with thorough documentation to know where exactly the changes are done. That is a tedious task.
Starting London, ServiceNow offers Extension points. It offers a great way to append original code without muddling much. It provides a systematic way of introducing deviations in existing code bases. The deviations may run back into original flow provided appropriate arguments are passed and received. Consider below image.
Let’s imagine we bought some application from app store with a strong and huge code base. This is represented by a rectangle named “Original code”. As we can see, this newly installed application has it’s own flow (A -> B -> C -> D). This is how the creator of this application wanted the code to work to suffice maximum use cases. Internally, every step in this workflow may have implementation which is very generic and which fits other purposes.
However, you are not okay with the way step B is developed. Rather, it doesn’t align with the requirements you have at hand. You need some modifications in that particular step. Now, in this case it is a good idea to create an Extension Point. Refer below image for navigation. This is a place holder record which specifies the scope restriction, API name, Application it belongs to and a unique name. It also has a script field to represent “Example” usage of this particular extension point.
Once this extension point is saved, you may now actually create implementation. This is where you specify and implement your version of the step. You may create multiple implementations and assign an order to it. Referring to the figure, we can see step ‘B’ has 3 different custom implementations (Red, Green, Blue) which are out of the actual application scope. These are nothing but deviations you created to better align with the requirements.
Now that, these implementations are ready, you need to embed the call to the same in the original code base. You do the same using
GlideScriptedExtensionPoint API. This API class has a function
getExtensions which needs to be called and the unique name of the extension should be passed. As per the implementation, it takes in the arguments passed, processes them in a custom way and returns the same to the base application.
This was originally built for Script Includes in London. By the time it is Orlando, over the period they have included UI extension and Client extension points which work on very similar logic. This is a great way to alter the original code base.