Datasets (CUSTOM)
A solução usa 15 datasets CUSTOM, em datasets/*.js. Eles são a ponte entre o widget e os dados: consultam o RM (SOAP), leem/escrevem as listas internas e alimentam os processos.
Os 15 datasets
RM via SOAP (sentenças LOAX RealizarConsultaSQL, Coligada 1 / Sistema T — ver Integração RM):
| Dataset | Sentença | Retorna |
|---|---|---|
ds_maritimo_rm | LOAX.005 | todos os marítimos |
ds_maritimo_centro_custo_rm | LOAX.005.01 | marítimos por centro de custo (CCUSTO) |
ds_maritimo_sindicato_rm | LOAX.005.02 | marítimos por sindicato (SINDICATO) |
ds_centro_custo_rm | LOAX.006 | centros de custo (CODIGO, NOME) |
ds_porto_rm | LOAX.011 | portos (CODIGO, NOME) |
ds_ferias_afastamento_rm | LOAX.012 + LOAX.013 | férias e afastamentos |
Consulta a listas internas:
| Dataset | Lista |
|---|---|
ds_evento_query | controle_maritimo_eventos |
ds_evento_rm_query | controle_maritimo_eventos_rm |
ds_periodo_query | controle_maritimo_periodos |
ds_status_query | controle_maritimo_status |
Escrita (com validação de grupo/período no servidor):
| Dataset | Grava em |
|---|---|
ds_evento_save | controle_maritimo_eventos |
ds_periodo_save | controle_maritimo_periodos |
Processo / suporte:
| Dataset | Papel |
|---|---|
ds_folha_movimento_query | movimento da folha e alertas (>42 dias) — ações movimento / alertas |
ds_pasta_controle_maritimo | id da pasta GED para o TXT/zip da folha (service task 15) |
ds_generic_query | helper de consulta SQL parametrizada |
Como a API de datasets autentica
A API de gestão /dataset/api/v1/datasets* deste tenant é cookie-bound: um Bearer sozinho (curl/OAuth1) enxerga a lista vazia. Por isso o deploy é feito a partir de uma sessão de browser logada. O script scripts/deploy_dataset.cjs resolve isso: abre um Chromium (Playwright da vue-app), faz login com o admin do .env.local, captura o Bearer e faz o POST com cookie + Bearer juntos.
Deploy de um dataset
Da raiz do repositório:
node scripts/deploy_dataset.cjs <code> datasets/<code>.js
# ex.:
node scripts/deploy_dataset.cjs ds_evento_rm_query datasets/ds_evento_rm_query.js
O script decide sozinho entre criar e atualizar: se o dataset já existe (GET .../datasets?datasetId=<code>), faz POST /datasets (update); senão, POST /datasets/create.
Deploy de todos
Não há um script "deploy all" pronto; rode o deploy_dataset.cjs para cada arquivo. Em Bash:
for f in datasets/*.js; do
code=$(basename "$f" .js)
node scripts/deploy_dataset.cjs "$code" "$f"
done
:::note Ordem e dependências
Os datasets de consulta a listas só retornam dados depois que as listas existem; os datasets *_rm dependem das sentenças RM. Os datasets de escrita dependem dos grupos para o gate de permissão. Publique a infra antes.
:::
Verificação
- Consumir um dataset simples (ex.:
ds_status_query) e conferir o retorno. - Conferir um dataset RM com filtro:
ds_centro_custo_rmexigesearchde 3+ caracteres (sem isso retorna vazio). - Os datasets de escrita são validados no smoke-test.
Troubleshooting
| Sintoma | Causa provável | Ação |
|---|---|---|
GET datasets retorna items: [] | autenticação só por Bearer (sem cookie) | usar o deploy_dataset.cjs (sessão logada), não curl/OAuth1 |
DuplicatedDatasetException no create | dataset já existe | o script deveria atualizar; confirme o <code> exato |
| Dataset RM volta vazio | falta search de 3+ chars ou data fora do padrão Oracle | ver Integração RM |