Olá esse é integration developer bootcamp estamos na etapa de boas práticas de desenvolvimento nesse vídeo falaremos sobre centralização de erros utilizando on Exception de subfluxo componentes que permitem a criação de subfluxo contam com a possibilidade de configuração de um on Exception para tratamento de erros é uma boa prática utilizar ao menos um componente log no fluxo do inception mesmo que não utilize para tratar erros isso tornará a rastra abilidade de erros mais fácil caso ocorra algum erro inesperado no processo também é possível utilizar o One inception de componentes para centralizar o tratamento de erros e
principalmente evitar a redundância no caso posterior temos um fluxo dentro de um process que possui saídas de erro para cada Choice aqui antes de parar interromper o fluxo por meio do troll nós enviamos um e-mail para o usuário com algum conteúdo específico Porém esse envio de e-mail ele se repete em todos os caminhos do Choice e aqui qualquer motivo que a gente precisa fazer alguma manutenção nesse envio de e-mail nós teríamos que fazer essa manutenção em todos esses componentes e isso não é uma boa prática porque estamos fazendo uma repetição desnecessária de componentes aqui podemos
resolver esse problema utilizando um process e um acception de Blocks e ctions da seguinte forma colocando todo esse processamento dentro de um Block execution esse caso aqui seria o caso do on process todos aqueles envios de e-mails agora serão centralizados no meu on Exception o que acontece aqui é o seguinte a informação chega pelo direção de entrada passa pela condição E aqui depois da condição há um TR erro que ativa meu inception e em todos os casos o meu inception será ativado e enviará um e-mail para o usuário aqui quando a gente precisar fazer uma
manutenção nesse componente por exemplo nós precisaremos fazer um uma única vez e não em todas as vezes que ele se repete como no caso anterior vamos ver um outro exemplo nesse fluxo temos diversas coisas acontecendo temos uma chamada H depois uma verificação de sucesso de falha temos algumas transformações e validações depois eu envio para outro sistema um detalhe que temos aqui é que depois de todas as chamadas externas nós temos uma verificação de sucesso de falha e em todos os casos de falha temos exatamente mesmo tipo de tratamento de erro que é nós devemos enviar
um e-mail para o gestor responsável pelo projeto por exemplo só que aqui os componentes são exatamente iguais para todos os dois tratamentos e na hora de fazer algum tipo de manutenção Principalmente se o fluxo fosse ainda maior teremos que repetir toda essa manutenção em cada condição de erro que é tratada por esse fluxo aqui nós podemos evitar essa repetição de componentes e centralizar o erro no Exception novamente e para fazer isso vamos fazer fazer o seguinte todo esse fluxo que estamos vendo ele vai passar a ficar dentro do meu on process do meu Block Exu
chamado processamento então aqui o que temos é o seguinte esse fluxo passa vir pro on process e esses componentes que estão repetidos logo anteriormente ao trow serão colados no meu on Exception e aqui temos o seguinte esse tratamento agora ele é disparado pelo troll meu on inception ativado e aqui temos os componentes que viamos anteriormente assim o quando precisamos fazer algum tipo de manutenção nós precisamos ir direto para um Exception e faremos essa manutenção uma única vez evitando a redundância e evitando uso desnecessário de componentes assim a gente faz a centralização do erro de maneira
mais performático agora nós vamos entrar na plataforma e ver como funciona esse método de centralizar erros com Exception em Loops e entender como funciona o encadeamento de erros que é o que aconteceria se se eu precisasse por exemplo pegar o erro que aconteceu dentro desse Block execution como eu faria com que esse erro viesse para o Exception desse processamento nós vamos ver isso na plataforma agora uma plataforma aberta já demonstrando no caso anterior temos o seguinte no meu on process eu tenho todo aquele processamento que vimos anteriormente e aqui no trow erro Eu tenho um
certo padrão eu tenho atributos status message pad repetindo em todos os TR erros aqui aqui e dentro do meu Block execution aqui no process eu tenho validator e no inception eu tenho outro trow erro também com o mesmo padrão de trow erro então o primeiro passo para fazer uma centralização é pegar todos os TR erros disparados dentro me process e manter um padrão assim tudo que chegar no one Exception vai chegar no mesmo formato e podemos fazer uma centralização um envio de e-mail por exemplo eh de maneira dinâmica Sem problemas vamos ver como funciona para
encadear aqui é o seguinte temos um Block execution de processamento em que diretamente na raiz desse Block execution temos esse e esse entretanto Se eu entrar em mais um BL execution como esse caso como eu faço para que o erro disparado aqui nesse process seja capturado pelo processament acamento para fazer isso é o seguinte primeiro o erro que acontecer aqui nesse caso representado pelo validator ele vai ser disparado para o One Exception desse Block execution então se eu tivesse um trou no meu One process meu One Exception seria ativado aqui caso eu não coloque esse
throw error aqui o que aconteceria era que o meu fluxo no processamento continuaria normalmente da seguinte forma caso eu não colocasse error faria o seguinte ele passaria pelo One PR encadear um erro que iria adicionar um Exception e no Exception ia fazer algum tratamento e aqui iria continuar meu fluxo normalmente caso eu queira parar o meu fluxo do processamento caso ocorra um erro aqui dentro Eu preciso colocar aqui dentro um outro TR erro aqui assim o que vai acontecer é o seguinte no meu process por meio do validator será disparado um erro será ativado o
exception Exception Eu tenho um outro true error E aí o resultado disso é como se tivesse um true error nessa posição o que aconteceria como vemos em diversos casos é que o fluxo pararia nesse momento iria direto pro on Exception do meu processamento então o erro que aconteceu no process desse Block execution iria ser encadeado para o One Exception do processamento e ele iria vi para esse caso aqui então para encadear os erros nós precisamos colocar throw errors dentro do Exception dos blocos que estão dentro de outros blocos isso poderia continuar acontecendo em diversos níveis
se eu tivesse um Block execution dentro do process desse Block execution primeiro eu teria que parar o erro no process seria redirecionado pelo inception colocaria um erro no inception que viria para cá e nesse Exception tem outro erro que viria para um Exception desse e assim por diante Resumindo para fazer o encadeamento de erros eu preciso colocar trow errors dentro de um Exception assim eu vou interromper o fluxo naquele momento e ao invés de fazer algum tipo de tratamento e continuar o fluxo normalmente para o tratamento de Sub de loopings Temos algo muito parecido a
diferença dos loopings é o seguinte como esse processamento ocorre diversas vezes aqui dentro nós não devemos colocar um TR erro dentro do Exception devemos apenas em um caso me on process ele fará diversos tipos de processamento em looping E caso algum desses problemas der erro no meu on process terá um TR será disparado para o Exception e aqui faremos o tratamento caso não coloquemos um true error dentro desse forit todos os outros registros continuarão normalmente e o resultado seria um somador de sucesso com um elemento a menos por exemplo se tivesse 100 registro sendo processado
pelo meu farit e apenas um dele dese erro eu teria que 99 registros deram sucesso e um deu erro e nesse único registro que deu erro ele ativaria um Exception uma única vez naquela repetição de looping assim se eu não colocar outro erro dentro do meu Exception ele Continuará fazendo os registros dos outros componentes agora se eu colocar out erro dentro do meu inception ele vai parar todo o meu flo e todo o meu farit Então se no meu registro 55 aconteceu um erro e eu coloco out erro dentro do inception nenhum Outro registro de
55 paraa frente será processado Então não é recomendada essa prática apenas em casos em que realmente o fluxo deve parar essa foi a apresentação de centralização de erros utilizando o Exception de subfluxo e nos vemos nos próximos vídeos
