Quella del Workflow parallelo è una potente funzione che consente a un'istanza di workflow di essere suddivisa in percorsi paralleli e successivamente riunita. Questo scenario supporta i seguenti concetti:
•Suddivisione in percorsi differenti che vengono elaborati in parallelo. Ad esempio, un processo produttivo in cui più lavori devono essere portati a termine simultaneamente.
•Elaborazione di un unico lavoro da parte di più utenti. Ad esempio, un contratto che deve essere approvato da più dirigenti.
Un elemento chiave dei workflow paralleli è il token di workflow. Quando un'istanza viene suddivisa, si vengono a creare più token che avanzano lungo il workflow. Un workflow può essere costituito da un numero illimitato di token che si sviluppano durante il processo. Per un utente di workflow non vi è alcuna differenza tra un token e un'istanza standard; nel riquadro Inbox workflow vengono riportati tutti i lavori e, se si richiede un lavoro, viene aperta una finestra di dialogo di lavoro come di consueto. Per la procedura di unione è necessario attendere l'arrivo del numero di token configurato, dopo di che i token vengono uniti in una singola istanza.
Per creare i workflow paralleli sono disponibili quattro lavori speciali. Dividi, Diviso da utente, Unisci e Unione con eccezione. Per ogni lavoro Dividi deve esistere un lavoro Unisci corrispondente, per assicurare che il numero di token configurato venga di nuovo unito in un'unica istanza.
Il primo semplice esempio mostra come separare un'istanza di workflow in più percorsi utilizzando le funzioni Dividi e Unisci. In questo esempio, si prenderà in considerazione un contratto che deve essere inviato ai responsabili finanziari e delle vendite per l'approvazione e, nel caso superi il valore di 100.000 euro, deve essere inviato anche al CEO. Il lavoro Unisci calcola dinamicamente il numero di token in sospeso e attende che venga restituito il numero di token corretto (configurato nelle impostazioni del lavoro manuale ) prima di procedere all'unione.
Non è tuttavia necessario che un solo lavoro Dividi venga successivamente riunito da un singolo lavoro Unisci. È possibile unire vari token dell'istanza di workflow in qualsiasi momento durante il processo. Ogni lavoro Unisci calcola dinamicamente il numero di token potenzialmente in sospeso e attende che venga restituito il numero di token configurato. L'esempio successivo illustra lo stesso processo; in questo caso, dopo l'approvazione da parte dei responsabili finanziari, il contratto deve essere sottoposto a una verifica per escludere possibili errori. Il primo lavoro di unione calcola dinamicamente i token in sospeso e attende che vengano tutti restituiti dai responsabili finanziari e delle vendite prima di riunirli; la funzione "è consapevole" dell'esistenza di un terzo token inviato al CEO, ma poiché non è possibile unirlo in questa fase, lo ignora. Analogamente, il lavoro di unione finale verifica dinamicamente il numero di possibili token ancora in sospeso. Per i contratti entro i 100.000 euro, è sufficiente attendere l'arrivo del token dei revisori, ma per quelli che superano tale importo, la funzione Unisci deve attendere sia il token dei revisori che quello del Consiglio di amministrazione.
|
A questo punto, si analizzerà il lavoro Unione con eccezione che in pratica consente di ignorare tutte le suddivisioni attive. Ad esempio, se l'altra parte coinvolta nella negoziazione del contratto decide improvvisamente di ritirarsi, tutti gli altri lavori risulteranno inutili e il workflow deve essere interrotto. Quando viene attivata un'Unione con eccezione, TUTTI i token in sospeso vengono immediatamente "raccolti" e uniti. Nell'esempio che segue, nel momento in cui il contratto viene annullato, TUTTI i token attivi in qualsiasi fase del processo vengono immediatamente raccolti e uniti. In questo modo, i lavori del workflow vengono cancellati dal riquadro Workflow inbox dell'utente e il workflow procederà alla fase successiva (in questo caso, viene terminato).
|
È infine disponibile il lavoro Diviso da utente che consente di assegnare dinamicamente le suddivisioni in fase di runtime. Ad esempio, anziché creare task manuali individuali per ogni manager, è possibile usare una funzione Diviso da utente per suddividere il workflow in base agli utenti assegnati al task manuale dopo la divisione da parte degli utenti.
Nell'esempio che segue, il contratto viene instradato verso un lavoro Diviso da utente che suddivide automaticamente il workflow nel numero di token richiesti dal task manuale.
È previsto un solo lavoro di approvazione, tuttavia, ogni utente assegnato riceve un token indipendente e può lavorare sul task esattamente come nei lavori Dividi standard. Una volta che tutti gli utenti assegnati hanno portato a termine il loro lavoro, i token vengono nuovamente uniti.Â
Può anche essere utilizzato un lavoro di Unione con eccezione, in tal caso, non appena un responsabile rifiuta il contratto, tutti i token vengono immediatamente raccolti e la suddivisione viene annullata.
|
1. Ogni lavoro Dividi richiede almeno un lavoro Unisci corrispondente. Nell'esempio che segue, non è stato definito un lavoro Unisci, di conseguenza il processo non risulta valido.
2. Dall'interno di un lavoro Dividi/Unisci, non è possibile tornare alla fase Dividi o a un lavoro precedete la divisione. Un tale loop porterebbe alla creazione di nuovi token non necessari.
|
I loop in realtà sono consentiti, ma devono avvenire all'interno della divisione/unione oppure completamente al di fuori di essa. Nell'esempio che segue, il loop da Verify (Verifica) a Send for Approval (Invia per approvazione) è valido, in quanto avviene completamente al di fuori della divisione/unione.
|
3. Due lavori di unione non possono essere collegati mediante una transizione, in quanto ognuno dei due lavori deve attendere il completamento dell'altro.
Â
|
|