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.
O mapeamento abaixo foi conferido campo a campo contra um export real de Tenable/ServiceNow
(arquivos em ampmInsights_V1_Cliente/Artefatos/, só linhas AM...) — não
é suposição. O que falta é a parte que não é scriptável: criar os dois perfis de
carga de fato no App Builder (Shared Components → Data Load Definitions), seguindo o roteiro da
seção 4.
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:
| Coluna no export ServiceNow | Coluna destino (v2.0.0) | Observação |
|---|---|---|
install_status | INSTALL_STATUS | texto direto |
life_cycle_stage_status | LIFE_CYCLE_STAGE_STATUS | texto direto |
assigned_to (ou assigned, se assigned_to vier vazio) | ASSIGNED_TO | nos ativos AMPM amostrados, os dois vinham vazios com frequência — não é bug, é lacuna do cadastro de origem |
attestation_score | ATTESTATION_SCORE | numérico direto |
attestation_status | ATTESTATION_STATUS | texto direto (ex.: "Ainda não revisada") |
attested | ATTESTED_FLAG | vem como Verdadeiro(a)/Falso(a) — mesma convenção já usada em SOX/COFRE/TENABLE/SIEM no capítulo 10; converter para 1/0 |
attested_by | ATTESTED_BY | texto direto |
u_fim_do_suporte | U_FIM_DO_SUPORTE | formato confirmado: DD-MM-YYYY (ex.: 01-07-2029) — configurar a máscara de data do Data Load Wizard como DD-MM-YYYY |
location | LOCATION | texto direto |
asset_tag | ASSET_TAG | texto direto |
u_server_role | U_SERVER_ROLE | texto direto |
4. Mapeamento — DL_TECH_VULNERABILIDADE_V3 (23 colunas novas)
| Coluna no export Tenable | Coluna destino (v2.0.0) | Observação |
|---|---|---|
definition.cve | DEFINITION_CVE | lista separada por vírgula, texto direto |
definition.description | DEFINITION_DESCRIPTION | texto direto (CLOB) |
definition.solution | DEFINITION_SOLUTION | texto direto (CLOB) |
definition.synopsis | DEFINITION_SYNOPSIS | texto direto |
software_vulns | SOFTWARE_VULNS | texto bruto (CLOB) — não fazer parsing agora, formato não é JSON válido (ver gap analysis seção 2.4) |
definition.cvss3.base_score | DEFINITION_CVSS3_BASE_SCORE | numérico direto |
definition.cvss3.base_vector | DEFINITION_CVSS3_BASE_VECTOR | texto direto |
definition.cpe | DEFINITION_CPE | texto direto |
definition.epss.score | DEFINITION_EPSS_SCORE | numérico direto |
definition.vpr.drivers_on_cisa_kev | CISA_KEV_FLAG | confirmado: vem como texto true/false (não aninhado) — converter para 1/0 |
definition.exploited_by_malware | EXPLOITED_BY_MALWARE_FLAG | confirmado: texto true/false — converter para 1/0 |
definition.exploited_by_nessus | EXPLOITED_BY_NESSUS_FLAG | confirmado: texto true/false — converter para 1/0 |
port | PORT | numérico direto |
asset.operating_system | ASSET_OPERATING_SYSTEM | texto direto; asset.operating_systems (plural) tem o mesmo conteúdo nos exemplos vistos — usar o singular como principal |
last_fixed | LAST_FIXED | data/timestamp direto |
time_to_fix | TIME_TO_FIX | numérico direto |
vuln_sla_date | VULN_SLA_DATE | data/timestamp direto |
definition.patch_published | PATCH_PUBLISHED | correção: o nome real no export tem o prefixo definition., diferente do que constava antes |
definition.vulnerability_published | VULNERABILITY_PUBLISHED | correção: idem, prefixo definition. |
source | SOURCE_SCAN | texto direto |
scan.id | SCAN_ID | texto direto |
scan.target | SCAN_TARGET | texto direto |
5. Como criar os perfis — e por que não é um script SQL
As definições de carga (DL_TECH_CMDB_V1 e as duas de vulnerabilidades) já existem
hoje dentro de sql/02_ampminsights_apex_app.sql, criadas via
wwv_flow_imp_shared.create_data_profile/.create_data_profile_col/
.create_load_table — a API interna que o próprio export/import do APEX usa. Escrever
essas chamadas à mão, fora do contexto de um import completo (com os IDs que só o APEX gera
corretamente), arrisca corromper os Shared Components da Application 100. Por isso este passo é
feito uma vez no App Builder e depois capturado automaticamente num novo export
completo (seção 7) — o cliente nunca toca em Data Load Definitions manualmente, só importa esse
arquivo, exatamente como já faz hoje em cada release.
Boa notícia: não precisa preencher campo a campo. O jeito mais rápido é criar o perfil do zero apontando pra um arquivo de amostra (só cabeçalho, sem dados) com todas as colunas certas — o APEX detecta as colunas automaticamente a partir do cabeçalho. Já preparei os dois arquivos:
| Arquivo de amostra (no repositório) | Colunas | Perfil a criar |
|---|---|---|
templates/sample_DL_TECH_CMDB_V2.xlsx | 27 (16 originais + 11 novas — sem RAW_JSON) | DL_TECH_CMDB_V2 |
templates/sample_DL_TECH_VULNERABILIDADE_V3.xlsx | 40 (18 originais + 22 novas — sem RAW_JSON) | DL_TECH_VULNERABILIDADE_V3 |
- Baixe os dois arquivos de
templates/neste repositório. - App Builder → Application 100 → Shared Components → Data Load Definitions → Create.
- Na tela de criação, escolha carregar a partir de um arquivo e faça upload do
sample_DL_TECH_CMDB_V2.xlsx(ou o de vulnerabilidades) — o APEX lê o cabeçalho e monta o Data Profile com as 27 (ou 40) colunas automaticamente. - Name:
DL_TECH_CMDB_V2(ouDL_TECH_VULNERABILIDADE_V3). Target Type: Table. Table Name:TB_26AI_TECH_CMDB(ouTB_26AI_TECH_V2). Loading Method: Append — mesma configuração do perfil original (ver aba "Data Load" da tela, igual à doDL_TECH_CMDB_V1). - Em Edit Data Profile, confira o tipo de cada coluna nova contra a tabela da seção 3 (ou 4) — a maioria detecta como
VARCHAR2/texto por padrão, então ajuste manualmente:DEFINITION_CVSS3_BASE_SCORE,DEFINITION_EPSS_SCORE,PORT,TIME_TO_FIX,ATTESTATION_SCORE→NUMBER;LAST_FIXED,VULN_SLA_DATE,PATCH_PUBLISHED,VULNERABILITY_PUBLISHED→ data/timestamp;U_FIM_DO_SUPORTE→ data, máscaraDD-MM-YYYY. - Para os campos flag (
ATTESTED_FLAG,CISA_KEV_FLAG,EXPLOITED_BY_MALWARE_FLAG,EXPLOITED_BY_NESSUS_FLAG): configure a transformação de valor (Column Transformation)Verdadeiro(a)/true → 1,Falso(a)/false → 0— mesma convenção já usada emSOX/COFRE/TENABLE/SIEM. - Salve e teste com uma planilha pequena (5-10 linhas de ativos
AM..., com dado real nas colunas — não só o cabeçalho) antes de rodar a carga completa.
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.
As seções 5-6 (criar e testar os perfis) são trabalho seu, num ambiente com acesso ao App Builder. O cliente recebe só o resultado — o export completo atualizado — e importa como já importa qualquer outra versão da aplicação.