Downside to using System Properties?

[felixs]

Hello All,

I'm currently doing some research on System Properties as I plan to propose to my organization to use System Properties (as outlined by ServiceNow best practices) instead of hard coding values (such as sys_id) into our scripts.

I wanted to know if there were any down sides to using System Properties that I am not seeing? Or any special caveats? I guess one thing would be to carefully manage, name, and group all the System Properties created.

Another may be that the gs.getProperty() call is for server side script only. Is there an easy way to access system properties in a client side script? Ive only been able to see that you may have to create a workflow to return it but is there another way? Access property from client script

Thank you all!

Message was edited by: Nestor Sotres (changed to *client side script on second question.

[bernyalvarado]

Hi Nestor,

I forgot to make reference to your MAC example and provide some further reference about how this is done in ServiceNow:

On your MAC example, all of these belong to the Computer class. These exist within the cmdb_ci_computer table which extends (aka 'inherits') from Hardware (cmdb_ci_hardware). Companies will often decide to classify their computers within the Computer table/class because it has all of the properties that they need, but they could also choose to classify it within a more specialized table for Personal Computers. If that's not know, you could create an additional specialization for your MACs by either extending a new table from Personal Computers or from Computers, depending on how you as a business want to manage it.

So, as you can see a class is represented by a table definition... and the schema of it's relationships (like the one shown below) it's available on the record of the Table definition [navigate to Tables & Columns in your ServiceNow Navigation window].

I know this may be a lot of information... and I really wish we could rather sit down and talk about this next to a coffee cup. Perhaps one day we can have the opportunity to do so...

I hope all this helps! Please don't hesitate to ask if you have any further questions.

[felixs]

Hello Berny,

I wanted to follow up with you again on this topic to see if you could provide some insight or point me in the right direction, if you could please. I am dealing with some senior people in my organization in regards to using System Properties or Hard Coded sys_id in scripts. I have some developers stating that it is better to use hard coded sys_id values in scripts most of the time. The most prominent reasons, for me, were:

1. You dont have to have the system access the database with the gs.getProperty() call. Making this call in a workflow that deals with thousands of records may slow down performance as opposed to just having a static value in scripts

2. We dont really change many of the names or sys_ids in scripts. Most are just one offs. There is really nothing we need to ping back in a future date. (this to me is not the strongest argument).

In regards to point 1:

a. What are the effects of using the gs.getProperty() on a large scale as far as creating Database cycles (query to the database and a response back from the database) ?

b. Is there a way to measure Database cycles in a script?

c. Is there a way to have "static variables" that are accessible within a script/application scope in workflows or business rules? I know it is possible under Transform Map scripts as you can set your "static variables" in an onStart() script then access them in your other onBefore, onAfter(), or explicit scripts later on.

Any other input? Thank you!

[bernyalvarado]

Hi Nestor, great questions!

Answer to point a). Surely on a large scale it could have some performance impact, but on the example you're giving of dealing with thousands of records you will just have to retrieve the sys_id once outside the loop. In other words... the same amount of times you will need to write a line to hardcode your sys_id is the same amount of times that under a good design you will need to execute the gs.getProperty() to retrieve a sys_id. I doubt you have a use case/scenario where you need to hardcode thousands of sys_ids . If you do have one, I'll love to have a meeting with you to hear about it.

Answer to point b) Sure. You can write a background script and test the performance impact yourself.

You can use a gs.print() and any of the datetime functions (GlideSystem Date and Time Functions - ServiceNow Wiki ) within it to display the execution times within your script.  

Answer to point c) There's nothing like static variables in ServiceNow. I can think of some alternatives of ways on how a static variable could be implemented within ServiceNow but I prefer no to share these since it could have serious downsides/side effects/risks.

Hopefully the above helps.

p.d: i'm sorry it took me a while to respond. Have been focus teaching a ServiceMapping class so I have been totally out of the community these days. I hope you're doing great!

Thanks,

Berny

[bernyalvarado]

Perhaps to add...

In regards your comment on the "workflow"; i'm not totally sure what you're referring to 😜 .... but... here goes some pointers that may be helpful:

a) please remember that the code within your workflows run on the server side.

b) since the workflows run on the server side then the scripts within your workflow activities can always use gs.getProperty()

c) other ServiceNow components which run server side code and on which gs.getProperty is available are:

1. notifications
2. email_scripts
3. scheduled jobs
4. business rules
5. script includes
6. inactivity monitors
7. workflows
8. transform scripts
9. etc...

I hope this helps.

Thanks,

Berny