Patterns Pre Post Scripts - Purpose and Usecases

[SiD2]

Hi Folks,

This article best describes mainly the purpose and use cases of the Pattern Pre Post Scripts to the best of my knowledge.

Target Audience

One should be aware of the basics of ITOM Discovery Product Line, Discovery Patterns and IRE products and how these work and their roles respectively.

Overview

You must be aware that ITOM Discovery product uses Probes/Patterns for discovering all kinds of resources. Starting NY ServiceNow recommends to migrate to patterns over probes as patterns being the future.

In this context, I would like to shed some more light on the Pattern Pre Post Scripts which was found to be least documented in ServiceNow docs.

Pre Post Scripts

You can locate these scripts under filter navigator menu under "Pattern Designer->Pre Post Processing".

These scripts are run only during Horizontal Discovery and after the configured pattern executions are completed.

You can configure the script to run for a list of patterns. The more generic the script, it can have multiple patterns linked to it. But anytime you can have 1 script per pattern if something is specific.

OOB there are many pre post scripts available which covers below scenarios and I recommend to check those for better understanding.

Purpose – Use Cases

Patterns doesn't have capability to access the existing data from CMDB or pass data b/w themselves.

If a particular discovery triggers 'n' no of patterns, all of these executions are independent and any pattern is not aware of the other pattern execution and information can't be exchanged b/w them.

So in below scenarios pre post scripts is the best bet for you

• If we need to query existing CMDB data or call other script includes to add/update attributes of current CI being discovered.
• Create relations/references with existing CMDB CIs.

But we have 2 types of pre post scripts which are explained in detail below.

Pre Sensor Scripts

These scripts get executed right after the pattern execution is completed and before IRE processes the payload for persisting data to CMDB. These scripts will have all the CIs data that is discovered during pattern execution in the JSON payload.

Primarily all the pre sensor scripts are mainly used to update the payload with any additional information for the CIs discovered before IRE processes the payload.

So when you need to add/update additional information by querying existing data or call any other script includes other code blocks to get necessary data, this is the best place. After the payload is modified that will be considered as final payload and then IRE processes and creates/updates CIs accordingly.

Some scenarios where pre sensor scripts can be used are:

1) To update reference attributes of the CI being discovered. Here we query the record from existing CMDB and update to the current CI reference attributes in the payload.

• Retrieve the model/vendor/manufacturer records and update the current CI reference attribute with respective sys id.
• When we need to link any other CIs like win/linux server to its application CIs, we update the server ref attribute with the CI sys id.

2) To create relations b/w the CIs that are part of current payload. In some scenarios where patterns can't create relations due to the pre-defined operations, one can write code with own logic and create relations here in script.

3) To create relations b/w the existing CIs from CMDB. This can best be done in post sensor scripts and I would also recommend the same as I believe this looks little complex. We do have some OOB scripts which does this way but not sure though the intent behind.

      However if you need to do this way, you can query the existing CMDB CIs and add those to the payload as if to make that CIs are discovered in current payload, then you can add relations b/w these and actual discovered CIs which are already part of payload.

      One important note here is when you query and add existing CI to payload make sure you include the sys id along with any other attributes, which is a recommendation as I'm not sure about the consequences if missed. You can check OOB scripts where sys id is also added.

You can refer OOB script include "IEJsonUtility" for utility methods to add CIs and relations to the payload which are being used in these pre post scripts.

Post Sensor Scripts

These scripts are executed after all pre sensors script executions are completed and IRE processing as well. So it means all the CIs discovered are persisted in CMDB by now. You can access the persisted CIs sys ids of current discovery in the JSON payload here right in the beginning.

    So when we need to create relation with existing CMDB CIs or the CIs out of concurrent pattern executions this is the best place.

Some Imp Notes

• As and when you create a new script there is a template code that will be generated for you and you can only fill your logic for querying and updating the payload and rest is taken care.

• There is even a short description available in the template code about how you can use above 2 different type of scripts in the comments. The payload JSON will be passed as input to these scripts and you can print to logs for checking / understanding how it looks like.

• You can check the payload content in these scripts by printing the JSON payload in the beginning and end of this script to check what was modified during its execution, which also helps for debugging as well.

        Ex: gs.log('TEST ******************** Message ' + varname);

• Make sure you Prefix some unique string before so that it makes easy to search your logs. You can check these logs under filter navigator "System Logs->System Log->Script Log Statements".

• To check available methods for JSON parsing you can refer OOB script include "JSON" which are being used in these pre post scripts.

[doug_schulze]

A great follow-up to a foundational post by our friend Patrick around the same technology

[SiD2]

Please refer this advanced article as continuation of this which helps debugging the pre post scripts.

[James Fricker]

Wasn't ServiceNow sued for calling it SNOW?