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

7. De volta à lista Data Load Definitions, mude pra visão em tabela (ícone ao lado da grade) pra ver os nomes completos e a coluna Target Name de cada cópia — assim dá pra confirmar qual é qual antes de mexer (compare com a tabela abaixo).

8. Abra a cópia indesejada (Copy of DL_TECH_VULNERABILIDADES) → botão Delete (topo da tela).
9. Abra Copy of DL_TECH_CMDB_V1 → campo Name (e Static ID, que atualiza junto): troque para DL_TECH_CMDB_V2 → Apply Changes. Todos os outros campos (Target Type, Table Owner, Table Name, Loading Method, Commit Interval, Error Handling, Data Profile com as 16 colunas originais) ficam exatamente como vieram da cópia — não mexer.
10. Abra Copy of DL_TECH_VULNERABILIDADE_V2 → mesmo processo: Name/Static ID → DL_TECH_VULNERABILIDADE_V3 → Apply Changes.

Confirmado: a lista final tem 5 definições — as 3 originais intactas (DL_TECH_CMDB_V1, DL_TECH_VULNERABILIDADES, DL_TECH_VULNERABILIDADE_V2) + as 2 novas já renomeadas (DL_TECH_CMDB_V2 → TB_26AI_TECH_CMDB, DL_TECH_VULNERABILIDADE_V3 → TB_26AI_TECH_V2).

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.