diff --git a/TASKS.md b/TASKS.md index b535da6..b25e7dc 100644 --- a/TASKS.md +++ b/TASKS.md @@ -43,19 +43,18 @@ 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. -- [ ] **Em andamento, roteiro sendo confirmado tela a tela** (ver - [docs/13-v2-perfis-carga.html](docs/13-v2-perfis-carga.html)) — mapeamento de colunas - pronto; passo a passo real do App Builder confirmado até "Copy Data Load Definition" - (método = cópia de `DL_TECH_CMDB_V1`/`DL_TECH_VULNERABILIDADE_V2`, renomeadas pra - `DL_TECH_CMDB_V2`/`DL_TECH_VULNERABILIDADE_V3` — **não** "upload de amostra", isso foi um - chute meu já corrigido). Falta confirmar a tela seguinte (adicionar as colunas novas na - cópia) antes de completar o roteiro. Depois de pronto: exportar a Application 100 de novo - (captura os perfis com IDs corretos) — o cliente só importa esse export, nunca toca em Data - Load Definitions. **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. - Os `templates/*.xlsx` servem pra testar a carga depois de pronta, não pra criar o perfil. +- [x] **Perfis criados e colunas confirmadas em 2026-09-09** — `DL_TECH_CMDB_V2` (27 colunas: 16 + originais + 11 novas) e `DL_TECH_VULNERABILIDADE_V3` (40 colunas: 18 originais + 22 novas) + criados via "As copy of an existing Data Load Definition" + `Add Column` manual (roteiro + completo em [docs/13-v2-perfis-carga.html](docs/13-v2-perfis-carga.html)). Investigado e + descartado: não existe atalho scriptável pra adicionar colunas (nem + `wwv_flow_imp_shared` — risco de corromper Shared Components — nem `APEX_DATA_LOADING`, + confirmado via `all_arguments` + doc oficial que só serve pra **executar** carga, não + criar/editar definição). `RAW_JSON` continua fora do escopo — depende do item de staging + abaixo. **Falta:** (1) testar upload real através dos dois perfis novos (query de validação + do capítulo 13 retorna "no data found" até isso acontecer — esperado, não é erro); (2) + export completo novo da Application 100, capturando os perfis com IDs corretos — é isso que + vira o próximo release pro cliente, que nunca toca em Data Load Definitions. - [ ] 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 16556a0..84c3352 100644 --- a/docs/13-v2-perfis-carga.html +++ b/docs/13-v2-perfis-carga.html @@ -42,13 +42,12 @@
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.
DL_TECH_CMDB_V2 (27 colunas) e DL_TECH_VULNERABILIDADE_V3 (40
+ colunas) confirmados no App Builder, tela a tela, sem nenhum passo adivinhado. Falta: testar um
+ upload real através dos dois (seção 6 — a query de validação retorna "no data found" até isso
+ acontecer, é esperado) e gerar o export completo novo da Application 100 (seção 7).