API padrão Datasul ou serviço específico: como escolher a melhor abordagem?
Quando surge uma necessidade de integração com o Datasul, uma das primeiras decisões técnicas é definir como os sistemas irão se comunicar.
Em alguns cenários, pode existir uma interface padrão adequada ao processo. Em outros, a necessidade pode exigir um serviço específico ou até uma aplicação intermediária.
A melhor escolha não deve partir apenas da tecnologia disponível. É necessário entender o processo, a informação que será trocada, a responsabilidade de cada sistema e como a solução será mantida ao longo do tempo.
Comece pelo processo, não pela API
Antes de procurar um endpoint ou desenvolver um serviço, é importante definir o que precisa acontecer.
Algumas perguntas ajudam:
- qual evento inicia a integração?
- qual informação precisa ser enviada ou consultada?
- qual sistema é responsável pelo dado?
- há alteração de estado ou apenas consulta?
- qual resposta o sistema de origem precisa receber?
- o processo pode ocorrer de forma assíncrona?
- o que acontece quando existe erro?
Essas respostas ajudam a determinar qual tipo de interface faz sentido.
Quando uma API disponível no produto pode ser a melhor opção
Quando existe uma interface disponibilizada pelo produto que atende corretamente à necessidade, utilizá-la pode reduzir componentes específicos e aproveitar contratos de integração já previstos no ambiente.
Mesmo assim, é necessário confirmar se os dados, operações e regras atendem ao processo real da empresa.
O fato de uma API existir não significa automaticamente que ela atende qualquer cenário relacionado ao mesmo módulo.
Não escolha uma API apenas porque ela existe
Uma interface pode disponibilizar parte das informações necessárias e ainda assim não representar todo o processo.
Também pode existir diferença entre consultar um registro, criar uma transação e executar uma regra de negócio completa.
Antes de adotar a interface, é necessário entender exatamente o contrato oferecido e o comportamento esperado.
Quando avaliar um serviço específico
Um serviço específico pode fazer sentido quando existe uma necessidade legítima que não é atendida adequadamente pelas interfaces disponíveis.
Alguns exemplos de situações que merecem análise são:
- orquestração de várias etapas do processo;
- regra específica do negócio;
- transformação de informações entre sistemas;
- validação adicional;
- necessidade de consolidar informações de diferentes fontes;
- integração com aplicação especializada.
Isso não significa que todo gap precisa virar customização. Antes de desenvolver, é importante confirmar se o produto já possui uma alternativa adequada.
Onde deve ficar a regra de negócio?
Essa é uma decisão importante em qualquer integração.
Duplicar a mesma regra em vários sistemas aumenta o risco de comportamentos diferentes ao longo do tempo.
Quando possível, cada regra deve permanecer próxima do sistema ou processo responsável por ela.
A integração deveria transportar e coordenar informações sem criar duplicação desnecessária de lógica entre aplicações.
Aplicação satélite também pode ser uma alternativa
Nem toda necessidade precisa ser implementada dentro do ERP.
Alguns processos podem se beneficiar de uma aplicação especializada para operação, mobilidade, interface ou automação, enquanto o Datasul continua responsável pelos registros e regras correspondentes ao ERP.
Nesse cenário, a integração entre as aplicações precisa ser claramente definida.
Considere manutenção e atualização futura
Uma solução de integração continuará existindo depois que o projeto terminar.
Por isso, a decisão precisa considerar como ela será mantida e testada durante futuras atualizações do Datasul e dos demais sistemas envolvidos.
Quanto maior o acoplamento com detalhes internos de uma aplicação, maior tende a ser a necessidade de atenção quando o ambiente evolui.
Para projetos de atualização, veja também nosso serviço de Atualização Datasul.
Contratos de integração precisam ser claros
Origem e destino precisam conhecer o formato esperado das informações.
Campos obrigatórios, tipos de dados, identificadores, respostas e códigos de erro fazem parte desse contrato.
Quando o contrato não está claro, mudanças em um sistema podem gerar impactos inesperados no outro.
Versionamento ajuda a controlar evolução
Interfaces também evoluem.
Quando uma mudança altera o contrato utilizado por outros sistemas, é importante saber quais consumidores serão impactados.
Estratégias de versionamento podem permitir que aplicações sejam adaptadas de forma controlada, dependendo da arquitetura utilizada.
Segurança precisa entrar na decisão
Uma integração pode acessar informações sensíveis ou executar operações importantes no ERP.
Por isso, autenticação, autorização, perfis de acesso e proteção das informações precisam ser avaliados desde o desenho da solução.
Não é recomendável conceder acesso mais amplo do que o necessário para o processo.
Volume e frequência também importam
Uma interface utilizada poucas vezes por dia possui características diferentes de outra que recebe grande quantidade de transações continuamente.
Volume, frequência, tamanho das mensagens e tempo esperado de resposta podem influenciar a arquitetura escolhida.
A decisão precisa considerar o ambiente real e não apenas testes com poucos registros.
Síncrono ou assíncrono?
Alguns processos precisam de resposta imediata para continuar.
Outros podem registrar uma solicitação e permitir que o processamento aconteça posteriormente.
Não existe uma resposta única.
A escolha deve considerar dependência entre etapas, experiência do usuário, criticidade, disponibilidade dos sistemas e tratamento de falhas.
Tratamento de erro faz parte da interface
Uma integração não está completa se apenas o cenário de sucesso foi definido.
Também é necessário estabelecer como serão tratados:
- dados inválidos;
- indisponibilidade;
- timeout;
- rejeições;
- retentativas;
- duplicidades;
- reprocessamento.
Para aprofundar esse tema, veja nosso artigo sobre reprocessamento e idempotência em integrações Datasul.
Evite integração diretamente acoplada ao banco sem análise
Acessar diretamente estruturas internas pode aumentar o acoplamento entre sistemas e tornar a solução mais sensível a mudanças do ambiente.
Existem cenários técnicos específicos que precisam ser avaliados individualmente, mas acesso direto a estruturas internas não deve ser adotado apenas por parecer mais simples no início.
Antes dessa decisão, é importante avaliar interfaces disponíveis, regras de negócio, suporte, segurança e manutenção futura.
Documente a decisão de arquitetura
Depois de escolher a abordagem, registre por que ela foi adotada.
A documentação pode incluir:
- processo atendido;
- sistemas envolvidos;
- responsabilidade de cada aplicação;
- interface escolhida;
- contrato dos dados;
- tratamento de erros;
- segurança;
- dependências;
- critérios considerados.
Isso ajuda futuras equipes a entender a solução sem depender apenas de conhecimento informal.
Quando Progress OpenEdge e ABL entram na arquitetura?
Em ambientes Datasul, algumas necessidades específicas podem envolver componentes desenvolvidos em Progress OpenEdge/ABL.
Esses componentes podem participar de processos, serviços ou integrações quando existe uma necessidade técnica legítima.
Antes de desenvolver, é importante avaliar interfaces existentes e o impacto da solução na manutenção futura.
Conheça nosso serviço de Desenvolvimento Progress OpenEdge e ABL para Datasul.
Como escolher entre API padrão e serviço específico?
Uma decisão consistente normalmente considera:
- aderência ao processo;
- interface já disponível;
- responsabilidade pelas regras;
- manutenção;
- segurança;
- volume;
- tratamento de falhas;
- evolução futura;
- custo de implementação e sustentação.
O objetivo não é utilizar mais desenvolvimento, mas utilizar a arquitetura mais adequada para o processo.
Precisa definir a arquitetura de uma integração Datasul?
A DATA IT pode apoiar na análise do processo, escolha da abordagem, arquitetura, desenvolvimento e homologação da integração.
Conheça nosso serviço de Integrações Datasul e APIs ou fale com nosso time.
