Basicamente, a diferença entre esses componentes é:

• Exclusivo: decide o destino da solicitação baseado em condições e a direciona para o fluxo da primeira condição atendida. A partir disso, ela segue adiante em um fluxo único.

  #ebecf0

  trueExemplo
  Em um processo de Aprovação de crédito, um cliente faz uma solicitação de crédito para um banco e o processo precisa determinar se a solicitação é aprovada ou rejeitada. Para tomar essa decisão, esse componente analisa a pontuação de crédito que o cliente possui no mercado. Se a pontuação for maior que 700, o crédito é concedido e a solicitação segue para as etapas necessárias para que seja liberado ao cliente. Caso contrário, o crédito é negado e a solicitação é finalizada.
  

• Paralelo: divide o fluxo em várias etapas que podem ser executadas em paralelo e, depois de finalizadas, o fluxo se torna único novamente.

  #ebecf0

  trueExemplo
  Em um processo de Lançamento de produto, as etapas Marketing, Logística e Treinamento de vendas podem ser feitas simultaneamente. Dessa forma, esse componente divide o fluxo em três etapas e indica o início dessas etapas que serão executadas em paralelo. Quando finalizadas, as três etapas são unificadas pelo componente Join e o fluxo volta a ser único.
  

  
  

• Inclusivo: é uma junção do Exclusivo e do Paralelo, ou seja, divide o fluxo no número de etapas correspondente ao número de condições que foram atendidas.

  #ebecf0

  trueExemplo
  Em um processo de Análise de renda, o banco verifica qual é a renda familiar do cliente para que diferentes tipos de crédito ou investimentos sejam aprovados ou oferecidos. Existem 3 condições:

  1. se a renda for maior que R$ 8.000,00, o financiamento de automóvel é liberado para o cliente;
  2. se a renda for maior que R$ 15.000,00, o financiamento de imóvel é liberado para o cliente;
  3. se a renda for maior que R$ 20.000,00, a compra de títulos do governo é oferecida como investimento para o cliente.

  Vamos supor que um cliente possua a renda de R$ 18.000,00. Quando sua renda for analisada, as duas primeiras condições serão atendidas. Neste caso, o fluxo seguirá paralelamente por dois caminhos: o que leva para a etapa Liberar financiamento automóvel e o que leva para a etapa Liberar financiamento imóvel. A terceira condição não é atendida, por isso, o fluxo não seguirá pelo caminho correspondente a ela.

Não. O componente Exclusivopor si só não costuma comprometer o desempenho de um processo de forma significativa. No entanto, o impacto no desempenho depende mais do contexto em que ele é utilizado e das decisões associadas a ele.

Se houver muitas condições complexas sendo avaliadas ou se o processo tiver muitos componentes Exclusivos com decisões complicadas em cada passo, isso pode, de fato, afetar o desempenho de forma indireta, mas não por causa do componente em si, mas pela lógica de decisão ou pela quantidade de validações necessárias.

Além disso, em ambientes que exigem processamento de alta carga ou baixa latência, o número excessivo de validação de condições em componentes Exclusivos pode, em alguns casos, aumentar o tempo de execução do processo. Isso seria mais um reflexo da lógica e da complexidade da aplicação do que do componente em si.

No geral, o componente Exclusivo não costuma ser a causa direta de baixo desempenho, mas a forma como ele é aplicado, em conjunto com outras práticas e a complexidade das condições envolvidas, pode influenciar no tempo de execução do processo.

Sim, é possível criar múltiplas regras para cada condição, bem como, criar múltiplas condições para serem validadas em cada componente Exclusivo de um processo.

Porém, vale ressaltar que as condições são validadas na ordem em que são criadas. Por isso, é importante garantir que a lógica de decisão seja clara para evitar que rotas inadequadas sejam seguidas.

Também é importante que exista um fluxo padrão, que funciona como um escape e será seguido quando nenhuma das condições for atendida.

Em resumo, é possível utilizar várias regras e condições, desde que cada rota tenha sua própria expressão condicional. A escolha da rota a ser seguida é feita de forma exclusiva com base na validação dessas condições.

Para testar se as condições criadas para o componente Exclusivo estão corretas, é possível seguir algumas abordagens:

• validação manual: revisar as condições – analisando as expressões e verificando se são lógicas e se não existe sobreposição ou ambiguidades entre elas – e compreender os dados envolvidos – entendendo quais variáveis ou dados são avaliados para garantir que as condições estejam de acordo com o esperado em cada situação;

• testes: criar um conjunto de entradas (valores das variáveis) que abrangem as possibilidades de decisão que o componente pode tomar. Depois, executar o processo com essas entradas e verificar se ele segue a rota correta;

• ferramentas de teste de BPMN: utilizar alguma ferramenta que ofereça recursos específicos para validação e testes do componente Exclusivo. Essas ferramentas permitem simular a execução do processo, analisar os fluxos e verificar se as decisões tomadas pelo componente estão corretas;

• revisão lógica de negócio: contar com a análise colaborativa dos especialistas no negócio pode ajudar a validar se as condições criadas fazem sentido para o objetivo do processo. 

Existem alguns motivos pelos quais uma solicitação pode ficar "presa" no componente Exclusivo e geralmente eles estão associados à forma como as condições e lógicas de decisão foram configuradas. Os motivos mais comuns são:

• condição não atendida: nenhuma das condições configuradas para o componente foi atendida e não existe um fluxo padrão de escape. Isso pode ocorrer quando as condições não foram configuradas corretamente, não consideraram algum cenário mais específico ou a lógica das condições não foi definida de forma adequada;

• dados ou variáveis de entrada ausentes ou inválidos: quando dados ou variáveis que são utilizados para determinar a rota que a solicitação deve seguir não estão presentes no processo ou são inválidas. Por exemplo, um dado ou variável que deveria ter sido preenchida anteriormente e não foi;

• inconsistência de execução: se ocorrer alguma inconsistência ou falha técnica na plataforma que está executando o processo no momento de avaliar as condições do componente, o fluxo pode ser interrompido sem ser direcionado para uma rota válida. Isso também pode ocorrer por questões de timeout – se o fluxo envolve tempos de espera ou tempos máximos e esses tempos tenham sido atingidos sem que existam definições sobre como lidar com esses casos – e por questões de integração – quando o fluxo depende de dados de uma fonte externa (como API, banco de dados ou integração com outros produtos) e ocorrer alguma falha nessa fonte;

• falta de fluxo padrão: não há um fluxo padrão por onde a solicitação possa seguir caso nenhuma das condições seja atendida. É uma boa prática sempre definir um fluxo padrão, pois garante que o fluxo não seja interrompido quando nenhuma condição foi atendida;

• falhas em subprocesso ou etapas anteriores: se antes do componente um subprocesso ou etapa falhou ou não foi completada corretamente – não fornecendo as informações necessárias para a decisão, por exemplo – pode afetar a validação das condições e impedir o avanço da solicitação.

Para resolver essas questões, é importante revisar as regras e condições, garantir que as variáveis de entrada estão sendo corretamente inseridas e sempre definir um fluxo padrão para que sempre haja uma rota válida para a solicitação seguir adiante.