A referência da Infraestrutura: Servidor (cmdb_ci_server) e Localização (cmn_location)

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:

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

em seguida buscamos pela tabela

e assim podemos ver a estrutura da tabela cmdb_ci_server

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

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.

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

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

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.zipcode_.

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.timezone;_

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)PrefixoOrdemUso**cmdb_ci_server**ci1Nosso CI principal (o Servidor).**cmn_location**loc2A localização física do servidor.**incident**inc3O 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](https://[sua%5Finstancia].service-now.com/api/now/table/ci%5Floc%5Finc%5Fop)

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:

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

O Guia Definitivo para Certificações ServiceNow: Da preparação à Manutenção. English, Español