Servizi di persistenza del flusso di lavoro di Windows
Molti processi aziendali impiegano molto tempo per essere completati (fino a mesi o addirittura anni). Mantenere il flusso di lavoro in memoria non solo non è pratico (a causa delle limitazioni della memoria) ma impedisce anche la scalabilità, dal momento che un'istanza deve essere elaborata su un singolo server. Molti di questi flussi di lavoro di lunga durata non eseguono flussi o logiche di elaborazione attivamente ma sono in realtà inattivi, in attesa di un input dagli utenti o da altri sistemi. Tramite lo scaricamento di un'istanza inattiva, l'applicazione host può risparmiare memoria e consentire la scalabilità tra server di elaborazione.
Quando si verificano determinate condizioni mentre è in esecuzione un flusso di lavoro, il motore di runtime del flusso di lavoro utilizza un servizio di persistenza, se ne è caricato uno nel runtime, per rendere persistenti le informazioni sullo stato relative all'istanza del flusso di lavoro. Queste condizioni includono gli elementi seguenti:
Quando vengono completate transazioni atomiche in attività TransactionScopeActivity e attività CompensatableTransactionScopeActivity.
Quanto un'istanza del flusso di lavoro diviene inattiva e il flag UnloadOnIdle viene impostato su true per un elemento WorkflowPersistenceService. Ciò si verifica, ad esempio, quando si utilizza un'attività DelayActivity.
Quando l'applicazione host in fase di esecuzione chiama System.Workflow.Runtime.WorkflowInstance.Unload o System.Workflow.Runtime.WorkflowInstance.TryUnload sull'istanza del flusso di lavoro.
Quando un'istanza del flusso di lavoro viene terminata o termina.
Quando viene completata un'attività personalizzata utilizzando l'attributo PersistOnCloseAttribute.
Se viene soddisfatta una di queste condizioni e al motore di runtime viene aggiunto un servizio di persistenza, il motore di runtime chiama i metodi forniti dal servizio di persistenza per salvare le informazioni sullo stato relative all'istanza del flusso di lavoro. Analogamente, quando il motore di runtime del flusso di lavoro deve ripristinare un'istanza del flusso di lavoro precedentemente impostata come persistente, chiama i metodi forniti da un servizio di persistenza per caricare queste informazioni sullo stato. In altre parole, il motore di runtime del flusso di lavoro determina quando deve verificarsi la persistenza, ma spetta a un servizio di persistenza eseguire le operazioni necessarie.
Un'altra parte dello stato del flusso di lavoro gestita da SqlWorkflowPersistenceService è rappresentata dalle informazioni Timer. Ogni volta che si configura un'attività DelayActivity nella definizione del flusso di lavoro e si utilizza un servizio di persistenza come SqlWorkflowPersistenceService, le informazioni relative all'intervallo di tempo associato all'attività vengono rese persistenti come parte dello stato del flusso di lavoro. Ogni volta che l'istanza del flusso di lavoro viene valutata dal runtime del flusso di lavoro, vengono elaborati gli eventi timer in sospeso.
Creazione di servizi di persistenza
È possibile creare un servizio di persistenza derivando una classe dalla classe WorkflowPersistenceService. È possibile aggiungere il servizio di persistenza al motore di runtime del flusso di lavoro chiamando AddService o creando una voce adatta nel file di configurazione dell'applicazione. In Windows Workflow Foundation è disponibile la classe SqlWorkflowPersistenceService, un servizio di persistenza predefinito che può essere utilizzato direttamente o dopo essere stato esteso. Per ulteriori informazioni sulla creazione di un servizio di persistenza personalizzato, vedere Creazione di servizi di persistenza personalizzati. Per ulteriori informazioni sull'utilizzo della classe SqlWorkflowPersistenceService, vedere Utilizzo di SqlWorkflowPersistenceService.
Nota
.WorkflowRuntime deve contenere solo un servizio di persistenza.
Blocco delle informazioni sullo stato del flusso di lavoro
Il motore di runtime del flusso di lavoro dispone della semantica necessaria per bloccare le informazioni sullo stato del flusso di lavoro negli ambienti in cui i servizi di persistenza che sono in esecuzione in processi diversi possono avere accesso a un solo archivio dati. La classe WorkflowPersistenceService consente il supporto di questa funzionalità del motore di runtime del flusso di lavoro fornendo un parametro a SaveWorkflowInstanceState che specifica se le informazioni sullo stato di un'istanza del flusso di lavoro devono essere sbloccate nell'archivio dati e fornendo il metodo UnlockWorkflowInstanceState per sbloccare tali informazioni precedentemente bloccate. In un servizio di persistenza che implementa il blocco, una chiamata a LoadWorkflowInstanceState deve bloccare le informazioni sullo stato per un'istanza del flusso di lavoro.
Quando si crea un proprio servizio di persistenza, generare un'eccezione PersistenceException se il servizio non è in grado di salvare le informazioni sullo stato nell'archivio dati o di caricarle dall'archivio. Questo è il comportamento previsto dal motore di runtime del flusso di lavoro.
Comportamento di inclusione in batch del servizio di persistenza
Un meccanismo di inclusione in batch è disponibile per i servizi che utilizzano un archivio durevole per salvare le informazioni sullo stato del flusso di lavoro. È importante in questi casi mantenere la coerenza tra l'archivio durevole utilizzato dal servizio di persistenza e lo stato interno del motore di runtime del flusso di lavoro. È possibile aggiungere la funzionalità definita dall'interfaccia IPendingWork al servizio e quindi partecipare all'inclusione in batch delle transazioni del flusso di lavoro fornita dal servizio WorkflowCommitWorkBatchService aggiungendo modifiche all'archivio dati come elementi di lavoro in WorkBatch. Per ulteriori informazioni, vedere SaveCompletedContextActivity o SaveWorkflowInstanceState.
Scenari di hosting complessi
Un possibile scenario per la distribuzione di soluzioni di Windows Workflow Foundation è creare più applicazioni host, ognuna con un insieme diverso di servizi in esecuzione in configurazioni server e desktop differenti. In tale scenario, potrebbe essere un requisito che alcuni flussi di lavoro definiti nella soluzione possano essere eseguiti soltanto in determinati sistemi. I servizi predefiniti in Windows Workflow Foundation, ad esempio il servizio SqlWorkflowPersistenceService, non supportano questo tipo della configurazione. Per controllare quali istanze del flusso di lavoro caricano i singoli sistemi, è necessario creare un servizio di persistenza personalizzato. Per ulteriori informazioni, vedere Creazione di servizi di persistenza personalizzati.
Vedere anche
Riferimenti
SqlWorkflowPersistenceService
SqlPersistenceWorkflowInstanceDescription
WorkflowPersistenceService
WorkBatch
Concetti
Utilizzo di SqlWorkflowPersistenceService
Creazione di servizi di persistenza personalizzati
Altre risorse
Servizi di Windows Workflow Foundation
Esercizio 4: utilizzare i servizi di runtime
Using Persistence Services
Copyright © 2007 Microsoft Corporation. Tutti i diritti riservati.