5 padrões de integração para conectividade conduzida por API

5 padrões de integração para conectividade conduzida por API

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

[ad_1]

Quando fui entrevistado para minha função na MuleSoft há alguns meses, me perguntaram se era possível ter mais de uma camada de API do sistema. Eu congelei – e é possível que essa pergunta também tenha passado pela sua cabeça.

Após a entrevista, esbocei alguns casos de uso para descobrir a resposta a essa pergunta. Não demorou muito para eu entender que a conectividade baseada em API não é estritamente restrita a três camadas – API de sistema, API de processo e API de experiência – mas que este é apenas um ponto de partida. A chave para o sucesso é usar as camadas de maneira eficaz e flexível.

Os mitos sobre três camadas são:

  • Todas as três camadas são obrigatórias e o medo de qualquer anomalia pode levar ao fracasso.
  • Construindo APIs em cada camada para segurança, seja ela ideal ou não.
  • Construir APIs para agilidade sem avaliar se é aplicável ou não.

Esses mitos criam seus próprios desafios:

  • Aumento do custo de implementação de APIs, complexidade, operações e manutenção.
  • O impacto do SLA pode causar sobrecarga.
  • Dar ao consumidor imprecisos ou mais elementos do que deveria consumir.

Muito parecido com um bolo, sua rede de aplicativos precisa ser coberta com padrões apropriados e cozida para que tenha um bom gosto na produção. O truque é descobrir quantas camadas você precisa!

Escolhendo seu sabor: escolhendo um caso de uso

Vamos dar uma olhada nos ingredientes de que precisamos para o caso de uso de uma indústria de varejo para gerenciamento da cadeia de suprimentos e vários sistemas que uma organização normalmente usa para lidar com seus negócios. Usaremos um exemplo de varejo aqui:

O negócio de varejo adquire mercadorias de vários parceiros comerciais e se comunica por meio de troca de arquivos EDI.

A MuleSoft fornece ao Anypoint Partner Manager recursos avançados, como integração de parceiros comerciais, rastreamento de transações, métricas operacionais avançadas de B2B e muito mais. No entanto, este caso de uso usa um conector tradicional Anypoint EDI (EDIFACT, X12) para fornecer uma ideia geral dos padrões.

Por outro lado – o pedido de compra, o envio, o recebimento e o status da fatura são rastreados como rastreamento do pedido de compra a ser consumido pelo Portal do Fornecedor na Web ou por um aplicativo móvel. Além disso, essas transações farão parte da análise das métricas de KPI e o custo do ERP será exportado para a EDW diariamente como parte do controle de lucros e perdas.

A receita da visão geral usando uma abordagem baseada em API é assim:

Agora é hora de aprender a fazer o bolo!

Assando o bolo: 5 padrões diferentes baseados em API

Embora você possa nomeá-los como quiser, tomei a liberdade de nomear minhas diferentes opções de cozimento.

Padrão 1: a abordagem em três camadas

Camadas: API de sistema MuleSoft, API de processo e API de experiência

Aproximação: Esta é a abordagem comum que você encontrará pela primeira vez ao aprender a abordagem conduzida por API. Neste exemplo:

  • O WMS e os sistemas bancários não fornecem suas próprias APIs. Conseqüentemente, o sistema de registros é desbloqueado pela construção de APIs do sistema MuleSoft para informações de estoque e pagamento.
  • O rastreamento do pedido de compra é orquestrado para obter o status de vários estágios do ciclo de vida do pedido de compra. Para essa lógica, é necessário construir uma camada de API de processo.
  • Como existem dois consumidores diferentes – API móvel e API de aplicativo da Web – cada um requer uma API de experiência.

Inferência: Os benefícios clássicos dessa abordagem são maior capacidade de reutilização de APIs, clareza de propriedade e facilidade de gerenciamento de quaisquer alterações na origem dos sistemas de registro. Ele também fornece uma Camada de Experiência para conduzir a abordagem focada no produto / consumidor.

Padrão 2: a abordagem de três camadas com camadas do sistema camarada

Camadas: API de sistema não MuleSoft, API de sistema MuleSoft, API de processo e API de experiência

Aproximação: A camada Non-MuleSoft System API tem APIs do sistema ERP downstream que atua como o provedor. Essas APIs de sistema não MuleSoft podem ser APIs SOAP e REST.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
  • Uma API do sistema MuleSoft é construída como um wrapper ou uma API proxy. Alguns dos exemplos podem ser Find-Purchase-Order junto com UOMConversion (quando o UOM do fornecedor e o UOM da empresa são diferentes), remessas, recibos e faturas. Eles se tornam parte da camada MuleSoft System API.
  • Um conjunto de APIs de processo – como status de remessa, pedido de compra, status de fatura, status de recebimento ou rastreamento de pedido de compra é construído como parte da camada de API de processo.
  • Uma API de experiência é construída em torno desses status para serem consumidos pelos consumidores correspondentes, como aplicativos móveis e da web.

Inferência: Este é um padrão em que a fonte de downstream do sistema de registros fornece suas próprias APIs. Para obter o pedido de compra completo (Ex: PO e UOM convertido), é necessária uma API do sistema MuleSoft. Isso permite um acoplamento fraco para obter agilidade. Agora que temos proxies de API do sistema criados, podemos gerenciar QoS para backend APIs de sistema não MuleSoft usando políticas como limitação. As APIs de processo podem ser integradas a APIs de sistema reutilizáveis ​​com complexidade reduzida.

Padrão 3: todo o sistema e processo, mas nenhuma camada de experiência

Camadas: API de sistema não MuleSoft, API de sistema MuleSoft e API de processo

Aproximação: Neste cenário, o sistema de registros é desbloqueado usando Non-MuleSoft System SOAP / REST APIs de ERP e sistema de gerenciamento de transporte.

  • APIs do sistema Mulesoft para pedidos de compra, remessas, recibos, faturas, estoque, pagamento e transporte são construídos como um proxy.
  • As APIs de processo são construídas para orquestrar vários fluxos de rastreamento de pedido de compra.
  • Como a definição de API de processo e analítica são as mesmas, não há necessidade de construir uma camada adicional, exceto no caso de mudanças antecipadas na definição de API de processo.

Inferência: Esta API de processo é propriedade da equipe de análise e adequada para uso que eliminou a necessidade de uma camada de experiência. Este padrão demonstra como a API de processo focada no produto interno foi criada e de propriedade do LOB, que utiliza informações de APIs de terceiros.

Padrão 4: Sistema MuleSoft e camadas de processo apenas

Camadas: MuleSoft System API e Process API

Aproximação: Neste cenário, como WMS e o banco não fornecem suas próprias APIs.

  • O sistema de registros é desbloqueado pela criação de APIs do sistema MuleSoft para estoque e pagamento de WMS e bancos.
  • APIs de processo são construídas para orquestrar através de vários fluxos de sistema para rastrear os status de remessa, recebimento e fatura.
  • Como a definição de API de processo e analítica são as mesmas, não há necessidade de construir uma camada adicional, exceto no caso de mudanças antecipadas na definição de API de processo.

Inferência: Isso é semelhante ao caso de uso acima, em que a API de processo era uma candidata adequada para uso para análise. Essa abordagem é outro exemplo em que nem todas as camadas são necessárias para promover agilidade e usabilidade. Também é extensível o suficiente para desbloquear dados para quaisquer outros canais de consumo. Por outro lado, isso gerencia menos APIs. No entanto, se um novo canal for adicionado, podemos sempre avaliar se esse padrão funcionará como está ou se outro padrão é necessário.

Padrão 5: apenas uma camada de sistema MuleSoft

Camadas: API do sistema MuleSoft

Aproximação: Para fins de reconciliação de lucros e perdas, o custo precisa ser extraído para EDW (data warehouse) diariamente.

  • Uma API de sistema MuleSoft é construída para realizar a transferência de arquivos de custo da pasta do sistema (fonte) para a pasta de negócios comum de onde o EDW pega o arquivo.
  • Esse custo de exportação é apenas uma pequena parte, mas há outra área de integração com ETL a explorar.
  • Como este caso de uso não envolve nenhum processamento de mensagem e nenhuma lógica de negócios está envolvida, a necessidade de ter uma API de processo não surge.

Inferência: O processo de transferência de arquivos aqui é uma única API que pesquisa de um local de ERP e cai em uma pasta comum que fornece flexibilidade em torno do consumo por qualquer aplicativo ou sistema com manutenção econômica.

O momento da verdade: o teste de sabor!

Embora esses padrões sejam apenas uma ideia de design, mas não sejam o mesmo que produção. Os fatores que impactam na construção de uma arquitetura robusta, como:

  • Desempenho e SLAs
  • Segurança
  • Topologia de implantação (nuvem, local, híbrido)
  • Linhas adicionais de negócios, aquisições e remodelagem
  • Pandemias inesperadas, etc.,

Esses outros fatores precisam ser considerados antes de você se aprofundar na produção e em quaisquer mudanças futuras que ajudem a informar qual receita funciona melhor para você.

Embora eu goste do bolo em camadas que ajudo meus clientes a assar, há ainda mais receitas por aí com sabor B2B e um livro de receitas inteiro que estabelece padrões que podem fornecer um salto para suas aventuras em camadas de bolo. Feliz cozimento!


[ad_2]

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso