Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Script Background - GS.PRINT - value from databse

Pastupe
Mega Guru

Hello,

Before I write the text here I want to thank you to all who spend time to read and reply on this, Thank You.
(I had opened same topic some time ago - name was""" script background - gs.print how to get the result to excell ? "" but there were not respond's I expected)
Now I have found one way I want to Share with you all and Also want to find if some of You does know any other way how to achieve the below.


I need get data from database. I have script in Script's-Background. This script give me result's back.
To be able take those data to excell file, You must write SEMICOLON in gs.print before every value I want get.

Like this --- gs.print(";"+ c.u_code_of_mill +";"+ c.sys_id +";"+ c.u_country_code);
(without semicolon i cannot get value's in separate column later in excel or CSV)

After I get result on the screen, I copy the data from screen to Notepad and save it as CSV file to be able have every value in separate column. So here I finally achieve that I have everey values I asked for in, in separate column in CSV or excel.

Now My question is if there is any other way how to achieve this ?
Please note, that I cannot use reporting as I need get back also SYS_ID value which is not displayed on the form where I take a data from table, so reporting is not a solution here.

Any Tip's or tric's ?

Petr

Script Background:

var c = new GlideRecord('u_mill_code');

c.addQuery('u_code_of_mill');
c.orderBy('u_mill_code');
c.query();

while (c.next()) {
c.autoSysFields(false); // Do not update sys_updated_on, sys_updated_by, and sys_mod_count
c.setWorkflow(false); // Do not run any other business rules
gs.print(";"+ c.u_code_of_mill +";"+ c.sys_id +";"+ c.u_country_code);
//gs.print(c.sys_id);
}

Result in CSV file here:

Code SYS ID Country
AT_160258162d4b9fec100438058bb8299c0a4Austria
AT_161218162d4b9fec100438058bb8299c0a5Austria
AT_162e18162d4b9fec100438058bb8299c0a5Austria
AT_912a58162d4b9fec100438058bb8299c0a5Austria
AU_600698162d4b9fec100438058bb8299c0a5Australia
AU_9172d8162d4b9fec100438058bb8299c0a5Australia
BE_130ed8162d4b9fec100438058bb8299c0a5Belgium
BE_225a18162d4b9fec100438058bb8299c0a6Belgium
BE_443658162d4b9fec100438058bb8299c0a6Belgium

11 REPLIES 11

richard_selby
Kilo Guru

You don't have to make view tables viewable to all users (ACLs), or even let users know they exist (obfuscation). Remember, the base table is still there. Your average user will query the table they know, not go fishing for new tables to have a look. Also, the sys_id isn't particularly interesting to a regular user, unless they have a thing for long hex numbers.


Yes and thank you for the information. I was wondering about security reason's(if users could somehow divert sys_id data ) if the average user will see those data if he/she open report and will explore it....

yes, sys_id on the first look don't look interesting, you are right. I have read about new ACL's for reporting in Calgary where we have in plan go at the end of this year.

Richard, thank you for your time you spent on this topic. It's really good that people like you and Chris are here and share SN knowledge.

I will test this reporting you proposed - and will bring my result's here soon

Petr