# Como usar Arquitetura orientada a eventos na Digibee Integration Platform A **Arquitetura orientada a eventos (Event-driven architecture, EDA)** é uma abordagem de design onde aplicações ou microsserviços desacoplados se comunicam de forma assíncrona por meio de eventos. Um evento representa uma mudança de estado, como a criação de uma nova conta de usuário ou o envio de uma avaliação de produto. Esses eventos são emitidos sem que o produtor saiba quais consumidores responderão a eles. **Os principais componentes da EDA incluem:** * **Produtores de eventos (Event producers)**: Fontes dos eventos acionados por mudanças de estado ou ações. * **Consumidores de eventos (Event consumers):** Serviços que reagem aos eventos e executam ações em resposta. * **Brokers de eventos (Event Brokers)**: Atuam como intermediários, garantindo a entrega dos eventos dos produtores para os consumidores. Neste artigo, você vai explorar os princípios fundamentais da EDA e vai aprender a implementá-los em suas integrações usando a Digibee Integration Platform, por meio de um caso prático. ## Benefícios da Arquitetura orientada a eventos Embora os benefícios a seguir sejam descritos no contexto de integrações, eles se aplicam amplamente à EDA em geral: * **Processamento assíncrono:** Permite que as integrações lidem com eventos de forma independente, aumentando a escalabilidade. * **Desacoplamento**: Produtores e consumidores não precisam ter conhecimento mútuo, promovendo flexibilidade. * **Escalabilidade**: As integrações podem ser escaladas de forma modular, permitindo o aumento independente de serviços para lidar com variações na carga. * **Confiabilidade**: Falhas são isoladas em serviços individuais, garantindo o funcionamento contínuo das outras integrações. * **Respostas em tempo real:** Consumidores podem priorizar suas funções e reagir aos eventos conforme eles ocorrem. ## Alavancando a Arquitetura orientada a eventos com a Digibee A Digibee utiliza uma arquitetura orientada a eventos baseada no padrão **publisher/subscriber (pub/sub)**, onde eventos são publicados em um *broker* e consumidos por assinantes. Os seguintes conectores colaboram para simplificar o processamento de eventos: * [Event Publisher](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/queues-and-messaging/event-publisher): Um conector que publica eventos com configuração mínima, incluindo o nome e a especificação do payload do evento. * [Event Trigger](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/triggers/messaging-and-events/event): Escuta eventos específicos e inicia processos com base no payload do evento. * [Pipeline Executor](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/tools/pipeline-executor): Um conector que permite chamadas síncronas e assíncronas para outros pipelines previamente implantados. ### Integração com Brokers de Eventos de Terceiros A Digibee pode ser integrada com *brokers* de eventos de terceiros, como **RabbitMQ**, **AWS SQS** e **Kafka**, permitindo que você combine as capacidades da Digibee com soluções externas. Consulte a [documentação sobre conectores de Queues and messaging](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/queues-and-messaging) para mais informações. Por exemplo, o [JMS Trigger](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/triggers/messaging-and-events/jms) utiliza filas JMS externas. Enquanto que o **Event Publisher + Event Trigger** utiliza as filas internas da Digibee. Embora as filas sejam hospedadas em locais diferentes, ambas as abordagens funcionam de maneira semelhante no acionamento e processamento de eventos. ### Cenários para uso do padrão Pub/Sub * **Acionar múltiplas tarefas simultaneamente:** Publicando eventos para diversos consumidores , permitindo que as tarefas sejam executadas de forma independente. * **Desacoplar integrações:** Facilita a comunicação sem dependências diretas, eliminando a necessidade de espera por respostas. * **Coordenar processos assíncronos:** Permite que integrações "colaborem" em tarefas sem a necessidade de comunicação síncrona imediata. ## Colocando a teoria em prática Para compreender plenamente como a EDA pode ser aplicada em cenários reais, vamos explorar um caso prático. Este exemplo é dividido em duas partes: **o pipeline Publicador (Publisher)** e **pipeline consumidor (Subscriber)**, cada um desempenhando um papel específico na integração geral. O diagrama de sequência abaixo oferece uma visão geral do processo, mostrando como cada registro é enviado individualmente ao **pipeline consumidor** para processamento.
### Parte I: O pipeline Publicador (Publisher) Imagine uma empresa de varejo que precisa processar dados diários de pedidos e publicá-los como eventos para que outras integrações possam consumi-los. O objetivo é automatizar esse processo implementando um pipeline que: * Consulta um banco de dados pelos dados dos pedidos do dia. * Valida a resposta da consulta. * Publica cada registro em um pipeline consumidor para processamento adicional. Vamos detalhar o processo passo a passo: 1. **Configuração do trigger** O pipeline é acionado todas as noites à meia-noite, utilizando o [trigger Scheduler](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/triggers/scheduling/scheduler) com a variável Midnight. 2. **Consulta ao banco de dados** O primeiro passo do fluxo envolve um conector de banco de dados que executa uma consulta para buscar os dados de pedidos do dia. 3. **Validação da resposta da consulta** * **Se a consulta retornar registros *****(rowCount > 0)*****:** O pipeline prossegue para a próxima etapa. * **Se a consulta não retornar registros**, o pipeline retorna uma mensagem indicando que "não há registros para processar". * **Se a consulta retornar um erro**, o pipeline segue pelo caminho de erro, onde o conector [Throw Error](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/tools/throw-error) emite o erro encontrado.

Pipeline scheduler no nível raiz com um conector de banco de dados, levando a três possíveis caminhos de execução.

4. **Processando cada registro** O conector [For Each](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/logic/for-each) itera sobre o conjunto de dados, processando cada registro individualmente. * Dentro da iteração, um conector [JSON Generator](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/tools/json-generator) (ou qualquer outro conector adequado ao caso de uso) transforma os dados conforme necessário. * Por fim, o conector **Event Publisher** envia o registro processado para o pipeline consumidor , pronto para fins de integração adicionais.

Visão do subfluxo OnProcess de um conector For Each. Cada registro é publicado individualmente no pipeline consumidor via o conector Event Publisher.

5. **Saída final** Após o processamento de todos os registros, o pipeline conclui sua execução. ### Parte II - O pipeline Consumidor (Subscriber) Uma vez que o evento é publicado pelo pipeline ***Midnight Scheduler***, o pipeline consumidor entra em ação: 1. **Event Trigger** O pipeline é acionado quando um novo evento é publicado pelo Scheduler (pipeline #1). 2. **Etapa de validação** Como boa prática, é importante validar o payload recebido (com o [Validator V2](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/tools/validator-v2)) contra o *schema* esperado, pois o pipeline consumidor pode receber eventos de múltiplos publicadores. 3. **Lógica subsequente** Após a validação, o payload é transformado conforme necessário e segue pelo fluxo para processamento adicional.

Pipeline consumidor com um Event Trigger, começando com um conector Log para capturar o payload recebido, seguido por um Validator V2. O Block Execution indica a continuação do fluxo.

## Considerações finais Ao desacoplar produtores e consumidores de eventos e permitir a comunicação assíncrona, a **Arquitetura Orientada a Eventos (EDA)** permite que suas integrações lidem com grandes volumes de eventos, se adaptem a cargas de trabalho variáveis e mantenham a tolerância a falhas. Incorporar esses princípios em sua estratégia de integração não só melhora o desempenho do fluxo de trabalho, mas também o prepara para escalar e evoluir conforme as necessidades da sua organização. Recomendamos fortemente a exploração dos cursos de [Arquitetura Orientada a Eventos I](https://digibee.academy/courses/event-driven-arhcictecture-building-scalable-integrations-en/) e [II](https://digibee.academy/courses/event-driven-arch-2/), bem como dos [webinars de EDA](https://digibee.academy/live-training/) disponíveis na Digibee Academy. Você também pode explorar mais possibilidades em nosso [Portal de Documentação](https://docs.digibee.com/documentation/pt-br?fallback=true) ou visitar nosso [Blog](https://www.digibee.com/blog/) para descobrir mais recursos e insights. Se você tiver feedback sobre este "Caso Prático de Uso" ou sugestões para artigos futuros, adoraríamos ouvir você em nosso [formulário de feedback](https://docs.google.com/forms/d/e/1FAIpQLSd2EnkeEI6TOfgdgJ5gv16Ukozt9oY5Rm2N8X9o5JF4w5kB3Q/viewform).