Windows Workflow - PersistableIdle

Question

Nella nostra azienda abbiamo un processo di business che ha bisogno di:

1. ottenere i dati da X
2. Attendere utente Y per fare ricerca
3. ottenere i dati da Z sulla base di fase 2 dati

Nella ricerca di questo, sembra che ci siano alcune opzioni per implementarlo nel flusso di lavoro.

1. Aggiungere un'attività di ritardo tra il passaggio 1 (attività del flusso di lavoro) e il passaggio 3 (attività del flusso di lavoro). Quindi durante l'evento PersistableIdle, scaricare il flusso di lavoro. Quando l'utente ha terminato il passaggio 2, ricarica il flusso di lavoro dal database.
2. Come al punto 1, tranne usare un segnalibro invece di un'attività di ritardo.

C'è un approcio migliore (1, 2 o un'altra opzione)?

Tutte le altre nostre attività sono AsyncCodeActivities, quindi sono abbastanza sicuro che non genereranno l'evento PersistableIdle (poiché si trovano in una zona non persistente), ma voglio assicurarmi che il flusso di lavoro non venga scaricato accidentalmente in altri casi. C'è qualche rischio qui? Esiste comunque la possibilità di creare un'attività che costringa il flusso di lavoro a scaricarsi?

Answer 1

C'è un approccio migliore (1, 2 o un'altra opzione)?

A prima vista, il n. 2 sembra necessario. Il motivo per utilizzare i segnalibri (o l'attività di bookmarking di qualche tipo, come Ricevi) è che possono essere ripresi in qualsiasi momento. Ciò consente alla ricerca dell'utente di terminare e al flusso di lavoro di riprendere l'esecuzione in qualsiasi momento (invece di essere bloccato fino alla scadenza di un ritardo).

Il controsenso, che potrebbe essere necessario anche # 1, è che si potrebbe desiderare di impostare un limite di tempo che attivi le azioni del flusso di lavoro (promemoria che si spengono, eccezioni, cancellazioni, ecc.).

Come decidere? Penso che la risposta sia solitamente # 3: Entrambi

L'utilizzo di Pick Activity è un ottimo modo per fare entrambe le cose. Usando l'attività Segnalibri in un trigger PickBranch e l'attività Ritardo nell'altro trigger PickBranch, puoi comporre un flusso di lavoro che "gestirà qualsiasi cosa succeda prima - utente Y, o timeout".

Una domanda secondaria che si pone è "Come faccio a interrompere un flusso di lavoro che viene scaricato quando non lo desidero - il flusso di lavoro a sorpresa scarica un rischio"?

Bene, questo dipende. Se stai utilizzando WorkflowServiceHost, avere scaricato il tuo flusso di lavoro non sembra un grosso rischio, perché WorfklowServiceHost è abbastanza intelligente da ricaricare il tuo flusso di lavoro quando ha bisogno di fare più lavoro (gestire un messaggio in arrivo o riprendere dal ritardo).

Se non stai utilizzando WorkflowServiceHost, probabilmente stai scrivendo il tuo host, puoi ottenere lo stesso effetto con un po 'di lavoro, o puoi semplicemente impedire che lo scaricamento si verifichi sempre - quando scrivi l'host, controlli la politica di scarico , tramite gli eventi su WorkflowApplication

Altri punti vari: - Le attività di codice asincrono impediscono effettivamente la persistenza del flusso di lavoro mentre eseguono il lavoro asincrono. Non penso che dovrebbero essere usati deliberatamente come meccanismo anti-persistenza - se vuoi uno di questi, dai un'occhiata allo NoPersistZone activity.

-Non c'è attività "Scarica", ma esiste un'attività "Persist". I flussi di lavoro possono dire che vogliono salvare i progressi, ma solo l'host arriva a prendere la decisione definitiva quando si verifica lo scaricamento.