Olá esse é o integration developer bitcamp estamos na etapa de boas práticas de desenvolvimento hoje falaremos sobre subfluxo e Block execution alguns componentes da plataforma Deb nos permitem criar sub fluxos ou sub pipelines para processamento os principais componentes que são que nos permitem isso são o forit oou Block execution e o string DB existem diversos outros componentes na plataforma que possuem a tecnologia de subfluxo mas esses são os mais comummente utilizados todos eles possuem essa coloração rosa e esse formato pentagonal para auxiliar desenvolvedor a entender quando componentes possuem essa tecnologia ou não para cada componente
de subfluxo da DB Existem duas opções adicionais para configurar além das configurações padrões do componente e essas duas configurações adicionais são o One process e o One Exception então ao passar o mouse por cima do componente Como por exemplo o Block execution nós temos além da engrenagem da lixeira que estamos habituados temos esses dois do meio que representam One process e One Exception ao clicar em qualquer um desses dessas configurações adicionais um novo pipeline ou melhor um sub pipeline será aberto para construção novo pipeline Será aberto para construção no caso dopr ele é comumente utilizado
para definir um determinado processamento e ele é representado por uma sequência de conectores já no assim como no one process também definiremos a partir de conectores uma sequência um novo pipeline ou um sub pipeline para construção só que a diferença entre os dois é que no caso do Exception ele é utilizado para um tratamento de erro e ele somente ser acionado caso ocorra algum erro dentro do do sub pipeline do on process então aqui nós definimos algum tipo de processamento qualquer e qualquer erro estourado aqui dentro como por exemplo um trow erro esse pipeline será
acionado e aqui teremos uma sequência de con tores para fazer algum tipo de tratamento de erro caso desejemos falando agora sobre o Block execution em si ele permite o desenvolvedor agrupar de forma lógica trechos de um pipeline seus principais casos de uso são separar e agrupar trechos de um pipeline para que o processamento seja mais intuitivo e ele permite que diferentes caminhos de processamentos criados pelos pipelines se unam em um único processamento evitando a redundância do no pipeline para entender um pouco melhor esse contexto temos o seguinte verificações com componente Choice podem dividir um pipeline
em diversos caminhos em certos casos os caminhos podem começar a fazer o mesmo processamento gerando uma redundância no pipeline componente Block execution ele pode ser utilizado para unir o pipeline e evitar que esse problema aconteça Vamos ver isso de forma imagética aqui temos um exemplo de pipeline com redundância o que que isso significa a utilização do Choice para fazer validações pode gerar diversos caminhos que possuem o mesmo processamento causando uma repetição desnecessária de componentes então no exemplo a seguir temos um Choice que ele verifica um atributo cidade e necessidade ele verifica se o valor desse
atributo é vazio ou não caso ele seja vazio nós entraremos nessa direção do fluxo caso ele não seja vazio nós entraremos nessa direção do fluxo só que perceba o seguinte no caso em que o atributo cidade esteja vazio Eu tenho um componente para preencher o atributo cidade com valor padrão e logo depois eu tenho um certo processamento que é transformações na estrutura o envio desse Registro para um serviço post no sistema B por exemplo depois uma verificação se essa requisição foi bem sucedida mas ao compararmos com o fluxo de baixo percebemos que todo esse processamento
é idêntico aqui temos o seguinte a partir desse momento tanto aqui quanto aqui o meu payload o meu jison de entrada é igual a única coisa que eu fiz foi que no caso que ele estivesse vazio eu vou fazer um enriquecimento do meu dado porém toda a transformação seguinte é exatamente igual e se tivesse um um fluxo ainda maior isso poderia provocar ainda mais repetições de componentes e um dos problemas que isso gera é além de um uma má utilização da memória do pipeline temos o caso que no momento de fazer uma manutenção teremos que
fazer manutenção em outros componentes por exemplo eu teria que fazer componente uma manutenção no componente de eu teria que também fazer no fluxo de baixo por conta de não estar de maneira centralizada estar de maneira repetida para resolver esse problema temos o seguinte com a utilização do Block execution todos os caminhos que finalizam os subfluxo são convergidas no componente imediatamente posterior ao blo então no caso anterior após o esses componentes de transformer e o log temos ex o mesmo dião de entrada o processamento é o mesmo para todos os dois caminhos então eu posso colocar
todo esse essa estrutura dentro do meu process do Block execution e todos esses caminhos serão converg no componente imediatamente posterior ao Block execution Assim eu evito que eu tenha que repetir todos os componentes para cada caminho do Choice e a manutenção se torna centralizada e o processo se torna mais eficiente para entender melhor sobre essa questão de Como configurar os subfluxo vamos abrir a plataforma e eu vou dar um exemplo utilizando Block execution e validator justamente para demonstrar a utilização de do um um Exception para tratamento de erros que ocorrem no on process te vejo
na plataforma
