# 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](/documentation/connectors-and-triggers/pt-br/connectors/queues-and-messaging/event-publisher.md): Um conector que publica eventos com configuração mínima, incluindo o nome e a especificação do payload do evento. * [Event Trigger](/documentation/connectors-and-triggers/pt-br/triggers/messaging-and-events/event.md): Escuta eventos específicos e inicia processos com base no payload do evento. * [Pipeline Executor](/documentation/connectors-and-triggers/pt-br/connectors/tools/pipeline-executor.md): 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](/documentation/connectors-and-triggers/pt-br/connectors/queues-and-messaging.md) para mais informações. Por exemplo, o [JMS Trigger](/documentation/connectors-and-triggers/pt-br/triggers/messaging-and-events/jms.md) 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](/documentation/connectors-and-triggers/pt-br/triggers/scheduling/scheduler.md) 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](/documentation/connectors-and-triggers/pt-br/connectors/tools/throw-error.md) 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](/documentation/connectors-and-triggers/pt-br/connectors/logic/for-each.md) itera sobre o conjunto de dados, processando cada registro individualmente. * Dentro da iteração, um conector [JSON Generator](/documentation/connectors-and-triggers/pt-br/connectors/tools/json-generator.md) (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](/documentation/connectors-and-triggers/pt-br/connectors/tools/validator-v2.md)) 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). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.digibee.com/documentation/resources/pt-br/use-cases/how-to-event-driven-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.