Saltar para o conteúdo principal
FromNine
Menu

Engenharia

Integrações que mantêm os dados em movimento e mostram quando param.

Ligamos CRM, ERP, sistemas de gestão processual e plataformas públicas através de contratos, eventos e gestão de identidades bem feitos, para que os dados circulem com fiabilidade, os erros fiquem visíveis e novas capacidades, incluindo a IA, se liguem em segurança.

Para organizações que ligam sistemas, parceiros e plataformas públicas em Portugal e noutros Estados-Membros.

Fale-nos do seu projetoVer as plataformas que ligamos
Integrações e APIs: camadas de capacidadesQuatro camadas sobrepostas em profundidade. De cima para baixo: os consumidores, como portais, aplicações e agentes, o gateway de APIs com a gestão de identidades, a espinha dorsal de eventos e, por baixo, os sistemas de registo.01Portais, aplicações e agentes02Gateway de APIs e identidade03Espinha dorsal de eventos04Sistemas de registo
  1. 01APIs concebidas a partir do contrato, com OpenAPI e AsyncAPI, versionadas e documentadas
  2. 02Eventos com ordenação, idempotência, tratamento de mensagens falhadas e reprodução
  3. 03Fluxos monitorizados de ponta a ponta, filas de erro com equipas responsáveis identificadas

01 Problemas

Problemas de integração para os quais nos chamam

  1. 01

    Ligações ponto a ponto que ninguém se atreve a mudar

    Dezenas de ligações diretas entre CRM, ERP e sistemas à medida. Mudar um campo obriga a testar dez interfaces.

  2. 02

    Duplicados e falhas silenciosas

    Uma nova tentativa cria uma segunda encomenda. Uma mensagem falhada desaparece. Quem está no negócio sabe pelos clientes.

  3. 03

    Cada novo canal exige novo trabalho de integração

    O portal, a aplicação móvel e agora um assistente de IA precisam dos mesmos dados, e cada um recebe a sua própria extração.

  4. 04

    Ligar à administração pública é um projeto à parte

    Ligar à autenticação do Estado, a uma plataforma pública de troca de dados ou à faturação eletrónica para entidades públicas exige, de cada vez, meses de trabalho de segurança e de adesão.

02 O que entregamos

O que entregamos

  1. 01 Estratégia e gestão de APIs

    Conceção API-first com contratos OpenAPI e AsyncAPI, uma política de versões, um gateway que a aplica e um portal para programadores, para que as equipas encontrem e reutilizem o que já existe.

    O que fazemos

    • Mapa das APIs existentes e dos seus responsáveis
    • Regras de conceção e processo de revisão
    • Políticas do gateway para segurança, quotas e versões
    • Portal para programadores e catálogo de APIs

    O que recebe

    • Regras de APIs adotadas pelas suas equipas
    • Configuração do gateway como código
    • Catálogo de APIs documentadas

  2. 02 Integração orientada a eventos

    Brokers, captura de alterações e o padrão outbox, com os pormenores que decidem se funciona: ordenação, consumidores idempotentes, tratamento de mensagens falhadas e reprodução.

    O que fazemos

    • Modelo de eventos e convenções de nomes
    • Outbox e CDC nos sistemas de origem
    • Idempotência dos consumidores e garantias de ordenação
    • Filas de mensagens falhadas com ferramentas de reprodução

    O que recebe

    • Espinha dorsal de eventos em produção
    • Registo de esquemas e regras de compatibilidade
    • Procedimento de reprodução e recuperação

  3. 03 Plataformas de integração, escolhidas fluxo a fluxo

    SAP Integration Suite, MuleSoft e os serviços de integração nativos da cloud têm cada um o seu lugar. Dizemos-lhe quando uma iPaaS é melhor do que código à medida, e quando não é.

    O que fazemos

    • Avaliação do middleware existente
    • Escolha da plataforma com o custo total de propriedade
    • Mapeamentos e conectores reutilizáveis
    • Migração a partir de middleware legado

    O que recebe

    • Registo da decisão sobre a plataforma de integração
    • Biblioteca de padrões de integração
    • Plano de migração das interfaces existentes

  4. 04 Identidade e confiança entre sistemas

    OAuth 2.0 e OpenID Connect, TLS mútuo, identidade entre serviços e integração com a identificação eletrónica de cidadãos e empresas: em Portugal, a Chave Móvel Digital e o Cartão de Cidadão; noutros Estados-Membros, esquemas como itsme, DigiD, BundID, FranceConnect, Cl@ve e SPID.

    O que fazemos

    • Arquitetura de identidade para utilizadores e serviços
    • Conceção de tokens, âmbitos e consentimento
    • Apoio à adesão e à certificação de esquemas de eID
    • Preparação para as Carteiras Europeias de Identidade Digital

    O que recebe

    • Conceção da identidade e modelo de ameaças
    • Integração de eID em produção
    • Identidade de serviço e rotação de segredos em funcionamento

  5. 05 Intero­pera­bilidade com a administração pública

    Autenticação pela Chave Móvel Digital nos serviços públicos digitais, como prevê o Decreto-Lei n.º 49/2024, faturação eletrónica para entidades públicas através da rede Peppol segundo os requisitos da eSPap, ligações a plataformas nacionais de troca de dados de outros Estados-Membros e ao sistema técnico europeu de declaração única (Once-Only Technical System).

    O que fazemos

    • Adesão junto da entidade que gere a plataforma
    • Correspondência com as normas de dados nacionais, como o formato CIUS-PT
    • Requisitos de segurança e de registo de cada plataforma
    • Conceção da troca de comprovativos segundo o princípio da declaração única

    O que recebe

    • Ligação certificada à plataforma
    • Documentação dos mapeamentos
    • Procedimentos operacionais acordados com a entidade gestora

  6. 06 Visibilidade operacional para o negócio

    Monitorização dos fluxos que o negócio consegue ler, conciliação entre sistemas e filas de erro que têm um responsável e são tratadas.

    O que fazemos

    • Monitorização dos fluxos ao nível do negócio
    • Relatórios de conciliação entre sistemas
    • Classificação e encaminhamento de erros
    • Alertas por responsável de fluxo

    O que recebe

    • Painel de integração por processo de negócio
    • Verificações de conciliação em produção
    • Mapa de responsáveis para cada fila de erro

03 Arquitetura

Uma arquitetura de referência ilustrativa

Dois caminhos saem dos sistemas de registo. Os pedidos síncronos passam por APIs de sistema e por um gateway que verifica a identidade, os âmbitos e as quotas. As alterações são publicadas como eventos através de um outbox ou de captura de alterações, e os consumidores processam-nas de forma idempotente.

As mensagens falhadas vão para uma fila própria, com reprodução, e não para um ficheiro de registo. Uma faixa de monitorização mostra cada fluxo em termos de negócio, para que quem é responsável por um processo veja quando ele para.

Camadas do desenho

Sistemas de registo
ERP, CRM e gestão processual mantêm a autoridade sobre os seus dados.
APIs síncronas
APIs de sistema versionadas atrás de um gateway com OAuth 2.0, mTLS e quotas.
Eventos
Outbox, broker, fila de mensagens falhadas e mapeamentos na plataforma de integração.
Consumidores
Portais, aplicações, agentes, parceiros e plataformas públicas, com eID quando há cidadãos envolvidos.
Exemplo ilustrativo

  1. Sistemas de registo

    • ERP, CRM e gestão processual

  2. APIs síncronas

    • APIs de sistema
    • Gateway de APIs: OAuth 2.0, mTLS, quotas

  3. Eventos

    • Outbox e CDC
    • Broker de eventos
    • Mensagens falhadas e reprodução
    • Mapeamentos na plataforma de integração

  4. Consumidores

    • Portais, aplicações e agentes
    • Parceiros e administração pública
    • Identidade: OIDC, mTLS, eID

  5. Operação

    • Monitorização dos fluxos, conciliação, filas de erro com responsável
APIs e uma espinha dorsal de eventos, lado a lado

Arquitetura ilustrativa, não corresponde a um sistema de um cliente.

Ler o diagrama em texto

O percurso principal vai dos sistemas de registo, através de APIs de sistema versionadas e de um gateway de APIs, até portais, aplicações e agentes.

Em paralelo, os sistemas de registo publicam as alterações através de um outbox e de captura de alterações para um broker de eventos, que as entrega a trocas com parceiros e com a administração pública e a uma plataforma de integração para os mapeamentos. As mensagens falhadas vão para uma fila de mensagens falhadas com reprodução. Os serviços de identidade com OAuth, mTLS e eID protegem as trocas com parceiros.

Uma faixa de monitorização, em baixo, mostra o estado dos fluxos, a conciliação e as filas de erro com responsável.

04 Considerações e limites

Considerações de engenharia e limites

  • «Exatamente uma vez» é conceção, não uma definição

    Como o tratamos

    Partimos do princípio de que as mensagens chegam duas vezes ou fora de ordem e concebemos consumidores idempotentes, com chaves e regras de ordenação acordadas por tipo de evento.

    Limites e dependências

    Alguns sistemas legados não aceitam chaves de idempotência nem indicam o que processaram. À volta desses, acrescentamos conciliação em vez de fingir.

  • Uma iPaaS nem sempre é a resposta

    Como o tratamos

    As plataformas ganham em muitos conectores e mapeamentos padrão. Os serviços à medida ganham em lógica complexa, grandes volumes ou latência exigente. Documentamos a escolha por integração.

    Limites e dependências

    Os modelos de licenciamento mudam. Uma plataforma barata hoje pode tornar-se a maior rubrica do seu orçamento de integração, por isso modelamos os custos ao longo de vários anos.

  • As plataformas públicas têm o seu próprio ritmo

    Como o tratamos

    Preparamos cedo os processos de adesão, as evidências de segurança e os planos de teste, e trabalhamos com a entidade gestora da plataforma desde a primeira semana.

    Limites e dependências

    Os prazos de certificação e de adesão são definidos pela entidade gestora, não por nós. Planeamos em função deles e indicamos onde estão no caminho crítico.

  • Os consumidores de IA precisam de APIs restritas

    Como o tratamos

    Os agentes e os assistentes recebem APIs dedicadas e delimitadas, com limites e registo de auditoria, e não o mesmo acesso amplo que os serviços internos.

    Limites e dependências

    Expor uma API a um agente acrescenta risco. Revemos cada uma com a sua equipa de segurança antes de entrar em produção.

05 Como trabalhamos

Como trabalhamos

Desembaraçamos antes de construir, e deixamos cada fluxo com um responsável.

  1. 01

    Mapear os fluxos

    Cada interface, o seu volume, o seu historial de falhas e o seu responsável de negócio.

    ResultadoMapa das integrações e classificação de risco

  2. 02

    Definir as regras

    Regras de APIs, convenções de eventos, modelo de identidade e escolha da plataforma.

    ResultadoRegras de integração e registos de decisão

  3. 03

    Mudar fluxo a fluxo

    Primeiro os fluxos de maior risco, com conciliação a correr ao lado da interface antiga até os números coincidirem.

    ResultadoFluxos migrados com evidências de conciliação

  4. 04

    Operar com visibilidade

    Painéis por processo de negócio e filas de erro com responsáveis identificados.

    ResultadoMapa de responsáveis pelos fluxos e painéis

06 Controlo humano

Onde as pessoas mantêm o controlo

A integração corre sem supervisão. A responsabilidade pelo que corre mal não pode correr sem ninguém.

  • Cada fila de erro tem um responsável

    As mensagens falhadas vão para uma equipa que responde por elas, com contexto e um botão de reprodução, e não para um registo partilhado.

  • As alterações aos contratos são revistas

    As alterações a APIs ou eventos que quebram a compatibilidade passam por uma revisão com os consumidores antes de serem publicadas.

  • As reproduções são deliberadas

    Reproduzir mensagens num sistema de registo é uma ação autorizada, registada com quem a fez e porquê.

07 Tecnologias

Tecnologias com que trabalhamos

Plataformas de integração
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Serviços de integração da AWS e do Google Cloud
Eventos e streaming
  • Apache Kafka
  • RabbitMQ
  • Brokers de eventos na cloud
  • Debezium para captura de alterações
APIs
  • OpenAPI e AsyncAPI
  • Gateways de APIs e portais para programadores
  • GraphQL quando se justifica
  • Testes de contrato
Identidade
  • OAuth 2.0 e OpenID Connect
  • TLS mútuo
  • Keycloak e fornecedores de identidade na cloud
  • Esquemas nacionais de eID

A referência a uma tecnologia descreve a nossa experiência de engenharia. Não implica uma parceria com o respetivo fabricante nem o seu aval.

08 Exemplo

Um exemplo ilustrativo

Exemplo ilustrativo

Faturas eletrónicas para clientes públicos a partir do ERP de uma PME

01Situação
Uma PME de equipamentos que fornece câmaras municipais e institutos públicos envia hoje as faturas em PDF por e-mail. A partir de 1 de janeiro de 2027 tem de emitir faturas eletrónicas nos contratos públicos, e um PDF enviado por e-mail não é uma fatura eletrónica.
02O que construiríamos
Uma ligação do ERP à rede Peppol que gera as faturas no formato CIUS-PT, as valida antes do envio e devolve ao ERP o estado de cada fatura, com a referência da encomenda preenchida a partir do ERP.
03Onde as pessoas decidem
A contabilidade aprova as faturas que falham a validação ou que se afastam da encomenda; nenhuma fatura corrigida é reenviada sem essa aprovação.
04O que mediríamos
Percentagem de faturas aceites à primeira, tempo entre a emissão e a receção confirmada e pedidos de esclarecimento dos clientes públicos.

09 Por setor

No seu setor

  • Administração pública

    Troca de dados segundo o princípio da declaração única, com fontes autênticas, autenticação pela Chave Móvel Digital e os registos que as plataformas públicas exigem. Conheça o nosso trabalho para a administração pública.

  • Indústria transformadora

    ERP, MES e portais de fornecedores ligados por eventos, para que o planeamento, a produção e a assistência partilhem a mesma visão.

  • Serviços financeiros

    Sistemas centrais, CRM e APIs de parceiros ligados com gestão de identidades robusta, registo de auditoria e uma conciliação em que a área financeira confia.

Portugal

Intero­pera­bilidade em Portugal e entre Estados-Membros

As entidades públicas estão a levar os seus serviços para o gov.pt e, ao abrigo do Decreto-Lei n.º 49/2024, usam a autenticação do Estado, incluindo a Chave Móvel Digital. Os serviços transfronteiriços encontram em cada país outra plataforma de troca de dados, outro esquema de eID e outra norma de dados. O Regulamento Europa Interoperável pede às entidades públicas que avaliem a interoperabilidade transfronteiriça, e o eIDAS 2 traz as Carteiras Europeias de Identidade Digital que cada Estado-Membro tem de disponibilizar.

Para quem fornece entidades públicas, a faturação eletrónica nos contratos públicos é a ligação mais próxima: as PME, as microempresas e as entidades públicas cocontratantes passam a emiti-la a partir de 1 de janeiro de 2027, segundo os requisitos técnicos da eSPap. Concebemos camadas de integração em que as plataformas nacionais e os esquemas de identidade são adaptadores atrás de contratos internos estáveis. Acrescentar um país passa a significar acrescentar um adaptador e a respetiva adesão, sem refazer os sistemas que estão por trás.

Perguntas sobre integrações e APIs

Devemos usar uma plataforma de integração ou desenvolver integrações à medida?

As duas coisas, para fluxos diferentes. Os conectores padrão, os mapeamentos e a adesão de parceiros favorecem uma plataforma. Os fluxos de grande volume, sensíveis à latência ou com muita lógica favorecem muitas vezes serviços à medida. Decidimos fluxo a fluxo e documentamos porquê.

Integram Salesforce, SAP e Odoo?

Sim, com regularidade, entre si e com sistemas à medida e da administração pública. A FromNine é parceira das três (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), por isso as nossas equipas de integração trabalham ao lado de especialistas de cada plataforma. Conheça o nosso trabalho de integração com SAP.

Podem ligar o nosso ERP à faturação eletrónica para entidades públicas?

Sim. Os fornecedores de entidades públicas emitem faturas eletrónicas nos contratos públicos: as grandes empresas desde 1 de janeiro de 2021, as PME, as microempresas e as entidades públicas cocontratantes a partir de 1 de janeiro de 2027. A eSPap emite os requisitos técnicos e funcionais e o formato é o CIUS-PT, conforme com a norma europeia EN 16931. Um PDF enviado por e-mail não é uma fatura eletrónica. Ligamos o ERP à rede Peppol, validamos cada fatura antes do envio e devolvemos o estado ao ERP.

Conseguem integrar a Chave Móvel Digital e outros esquemas nacionais de eID?

Sim. Integramos a Chave Móvel Digital e esquemas de eID de cidadãos e empresas de outros Estados-Membros, e concebemos para as Carteiras Europeias de Identidade Digital que os Estados-Membros têm de disponibilizar ao abrigo do eIDAS 2. Os requisitos de adesão variam de esquema para esquema e planeamo-los cedo.

Temos middleware legado. Temos de o substituir?

Não de uma só vez. Mapeamos o que corre nele, mudamos primeiro os fluxos mais arriscados ou mais caros e mantemos a conciliação até cada fluxo migrado estar comprovado.

Traga a interface que mais falha

Mostramos como a tornaríamos observável, idempotente e com responsável, e o que seria preciso para fazer o mesmo com as restantes.

Fale-nos do seu projetoVer assistência no atendimento