Padrão Publisher Subscriber | Integration Developer Bootcamp - Itaú | Digibee Academy

Olá esse é o integration developer bootcamp estamos na etapa de arquitetura e padrões de projeto 1 hoje falaremos um pouco sobre arquitetura orientada eventos e o padrão publisher subscriber utilizado na plataforma de jbi padrão publish subscribe ele funciona da seguinte forma ele permite um aplicativo anunciar eventos para vários consumidores de seu interesse assincronamente sem acoplar os emitentes aos destinatários vamos entender um pouco melhor disso no exemplo temos Um publicador temos inscritos a transmissão de mensagem funciona da seguinte forma Um publicador ele vai publicar um evento que será gerenciado pelo event broker O Event broker vai

analisar nesse evento quem está inscrito a esse evento e vai enviar dessa forma para todos os inscritos desse evento a mensagem que foi enviada do publicador Esse foi o primeiro passo para entendimento para continuar temos o seguinte o publicador ele pode publicar diversos eventos diferentes ou publicar o mesmo evento várias vezes o que vai acontecer é que o event broker vai enfileirar todos esses eventos publicados e um por um ele vai analisar quem está inscrito em cada evento e vai enviar a mensagem do publicador para aquele que tá inscrito um por um então podemos publicar

diversos eventos tanto iguais quanto diferentes O Event broker vai infar todos esses eventos E à medida que ele vai processando esses dados ele vai entregando a informação para todos aqueles que estão inscritos naquele evento específico por fim temos o seguinte percebemos que o publicador pode publicar diversos eventos percebemos que O Event broker infera esses eventos publicados mas temos um detalhe subscriber ele só consegue ouvir um evento por vez não é possível que um subscriber escute mais de um evento por vez Vamos ver o seguinte caso aqui temos por exemplo o seguinte no momento de uma

venda realizada nós publicamos um evento chamado e-mail gestão então quando esse evento é publicado ele vai ser capturado pelo event broker e O Event broker vai procurar aqueles que estão inscritos ao evento e-mail gestão então foi publicado veio pro event broker e O Event broker vai entregar essa mensagem para apenas esse elemento visto que apenas ele está inscrito em e-mail de gestão agora vamos a segundo caso temos um cadastro de pessoas e quando um cadastro de alguma pessoa foi efetuado nós vamos publicar dois eventos primeiro evento é pessoa registrada e o segundo e-mail gestão os

dois eventos são publicados no momento em que uma pessoa cadastrada então esses dois eventos vem pro event broker O Event broker vai pegar um evento por vez e vai falar pessoa registrada quem está inscrito em pessoa registrada el vai perceber que existem dois inscritos em pessoa registrada vai pegar essa informação e vai entregar para esses dois inscritos logo depois ele vai vir em e-mail gestão vai ver que e-mail gestão deve ser enviada para esse inscrito específico Então temos o seguinte percebemos que Um publicador pode publicar diversos eventos ao mesmo tempo mas que o subscribe só

consegue ouvir um evento por vez Justamente por isso porque quando uma pessoa é cadastrada por exemplo e vai ouvir pessoa registrada cadastro Rei vai ouvir esse evento mas o email RH também vai ouvir esse evento são procedimentos diferentes por causa do mesmo motivo que a pessoa foi registrado também temos a questão da das filas que foram foram abordadas quando esse cara publicar esses dois eventos esses eventos ficarão em fila e serão processados individualmente agora vamos entender melhor como funciona esse padrão diretamente na plataforma de JB plataforma JB Ela utiliza como event broker um rabit MQ

Então temos aqui dois principais sujeitos para que isso aconteça temos O Event publisher que é um componente e ele vai definir qual evento vamos publicar e vai definir também a mensagem que será enviada juntamente com esse evento e temos o subscriber que é o Trigger o Trigger ele vai capturar a mensagem que o o evento publicou então ele vai estar escutando o evento e vai receber essa mensagem criada pelo publisher então Já percebemos aqui o seguinte por ser um componente diretamente na aba de criação de pipelines podemos colocar diversos componentes que publicam eventos em um

único pipeline mas só podemos escutar um evento por vez e um pipeline que é por meio do Trigger justamente por ser um Trigger ele escuta um evento por vez nós vamos ver isso na prática diretamente na plataforma mas antes disso vamos ver sobre esses componentes event publisher que é um componente ele tem por exemplo o step name que é o nome que aparece no Canvas o evento que ele vai publicar então definimos o nome do evento aqui e por fim temos o corpo né a mensagem que será enviada na publicação desse evento temos também o

Trigger event então no Trigger event nas suas configurações nós vamos definir qual evento ele estará escutando quanto tempo esse evento pode ficar na fila antes da expiração e por exemplo outras configurações padrão de de pipelines Antes de mostrar isso na prática nós temos entender sobre o minar geria na plataforma por outras maneiras já disse que o a plataforma DB utiliza do Rabbit MQ porém existem diversas configurações do Rabbit MQ caso você queira fazer outro tipo de configuração uma das oportunidades é utilizar o Trigger Rabbit MQ juntamente com o componente rabit MQ na mesma lógica do

publisher subscriber isso se repete para outros dois temos também por exemplo jms PR mensageria também com padrão algum publicador e algum ouvinte eica que também temos publicadores e ouvintes emica especificamente temos um detalhe adicional temos a opção de ativar tanto no momento do publicador quanto no trig receber ou enviar oad como avro utilizando novo formato de dado mais eficiente para Grande volumetria Essa foi a apresentação de publisher subscriber e nos vemos nos próximos vídeos