Use multiple sysids in system property and use it in business rule
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-10-2023 11:19 PM
Hi,
I'm trying to check multiple countries and update the assignment group based on those countries. I have created a system property and added 4 countries sysids separated by comma (,). When i'm checking it, it does not work even though i have used split.
var emea = gs.getProperty('x.country.emea');
emea = emea.split(",");
var coe = gs.getProperty('x.group.coe');
var gr = new GlideRecord("table_name");
gr.addQuery("sys_id", current.task);
gr.query();
while (gr.next()) {
if (gr.country == emea) {
gr.assignment_group = coe;
gr.update();
}
}
Can someone help here
Thanks,
Gopal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2023 12:19 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2023 12:39 AM
When reading properties that should be a list of something it is best to:
- provide a default value for getProperty(); if the property is missing the returned value will be null and then when trying to split, a nice error will happen.
- split using a RegExp (vs. a string) that splits on multiple characters and cleans up unwanted white spaces around the delimiters
- filter the result to eliminate empty/invalid items - this will also solve the problem of empty property resulting in an array with one element (not in an empty array).
Something like:
var delimiter = /\s*[;,\n]+\s*/gi;
var emeaDefaultValue = '';
var emea = String(gs.getProperty('x.country.emea', emeaDefaultValue))
.trim()
.split(delimiter)
.filter(isNotEmpty);
function isNotEmpty (element) {
return typeof element != 'undefined' && element != null && '' != element;
}
Cause you can never be sure that the property will be properly edited by someone and that the data will be in the exact form as the one expected.
Of course providing a default to a getProperty() call should be done always, even if it will not be split.
You are using a while to go through the record returned by the query, but in this case that is not necessary. Since all sys_id fields are unique keys, only at most one record will be found, so an if is more expressive of the actual situation. Also, since you are filtering by sys_id, you can just use the simplified GlideRecord paradigm:
var gr = new GlideRecord("table_name");
gr.addQuery("sys_id", current.task);
gr.query();
while (gr.next()) {
...
}
can be
var gr = new GlideRecord("table_name");
if (gr.get(current.task)) {
...
}
get() will know that it should filter by sys_id, it will call query() and it will call next().
The test
if (gr.country == emea) {
is wrong: basically you are saying
if a table element object is equal to a list of strings
which in JavaScript will never be true.
country will be an object of type GlideElement and emea will be an object of type Array.
What you really want is a condition that is the translation of:
if the value in the field is the same as one of the elements in the array
which is done (or at least is a variant of how it can be done) as below:
if (emea.indexOf(gr.country.toString()) > -1) {
Note that the GlideElement (gr.country) is made to return the value it holds as a string by calling the toString() method.
But this - while the easiest to understand - is not the best way to do it, generally speaking, as the search will be case sensitive. So if the array contains item Doe and the value in the field is DOE or doe, it will not be "found".
Finally, most important, unless this is an exercise, one should use Data Lookups or Decision Tables in these kind of situations. Properties are meant to hold small pieces of data that are almost certain to never change. But a mapping between countries and assignment groups will 100% change quite often. Updating properties can not be delegated easily to non-admins, or arbitrary groups, both Data Lookups and Decision Tables can be, plus updating properties flushes the cache with impacts performance for a while (until caches are re-built). That is not something that should be done woo often, especially in a production instance. While one might think that this is a single property and os a single performance hit is acceptable now and than, the practice might become widespread and cache flushes because of property updates could become way too frequent.