diff --git a/TASKS.md b/TASKS.md index 5f1d0dc..4814676 100644 --- a/TASKS.md +++ b/TASKS.md @@ -43,10 +43,16 @@ teste — a menos que você peça explicitamente o contrário. (bloco grande) foi pulado na primeira passada — o checkpoint de compilação deu `VALID` porque a view *antiga* (46 colunas) já era válida antes. Resolvido rodando o bloco explicitamente; segunda checagem confirmou as 81 colunas. -- [ ] **Mapeamento pronto e confirmado contra export real** (ver - [docs/13-v2-perfis-carga.html](docs/13-v2-perfis-carga.html)) — falta só criar os dois - perfis de fato no App Builder (não é scriptável, precisa ser feito na UI). `RAW_JSON` - deliberadamente fora do escopo deste item — depende do item de staging abaixo. +- [ ] **Mapeamento pronto + templates de amostra prontos** (ver + [docs/13-v2-perfis-carga.html](docs/13-v2-perfis-carga.html) e `templates/`) — falta criar + os dois perfis no App Builder (uma vez, seu acesso, não do cliente — upload dos templates de + amostra, não preenchimento campo a campo) e depois gerar um export completo novo da + Application 100 (captura os perfis automaticamente, com IDs corretos). O cliente só importa + esse export, nunca toca em Data Load Definitions — mesmo fluxo de sempre. **Achado + importante:** essas definições vivem dentro de `sql/02_ampminsights_apex_app.sql` via API + interna do APEX (`wwv_flow_imp_shared`) — não escrever isso à mão fora de um import + completo, risco de corromper os Shared Components. `RAW_JSON` deliberadamente fora do + escopo deste item — depende do item de staging abaixo. - [ ] Pipeline de staging: bucket → `TB_26AI_TECH_V2_STG` via `DBMS_CLOUD.COPY_DATA` (tabela nova, não mexe nas existentes) - [ ] `MERGE` com histórico (`LOAD_BATCH_ID`, `TB_26AI_TECH_V2_HIST` — tabela nova), honrando o diff --git a/docs/13-v2-perfis-carga.html b/docs/13-v2-perfis-carga.html index 4a1a27e..2c476e8 100644 --- a/docs/13-v2-perfis-carga.html +++ b/docs/13-v2-perfis-carga.html @@ -113,17 +113,39 @@ coluna, e um `JSON_OBJECT(*)` sobre o staging resolve isso corretamente.

-

5. Como criar os perfis no App Builder

-

Não é scriptável de forma confiável para esta aplicação (ver decisão registrada no -capítulo 8/histórico do projeto sobre export de página) — -precisa ser feito manualmente no App Builder:

+

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

+
+
Por que isto não vira um .sql como os Passos 1 e 2
+

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)ColunasPerfil a criar
templates/sample_DL_TECH_CMDB_V2.xlsx27 (16 originais + 11 novas — sem RAW_JSON)DL_TECH_CMDB_V2
templates/sample_DL_TECH_VULNERABILIDADE_V3.xlsx40 (18 originais + 22 novas — sem RAW_JSON)DL_TECH_VULNERABILIDADE_V3
+
+
    -
  1. App Builder → Application 100 → Shared Components → Data Load Definitions.
    2. -
  2. Selecione DL_TECH_CMDB_V1 (ou DL_TECH_VULNERABILIDADE_V2) e use Copy (não edite o original) — renomeie a cópia para DL_TECH_CMDB_V2 (ou DL_TECH_VULNERABILIDADE_V3).
    3. -
  3. Na cópia, adicione os campos novos da tabela da seção 3 (ou 4) — cada campo novo mapeado para a coluna de destino correspondente.
    4. -
  4. Para os campos flag (ATTESTED_FLAG, CISA_KEV_FLAG, EXPLOITED_BY_MALWARE_FLAG, EXPLOITED_BY_NESSUS_FLAG): configure a transformação de valor (Value Map / Column Transformation) Verdadeiro(a)/true → 1, Falso(a)/false → 0.
    5. -
  5. Para U_FIM_DO_SUPORTE: configure a máscara de data como DD-MM-YYYY.
    6. -
  6. Salve e teste com uma planilha pequena (5-10 linhas de ativos AM...) antes de rodar a carga completa.
    7. +
  7. Baixe os dois arquivos de templates/ neste repositório.
    8. +
  8. App Builder → Application 100 → Shared Components → Data Load Definitions → Create.
    9. +
  9. 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.
    10. +
  10. Name: DL_TECH_CMDB_V2 (ou DL_TECH_VULNERABILIDADE_V3). Target Type: Table. Table Name: TB_26AI_TECH_CMDB (ou TB_26AI_TECH_V2). Loading Method: Append — mesma configuração do perfil original (ver aba "Data Load" da tela, igual à do DL_TECH_CMDB_V1).
    11. +
  11. 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áscara DD-MM-YYYY.
    12. +
  12. 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 em SOX/COFRE/TENABLE/SIEM.
    13. +
  13. 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

@@ -143,6 +165,21 @@ FETCH FIRST 5 ROWS ONLY; 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.

+
+
Você faz isso uma vez; o cliente nunca faz
+

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.

+
+
diff --git a/templates/sample_DL_TECH_CMDB_V2.xlsx b/templates/sample_DL_TECH_CMDB_V2.xlsx new file mode 100644 index 0000000..0fa2d60 Binary files /dev/null and b/templates/sample_DL_TECH_CMDB_V2.xlsx differ diff --git a/templates/sample_DL_TECH_VULNERABILIDADE_V3.xlsx b/templates/sample_DL_TECH_VULNERABILIDADE_V3.xlsx new file mode 100644 index 0000000..06303a2 Binary files /dev/null and b/templates/sample_DL_TECH_VULNERABILIDADE_V3.xlsx differ