ritardare l'attività nella gestione degli eventi di attività portata - Windows Workflow sharepoint

Question

Sto cercando di creare uno scenario seguente:

• un compito viene assegnato all'utente per completare
• un compito ottenere creato per il manager per riassegnare il task utente, se necessario (non chiedere, hanno voluto in questo modo)
• un promemoria tramite email neeeds da inviare quando l'attività si sta avvicinando una data di scadenza

Così, ho pensato di usare EventHandlingScope per questo:

• sto ascoltando per un cambiamento compito sul ramo principale del eventhandlingscope attività,
• l'ascolto di riassegnare cambiamento compito in event driven ramo - e se compito Riassegna viene attivato, riassegnare il primo compito per l'utente specificato
• in un altro ramo guidato evento Usa un'attività ritardo e verificare periodicamente se l'utente compito assegnato si sta avvicinando una data di scadenza e inviare un promemoria tramite email

Quindi, ho pensato eventhandlingscope sarebbe un bene per questo, ed è in gran parte è, tranne che per il problema con il DelayActivity.

Se metto un'attività ritardo in uno dei gestori di eventi rami spara una volta, ma non di più. Mentre se metto un'attività onTaskChange lì si spara ogni volta che qualcuno cambia questo compito.

Quindi, è questo il comportamento previsto? Perché non lo fa ciclo DelayActivity? Come potrei farlo in modo diverso? Il mio pensiero è con un CAG, ma questo sembra un po 'più complesso ...

Aggiornamento: il problema con CAG è che l'intero blocchi cosa fino a incendi di attività di ritardo, anche se l'evento onChange sparato. Questo ha senso, ma lo rende un po 'più complicato da usare.

Update2: Ho riformulato il testo per renderlo più chiaro si spera

Answer 1

La soluzione

La disposizione attività fundemental che risolve questo problema è un WhileActivity contenente un ListenActivity.

L'attività di ascolto viene data 3 filiali EventDrivenActivity. Sul primo è il vostro "task utente Completato" ramo, il secondo è il "Gestore ha cambiato il assegnato utente" ramo e il terzo contiene un DelayActivity seguito dal vostro logica email.

In un'attività ascoltare uno qualsiasi dei rami può completare l'attività Ascoltare e quando lo fanno le altre attività nell'attività di ascolto è annullata.

È necessario garantire la "Task utente ha completato" sequenza imposta un valore che può essere testato dal ciclo while in modo tale che il tempo ciclo termina quando un utente completa un compito.

Quando un ramo diverso dal "task utente Completato" ramo è responsabile per il completamento del flusso di lavoro del ListenActivity sarà loop back al ListenActivity e ri-esecuzione di tutte le attività guidate 3 eventi tra cui quella che contiene il DelayActivity.

Si noti che questo è leggermente diverso dal metodo EventHandlingScope perché il "ascoltare task utente completata" andranno cancellati e ri-eseguita mentre con l'EventHandlingScope questo non sarebbe accaduto. IMO questo un accordo meglio dato che significa che l'utente che è stato selezionato per fare il compito a inizio l'attività Listen è garantito per essere invariato alla fine (perché se è cambiato l'intera attività viene scartato e uno nuovo iniziato ).

Perché il solo ritardare sparato una volta nella EventHandlingScope

In effetti quello che aveva creato è un ambito che è in ascolto per i due eventi. Uno era il tuo manager cambiano evento utente assegnato, l'altro è stato un "timer licenziati evento".

Ora, il modo in cui la sua descritto nella documentazione che suona come un ciclo è coinvolto come se una volta che una di queste attività completa che vengono riavviati. Tuttavia la sua non è proprio così, ma in realtà solo continua ad ascoltare per l'evento originale e si ri-eseguire il contenuto se un altro tale evento viene generato.

Nel caso del DelayActivity c'è qualche interno "timer sparato evento" che si sta ascoltando. Quando il ritardo è prima entrato il timeout è impostato in modo che il timer sparerà al momento opportuno, ascolta poi per quell'evento. Una volta che ha sparato la portata ritorna all'ascolto di un "evento sparato timer", tuttavia, non v'è alcuna ri-esecuzione del codice iniziale che impostare il timeout, quindi, nessun altro "timer evento licenziato" è venuta alla luce.

Answer 2

Lo so che non vuoi sentire questo, ma si sarebbe meglio creare un flusso di lavoro al posto del gestore come i flussi di lavoro sono progettati per gestire la dimensione temporale molto meglio così come sono "corsa lunga". I gestori di eventi sono maggiormente scope per un evento di momento-in-time li innesca e poi completano un'azione. Non solo, ma a giudicare da quello che scrivi, se i requisiti sono così semplici è possibile creare un flusso di lavoro SharePoint Designer modo che non avrebbe nemmeno bisogno di Crach aprire Visual Studio.

Inoltre, non so se lo sai, ma le attività di SharePoint non inviare messaggi di posta elettronica, questi compiti saranno inviano promemoria quotidiane quando l'attività è in ritardo per cui si potrebbe essere in grado di affrontare la vostra attività di ritardo utilizzando out-of-the-box funzionalità .

Infine, se si esegue nella modalità di debug e si è hard-coded vostra taskid, è possibile eseguire un solo compito per ogni sessione di debug in caso contrario il gestore di eventi si ferma quando un altro elemento con lo stesso ID viene aggiunto a SharePoint. Questo potrebbe spiegare il motivo per cui la vostra attività di ritardo è bloccato.