Administração e desenvolvimento

Visão técnica do Selfint

O Selfint é uma plataforma de integração multi-cliente com workflows dinâmicos, catálogo de conexões, gestão de credenciais, observabilidade operacional e opções de deployment para diferentes contextos.

Esta página resume as capacidades mais relevantes para administradores, equipas de integração e developers.

Capacidades técnicas principais

Engine de workflows

Workflows criáveis por API/UI, com duplicação, pausa, retoma, execução, observabilidade, snapshots manuais, tagging, comparação de versões e rollback.

Triggers e entradas

Suporte no enum e na gestão de triggers para API, webhook, schedule, email poll, Kafka, queue consumer, spawn, pubsub, AMQP e MQTT.

Transformação e enriquecimento

Mappings configuráveis, importação OpenAPI, catálogos externos, JavaScript executor e processamento linha a linha.

Camada AI já operacional

Há AI Builder para sugestões e composição de workflows, além de steps AI com prompts, connections, preview, guard rails e logs de execução.

Segurança e governação

Multi-cliente: isolamento por cliente com contexto ativo e controlo de acesso por escopo.
RBAC: roles, permission sets, grupos e permissões efetivas por utilizador.
SSO: configuração de login único por cliente.
Auditoria: registo de ações críticas, histórico operacional e suporte a troubleshooting.
Credenciais: cofre por cliente, aliases e gestão segura de segredos.

Conexões e autenticação

Catálogo unificado de conexões para reaproveitamento entre workflows e triggers.
Gestão de API credentials para HTTP outbound com OAuth2, API key, Basic, JWT e cenários mTLS.
Administração de credenciais de cliente com namespace, alias, reveal controlado e rotação.
Suporte para testar conexões persistidas ou temporárias; o código refere probes para SMTP, IMAP, HTTP, Kafka e SFTP, além de testers específicos para providers como OAuth2 e Bitrix.

Operação e observabilidade

Consulta de execuções e detalhe por etapa.
Histórico de versões de workflow com snapshot completo, tags e rollback.
Reprocessamento de workflows e mensagens.
Gestão de filas, mensagens pendentes e DLQ.
Métricas operacionais e superfícies administrativas de monitorização.
Jobs de cluster, health endpoints e pages de observabilidade.

Administração funcional

Gestão de clientes, parceiros, utilizadores e preferências.
Planos de uso, quotas, alertas, overrides e dashboards de consumo.
Context variables, feature flags, plugins, triggers e catálogos administrativos.
Módulos dedicados para AI connections, prompts, preview e logs com estatísticas.
Suporte a providers como OpenAI, Azure OpenAI, Ollama e HTTP custom no editor de AI_CALL.

Deployment e ambientes

O produto já contempla mais do que um modelo de instalação.

Desenvolvimento

Suporta arranque local com H2 para acelerar setup, além de execução tradicional do backend e frontend em ambiente de desenvolvimento.

Containers e orquestração

Existe suporte para Docker Compose, Kubernetes e Helm com pipeline de migrações e promoção controlada.

On-prem

O instalador on-prem usa artefactos já construídos e suporta cenários bare-metal ou VM com backend, frontend e runner de migrações.

Bases de dados

Há caminhos de instalação e operação para MySQL, Oracle e H2, conforme o contexto do ambiente.

Notas úteis para developers

O produto é API-first e expõe controladores específicos para workflows, versões, triggers, conexões, permissões, credenciais e planos.
Existe suporte para importação e exploração de especificações OpenAPI, útil para acelerar integrações e mappings.
Os workflows podem ser expostos via endpoints públicos controlados para triggers de API e webhook, e o produto também expõe endpoints públicos de OAuth.
O ecossistema inclui superfícies dedicadas a AI builder, AI connections, prompts e logs, pensadas para uso administrado.
O step `AI_CALL` expõe provider, connection ref, prompts de sistema e utilizador, variáveis, input/output mapping, JSON schema, privacy flags e guard actions.
Operação segura depende de validar permissões, scoping por cliente, credenciais e quotas desde o desenho da integração.
O módulo visual de file processing existe no frontend, mas os presets estão hoje guardados em `localStorage`, não em backend partilhado.