...

Modelos de Integração

API

Âncora
api api

...

• • • Permite que a API siga para o fluxo de aprovação já com o adapter devidamente alinhado com a especificação OpenAPI, restando apenas o aval do comitê para publicação da integração.
    • Analista irá mais bem preparado para discutir a entidade desenvolvida.

...

• • • Possibilidade de retrabalho, já que a implementação virá antes da aprovação da integração pelo comitê.

• Fluxo 2

  Âncora
  fluxo-2 fluxo-2

...

• • • Mitiga o risco de retrabalho, por ter aprovado a documentação em comitê antes da implementação.

Desvantagens

• • • As APIs e Mensagens Padronizadas são aprovadas antes da implementação de um POC para garantir a aderência ao negócio.
    • Caso durante o desenvolvimento ou testes for identificada a necessidade de outros campos, será necessário solicitar nova versão e aprovação da mesma ao comitê.

Caso haja necessidade de inclusão de novos campos após a implementação da API, a aprovação do comitê poderá ser solicitada por e-mail a [email protected], informando quais campos serão acrescidos a mensagem original.

...

Análise de negócio

...

e da integração

Âncora
analise-negocio analise-negocio

...

(Redigir texto analisando as considerações abaixo)

...

• Quem é o dono da mensagem?
• Lote? Timeout?

...

Apesar de ser uma etapa importante, a definição de uma mensagem (campos trafegados, estrutura, modo de operação) depende de uma boa análise do negócio e da integração como um todo.

...

• Quantos sistemas ou aplicativos estarão envolvidos na integração?
• Quais serão consumidores e quais serão produtores de informação?
• Quais as informações (entidades) serão trafegadas?
• Haverá replicação de entidades entre os aplicativos?
• Haverá requisição de informações entre os aplicativos?
• Um aplicativo iniciará algum processo em outro aplicativo?
• A informação trafegada é específica de um aplicativo ou pode ser utilizada futuramente por outros aplicativos?

Embora não seja ainda o momento de decidir questões de nível técnico, já importante ter em conta alguns conceitos e premissas da infraestrutura de integração disponível nos produtos TOTVS.

• O fluxo de integração assíncrono é preferível em relação ao fluxo síncrono, porque reduz o acoplamento entre os aplicativos e permite ampliar o número de participantes da integração.
• A infraestrutura de integração da TOTVS dispõe de vários canais de integração. Atualmente, são suportados:
  • Padrão SOAP com mensagens trafegando em formato XML.
  • Padrão REST com mensagens trafegando em formato JSON.
  • Canal AMQP, com mensagens trafegando em formato JSON.
• Cada canal tem suas características e particularidades. Por exemplo, o canal SOAP é o mais suportado, mas tem um consumo de banda de dados um pouco maior que o canal REST, já que utiliza XML. Sendo assim, ter em mente os prós e contras de cada canal ajuda a definir melhor uma integração.
• Processamentos mais pesados costumam gerar timeout num modelo síncrono. Sendo assim, deve-se tentar antecipar qual será o comportamento dos aplicativos em um cenário de timeout excedido.

Por fim, é importante envolver e manter em contato todas as "pontas" da integração, de forma a evitar que cada equipe desenvolva o seu lado da integração e, no momento da entrega ou da implantação no cliente, se perceba gaps ou falhas de entendimento, que muitas vezes são fatais para o projeto de integração.