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.

[srinivasthelu]

Hi Nestor,

I would never hardcode sys_ids even in System properties. I would always try to use meaningful values like Group name instead of Group sys_id(2 groups with same name?, come on!!, that serves no purpose).

I would not use system properties for something that is expected to updated by code(logic!!). Do not write code to update system properties.

I would always start my custom properties with the unique identifier . i.e company name as prefix.

Depends on Client side scenario, I will use Display Business Rules, <g:evaluate>   and jelly over Ajax.

Hope that make sense!!

Thanks

Srinivas

[bernyalvarado · Accepted solution]

Hi Nestor,

There's no downside of when to use a system property. As you mentioned, properly naming these (with namespaces fashion) is important for the maintainability of the code.

gs.getProperty() will always be the way you can retrieve a property on the server side.

In regards pulling a property on the client side, you have two options:

a) using a scratchpad and a display business rule to make the property available to the client as soon as a form is loaded

b) using a GlideAjax to call a script include which returns the property.

Thanks,

Berny

[felixs]

Hi Berny,

Thank you for your reply, its most appreciated. May I ask a follow up? (goes to anyone as well) ...

To clarify per: System Properties Best Practices - ServiceNow Wiki

The wiki states that the System Property, for best practice, should be named with the guideline of [company name].[application].[process].[description]

This is great and I get it. I also understand that there are many System Properties already created and you should access those before creating new ones.

I wanted to talk about an alternative way/view for System Properties to help with a SN instance that has a lot of added tables in it and move development for the SN instance into a more Object Oriented Programming approach. As a Developer, I wanted to know your thoughts (and anyone elses really) on attempting to take an OOP approach with the System Properties. So you would take a look at each table as a Class, and out of that you would create System Properties as instance variables of the Class.

For example, say you created a new table named Mac Computer. In this table, Mac Computer, you have 5 rows with the following names: iMac, Mac mini, Mac Pro, MacBook Air, MacBook Pro. So from the OOP view, your class would be MacComputer and the instance variables would be iMac, Mac mini, Mac Pro, MacBook Air, MacBook Pro. So each instance variable would in actuality be a System Property. So the naming convention would be as follows:

[company name].[class].[method].[instance variable]

ex:

MyCompany.MacComputer.get.iMac

Then, when you have the instance variable, on a server side script you can start accessing all of the instance object's methods and variables. Any thoughts?

[bernyalvarado]

Hi Nestor,

The way tables are structured in ServiceNow are very much based on O.O principles. Are you familiar of how the CMDB is structured? That's perhaps the best way to see it applied.

I'm still trying to process in my head how you're trying to leverage properties for these to be an instance of a variable. Keep in mind that in O.O an instance of an object is an actual representation of the Object. On this case an instance is actually a row for a given table.

Thanks,

Berny