ServiceNow — Melhores Práticas na Execução de Scripts através do Xplore
O ServiceNow é uma plataforma de software com vastos recursos de autoatendimento. É um sistema perfeito para trabalhar com automações nas operações de serviço pois, com sua ampla gama de plugins e aplicativos, permite que os usuários de uma empresa sejam capazes de gerenciar equipes, projetos e interações com os clientes. Dentro desse sistema, existe um recurso chamado Xplore. Trata-se de um aplicativo interno criado para desenvolvedores. Através dele, é possível desenvolver, testar e depurar códigos nas linguagens Java e Javascript.
Nesse caminho, existem melhores práticas que podem ser utilizadas para evitar alteração de campos indevidos e até mesmo para melhorar a performance dos Scripts utilizando essa ferramenta. Confira essas dicas!
1. Sempre utilize o comando setWorkflow(false) quando o intuito for Data Fix (correção de dados)
O método setWorkflow() aceita apenas um argumento: um valor booleano verdadeiro/falso. Este argumento determinará se as Business Rules (Regras de Negócio) devem ser acionadas por quaisquer ações do banco de dados executadas por seu script GlideRecord. Por exemplo: se você fizer uma alteração e antes de chamar o método update(), chamar esse método setWorkflow() e passar false, isso impedirá a execução de quaisquer Business Rules que normalmente seriam acionadas por essa atualização.
Exemplo:
var grCI = new GlideRecord(‘cmdb_ci’);
grCI.addQuery(‘name’,’=’,’CITESTECWI’);
grCI.query();
gs.log(‘grCI Query: ‘ + grCI.getEncodedQuery() + ‘ = ‘ + grCI.getRowCount());
if (grCI.next()){
grCI.comments=’TesteCWI’;
grCI.setWorkflow(false); //Nenhuma Business Rule será executada
grCI.update();
}
Além dessa técnica impedir eventuais transtornos causados por uma BR do sistema, isso aumentará a performance de execução, uma vez que somente os dados que você inseriu em seu script serão alterados. Trata-se de um método bastante seguro e até mesmo preventivo.
2. Implemente um contador e utilize o método nativo addInfoMessage para obter maior controle dos dados alterados
Assim que instanciar uma nova variável GlideRecord, acrescente uma variável de contador (var cont = 0). Cada vez que houver um update() no seu script, incremente o valor desse contador (cont++).
Ao final, utilize o método nativo addInfoMessage para imprimir esse contador. Trata-se de um método simples, que apenas exibe uma mensagem informativa com o fundo em azul na sua tela do Xplore.
Exemplo:
var grCmdbCi = new GlideRecord(‘cmdb_ci’);
var cont = 0; //Contador instanciado
grCmdbCi.addEncodedQuery(“u_accountSTARTSWITHCWI”);
grCmdbCi.query();
while (grCmdbCi.next()) {
if (grCmdbCi.u_management_type != ‘no_management’)
grCmdbCi.u_management_type = ‘no_management’;
grCmdbCi.setWorkflow(false);
grCmdbCi.update();
cont++; //Contador sendo incrementado em cada update()
}
gs.addInfoMessage(“CIs com Management Type Alterados: “ + cont); //Loga na tela a quantidade de CIs atualizados
Isso fará com que no final da execução do seu script seja logado na tela quantos registros foram modificados. Se houver alguma surpresa, você pode verificar o impacto e refazer o script.
3. Utilize o método setLimit() em consultas que não exigem alteração de muitos dados ou para realizar testes com menos registros
A função setLimit() ajuda a retornar quantos registros você deseja obter no GlideRecord. Como parâmetro, deve ser informado o número máximo de registros a serem buscados.
Exemplo:
var gr = new GlideRecord(‘request’);
gr.orderByDesc(‘sys_created_on’);
gr.setLimit(5);
gr.query(); // Retorna os últimos 5 registros de requests criadas
Se você quiser obter os 100 últimos registros mais recentes criados de uma tabela, você pode fornecer esse número como parâmetro. Ou seja, setLimit(100) .
Essa técnica é muito útil para aumentar a performance da consulta ou para realizar testes em massas menores de dados, pois ao invés de retornar todos os registros da tabela, o script poupará tempo retornando apenas os últimos registros informados pelo setLimit().
4. Melhore o tempo de execução com os métodos setValue() e updateMultiple() para alterações em massa
Atenção! Esses métodos não devem ser utilizados com os métodos chooseWindow() ou setLimit() ao trabalhar com tabelas grandes. Além disso, é importante mencionar que o método setValue() define novos valores e não limpa os valores existentes.
Essa função vai atualizar todos os GlideRecords com as alterações feitas pelo seu script. Ao alterar os valores de um campo, use o método setValue() em vez de definir diretamente os valores do campo. Sendo assim, ao usar updateMultiple(), isso resultará na atualização de todos os registros necessários.
Exemplo:
// Atualiza o state de todos os incidentes ativos para 3
var gr = new GlideRecord(‘incident’)
gr.addQuery(‘active’, true);
gr.query();
gr.setValue(‘state’, 3);
gr.updateMultiple();
Essa técnica é muito útil para realizar alterações em massa, pois além de poupar o tempo de chamar a função update() para cada registro, atualiza os valores necessários de todos os registros da consulta.
5. Em situações especiais, diminua ou elimine o impacto do script utilizando o método autoSysField(false)
O método autoSysField() aceita como argumento um valor booleano verdadeiro/falso. Ele é utilizado para desativar as alterações dos campos ‘sys’ do ServiceNow. Isso inclui os campos sys_updated_by, sys_updated_on, sys_mod_count, sys_created_by e sys_created_on.
Essa técnica realmente deve ser utilizada apenas em situações particulares. O exemplo principal é quando você precisa realizar uma atualização em massa de registros para corrigir alguns dados, mas deseja manter o carimbo de data/hora de atualização originais, etc. Pode também ser necessário nos casos em que você está atualizando Tasks e a hora da última atualização afeta um SLA.
Exemplo:
//Altera a category de todos os incidentes de ‘software’ para ‘hardware’ sem atualizar os campos sys
var gr = new GlideRecord(‘incident’);
gr.addQuery(‘category’, ‘software’);
gr.query();
while(gr.next()){
gr.category = ‘hardware’;
gr.autoSysFields(false);
gr.update();
Isso fará com que os campos do sistema permaneçam inalteráveis. Dessa forma, também não haverá impacto nos fins de auditoria.
Gostou do Artigo? Por favor, envie sugestões sobre Scripts ou Técnicas no ServiceNow para meu e-mail:
patrick.moura@cwi.com.br
Obrigado!
