The CreatorCon Call for Content is officially open! Get started here.

tiagomacul
Giga Sage

Leia também no Medium.


A conexão entre a informação técnica de um servidor e o seu endereço físico não é feita por mágica. Ela é estabelecida por um campo de referência padrão que está presente em quase todas as tabelas de itens de configuração.

O Ponto de Conexão: O Campo location

A tabela cmdb_ci_server (e, na verdade, a tabela pai dela, cmdb_ci) possui um campo padrão chamado location.

  • Campo na Tabela cmdb_ci_server: location
  • Tipo de Campo: Reference (Referência)
  • Tabela de Referência: cmn_location

Ou seja, o campo location em um registro de Servidor aponta para um único registro na tabela cmn_location. Essa é a ligação que permite que o ServiceNow saiba o endereço físico exato do seu ativo.

Por Que Essa Relação é Crucial?

A manutenção correta desse join de dados tem impacto direto na operação de TI:

  1. ITSM (Resposta a Incidentes):
  • Quando um alerta dispara sobre um servidor, o Incidente gerado herda o campo location.
  • O time de campo (Field Service) sabe imediatamente para onde se deslocar (Ex: Edifício A, Sala 205, Rack 12).

2. Gestão de Ativos (ITAM):

  • O inventário é preciso. Você consegue rodar relatórios que mostram todos os servidores em uma determinada localização, facilitando auditorias e inventários físicos.

3. Mapeamento de Serviços:

  • Se um local é afetado por um problema (Ex: falta de energia), você pode ver rapidamente quais servidores são impactados e, por dot-walking, quais serviços de negócio dependem desses servidores.

4.Licenciamento e Compliance:

  • Em alguns casos, o licenciamento de software é vinculado ao país ou região onde o hardware está instalado, e a informação do location é usada para fins de compliance.

Como Usar Essa Relação (O Dot-Walking Clássico)

Você não precisa de código ou Database Views complexas para usar essa informação. Basta usar o Dot-Walking (caminhar pelo ponto):

  • No Filtro/Relatório de Servidores: Você pode usar [Localização.País] [é] [Brasil].
  • No Script: Você pode acessar o nome da localização a partir do registro do servidor: current.location.name.

Lembrete de Ouro: A tabela cmn_location armazena a hierarquia de locais. Ou seja, um local (Ex: "Rack 12") pode ser filho de outro ("Sala de Servidores"), que por sua vez é filho de outro ("Edifício A"). A Database View é a única forma de acessar facilmente a hierarquia de localizações.

Mantenha o campo location de seus CIs atualizado, e sua CMDB se tornará a fonte de verdade mais poderosa para toda a operação da sua empresa!

Para entender a relação entre o Servidor e o Endereço, precisamos olhar para a tabela, vamos a tabela cmdb_ci_server, para chegar a ela vamos navegar em >> System Definition > tables

tiagomacul_0-1760650471568.png

 

em seguida buscamos pela tabela

tiagomacul_1-1760650471562.png

 

e assim podemos ver a estrutura da tabela cmdb_ci_server

tiagomacul_2-1760650471897.png

 

clicando em Show Schema Map, podemos visualizar a relação entre as tabelas

tiagomacul_3-1760650471998.png

 

tiagomacul_4-1760650471972.png

 

Essa relação é a chave para a escalabilidade e a eficiência do ServiceNow. O princípio é simples: herança de atributos.

  • Nível 0: cmdb
  • Nível 1: cmdb_ci
  • Nível 2: cmdb_ci_hardware
  • Nível 3: cmdb_ci_computer
  • Nível 4: cmdb_ci_server

Voltando ao campo location apresenta-se a estrutura do Servidor, o campo location é a nossa porta de entrada para uma série de informações adicionais.

tiagomacul_5-1760650471743.png

 


Se você está no campo de batalha da implementação e desenvolvimento no ServiceNow, sabe que o campo location na tabela cmdb_ci_server não é apenas para inventário. Ele é um ponto de integração que influencia a experiência do usuário (UI), a inteligência dos relatórios, a comunicação de sistemas e a automação (backend).

Vamos detalhar, com exemplos técnicos:

1. No Formulário (Scripts Client e Políticas de UI)

Quando estiver editando é possível ver o campo location

tiagomacul_6-1760650471837.png

 

tiagomacul_7-1760650471583.png

 

Assim teremos as informações da location utilizando o dotwaling (referência)

tiagomacul_8-1760650471563.png

 

2. Em Relatórios (Listas e Relatórios Gráficos)

O objetivo é criar relatórios multi-tabela e filtros sofisticados sem a necessidade de Database Views para casos simples.

Filtro Avançado

Filtrar Servidores (tabela cmdb_ci_server) que estão em um país específico: [Location].[Country] [is] [Brasil].

3. Webservice/REST (Integrações com Sistemas Externos)

O objetivo é garantir que sistemas de inventário externo ou ferramentas de monitoramento possam criar ou atualizar CIs com precisão geográfica.

GET (API REST)

Um sistema de monitoramento consulta a lista de Servidores e precisa do código postal do local. A query precisa incluir um campo Dot-Walked. Ex: Pedir os campos name e location.zip_code.

4. Scripts (Server-Side — Business Rules e Script Includes)

Acesso Direto (Dot-Walking)

Acessar um atributo do local sem um GlideRecord adicional. Ex: var fuso = current.location.time_zone;

5. Database View para Webservice: Visão Operacional do Servidor (CI + Local + Incidente)

O objetivo é criar uma única view (ci_loc_inc) que possa ser consumida por uma API REST e que retorne o servidor, sua localização completa e o número do Incidente que está afetando-o.

Nome da Visão: ci_loc_inc_op (CI, Localização e Incidente Operacional)

Passo 1: Variáveis (Tabelas) da Database View

Vamos incluir as três tabelas necessárias, cada uma com seu prefixo único.

Tabela (Variável)PrefixoOrdemUsocmdb_ci_serverci1Nosso CI principal (o Servidor).cmn_locationloc2A localização física do servidor.incidentinc3O Incidente atualmente aberto sobre este servidor.

Exportar para as Planilhas

Passo 2: Cláusulas WHERE (A Lógica de União)

É aqui que definimos como as tabelas se conectam. Usaremos o sys_id para conectar o Servidor à Localização, e o Servidor ao Incidente.

1. União: Servidor (ci) com Localização (loc)

A Localização é um atributo do CI.

  • Na Tabela cmn_location (Prefix loc😞
  • Cláusula WHERE: ci_location = loc_sys_id
  • Tradução: O valor do campo location na tabela cmdb_ci_server deve ser igual ao sys_id do registro na tabela cmn_location.

2. União: Servidor (ci) com Incidente (inc)

O Incidente é um problema no Servidor.

  • Na Tabela incident (Prefix inc😞
  • Cláusula WHERE: inc_cmdb_ci = ci_sys_id
  • Tradução: O campo cmdb_ci (CI Afetado) no Incidente deve ser igual ao sys_id do registro na tabela cmdb_ci_server.
  • Condição Adicional (Opcional, mas Útil): Para uso operacional, você pode adicionar uma condição para limitar os resultados apenas a incidentes ativos: inc_active=true

O Resultado: A API REST Poderosa

Após salvar e testar a Database View, você terá uma tabela virtual que pode ser acessada via API REST.

Endpoint Exemplo: https://<instance>.service-now.com/api/now/table/ci_loc_inc_op

Payload de Exemplo (O que o Webservice Verá):

Em uma única chamada, um sistema externo (Ex: um painel de monitoramento) pode obter dados consolidados, como:

tiagomacul_9-1760650471596.png

 

Por que isso é melhor para Webservice?

Ao invés de um sistema externo ter que fazer três chamadas (uma para o Servidor, outra para a Localização e outra para o Incidente), ele faz apenas uma única chamada à Database View, reduzindo a latência e o consumo de recursos.

Use as Database Views para consolidar dados complexos sempre que a performance de integração for um requisito crítico!

 

 

 

 

Participe, entre nas comunidades, acompanhem os posts:

Conteúdos de interesse

Version history
Last update:
Thursday
Updated by:
Contributors