Al flusso di lavoro o non al flusso di lavoro?

Sono responsabile di un team di sviluppatori che stanno per iniziare lo sviluppo di un sistema di reclami assicurativi leggero. Il sistema prevede molte attività manuali e flussi di lavoro aziendali e stiamo cercando di utilizzare il flusso di lavoro di Windows (.NET 4.0).

Un esempio del dominio aziendale è il seguente: un assicurato chiama il contact center per presentare un reclamo. Questo "evento" attiva due attività secondarie che vengono eseguite manualmente in parallelo e possono richiedere molto tempo per essere completate;

1. Controlla il cliente per frode - Un processo manuale in base al quale un operatore chiama varie società di credito per verificare e valutare il potenziale di un cliente fraudolento. Da qui l'attività secondaria può inserire una serie di stati secondari (Controllo in corso, Controllo riferimenti non riusciti, Controllo riferimenti superato, ecc.)
2. Invia articolo al centro riparazioni - Un processo manuale in cui l'articolo per il quale l'assicurato ha presentato il reclamo viene inviato al centro riparazioni per essere riparato. Da qui l'attività secondaria può immettere una serie di stati secondari (In attesa di riparazione, In corso, Riparato, Registrato, ecc.). La richiesta può procedere solo una volta che lo stato di ciascuna attività secondaria ha raggiunto uno stato predefinito (in base alle regole aziendali).

In superficie sembra che Workflow sia davvero la migliore scelta tecnologica; tuttavia ho alcune preoccupazioni nell'utilizzo di WF 4.0.

1. Set di abilità - Guardando il set di abilità medio degli sviluppatori non vedo molti sviluppatori che capiscono o conoscono il flusso di lavoro.
2. Manutenibilità - Sembra esserci scarso supporto all'interno della comunità per i progetti WF 4.0 e questo, unito alla mancanza di competenze, solleva preoccupazioni sulla manutenibilità.
3. Barriera all'ingresso - Ho la sensazione che Windows Workflow abbia una curva di apprendimento ripida e non è sempre così facile da apprendere.
4. Nuovo prodotto - Poiché il flusso di lavoro è stato completamente riscritto per .NET 4.0, vedo il prodotto come un prodotto di prima generazione e potrebbe non avere la stabilità necessaria.
5. Reputazione - Le versioni precedenti di Workflow non sono state ben accolte, sono state considerate difficili da sviluppare e hanno comportato una scarsa accettazione del business.

Quindi la mia domanda è dovremmo usare Windows Workflow (WF) 4.0 per questa situazione o esiste una tecnologia alternativa (ad esempio, Simple State Machine , ecc.) O anche un motore di flusso di lavoro migliore da utilizzare?

Ho realizzato diversi progetti WF4, quindi vediamo se posso aggiungere informazioni utili alle altre risposte.

Dalla descrizione del tuo problema aziendale sembra che WF4 sia una buona corrispondenza, quindi nessun problema.

Per quanto riguarda le tue preoccupazioni hai ragione. Fondamentalmente WF4 è un nuovo prodotto e manca di alcune caratteristiche importanti e ha alcuni bordi irregolari. C'è una curva di apprendimento, devi fare alcune cose in modo diverso. Il punto principale è la lunga durata e la serializzazione, che è qualcosa a cui lo sviluppatore medio non è abituato e richiede un po 'di riflessione per ottenere il giusto perché troppo spesso sento che le persone hanno problemi a serializzare un contesto di dati del framework di entità.

La maggior parte delle volte l'utilizzo di servizi di flusso di lavoro ospitati in IIS / WAS è il percorso migliore quando si eseguono questi tipi di flussi di lavoro a lunga esecuzione. Ciò rende anche la risoluzione del problema di controllo delle versioni non complicata, basta che il primo messaggio restituisca la versione del flusso di lavoro e rendila parte di ogni messaggio successivo. Quindi inserire il router WCF tra che instrada il messaggio all'endpoint corretto in base alla versione. La base non è mai cambiare un flusso di lavoro esistente, ma crearne sempre uno nuovo.

Allora qual è il mio consiglio per te? Non scommettere troppo su una tecnologia sconosciuta e per te non provata. Eseguire una piccola parte dell'applicazione non critica utilizzando WF4. In questo modo, se funziona, puoi espanderlo, ma se fallisce puoi strapparlo e sostituirlo con un codice .NET più tradizionale. In questo modo ottieni una vera esperienza con WF4 invece di dover basare una decisione su informazioni di seconda mano e apprendi una nuova e potente tecnologia nel processo. Se possibile, segui un corso su WF4 in quanto ciò ti farà risparmiare un sacco di tempo per metterti al passo (senza vergogna collegarti qui ).

Informazioni sulla Simple State Machine. Non l'ho usato ma avevo l'impressione che fosse a breve termine, in memoria, macchine a stati. Uno dei principali vantaggi di WF4 sono gli aspetti di lunga durata.

Sono arrivato a questo dilemma un paio di volte e avevo scelto di non usare il fondotinta Work Flow. Alcune considerazioni (simili alla tua) lo erano

1. I flussi di lavoro coinvolti erano molto più semplici (una combinazione di macchine a stati e azioni sequenziali) e farlo in WF sembra essere eccessivo per gli sforzi coinvolti.
2. La curva di apprendimento per gli sviluppatori per comprendere e utilizzare in modo efficace WF è stata considerata elevata. La tabella di transizione dello stato che descrive le transizioni valide e le azioni da intraprendere viene utilizzata per una maggiore flessibilità e gli sviluppatori si sono sentiti a proprio agio, comprendendo facilmente il concetto e lo scopo.
3. Le possibilità di modifiche ai processi aziendali erano scarse e le modifiche rudimentali erano facilmente possibili con l'aiuto della tabella di transizione. Un cambiamento nella transizione significherebbe uno script di database mentre il cambiamento nelle azioni comporterebbe una nuova versione / patch. Tuttavia, la probabilità che si verificasse tale evento è stata ritenuta bassa.

Guardando indietro dopo 13-14 mesi, penso ancora che la decisione di non utilizzare WF fosse corretta. IMO, WF ha senso dove c'è una forte probabilità che il flusso di lavoro possa cambiare e / o le regole aziendali possano cambiare. WF consente di isolare il flusso di lavoro in file separati e quindi renderlo configurabile dagli utenti sarà più semplice.

Abbiamo utilizzato WF 4.0 negli ultimi due mesi. Devo dire che è difficile pensare in modo Workflow. Tuttavia, posso dirti che ne vale la pena. Sapevamo molto poco quando abbiamo iniziato. Abbiamo acquistato un libro per principianti e professionale per WF 4.0 che ci ha aiutato. Io stesso, ho guardato molti video online e ho seguito PDC 2009 per le loro ultime notizie su WF 4.0 e come è diverso dalle precedenti versioni un po 'schifose. Una delle cose principali per cui abbiamo dovuto proporre una soluzione è il modo in cui possiamo gestire In / Our Arguments in un flusso di lavoro senza limitare le nostre attività personalizzate a determinati tipi di dati e come trasferire parametri tra le attività. Ho trovato una buona soluzione per questo e l'esperienza del flusso di lavoro che abbiamo finora non è affatto male. In realtà, abbiamo un'applicazione ad alta intensità di flusso di lavoro che sta diventando sempre più grande e non riesco davvero a immaginarmi di risolverla in un ambiente diverso. Adoro l'effetto visivo che ha: mi tiene lontano dai dettagli dei costrutti if / else ecc. E rende evidenti le regole aziendali in un modo che non ti costringe a immergerti nelle righe di codice per sapere cosa sta succedendo o come correggere qualche bug. A proposito, il progetto su cui abbiamo lavorato è molto simile a quello che hai descritto ed è un progetto di medie dimensioni. Puoi dire dalle mie parole che mi piace e lo consiglio anche se incorpora alcuni rischi in quanto è una nuova tecnologia e devi trovare alcune idee innovative. mi tiene lontano dai dettagli dei costrutti if / else ecc e rende evidenti le regole di business in un modo che non ti costringe a immergerti nelle righe di codice per sapere cosa sta succedendo o come correggere qualche bug. A proposito, il progetto su cui abbiamo lavorato è molto simile a quello che hai descritto ed è un progetto di medie dimensioni. Puoi dire dalle mie parole che mi piace e lo consiglio anche se incorpora alcuni rischi in quanto è una nuova tecnologia e devi trovare alcune idee innovative. mi tiene lontano dai dettagli dei costrutti if / else ecc e rende evidenti le regole di business in un modo che non ti costringe a immergerti nelle righe di codice per sapere cosa sta succedendo o come correggere qualche bug. A proposito, il progetto su cui abbiamo lavorato è molto simile a quello che hai descritto ed è un progetto di medie dimensioni. Puoi dire dalle mie parole che mi piace e lo consiglio anche se incorpora alcuni rischi in quanto è una nuova tecnologia e devi trovare alcune idee innovative.

i miei 2 centesimi ...

Ho fatto tre progetti in WF 3.5 e devo dire che non è facile. Ti costringe a pensare in un modo completamente nuovo, specialmente quando si usa la persistenza. L'aggiornamento dell'applicazione che contiene centinaia di flussi di lavoro persistenti incompleti è impegnativo. Un singolo cambiamento decisivo nella serializzazione li blocca tutti. L'introduzione di più versioni della stessa libreria per supportare flussi di lavoro in esecuzione vecchi e nuovi è comune. È stata una sfida.

Non ho ancora provato WF 4.0, ma in base all'esperienza di BizTalk e WF 3.5 penso che sarà simile.

Comunque l'approccio migliore che puoi adottare è quello di fare Proof-of-Concept. Prendi un singolo WF dai tuoi requisiti e prova ad implementarlo in WF 4.0. Trascorrerai un po 'di tempo con esso, ma dimostrerai se sei in grado di farlo in WF 4.0 e se ci sono benefici visibili.

Se decidi di utilizzare WF 4.0, insisto per verificare la possibilità di eseguire WF come servizio WCF ospitato in Windows AppFabric. AppFabric fornisce alcune funzionalità predefinite per l'hosting di WF.

Penso che oggi non abbia davvero senso parlare del flusso di lavoro in WF4 come scelta tecnologica per questo tipo di problema. Ciò che è veramente appropriato, come menzionato sopra da Ladislav Mrnka, è WCF WF Services ospitato in AppFabric.

La mia esperienza con questo è che paga grandi dividendi ed è molto divertente, ma all'inizio sorgono problemi perché non è adeguatamente apprezzato che per molti programmatori questo è un cambiamento di metodologia più che un cambiamento di tecnologia. D'altra parte, i generalisti e quelli con una mentalità per la risoluzione dei problemi hanno visto WCF WF AppFabric come un insieme di opportunità entusiasmanti. Quindi, se il mix di persone nel progetto sono sviluppatori C # abbastanza conservatori collegati al loro set giornaliero di OO e modelli, sarà difficile da introdurre. Se il team è più innovativo, l'adozione sarà molto più semplice perché il potenziale e le nuove porte si moltiplicano ad ogni scoperta.

Due problemi concettuali principali che i programmatori hanno avuto nel passare a questa tecnologia sono stati: a) Correlazione dei messaggi e schemi di scambio di messaggi b) Flussi di lavoro e test di unità Nei sistemi standard in C #, ad esempio, un flusso di lavoro è raramente esplicito e quindi raramente testato in unità. Il flusso di lavoro complessivo viene lasciato per testare scenari di accettazione o integrazione. Introduci un WF esplicito come artefatto software e improvvisamente gli sviluppatori standard vogliono provare a testarlo, cosa che di solito non vale la pena fare.

L'aspetto della correlazione del messaggio è un piccolo cambiamento di mentalità per coloro che non hanno familiarità con i modelli di scambio di messaggi. La maggior parte degli sviluppatori si è occupata di chiamate in corso e remote, servizio web e SOAP, e di solito si è concentrata su uno o due di questi. Astrarre soprattutto e lavorare con un sistema generale basato su messaggi può essere fonte di confusione all'inizio.

Sul lato positivo, però, il risultato finale è qualcosa che fa risparmiare molto tempo e crea molte opportunità. Una cosa principale è che il flusso di lavoro, se visivamente chiaro, è qualcosa su cui può essere lavorato da utente finale, sviluppatore e analista insieme, eliminando passaggi non necessari nel ciclo di vita dello sviluppo e concentrando le parti su un artefatto. Inoltre, scoraggia le isole di funzionalità nelle app dedicate, con strati di colla dedicati, incoraggiando una suite di processi aziendali in WF per dominio aziendale. Inoltre, con AppFabric, l'idraulica per la persistenza, la registrazione e il risveglio delle attività pianificate è tutto fatto per te. Anche le prestazioni di WF4 sono eccezionali.

La mia raccomandazione sarebbe quella di trovare il membro del team più innovativo o esplorativo che faccia lo scouting iniziale per scoprire le parti difficili, far funzionare le funzioni principali e avere quella persona iniziale responsabile della suddivisione in compartimenti del lavoro rimanente.

Per realizzare un sistema di reclamo assicurativo di qualsiasi complessità che coinvolga ruoli e "sotto-attività", è davvero necessaria una soluzione BPM, non solo un flusso di lavoro. Workflow Foundation 4.0 è intelligente ma in realtà non si avvicina alle funzionalità di un prodotto BPM.

Le soluzioni BPM, come Metastorm BPM, Global360 e K2.NET, forniscono flussi di lavoro, attività, ruoli e integrazione di sistemi incentrati sull'uomo in grado di modellare e semplificare i processi aziendali come il sistema di reclamo assicurativo. Usa ASP.NET per creare l'interfaccia che si integra con il motore del flusso di lavoro BPM poiché i loro progettisti incorporati sono generalmente limitati e ti costringono a utilizzare il loro controllo web personalizzato che di solito non è completo come i controlli web ASP.NET.

Scegli la tecnologia che il tuo team conosce e con cui si sente a proprio agio. Workflow Foundation non è un prodotto che puoi usare immediatamente, è piuttosto un insieme di pezzi che puoi incorporare nella tua applicazione per costruire un sistema di flusso di lavoro. IMHO la logica del flusso di lavoro è il pezzo di tecnologia meno importante, prima di tutto devi concentrarti sulla GUI perché gli imprenditori non vedranno altro che la GUI. Ma se il tuo sistema ha successo, devi essere preparato a richieste di modifica senza fine e nuovi requisiti, quindi devi implementare la tua logica di business in modo che sia facile da cambiare e facile da suddividere in processi separati per soddisfare le diverse esigenze degli utenti (a volte contraddittori) . BPM aiuta in questa attività perché consente di avere versioni separate e multiple di processi aziendali che soddisfano le varie esigenze aziendali. Tu non Non è necessario un motore BPM completo per questo, ma è utile codificare la logica aziendale in modo che possa essere versionata e divisa in singoli processi aziendali: la cosa peggiore da avere è un blob di codice non gestibile e intrecciato che gestisce 'tutto' e che no si può capire. Ci sono molte idee per questo - macchine a stati, DSL (linguaggi specifici del dominio), script ecc. - Decidi tu quale dovrebbe essere l'implementazione. Ma dovresti sempre pensare in termini di processi aziendali e organizzare la tua logica di conseguenza in modo che rifletta questi processi. Ed essere preparati alla coesistenza di molte varianti di logica aziendale e strutture dati: questa è l'attività di progettazione più difficile per me. È utile per codificare la logica aziendale in modo che possa essere versionata e suddivisa in singoli processi aziendali: la cosa peggiore da avere è un blob di codice non gestibile e intrecciato che gestisce "tutto" e che nessuno può capire. Ci sono molte idee per questo - macchine a stati, DSL (linguaggi specifici del dominio), script ecc. - Decidi tu quale dovrebbe essere l'implementazione. Ma dovresti sempre pensare in termini di processi aziendali e organizzare la tua logica di conseguenza in modo che rifletta questi processi. Ed essere preparati alla coesistenza di molte varianti di logica aziendale e strutture dati: questa è l'attività di progettazione più difficile per me. È utile per codificare la logica aziendale in modo che possa essere versionata e suddivisa in singoli processi aziendali: la cosa peggiore da avere è un blob di codice non gestibile e intrecciato che gestisce "tutto" e che nessuno può capire. Ci sono molte idee per questo - macchine a stati, DSL (linguaggi specifici del dominio), script ecc. - Decidi tu quale dovrebbe essere l'implementazione. Ma dovresti sempre pensare in termini di processi aziendali e organizzare la tua logica di conseguenza in modo che rifletta questi processi. Ed essere preparati alla coesistenza di molte varianti di logica aziendale e strutture dati: questa è l'attività di progettazione più difficile per me. DSL (linguaggi specifici del dominio), script ecc. - Decidi tu quale dovrebbe essere l'implementazione. Ma dovresti sempre pensare in termini di processi aziendali e organizzare la tua logica di conseguenza in modo che rifletta questi processi. Ed essere preparati alla coesistenza di molte varianti di logica aziendale e strutture dati: questa è l'attività di progettazione più difficile per me. DSL (linguaggi specifici del dominio), script ecc. - Decidi tu quale dovrebbe essere l'implementazione. Ma dovresti sempre pensare in termini di processi aziendali e organizzare la tua logica di conseguenza in modo che rifletta questi processi. Ed essere preparati alla coesistenza di molte varianti di logica aziendale e strutture dati: questa è l'attività di progettazione più difficile per me.

Mi trovo in una situazione in cui devo usare 4.0 poiché .NET 4.5 non è ancora accreditato per l'uso nel nostro ambiente di produzione. Ho avuto grandi difficoltà a capire in generale come ottenere flussi di lavoro di lunga durata adatti alle nostre esigenze aziendali, ma alla fine ho trovato una soluzione elegante. Non è qualcosa che chiunque venga in seguito per supportare può semplicemente raccogliere con facilità perché c'è così tanto a cui pensare, ma credo in WF come strumento per la gestione degli stati del flusso di lavoro.

Una cosa importante che ho in discussione con WF 4.0 è il commento di Maurice:

La base non è mai cambiare un flusso di lavoro esistente, ma crearne sempre uno nuovo

È fantastico se desideri solo una nuova versione, ma cosa succede se hai 50.000 flussi di lavoro persistenti e ti rendi conto a un certo punto che c'è un bug nel flusso di lavoro? Devi essere in grado di aggiornare xamlx ed essere ancora accoppiato alle istanze esistenti. Ho provato a decomprimere le varie colonne di metadati nella tabella delle istanze di SQL Server per trovare qualcosa che leghi l'istanza alla definizione del flusso di lavoro senza fortuna.

Ho scritto un'applicazione di sincronizzazione per importare i dati da un vecchio sistema nel nostro nuovo sistema basato su WF 4.0. Fondamentalmente carichiamo i dati nel sistema, quindi eseguiamo il processo che richiama automaticamente i passaggi del flusso di lavoro e chiama i metodi di convalida, essenzialmente deridendo l'interazione dell'utente. Questo ha funzionato davvero bene con noi solo grazie all'architettura che abbiamo implementato per l'accesso all'host del servizio del flusso di lavoro. È fantastico come una tantum, dove dopo aver eseguito è possibile eseguire ed eseguire controlli per garantire la coerenza del processo di migrazione dei dati, ma dover utilizzare questo approccio per potenzialmente centinaia di migliaia di casi una volta che un sistema è attivo non è davvero un approccio che infonde fiducia e appesantisce il processo di integrazione con semplici correzioni di bug.

Il mio consiglio è di evitare del tutto WF 4.0 e di passare direttamente a 4.5 se l'ambiente lo supporta. Gli aggiornamenti dinamici e il controllo delle versioni affiancato forniscono soluzioni per la correzione di bug e il controllo delle versioni di WF tutto pronto. Devo ancora indagare esattamente come 4.5 non sia ancora accreditato per l'uso dal nostro cliente, ma attendo con impazienza questa opportunità.

Quello che spero disperatamente è che il nostro cliente non richieda modifiche alla politica (e quindi aggiustamenti del flusso di lavoro) e che i flussi di lavoro attuali reggano senza bug. Quest'ultima è una speranza vana e vuota poiché gli insetti spuntano sempre.

Non riesco davvero a capire cosa stesse passando per la testa del team di sviluppo WF per rilasciare un sistema in cui non è possibile correggere facilmente i bug. Avrebbero dovuto sviluppare una tecnica per riassociare un'istanza al nuovo xamlx.