SAP BTP (Cloud Integration) como origem

Histórico de versões

• 1.8.2

  Confirmação de lote resiliente: quando o banco falha por pouco tempo (disco cheio, comando cancelado por tempo, trava, conexão), a consulta de confirmação do destino volta para a fila com espera crescente em vez de falhar de vez, e isso não gasta as tentativas de consulta ao destino. Se mesmo assim uma confirmação de lote falhar de forma definitiva, o alerta aparece em /admin/errors e no Sentry. Lotes enviados que ficaram sem consulta de confirmação por mais de 15 minutos têm a consulta recriada automaticamente pela rotina de recuperação.

  11/10/2026 · updated

• 1.8.1

  Correção: numa integração com origem REST ou Oracle e leitura incremental, um registro alterado cuja gravação falhava no banco era ignorado e a leitura seguia adiante — a alteração não voltava mais. Agora o Lefia confere e grava os registros em partes, tenta de novo quando o banco falha de forma passageira e só avança o ponto de leitura com tudo o que leu gravado. Se o banco recusa por um defeito do sistema (coluna, permissão, trava, regra do banco — inclusive uma regra de integridade que recusa todos os documentos) ou continua fora, a execução para mostrando o código e a causa, e a próxima lê de novo; se recusa um documento pelo dado dele, o documento aparece no log da execução e a leitura segue. Documento repetido na mesma leitura é gravado uma vez (a última ocorrência), com aviso no log quando o conteúdo difere. Caracteres nulos (\u0000), que o banco não guarda, são removidos do texto na chegada e o log do documento registra a remoção.

  09/10/2026 · updated

• 1.8.0

  Destino REST: envio em lote — "Registros por envio" na tela da conexão junta mensagens da mesma integração num POST de array até N registros (a mensagem de fan-out conta todos os registros dela e entra inteira), na ordem de chegada, com espera configurável para o lote incompleto; cada mensagem fica ligada ao lote e ao id do processo, a confirmação pela fila do lote atualiza todas, falha do lote aparece em cada mensagem com a causa, e o Monitor reprocessa a mensagem (sai do lote) ou o lote inteiro (mesma chave de idempotência). "Forma do corpo JSON" virou escolha (Objeto ou Array JSON). Confirmação pela fila em passo guiado com botão Testar, lista de status de sucesso (status desconhecido nunca vira aceito: segue aguardando com aviso ou vira erro) e id do processo devolvido como texto (ex.: venda por período do Meu Cliente).

  08/10/2026 · updated

• 1.7.1

  Confirmação assíncrona pela fila: o endereço de consulta (por exemplo /api/v2/fila/{id}) é um caminho do servidor do destino, não do endereço de envio. Antes, com a base_url apontando para o endpoint do envio (https://host/api/v2/venda), a consulta ia para …/venda/api/v2/fila/ID, dava 404 e toda mensagem terminava em "confirmação não recebida no prazo". O processo CANCELADO passa a contar como recusado (antes entrava como aceito).

  08/10/2026 · updated

• 1.7.0

  Upsert por chave externa no destino REST (#424): options.upsertPathTemplate com placeholders resolvidos do corpo por mensagem + PATCH (upsertMethod override); chave ausente/array = erro claro sem fallback pra POST. Reenvio deixa de duplicar (caso Salesforce External ID).

  28/08/2026 · updated

• 1.6.1

  Heartbeat de jobs externos: alerta também quando o job NUNCA registrou sucesso. Nova coluna system_heartbeats.watch_since + last_success_at nullable; idade sai de COALESCE(last_success_at, watch_since), então a graça inicial expira sozinha. Job monitorado sem linha na tabela também alerta; erro de leitura vira 500 em vez de "0 stale". Regra extraída para lib/monitoring/heartbeats com 7 testes.

  26/08/2026 · updated

• 1.6.0

  Auditoria Onda 4 (zero-risco): setCachedSuggestions em after(); 5 managers admin com toast no catch dos loaders; heartbeat de backup (tabela system_heartbeats + cron heartbeat-check detecta ausência do backup semanal); wizard revela webhook_secret one-time antes de sair.

  25/08/2026 · updated

• 1.5.0

  Auditoria Onda 2: fire-and-forget → after(); timeouts token exchange/Slack; reaper de execuções presas; execute-integrations checa erro da query e remove file_polling no-op; cron process-notification-emails.

  25/08/2026 · updated

• 1.4.0

  Logs de execucao uteis: (P1) run com erros agrega os MOTIVOS distintos no log (N× motivo + docnums) nos executores REST e OData; (P2) messages.execution_id (migration) carimbado por insert/update/event — card do run ganha "Ver mensagens →" abrindo o monitor filtrado por ?executionId= com banner/limpar; (P3) timestamps dos logs de run com data+hora. Dor real da DQ: "como descubro o erro da execucao?".

  30/07/2026 · updated

• 1.3.0

  Auto-adaptacao do Idempotency-Key: destino que rejeita o header (Salesforce sobjects -> 400 IDEMPOTENCY_NOT_SUPPORTED) recebe reenvio automatico SEM o header (seguro: o 400 garante que nada foi criado) e a connection memoriza options.idempotencyKeyUnsupported — proximas mensagens pulam o header direto. Match estrito (codigo ou frase explicita); 400 comum de payload nao dispara reenvio. Causa real dos 3x400 do cenario 3 da DQ.

  30/07/2026 · updated

• 1.2.2

  Tabela do monitor: docnum de hash trunca em 220px com tooltip do valor completo (antes empurrava a tabela); status origem/destino com tooltip do texto completo; status destino alargado 150->240px (carrega o motivo real do provider).

  30/07/2026 · updated

• 1.2.1

  Logs da mensagem no monitor: ordem DESC (evento mais novo em cima — com reprocessamentos o resultado recente e o que importa) + timestamp com DATA alem da hora (ciclos atravessam dias).

  30/07/2026 · updated

• 1.2.0

  Detalhe de erro do DESTINO no monitor: o extractor de erro agora entende os shapes comuns de provider — ARRAY na raiz [{message,errorCode}] (Salesforce, prefixa o codigo), errors[] aninhado (GitHub/JSON:API), error_description (OAuth), alem do {message|error|detail} classico. dest_status_text passa a mostrar o motivo real (ex. INVALID_FIELD: No such column...) em vez de so "400 Bad Request".

  30/07/2026 · updated

• 1.1.0

  Envio de lote em PARALELO: pool de workers com concorrencia limitada (default 4, teto 10, configuravel na UI do perfil REST em "Envios em paralelo"; 1 = sequencial legado). Antes o pipeline era 1 por vez — lote de 15 a ~1,5s/msg deixava a ultima esperando 25s (medido Dataquantica 27/07); agora ~6s. Cada mensagem e independente pos-dedup. Teto evita burst estourando rate-limit do destino.

  27/07/2026 · updated

• 1.0.0

  Executor de origem REST/JSON: Executar agora/cron agora puxam de API REST genérica (antes só OData). GET na origem, cada registro vira mensagem, processMessage (mapping ou passthrough), send+retry. Dedup por conteudo (docnum=sha256, so processa novos). host-lock. Dispatcher execute-integration por protocolo. Cap 2000/run.

  13/07/2026 · new