
Elaborazione di un flusso di pagine che inizia con un processo BPEL
Alcuni flussi di lavoro vengono eseguiti da una sola persona, ad esempio, ordinando libri da una libreria online. Questo tipo di flusso di lavoro non ha percorsi paralleli. Questo esempio mostra come utilizzare le API initiateAndClaimFirst e completeAndClaimSuccessor per elaborare questo tipo di workflow.
Prima di iniziare
- Poiché l'attività successiva nel flusso di pagina viene reso disponibile nella transazione dell'attività che è stata completata, il comportamento transazionale di tutte le attività human task deve essere impostato su
participates. - Per garantire che la successiva attività umana nel flusso di pagina possa essere trovata in fase di runtime, non vengono introdotti limiti di transazione tra le attività. Per fare ciò, ad esempio, assicurarsi che tutte le attività di richiamo tra due attività umane abbiano anche il comportamento transazionale impostato su
participatese che non utilizzino servizi, come le attività di attesa, che richiedono un limite di transazione.Nota: Business Process Choreographer introduce dinamicamente i limiti di transazione non modellati come richiesto, ad esempio come prevenzione di deadlock, che influenzano il funzionamento dell'API completeAndClaimSuccessor . Di solito, l'API rivendica la successiva attività umana nel flusso di pagine, se è disponibile nella transazione dell'attività completata. Tuttavia, se esiste un limite di transazione, la richiesta API viene restituita senza richiedere l'attività successiva.Inoltre, dove e come vengono aggiunti i limiti della transazione possono cambiare in futuro, ad esempio dopo l'aggiornamento di un prodotto o dopo l'installazione di una correzione. Pertanto, anche se si modellano i limiti delle transazioni impostando la proprietà di comportamento transazionale sulle attività, l'aderenza a tali limiti non è garantita.
- Se il flusso di pagina deve essere utilizzato in Business Space, ciascuna delle attività umane nel flusso di pagina deve avere la proprietà personalizzata htm.hasNext impostata su true, tranne l'ultima attività umana nella sequenza. Questa attività deve avere la proprietà personalizzata htm.hasNext impostata su false.
Informazioni su questa attività
- Flussi di pagine lato client, in cui la navigazione tra le diverse pagine è realizzata con una tecnologia lato client, come un modulo Lotus Forms a più pagine.
- I flussi di pagine lato server vengono realizzati utilizzando un processo BPEL e una serie di attività umane modellati in modo che le successive attività siano assegnate alla stessa persona.
- È necessario richiamare i servizi tra i passi eseguiti in un'interfaccia utente, ad esempio, per richiamare o aggiornare i dati.
- Si dispone di requisiti di controllo che richiedono la scrittura di eventi CEI una volta completata l'interazione dell'interfaccia utente.
Un esempio tipico di un flusso di pagine è il processo di ordinazione in una libreria online, in cui l'acquirente completa una sequenza di azioni per ordinare un libro. Questa sequenza di azioni può essere implementata come una serie di attività dell'attività umana (attività da eseguire). Se l'acquirente decide di ordinare diversi libri, ciò equivale ad avviare un processo di ordine e a richiedere la successiva attività umana.
L'API initiateAndClaimFirst avvia il flusso di pagina, ossia il processo specificato e richiede la prima attività umana nella sequenza di attività. Restituisce le informazioni sull'attività richiesta, incluso il messaggio di input su cui lavorare.
L'API completeAndClaimSuccessor completa quindi l'attività human task e ne richiede la successiva nella stessa istanza del processo per la persona collegata. L'API restituisce le informazioni sulla successiva attività richiesta, incluso il messaggio di input su cui lavorare.
Confrontare questo esempio con l'esempio di un flusso di pagine avviato da un'attività to-do.