ti-enxame.com

Para fluxo de trabalho ou não para fluxo de trabalho?

Sou responsável por uma equipe de desenvolvedores que iniciará o desenvolvimento de um sistema de reivindicações de seguro leve. O sistema envolve muitas tarefas manuais e fluxos de trabalho de negócios e estamos analisando o uso do Windows Workflow (.NET 4.0).

Um exemplo do domínio comercial é o seguinte: Um tomador de seguro liga para o contact center para apresentar uma reclamação. Esse "evento" dispara duas subtarefas que são acionadas manualmente em paralelo e podem levar um longo tempo para serem concluídas;

  1. Verificar se há fraude no cliente - Um processo manual pelo qual um operador chama várias empresas de crédito para verificar e avaliar o potencial de um cliente fraudulento. A partir daqui, a subtarefa pode inserir um número de subestados (verificação em andamento, verificação de referência com falha, verificação de referência aprovada, etc.)
  2. Enviar item ao centro de reparos - Um processo manual em que o item para o qual o tomador do seguro apresentou a solicitação é enviado ao centro de reparos a ser consertado. A partir daqui, a subtarefa pode inserir um número de subestados (Aguardando reparo, Em andamento, Reparado, Publicado, etc). A reivindicação só pode prosseguir quando o status de cada subtarefa atingir um status predefinido (com base nas regras de negócios).

Aparentemente, o Workflow é realmente a melhor opção de tecnologia; no entanto, tenho algumas preocupações ao usar o WF 4.0.

  1. Conjunto de habilidades - Observando o conjunto de habilidades médio do desenvolvedor, não vejo muitos desenvolvedores que entendem ou conhecem o Workflow.
  2. Manutenção - Parece haver pouco apoio dentro da comunidade para projetos WF 4.0) e isso, combinado com a falta de conjunto de habilidades, suscita preocupações em relação à manutenção.
  3. Barreira à entrada - sinto que o Windows Workflow tem uma curva de aprendizado acentuada e nem sempre é fácil de entender.
  4. Novo produto - Como o fluxo de trabalho foi completamente reescrito para o .NET 4.0, vejo o produto como um produto de primeira geração e talvez não tenha a estabilidade necessária.
  5. Reputação - As versões anteriores do Workflow não foram bem recebidas, consideradas difíceis de desenvolver e resultaram em má aceitação dos negócios.

Portanto, minha pergunta é: devemos usar o Windows Workflow (WF) 4.0 para essa situação ou existe uma tecnologia alternativa (por exemplo, Simple State Machine etc.) ou mesmo um mecanismo de fluxo de trabalho melhor para usar?

121
Kane

Eu fiz vários projetos WF4, então vamos ver se posso adicionar informações úteis para as outras respostas.

A partir da descrição do seu problema comercial, parece que o WF4 é uma boa combinação, portanto não há problemas.

Em relação às suas preocupações, você está certo. Basicamente, o WF4 é um produto novo e carece de alguns recursos importantes e possui algumas arestas. Há uma curva de aprendizado, você precisa fazer algumas coisas de maneira diferente. O ponto principal é o longo prazo e a serialização, algo que o desenvolvedor comum não está acostumado e que requer algumas considerações para dar certo, pois ouvi muitas vezes que as pessoas têm problemas para serializar o contexto de dados da estrutura de uma entidade.

Na maioria das vezes, o uso de serviços de fluxo de trabalho hospedados no IIS/WAS é a melhor rota para executar esses tipos de fluxos de trabalho de longa duração. Isso dificulta a solução do problema de controle de versão, basta que a primeira mensagem retorne a versão do fluxo de trabalho e faça parte de cada mensagem subsequente. Em seguida, coloque o roteador WCF entre as rotas da mensagem para o terminal correto com base na versão. O básico é nunca alterar um fluxo de trabalho existente, sempre criar um novo.

Então, qual é o meu conselho para você? Não faça uma grande aposta em uma peça de tecnologia desconhecida e para você não comprovada. Faça um pequeno pedaço não crítico do aplicativo usando o WF4. Dessa forma, se funcionar, você poderá expandi-lo, mas se falhar, poderá removê-lo e substituí-lo pelo código .NET mais tradicional. Dessa forma, você obtém experiência real com o WF4 em vez de ter que basear uma decisão em informações de segunda mão e aprende uma nova e poderosa tecnologia no processo. Se possível, faça um curso no WF4, pois você economizará muito tempo para se atualizar (plugue auto descarado aqui ).

Sobre a Simple State Machine. Eu não o usei, mas fiquei com a impressão de que era para máquinas de estado de execução curta, na memória,. Um dos principais benefícios do WF4 são os aspectos de longo prazo.

51
Maurice

Cheguei a esse dilema algumas vezes e decidi não usar a base do Work Flow. Algumas considerações (semelhantes às suas) foram

  1. Os fluxos de trabalho envolvidos eram muito mais simples (uma combinação de máquina de estado e ações seqüenciais) e fazê-lo em WF parece exagerar nos esforços envolvidos).
  2. Curva de aprendizado para os desenvolvedores entenderem e usarem WF foi considerado efetivamente alto. A tabela de transição de status descrevendo transições e ações válidas a serem tomadas é usada para flexibilidade adicional e os desenvolvedores ficaram à vontade com ela, compreendendo facilmente o conceito e finalidade.
  3. As chances de mudanças nos processos de negócios foram reduzidas e mudanças rudimentares foram facilmente possíveis com a ajuda da tabela de transição. Uma mudança na transição significaria um script de banco de dados, enquanto a mudança nas ações resultaria em uma nova versão/patch. No entanto, a probabilidade de tal ocorrência foi considerada baixa.

Olhando para trás depois de 13 a 14 meses, ainda acho que a decisão de não usar WF estava correta. IMO, WF faz sentido onde há forte probabilidade de que o fluxo de trabalho pode mudar e/ou as regras de negócios podem mudar. WF permite isolar o fluxo de trabalho em um arquivo separado e, portanto, torná-lo configurável pelos usuários será mais simples.

17
VinayC

Temos usado o WF 4.0 nos últimos dois meses. Devo dizer que é desafiador pensar da maneira do fluxo de trabalho. No entanto, posso dizer que vale a pena. Sabíamos muito pouco quando começamos) Compramos um livro iniciante e profissional para o WF 4.0 que ajudou. Eu próprio assisti a muitos vídeos on-line e segui PDC 2009 pelas notícias de última hora) about WF 4.0 e como é diferente das versões anteriores um pouco ruins. Uma coisa importante para a qual tivemos que propor uma solução é a maneira como podemos lidar com o In/Our Arguments em um fluxo de trabalho sem limites) nossas atividades personalizadas para determinados tipos de dados e como passar parâmetros entre as atividades.Eu encontrei uma boa solução para isso, e a experiência do fluxo de trabalho que temos até agora não é nada ruim.Na verdade, temos um aplicativo que usa intensamente o fluxo de trabalho que está ficando cada vez maior e eu realmente não consigo me imaginar resolvendo isso em um ambiente diferente.Eu amo o efeito visual que ele tem: isso me mantém A maneira como os detalhes de if/else etc constroem e tornam as regras de negócios aparentes de uma maneira que não o obrigam a mergulhar nas linhas de código para saber o que está acontecendo ou como corrigir algum bug. A propósito, o projeto em que trabalhamos é muito semelhante ao que você descreveu e é um projeto de tamanho médio. Você pode dizer pelas minhas palavras que eu gosto e recomendo, embora isso incorpore alguns riscos, pois é uma nova tecnologia e você precisa ter algumas idéias inovadoras.

meus 2 centavos ...

15
Derar

Eu fiz três projetos no WF 3.5 e devo dizer que não é fácil. Isso força você a pensar de uma maneira totalmente nova, especialmente quando a persistência é usada. Atualizando o aplicativo que contém centenas de itens incompletos o fluxo de trabalho persistente é desafiador. É comum a alteração de quebra única na serialização. É comum a introdução de várias versões da mesma biblioteca para suportar fluxos de trabalho em execução novos e antigos.

Ainda não tentei o WF 4.0 ainda, mas com base na experiência do BizTalk e WF 3.5) 3.5 Eu acho que será semelhante.

De qualquer forma, a melhor abordagem que você pode adotar é fazer a Prova de conceito. Pegue um único WF de seus requisitos e tente implementá-lo em WF 4.0 4.0. Você gastará algum tempo com ele, mas provará se é capaz de fazê-lo isso em WF 4.0 e se houver algum benefício visível.

Se você decidir usar WF 4.0, insisto que verifique a possibilidade de executar WF como serviço WCF hospedado no Windows AppFabric. O AppFabric fornece algumas funcionalidades prontas para uso) para hospedagem de WFs.

9
Ladislav Mrnka

Acho que atualmente não faz sentido falar sobre o Workflow no WF4 como uma opção de tecnologia para esse tipo de problema. O que é realmente apropriado, como mencionado por Ladislav Mrnka acima, são os WCF WF Services hospedados no AppFabric.

Minha experiência com isso é que ele paga grandes dividendos e é muito agradável, mas surgem problemas no começo porque não é bem entendido que, para muitos programadores, essa é uma mudança de metodologia mais do que uma mudança de tecnologia. Por outro lado, os generalistas e aqueles com uma mentalidade de solução de problemas viram o WCF WF AppFabric como um conjunto de oportunidades interessantes. Portanto, se a mistura de pessoas no projeto for devs C # razoavelmente conservadoras, anexada ao conjunto diário de OO e padrões, será difícil introduzir. Se a equipe for mais inovadora, a adoção será muito mais fácil, porque o potencial e as novas portas se multiplicam a cada descoberta.

Dois problemas conceituais principais que os programadores tiveram ao mudar para essa tecnologia foram: a) Correlação de mensagens e padrões de troca de mensagens b) Fluxos de trabalho e teste de unidade Em sistemas padrão em C #, por exemplo, um fluxo de trabalho raramente é explícito e, portanto, raramente é testado em unidade. O fluxo de trabalho geral é deixado para teste em cenários de aceitação ou integração. Apresente um WF explícito como um artefato de software e, de repente, os desenvolvedores padrão querem tentar fazer o teste de unidade, o que geralmente não vale a pena.

O aspecto da correlação de mensagens é um pouco de mudança de mentalidade para aqueles que não estão familiarizados com os padrões de troca de mensagens. A maioria dos desenvolvedores lida com chamadas remotas e em processo, serviço da web e SOAP, e geralmente se concentra em uma ou duas delas. Abstrair acima de tudo e trabalhar com um sistema geral baseado em mensagens pode ser confuso a princípio.

No lado positivo, o resultado final é algo que economiza muito tempo e cria muitas oportunidades. Uma coisa principal é que o worfklow, se visualmente claro, é algo que pode ser trabalhado juntos pelo usuário final, desenvolvedor e analista, eliminando etapas desnecessárias no ciclo de vida do desenvolvimento e concentrando as partes em um artefato. Além disso, desencoraja ilhas de funcionalidade em aplicativos dedicados, com camadas de cola dedicadas, incentivando um conjunto de processos de negócios em WF por domínio comercial. Além disso, com o AppFabric, o encanamento para persistência, registro e ativação de atividades agendadas é feito para você. O desempenho do WF4 também é excelente.

Minha recomendação seria encontrar o membro da equipe mais inovador ou explorador que fizesse o exame inicial para descobrir as partes complicadas, colocar as funções principais em funcionamento e fazer com que essa pessoa inicial fosse responsável por compartimentar o restante do trabalho.

9
Sentinel

Para executar um sistema de reivindicação de seguro de qualquer complexidade que envolva funções e "subtarefas", você realmente precisa de uma solução de BPM, não apenas de fluxo de trabalho. O Workflow Foundation 4.0 é liso, mas realmente não chega nem perto das funcionalidades de um produto BPM.

As soluções de BPM, como Metastorm BPM, Global360 e K2.NET, fornecem fluxo de trabalho, tarefas, funções e integração de sistemas centrados no ser humano, que podem modelar e otimizar os processos de negócios, como o seu sistema de reivindicação de seguro. Use o ASP.NET para criar a interface que se integra ao mecanismo de fluxo de trabalho BPM, já que seus designers internos geralmente são limitados e forçam você a usar seu controle da Web personalizado, que geralmente não é tão completo quanto os controles da Web do ASP.NET.

5
Stephen Cao

Vá com a tecnologia que sua equipe conhece e se sente à vontade. O Workflow Foundation não é um produto que você possa usar imediatamente - é um conjunto de peças que você pode incorporar ao seu aplicativo para criar um sistema de fluxo de trabalho. IMHO, a lógica do fluxo de trabalho é a parte menos importante da tecnologia. Antes de tudo, você precisa se concentrar na GUI, porque os empresários não verão nada além da GUI. Mas se o seu sistema for bem-sucedido, você deverá estar preparado para solicitações de mudança sem fim e novos requisitos, para implementar sua lógica de negócios, para que seja fácil mudar e dividir em processos separados para atender a diferentes necessidades do usuário (às vezes contraditórios) . O BPM ajuda nessa tarefa porque permite que você tenha várias versões separadas de processos de negócios que atendem a várias necessidades de negócios. Você não precisa de um mecanismo completo de BPM para isso, mas é útil codificar sua lógica de negócios para que ela possa ser versionada e dividida em processos de negócios individuais - a pior coisa a ter é um blob de código inatingível e entrelaçado que lida com 'tudo' e que ninguém pode entender. Existem muitas idéias para isso - máquinas de estado, DSLs (linguagens específicas de domínio), scripts etc. - você decide qual deve ser a implementação. Mas você deve sempre pensar em termos de processos de negócios e organizar sua lógica de acordo para refletir esses processos. E esteja preparado para a coexistência de muitas variantes da lógica de negócios e estruturas de dados - esta é a tarefa de design mais difícil.

4
nightwatch

Parece que sua equipe é centrada em c #, então talvez meus pensamentos não se apliquem. Eu administro uma empresa de tecnologia com muitos funcionários e encontramos a mesma necessidade. Ao contrário de muitos outros negócios, tínhamos muitos desenvolvedores à nossa disposição, portanto, uma solução de fluxo de trabalho baseado em código era ideal.

O problema é que não temos muitos recursos para configuração/manutenção do sistema e custos de licença, a menos que isso seja essencial para nossos negócios. O fluxo de trabalho do Azure/Window estava fora de questão. Também experimentamos algumas das grandes suítes de BPM existentes e encontramos mais problemas: elas oferecem uma experiência de programação visual bastante nerf. A programação simplesmente não pode ser totalmente realizada em um ambiente visual. Você pode ver o lista de softwares não BPM que realmente nos interessa. Ferramentas como Decisions.com e IFTTT são legais. De fato, as decisões podem ser uma boa opção para você, uma vez que ela se integra aos produtos da Microsoft como eu a entendo.

O final da história é que lançamos nosso próprio software como uma aventura empreendedora e para uso interno. Os fluxos de trabalho podem ser gravados e integrados a qualquer API, bem como processos humanos diretamente com formulários. Por exemplo, estamos integrando fluxos de trabalho para integrar novos desenvolvedores que extraem/atualizam muitos outros softwares. É relativamente verde, mas extremamente poderoso em cenários de fluxo de trabalho. Você pode fazer o checkout Nebri aqui. Como a abordagem baseada em regras é acionada nos eventos, a arquitetura é bem diferente. Reduz a quantidade de código que você precisa escrever e possui uma troca rápida. Mas ele pode lidar com coisas como processamento de eventos complexos facilmente, pois Python está à sua disposição).

3
Adam

Estou em uma situação em que tenho que usar o 4.0, pois o .NET 4.5 ainda não está credenciado para uso em nosso ambiente de produção. Tive muita dificuldade em entender como obter fluxos de trabalho de longa duração para atender às nossas necessidades comerciais, mas finalmente encontrei uma solução elegante. Não é algo que qualquer pessoa que venha a apoiar mais tarde possa entender com facilidade porque há muito em que pensar, mas acredito em WF como uma ferramenta para gerenciar estados de fluxo de trabalho.

Uma grande coisa que eu discuto WF 4.0, porém, é o comentário de Maurice:

O básico é nunca alterar um fluxo de trabalho existente, sempre criar um novo

Isso é ótimo se você quer apenas uma nova versão, mas e se você tiver 50.000 fluxos de trabalho persistentes e perceber que, em algum momento, há um bug no fluxo de trabalho? Você precisa poder atualizar o xamlx e ainda assim estar acoplado às instâncias existentes. Tentei descompactar as várias colunas de metadados na tabela de instâncias do SQL Server para encontrar algo que vincule a instância à definição de fluxo de trabalho sem sorte.

Escrevi um aplicativo de sincronização para importar dados de um sistema antigo para o nosso novo driver WF 4.0 4.0. Basicamente, carregamos os dados no sistema e, em seguida, executamos o processo que inicia automaticamente a chamada para o etapas do fluxo de trabalho e métodos de validação de chamada, que zombam da interação do usuário. Isso realmente funcionou bem conosco devido à arquitetura que implementamos para acessar o host do serviço de fluxo de trabalho. É ótimo como um exemplo, onde, após a execução, você pode passar e fazer verificações garantir a consistência do processo de migração de dados, mas ter que usar essa abordagem para potencialmente centenas de milhares de casos depois que um sistema estiver ativo não é realmente uma abordagem que instale confiança e sobrecarregue o processo de integração de correções simples.

Minha recomendação é que você evite o WF 4.0 por completo e vá direto para 4.5, se o seu ambiente o suportar. As Atualizações Dinâmicas e o Verso Lado a Lado que ele fornece para correção de bugs e WF tudo pronto para uso. Ainda estou para investigar exatamente como o 4.5 ainda não está credenciado para uso por nosso cliente, mas aguardando ansiosamente esta oportunidade.

O que espero desesperadamente é que nosso cliente não solicite alterações na política (e, portanto, ajustes no fluxo de trabalho) e que os fluxos de trabalho atuais sejam mantidos sem erros. Esta última é uma esperança vã e vazia, pois os insetos sempre aparecem.

Eu realmente não consigo entender o que estava passando pelas cabeças da equipe de desenvolvimento de WF para lançar um sistema em que você não pode consertar bugs facilmente. Eles deveriam ter desenvolvido uma técnica para vinculando uma instância ao novo xamlx.

3
Stephen York