Casos de uso do Workflow Engine

Question

Gostaria de saber sobre problemas específicos que você - o leitor SO - resolveu usando Workflow Engines e quais bibliotecas/frameworks você usou se não criou o seu próprio.Também gostaria de saber quando um Workflow Engine não foi a melhor escolha e se/como você escolheu algo mais simples, como um aplicativo do tipo TaskList/WorkList/Task-Management usando máquinas de estado.

Questões:

• Que problemas você usou mecanismos de fluxo de trabalho para resolver?
• Quais bibliotecas/frameworks você usou?
• Quando um sistema mais simples do tipo State Machine/Task Management foi suficiente?
• Bônus:Como você fez/você fez a distinção entre Gerenciamento de tarefas e Mecanismo de fluxo de trabalho?

Procuro experiências em primeira mão.

Alguns dos recursos que verifiquei:

• Ruote e Máquina de estado! = Mecanismo de fluxo de trabalho
• Caminho de pedra e Documentos
• Criando e gerenciando planos de tarefas de lista de trabalho com Oracle
• Projeto e Implementação de um Motor de Workflow - Tese
• Para que usar o Windows Workflow Foundation
• Documentos do JBoss jBPM

Answer 1

Eu também sou tendencioso, pois sou o principal autor de Caminho de pedra.

Eu desenvolvi aplicativos de fluxo de trabalho para o Departamento de Estado dos EUA, o Centro de Genebra para Deminação Humanitária, vários clientes da Fortune 500 e, mais recentemente, o sistema escolar público de Washington DC. Toda vez que eu vi um 'mecanismo de fluxo de trabalho' que tentava ser o único mestre de referência para processos de negócios, vi uma organização lutando para trabalhar em torno da ferramenta. Isso pode ser devido ao fato de que essas soluções sempre foram orientadas por fornecedores/produtos e, em seguida, acabam com uma equipe tática de 'consultores' alimentando constantemente o aplicativo ... mas por causa disso, eu tendem a reagir negativamente quando ouço o Benefícios das ferramentas baseadas em processos que prometem "centralizar as definições de fluxo de trabalho em um só lugar e torná-las repetíveis".

Dito isto, eu gosto muito de Ruote - eu acompanho esse projeto há algum tempo e, devo precisar desse tipo de solução, será a próxima ferramenta que estarei disposto a tentar. O Stonepath tem um propósito muito diferente de Ruote - onde a Ruote é útil para o Ruby em geral, o Stonepath é destinado a Rails, a estrutura da web escrita em Ruby. Onde a Ruote é sobre processos de negócios de longa duração e suas definições associadas, o StonePath é sobre o gerenciamento do fluxo de trabalho e das tarefas estatais. Francamente, acho que a distinção do lado de fora pode ser sutil-muitas vezes os mesmos tipos de processos de negócios podem ser representados de qualquer maneira-o modelo baseado em estado e tarefa tende a mapear para o meu modelo mental.

Deixe-me descrever os destaques de um fluxo de trabalho baseado no estado. Em suma, imagine um fluxo de trabalho girando em torno do processamento de algo como um empréstimo hipotecário ou uma renovação de passaporte. À medida que o documento se move 'ao redor do escritório', ele viaja de estado para estado. Imagine se você é responsável pelo documento, e seu chefe lhe pediu a cada poucas horas para uma atualização de status e queria uma breve resposta ... você diria coisas como "está na entrada de dados" ... "Estamos verificando As credenciais do candidato agora "..." Estamos aguardando revisão de qualidade "..." Nós terminamos "... e assim por diante. Estes são os estados em um fluxo de trabalho baseado no estado. Passamos de estado para estado por meio de transições - como "aprovar", "aplicar", kickback "," negar "e assim por diante. Eles tendem a ser verbos de ação. Coisas como essa são modeladas o tempo todo no software como uma máquina de estado .

A próxima parte de um fluxo de trabalho baseado em estado/tarefa é a criação de tarefas. Uma tarefa é uma unidade de trabalho, normalmente com uma data de vencimento e instruções de manuseio, que conecta um item de trabalho (o pedido de empréstimo ou a renovação do passaporte, por exemplo), a um usuário "na caixa". As tarefas podem acontecer em paralelo entre si ou sequenciosamente, e podemos criar tarefas automaticamente quando entramos nos estados, criar tarefas manualmente à medida que as pessoas percebem que o trabalho precisa ser executado e exigir que as tarefas sejam concluídas antes que possamos passar para um novo estado. Todo esse tipo de comportamento é opcional e parte da definição do fluxo de trabalho.

A toca do coelho pode ser muito mais profunda do que isso, e eu escrevi um artigo sobre isso para a edição nº 4 do Pragpub, a revista Pragmatic Programmer. Confira o link REO acima para um PDF atualizado desse artigo.

Ao trabalhar com a StonePath nos últimos meses, descobri que o modelo baseado no estado mapeia muito bem para as arquiteturas da Web RESTful - em particular, as tarefas e as transições estaduais mapeiam bem como recursos aninhados. Espere ver futuras escrita de mim sobre este assunto.

Answer 2

Eu sou tendencioso, sou um dos autores de RUOTE.

Variante 1) Máquina de estado anexada a um recurso (documento, ordem, fatura, livro, mobília).

Variante 2) Máquina de estado anexada a um recurso virtual chamado uma tarefa

variante 3) Definições de fluxo de trabalho do motor de fluxo de trabalho

Agora, sua pergunta está marcada "BPM", podemos ser expandidos para "Gerenciamento de processos de negócios". Como esse tipo de gestão ocorre em cada uma das variantes?

Na variante 1, o processo de negócios (ou fluxo de trabalho) está espalhado no aplicativo. A máquina de estado anexada ao recurso aplica alguns dos aspectos do fluxo de trabalho, mas apenas aqueles relacionados ao recurso. Pode haver outros recursos com sua própria máquina estadual seguindo o mesmo processo de negócios.

Na variante 2, o fluxo de trabalho pode ser concentrado em torno do recurso de tarefas e representado pela máquina de estado em torno desse recurso.

Na variante 3, o fluxo de trabalho é promulgado interpretando um recurso chamado definição de fluxo de trabalho (ou definição do processo de negócios).

O que acontece quando o processo de negócios muda? Vale a pena ter um mecanismo de fluxo de trabalho onde os processos de negócios são recursos gerenciáveis?

A maioria das bibliotecas de máquinas estaduais tem 1 estados definidos + transições. Os mecanismos de fluxo de trabalho são, a maioria deles, intérpretes de definição de fluxo de trabalho e permitem que vários fluxos de trabalho diferentes sejam executados juntos.

Qual será o custo de mudar o fluxo de trabalho?

As variantes não são mutuamente exclusivas. Vi muitos exemplos em que um mecanismo de fluxo de trabalho altera o estado de vários recursos alguns deles guardados pelas máquinas de estado.

Eu também uso muito a variante 3 + 2, para tarefas humanas: o mecanismo de fluxo de trabalho, em alguns pontos ao executar uma instância do processo, entrega uma tarefa (workitem) a um participante humano (a tarefa de recursos é criada e colocada no estado 'pronta') .

Você pode percorrer um longo caminho apenas com o Variant 2 (a variante do gerenciador de tarefas).

Também podemos mencionar a variante 0), onde não há máquina de estado, mecanismo de fluxo de trabalho e os processos de negócios estão espalhados e/ou codificados no aplicativo.

Você pode fazer muitas perguntas, mas se você não dedicar um tempo para ler as respostas e não dedicar um tempo para experimentar e experimentar, não vai muito longe e nunca adquirirá nenhum talento para quando usar esta ou aquela ferramenta.

Answer 3

Em um projeto anterior em que estava trabalhando, adicionei algumas regras do tipo de fluxo de trabalho a um conjunto de formulários do governo no setor de cura.

Os formulários precisavam ser preenchidos pelo usuário final e, dependendo de algumas respostas, outros formulários foram agendados para serem preenchidos posteriormente. Houve também eventos externos que cancelavam formulários agendados ou agendariam novos.

Fluxo de amostra:

Paciente admitido -> Formulário de avaliação inicial do cronograma -> Formulário de revisão trimestral do cronograma -> Paciente morreu -> Cancelar revisão -> Formulário de avaliação de alta agendamento

Muitas outras regras foram baseadas em coisas como a idade do paciente, onde estavam sendo admitidas etc.

Este era um aplicativo ASP.NET, as regras eram basicamente uma tabela no banco de dados. Eu adicionei scripts, para que um script seja executado na conclusão do formulário para determinar o que fazer a seguir. Este era um design horrível e teria sido perfeito para um mecanismo de fluxo de trabalho adequado.

Answer 4

Verificar Rails_workflow Gem - acho que isso está perto do que você procura.

Answer 5

Sou um dos autores de Mecanismo de fluxo de trabalho Cadence desenvolvemos na Uber.A diferença entre o Cadence e a maioria dos mecanismos de fluxo de trabalho existentes é que ele é focado no desenvolvedor e é extremamente flexível e escalável (para dezenas de milhares de atualizações por segundo e até bilhões de fluxos de trabalho abertos).Os fluxos de trabalho são escritos como programas orientados a objetos e o mecanismo garante que o estado dos objetos de fluxo de trabalho, incluindo pilhas de threads e variáveis ​​locais, seja totalmente preservado em caso de falhas do host.

Que problemas você usou mecanismos de fluxo de trabalho para resolver?Cadence é usado para praticamente qualquer aplicativo de back-end que vá além de uma única resposta de solicitação.Exemplos de uso são:

• Trabalhos CRON distribuídos
• Gerenciando pipelines de ML/dados
• Reagindo a eventos de negócios.Por exemplo, eventos de viagem no Uber.O fluxo de trabalho pode acumular estados com base em eventos recebidos e executar atividades quando necessário.
• Implantação de serviços para Mesos/Kubernetes
• Implementação do pipeline de CI
• Garantir que várias chamadas de serviço sejam concluídas quando uma solicitação for recebida.Incluindo SAGA implementação de padrão
• Gerenciando tarefas de trabalhadores humanos (semelhante ao Amazon MTurk)
• Processamento de mídia
• Roteamento de tickets de suporte ao cliente
• Processamento de pedido
• Serviço de teste semelhante a Macaco do Caos

e muitos outros

O outro conjunto de casos de uso é baseado na portabilidade de mecanismos de fluxo de trabalho existentes para execução no Cadence.Praticamente qualquer linguagem de especificação de fluxo de trabalho de mecanismo existente pode ser portada para rodar no Cadence.Existem vários sistemas internos do Uber que foram portados.Dessa forma, um único serviço de back-end pode alimentar vários sistemas de fluxo de trabalho específicos de domínio.

Quais bibliotecas/frameworks você usou?

Cadence é um serviço independente escrito em Go with Ir e Java bibliotecas do lado do cliente.A única dependência externa é o armazenamento.Bancos de dados Cassandra e SQL são suportados.

Cadence também oferece suporte à replicação assíncrona entre regiões (usando a terminologia AWS).

Quando um sistema mais simples do tipo State Machine/Task Management foi suficiente?

Dentro da Uber o serviço Cadence é gerenciado pela nossa equipe.Portanto, a sobrecarga de construção de qualquer gerenciamento de máquina/tarefa de estado personalizado é sempre maior do que usar o Cadence.Fora da empresa é necessário configurar o serviço e armazenamento do mesmo.Se você já possui um banco de dados SQL, a implantação do serviço é trivial por meio de uma imagem docker.A janela de encaixe também é usada para executar um serviço Cadence local para desenvolvimento em um computador pessoal ou laptop.

Answer 6

Rolei meu próprio mecanismo de fluxo de trabalho para oferecer suporte ao processamento em fases de documentos - catalogação, enviando para processamento de imagens (trabalhamos com a redação SW), se necessário, enviando para a validação, depois libere e, finalmente, envie de volta ao cliente. No nosso caso, temos uma carga de documentos para processar, às vezes precisamos executar cada serviço separadamente para controlar a entrega e o uso de recursos. Simples em conceito, mas de alto desempenho e processamento distribuído necessário, e não conseguimos encontrar nenhum produto fora do prateleira que se encaixe na conta para nós.

Answer 7

Eu tenho uma experiência com o uso Activiti Motor BPMN 2.0 para lidar com processos de transferência de dados de alto desempenho e de alto rendimento em uma infraestrutura de nós de rede. A tarefa básica era permitir a configuração e o monitoramento desses processos de transferência e controlar cada nó de rede (por exemplo, solicitar o Node1 para enviar um arquivo de dados para o Node2 por meio de camada de transporte específica).

Pode haver milhares de processos em execução de cada vez e dezenas em geral ou com centenas de milhares de processos por dia.

Havia um monte de definições diferentes de processo, mas não era necessariamente exigido que um operador do sistema pudesse criar fluxos de trabalho personalizados. Portanto, o caso de uso primário para o próprio mecanismo BPM deveria ser robusto, escalável e permitir o monitoramento de cada fluxo de processo.

No final, basicamente funcionou, mas o que aprendemos com esse projeto foi que uma plataforma BPMN, ou melhor, o mecanismo Activiti especificamente, não era a melhor aposta para um sistema tão alto.

Os principais desafios foram a priorização de execução de tarefas, o bloqueio de banco de dados, as tentativas de execução para nomear os poucos relacionados ao próprio BPM. Então, tivemos que desenvolver o manuseio personalizado deles, por exemplo:

• O manuseio de tentativas no BPM para os casos em que um nó não tinha trabalhador gratuito para uma tarefa determinada ou quando o nó não estava funcionando.
• Execução de tarefas de transferência paralela em um único processo e sincronização dos resultados (sucesso/falha).

Não sei se outros mecanismos BPMN seriam mais adequados para esse cenário, pois o BPMN se destina principalmente a tarefas de negócios de longa duração que envolvem a interação do usuário em que o desempenho provavelmente não é o mesmo problema do nosso caso.

Answer 8

Eu sou um dos autores de IMIXS-WorkFlow. O IMIXS-WorkFlow é um mecanismo de fluxo de trabalho de código aberto baseado no BPMN 2.0 e totalmente integrado à pilha de tecnologia Java EE.
Eu desenvolvo mecanismos de fluxo de trabalho sozinho desde mais de 10 anos. Vou tentar responder à sua pergunta em resumo:

> Que problemas você usou mecanismos de fluxo de trabalho para resolver?

Meu objetivo pessoal quando comecei a pensar nos mecanismos de fluxo de trabalho era evitar que a lógica de negócios dentro do meu aplicativo. Muitas coisas em um aplicativo comercial podem ser reutilizadas, por isso faz sentido mantê -las configuráveis. Por exemplo:

• enviando uma notificação
• Veja tarefas abertas
• atribuiu uma tarefa a uma pessoa
• descrevendo a tarefa atual

Nesta lista de funções, você pode ver que estou falando sobre fluxos de trabalho centrados em humanos. Em resumo: um mecanismo de fluxo de trabalho centrado no ser humano responde às perguntas: quem é responsável por uma tarefa e quem precisa ser informado a seguir? E essas são as questões típicas nos requisitos de negócios.

> Quais bibliotecas/estruturas você usou?

5 anos atrás, começamos BPMN 2.0. O BPMN é o padrão comum para modelagem de processos. E a coisa surpreendente para mim foi que de repente conseguimos descrever processos de negócios altamente complexos que poderiam ser visualizados e executados. Eu recomendo que todos usem o BPMN para modelar processos de negócios.

> Quando foi suficiente uma máquina de estado/gerenciamento de tarefas mais simples como o sistema?

Uma máquina de estado simples é suficiente se você deseja rastrear o status de um objeto de negócios. É o caso quando você começa a introduzir o atributo 'status' no seu modelo de objeto. Mas, caso você precise de processos de negócios com responsabilidades, log e controle de fluxo, uma máquina de estado não é mais suficiente.

> Bônus: como você fez/você fez a distinção entre gerenciamento de tarefas e mecanismo de fluxo de trabalho?

Este é exatamente o ponto em que muitos mecanismos de fluxo de trabalho mencionados aqui diferem. Para um fluxo de trabalho centrado no ser humano, você normalmente precisa de um gerenciamento de tarefas para distribuir tarefas entre atores humanos. Para uma automação de processos, esse ponto não é tão relevante. É suficiente se o motor executar determinadas tarefas. Os mecanismos de gerenciamento de tarefas e fluxo de trabalho não podem ser comparados porque o gerenciamento de tarefas é sempre uma função de um mecanismo de fluxo de trabalho.