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

11. Abra DL_TECH_CMDB_V2 → Edit Data Profile (confirma: mostra XLSX, 16 colunas — as originais, intactas).
12. No topo da tela do Data Profile ("Settings"), o campo Name ainda mostra Copy of DL_TECH_CMDB_V1 (é um objeto separado da Data Load Definition, o rename da etapa 9 não alcança aqui) — troca pra DL_TECH_CMDB_V2 por organização (não é obrigatório funcionalmente).
13. Pra cada coluna nova: botão verde Add Column → preenche o formulário → Create. Campos confirmados do formulário: Column Type (deixar Data), Name, Data Type, Length (só aparece pra Varchar2), Selector Type (deixar Name), Selector (mesmo texto do Name), Value Transformation (deixar None — ver nota abaixo).

Confirmado: total final 27 colunas (16 originais + 11 novas).

4.1 Mapeamento — DL_TECH_VULNERABILIDADE_V3 (repete o mesmo processo, 22 colunas)

Mesmo roteiro das etapas 11-13 acima, agora em DL_TECH_VULNERABILIDADE_V3 (perfil original tem 18 colunas — confirmado, bate exatamente com o capítulo 10). Os 3 campos-flag também seguem a regra de conversão manual no Excel (não usar Value Transformation), igual ATTESTED_FLAG acima.

Esperado: total final 40 colunas (18 originais + 22 novas).

Os arquivos templates/sample_DL_TECH_CMDB_V2.xlsx e templates/sample_DL_TECH_VULNERABILIDADE_V3.xlsx servem como planilha de teste (só o cabeçalho — adicione 5-10 linhas de ativos AM... com dado real, já com os flags convertidos pra 1/0, antes de subir) pra validar a carga depois que os dois perfis estiverem prontos, 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.