v2.0.0 · Passo 3

Perfis de carga: DL_TECH_VULNERABILIDADE_V3 e DL_TECH_CMDB_V2

Novos perfis de carga do APEX para alimentar as colunas Tier-1 criadas no capítulo 11 — sem sobrescrever DL_TECH_VULNERABILIDADE_V2/DL_TECH_CMDB_V1, que continuam servindo a v1.3.0 em produção.

1. Por que perfis novos, não sobrescrever os antigos

Mesma regra já usada na v1.3.0 (ver capítulo 10): não alterar DL_TECH_VULNERABILIDADE_V2/DL_TECH_CMDB_V1 até o fluxo novo estar validado, para não quebrar a carga que já roda em produção no cliente. Os perfis novos são adicionais às colunas de sempre — não removem nenhum mapeamento existente.

2. RAW_JSON continua pendente (de propósito)

Este passo não popula RAW_JSON. O motivo: o Data Load do APEX só leva pra tabela as colunas que ele mapeia — os campos Tier 2/3 do export (que nunca ganharam coluna tipada) não chegam nem perto da tabela por este caminho. Popular RAW_JSON de verdade (a linha completa do export, todas as ~99/41 colunas) depende da tabela de staging (próximo item da Fase 1 no TASKS.md) — lá sim a linha inteira do CSV existe antes de qualquer filtro de coluna, e um `JSON_OBJECT(*)` sobre o staging resolve isso corretamente.

3. Mapeamento — DL_TECH_CMDB_V2 (12 colunas novas)

Coluna de origem exatamente como aparece no export ServiceNow real:

4. Mapeamento — DL_TECH_VULNERABILIDADE_V3 (23 colunas novas)

5. Como criar os perfis — e por que não é um script SQL

1. App Builder → Application 100 → Shared Components → Data Load Definitions.
2. Clique no botão verde Create (canto superior direito).
3. Tela "Create Data Load - Method": marque "As copy of an existing Data Load Definition" (não "From scratch") → Next.
4. Tela "Create Data Load - Application": no campo Copy From Application, selecione "100 ampminsights" (a própria aplicação) → Next.
5. Tela "Create Data Load - As Copy": aparece uma tabela com as 3 definições que já existem (DL_TECH_CMDB_V1, DL_TECH_VULNERABILIDADES, DL_TECH_VULNERABILIDADE_V2), cada uma com um campo To Name e um dropdown Action (No/Yes/Copy and Subscribe). Faça, nesta mesma tela, as duas cópias de uma vez:
   • Linha DL_TECH_CMDB_V1: mude Action para Yes; no campo To Name, apague "Copy of DL_TECH_CMDB_V1" e escreva DL_TECH_CMDB_V2.
   • Linha DL_TECH_VULNERABILIDADE_V2: mude Action para Yes; no campo To Name, escreva DL_TECH_VULNERABILIDADE_V3.
   • Linha DL_TECH_VULNERABILIDADES: deixe Action = No (essa não faz parte do v2.0.0).
6. Clique em Copy Data Load Definition (canto inferior direito).

Depois de ter as colunas novas adicionadas na cópia (roteiro a completar), os ajustes que já sei que vão ser necessários, pela tabela da seção 3/4:

• DEFINITION_CVSS3_BASE_SCORE, DEFINITION_EPSS_SCORE, PORT, TIME_TO_FIX, ATTESTATION_SCORE → tipo NUMBER.
• LAST_FIXED, VULN_SLA_DATE, PATCH_PUBLISHED, VULNERABILITY_PUBLISHED → data/timestamp.
• U_FIM_DO_SUPORTE → data, máscara DD-MM-YYYY.
• ATTESTED_FLAG, CISA_KEV_FLAG, EXPLOITED_BY_MALWARE_FLAG, EXPLOITED_BY_NESSUS_FLAG → transformação de valor Verdadeiro(a)/true → 1, Falso(a)/false → 0 (mesma convenção já usada em SOX/COFRE/TENABLE/SIEM).

Os arquivos templates/sample_DL_TECH_CMDB_V2.xlsx e templates/sample_DL_TECH_VULNERABILIDADE_V3.xlsx continuam úteis, só que num momento diferente do que eu disse antes: não servem pra criar o perfil, servem como planilha de teste (só o cabeçalho — adicione 5-10 linhas de ativos AM... com dado real antes de subir) pra validar a carga depois que o perfil estiver pronto, na seção 6.

6. Como validar

Depois de rodar uma carga de teste pequena:

SELECT asset_name, definition_cve, definition_cvss3_base_score,
       cisa_kev_flag, exploited_by_malware_flag
FROM V_26AI_TECH
WHERE definition_cve IS NOT NULL
FETCH FIRST 5 ROWS ONLY;

Se vier linha com DEFINITION_CVE preenchido e CISA_KEV_FLAG/ EXPLOITED_BY_MALWARE_FLAG como 1 ou 0 (nunca texto), os perfis estão funcionando.

7. Como isso chega ao cliente (sem ele tocar em App Builder)

Depois dos perfis criados e testados (seções 5 e 6), a captura definitiva é um novo export completo da Application 100 (App Builder → Application 100 → ícone de exportar/download → SQL Script) — isso gera um 02_ampminsights_apex_app.sql novo, com os dois perfis novos já embutidos com os IDs corretos gerados pelo próprio APEX. Esse arquivo substitui o atual no próximo release (mesmo fluxo já usado em toda entrega anterior — zip → bucket → PAR, ver o processo de release do projeto). O cliente só importa esse arquivo via App Builder → Import — um wizard guiado, não precisa entender Data Load Definitions.