Introduzione all'hosting di Windows Workflow Foundation

 

Moustafa Khalil Ahmed
Program Manager
Microsoft Corporation

Agosto 2006

Si applica a:
   Windows Workflow Foundation
   Microsoft .NET Framework 2.0
   Microsoft .NET Framework 3.0

Riepilogo: Fornisce una panoramica del modo in cui un'applicazione che ospita Windows Workflow Foundation (WF) può gestire e monitorare i flussi di lavoro in esecuzione e offre una panoramica dei servizi di runtime e delle implementazioni predefinite. I lettori devono avere familiarità con Microsoft .NET Framework, C#e il modello di programmazione WF. (16 pagine stampate)

Contenuto

Introduzione
Gestione del ciclo di vita delle istanze del flusso di lavoro
Gestibilità e monitoraggio
Affidabilità e disponibilità elevata
Base Runtime Services
Conclusione
Ulteriori informazioni

Introduzione

Questo articolo è destinato agli sviluppatori che usano Windows Workflow Foundation (WF) per comprendere le diverse opzioni disponibili per consentire alle applicazioni di gestire e monitorare le istanze del flusso di lavoro in esecuzione. L'articolo presuppone che il lettore abbia una conoscenza di base di Microsoft .NET Framework, C#e WF.

WF è costituito da una libreria di attività e un framework, un motore di runtime e i componenti dei servizi di runtime che devono essere eseguiti all'interno di un processo dell'applicazione host. I flussi di lavoro vengono costruiti come set di attività eseguite dal motore di runtime. Il motore di runtime deve essere eseguito all'interno di un processo dell'applicazione host. Nell'illustrazione seguente viene mostrato in che modo i flussi di lavoro, le attività e il motore di runtime del flusso di lavoro sono ospitati nel processo con un'applicazione host.

Figura 1. Processo host di Windows Workflow Foundation

WF fornisce un motore di runtime, responsabile dell'esecuzione del flusso di lavoro e della gestione dello stato. Il runtime di WF può essere ospitato in qualsiasi processo .NET, tra cui ASP.NET, Servizi Windows, applicazioni console e applicazioni Windows Forms. Lo sviluppatore è responsabile della scrittura di questo processo host durante la creazione di un'applicazione abilitata per il flusso di lavoro. I servizi di runtime funzionano nel processo host per fornire funzionalità aggiuntive al motore di runtime in quanto gestisce l'esecuzione dei flussi di lavoro.

Esistono molti problemi da considerare quando si implementa un'applicazione host per WF. Questo articolo offre una panoramica del modo in cui l'applicazione host può gestire e monitorare i flussi di lavoro e un riepilogo dei servizi di runtime di base e delle relative implementazioni predefinite.

Gestione del ciclo di vita delle istanze del flusso di lavoro

WF fornisce attività predefinite e metodi di controllo nella classe WorkflowInstance per gestire gli stati del flusso di lavoro e il ciclo di vita. La sezione Gestione del ciclo di vita delle istanze del flusso di lavoro descrive i vari eventi di runtime specifici dell'istanza del flusso di lavoro e le transizioni tra tali eventi e la relazione con gli stati del flusso di lavoro.

Punti di persistenza

I flussi di lavoro sono spesso inattive e inattive, in attesa di un input da parte di un utente o di altri sistemi. Poiché è impraticabile contenere i flussi di lavoro inattivi in memoria, è consigliabile rendere permanente lo stato dell'istanza del flusso di lavoro in un supporto di archiviazione fino a quando il flusso di lavoro riceve l'evento in attesa. Inoltre, il salvataggio dello stato dell'istanza del flusso di lavoro consente di riprendere il flusso di lavoro da quel punto in caso di errore più avanti nel processo.

La figura 2 descrive come usare i punti di persistenza per riprendere le istanze del flusso di lavoro in esecuzione.

Figura 2. Uso dei punti di persistenza per riprendere le istanze del flusso di lavoro in esecuzione

Se uno stato dell'istanza del flusso di lavoro è persistente a punto B e un errore si verifica a punto C, l'applicazione può riprendere l'istanza del flusso di lavoro dal punto B senza perdere il lavoro svolto tra i punti A e B. Tuttavia, se un servizio di persistenza non è disponibile o lo stato dell'istanza del flusso di lavoro non è persistente, il lavoro eseguito dal punto A a B viene perso.

Se un flusso di lavoroPersistenceService è presente, ovvero aggiunto all'istanza di WorkflowRuntime , il motore di runtime del flusso di lavoro usa questo servizio per rendere persistente lo stato dell'istanza del flusso di lavoro a un supporto di archiviazione. Ciò potrebbe verificarsi nei punti seguenti:

• Al completamento delle attività contrassegnate con PersistOnCloseAttribute (ad esempio, attività dell'ambito delle transazioni)
• Prima del completamento dell'istanza del flusso di lavoro
• Prima della terminazione dell'istanza del flusso di lavoro
• Quando il flusso di lavoro passa inattiva
• Quando viene chiamato WorkflowInstance.Unload o WorkflowInstance.TryUnload

Il motore di runtime di WF chiama il metodo SaveWorkflowInstanceState() nel WorkflowPersistenceService per salvare lo stato dell'istanza del flusso di lavoro. Chiama il metodo LoadWorkflowInstanceState() per recuperare lo stato persistente dell'istanza del flusso di lavoro quando necessario. Il runtime del flusso di lavoro gestisce tutte le semantiche relative all'esecuzione della persistenza e i servizi di persistenza sono responsabili del salvataggio effettivo e del caricamento dell'istanza del flusso di lavoro. Gli stati attività e l'ID istanza del flusso di lavoro vengono serializzati e salvati nell'archivio di persistenza. Inoltre, tutte le altre informazioni necessarie per riprendere l'esecuzione dell'istanza del flusso di lavoro (ad esempio, le code) sono incluse nello stato serializzato, salvato.

Eventi dell'istanza del flusso di lavoro

Un'istanza del flusso di lavoro può essere in uno di cinque stati: Creazione,esecuzione, sospensione, completamento e terminazione. I flussi di lavoro hanno 13 eventi che si verificano durante tutta la durata dell'istanza del flusso di lavoro. Tali eventi possono indicare una transizione a uno stato diverso. Ad esempio, l'evento WorkflowCompleted indica che l'istanza è stata passata da Esecuzione a Completato. Alcuni eventi non indicano che l'istanza è stata passata a uno stato diverso. Ad esempio, l'evento WorkflowPersisted indica che l'istanza è persistente, ma ancora nello stato In esecuzione. Di questi 13 eventi, 11 vengono comunicati all'applicazione host tramite eventi di runtime e rilevamento degli eventi del flusso di lavoro. Due eventi, modifica e eccezione, vengono comunicati all'applicazione host solo tramite gli eventi del flusso di lavoro di rilevamento.

WF fornisce metodi di operazioni di controllo nella classe WorkflowInstance per consentire alle applicazioni host di gestire il ciclo di vita del flusso di lavoro. Inoltre, un'applicazione può impostare criteri per gestire il ciclo di vita del flusso di lavoro. Ad esempio, un'applicazione può avere criteri di scaricamento per indicare al motore WF di scaricare l'istanza del flusso di lavoro. WF fornisce attività predefinite che possono influire sulle statistiche dell'istanza del flusso di lavoro. Ad esempio, le attività SuspendActivity e TerminateActivity possono essere usate rispettivamente per sospendere e terminare l'istanza del flusso di lavoro. Le sezioni seguenti descrivono vari eventi specifici dell'istanza del flusso di lavoro generati dal runtime del flusso di lavoro per comunicare gli eventi dell'istanza del flusso di lavoro e le transizioni di stat dell'istanza del flusso di lavoro.

Flusso di lavoro interrotto

Un'istanza del flusso di lavoro viene considerata interrotta quando il motore di runtime del flusso di lavoro genera l'istanza in memoria. Le applicazioni host possono interrompere l'istanza del flusso di lavoro chiamando WorkflowInstance.Abort(). È possibile riprendere le istanze del flusso di lavoro interrotte dall'ultimo punto di persistenza chiamando WorkflowInstance.Resume(). L'interruzione di un'istanza del flusso di lavoro viene usata in situazioni estreme in cui un'applicazione decide di eliminare tutto il lavoro eseguito dall'ultimo punto di persistenza fino alla chiamata di WorkflowInstance.Abort().

Flusso di lavoroCompleted

Un'istanza del flusso di lavoro viene completata al termine dell'esecuzione dell'istanza. In quel momento, l'applicazione host può esaminare le code per i messaggi e altri eventi che non sono stati utilizzati dall'istanza del flusso di lavoro.

Flusso di lavoroCreato

Un flusso di lavoro viene creato quando l'istanza è completamente costruita, ma prima dell'avvio delle attività. L'istanza del flusso di lavoro viene creata chiamando uno dei diversi metodi di overload WorkflowRuntime.CreateWorkflow().

WorkflowIdled

L'istanza del flusso di lavoro è inattiva quando è in attesa di un evento esterno (timer, messaggio o altri eventi personalizzati) per continuare l'esecuzione. Per salvare le risorse di sistema, un'applicazione può impostare i criteri di scaricamento per scaricare l'istanza del flusso di lavoro dalla memoria quando è inattiva. Se l'applicazione host usa sqlWorkflowPersistenceService out-of-box, è possibile impostare un flag UnloadOnIdle nel file di configurazione dell'applicazione per indicare al motore di runtime di WF di rendere persistente lo stato del flusso di lavoro quando l'istanza è inattiva.

Flusso di lavoro Caricato

L'evento WorkflowLoaded viene generato quando lo stato dell'istanza viene caricato in memoria da un archivio di persistenza.

WorkflowPersisted

Quando l'istanza predefinita di SqlWorkflowPersistenceService o un servizio di persistenza personalizzata è stata aggiunta all'istanza di WorkflowRuntime , l'istanza del flusso di lavoro viene mantenuta quando lo stato dell'istanza del flusso di lavoro viene salvato nell'archivio di persistenza.

WorkflowResumed

L'istanza del flusso di lavoro viene ripresa quando WorkflowInstance.Resume() viene chiamato in un'istanza del flusso di lavoro sospesa o interrotta.

Flusso di lavoroStarted

L'evento WorkflowStarted viene generato quando viene chiamato WorkflowInstance.Start(). L'evento avviato dal flusso di lavoro viene generato prima che il motore di runtime del flusso di lavoro inizi a eseguire attività del flusso di lavoro.

WorkflowSuspended

La sospensione dell'istanza del flusso di lavoro viene eseguita tramite una chiamata WorkflowInstance.Suspend() o quando viene eseguita un'attività SuspendActivity . Di conseguenza, l'istanza del flusso di lavoro si trova in uno stato sospeso.

Flusso di lavoroTerminato

La terminazione dell'istanza del flusso di lavoro viene eseguita tramite una chiamata WorkflowInstance.Terminate(), quando viene eseguita un'attività TerminateActivity o quando si verifica un'eccezione non gestita nell'istanza del flusso di lavoro in esecuzione. Dopo aver generato questo evento, l'istanza del flusso di lavoro si trova nello stato terminato.

Flusso di lavoroUnloaded

L'evento WorkflowUnloaded viene generato quando l'istanza del flusso di lavoro viene scaricata dalla memoria a un archivio di persistenza. Questa operazione viene eseguita a seconda dei criteri di persistenza o tramite una chiamata a WorkflowInstance.Unload() o WorkflowInstance.TryUnload().

Transizioni degli eventi dell'istanza del flusso di lavoro

Gli eventi dell'istanza del flusso di lavoro vengono comunicati all'host tramite eventi di runtime del flusso di lavoro e tracciare gli eventi del flusso di lavoro. L'applicazione host può sottoscrivere eventi di runtime o usare un servizio di rilevamento per ricevere una notifica. Gli eventi di eccezione e modifica vengono comunicati solo all'applicazione host tramite i servizi di rilevamento. Un evento Exception indica che si è verificata un'eccezione durante l'esecuzione dell'istanza del flusso di lavoro. Un evento Modificato indica che l'istanza del flusso di lavoro è stata aggiornata dinamicamente durante l'esecuzione.

La figura 3 illustra le transizioni tra vari eventi del flusso di lavoro e gli stati del flusso di lavoro.

Figura 3. Transizioni tra eventi del flusso di lavoro e stati (fare clic sull'immagine per ingrandirla)

Se un servizio di persistenza è abilitato, i punti di persistenza si verificano come illustrato nella figura 3. Tali applicazioni host devono prevedere la visualizzazione degli eventi WorkflowPersisted, WorkflowUnloaded e WorkflowLoaded quando applicabile. Se l'istanza del flusso di lavoro non è in memoria e un servizio di persistenza è abilitato, tutte le operazioni valide nell'istanza (Resume, Abort, Terminate e così via) causano il caricamento dell'istanza del flusso di lavoro e quindi continuano a soddisfare la richiesta. Ad esempio, se si dispone di un'istanza del flusso di lavoro sospesa ma scaricata, la chiamata Di ripresa in esso causa il caricamento prima e quindi continuare a generare l'evento Resumed come indicato nel diagramma.

Operazioni dell'istanza del flusso di lavoro

Come illustrato in precedenza, la classe WorkflowInstance include metodi per controllare il ciclo di vita dell'istanza del flusso di lavoro. Questa sezione descrive questi metodi.

WorkflowInstance.Start()

Avvia l'esecuzione dell'istanza del flusso di lavoro creata. WorkflowInstance.Start() causa il runtime del flusso di lavoro per generare l'evento WorkflowStarted e l'istanza del flusso di lavoro si trova in uno stato In esecuzione. Viene generata un'eccezione InvalidOperationException se Start() viene chiamato in un'istanza del flusso di lavoro già avviata.

WorkflowInstance.Abort()

Interrompe l'istanza del flusso di lavoro. Quando l'interruzione ha esito positivo, il runtime del flusso di lavoro genera l'evento WorkflowAborted .

WorkflowInstance.Load()

Carica un'istanza del flusso di lavoro scaricata da un archivio di persistenza in memoria. L'istanza viene quindi pianificata per l'esecuzione dallo stato in cui è stata caricata. Quando il caricamento ha esito positivo, il runtime del flusso di lavoro genera l'evento WorkflowLoaded .

WorkflowInstance.Resume()

Riprende (continua l'esecuzione di) un'istanza del flusso di lavoro sospesa o interrotta. Il runtime del flusso di lavoro genera l'evento WorkflowResumed appena prima dell'esecuzione dell'istanza del flusso di lavoro viene ripresa.

WorkflowInstance.Suspend()

Sospende l'esecuzione dell'istanza del flusso di lavoro. Quando la chiamata a WorkflowInstance.Suspend() ha esito positivo, il runtime del flusso di lavoro genera l'evento WorkflowSuspended .

WorkflowInstance.Terminate()

Termina l'istanza del flusso di lavoro e cancella l'istanza del flusso di lavoro in memoria. Il runtime del flusso di lavoro informa il servizio di persistenza registrata che l'istanza del flusso di lavoro è stata cancellata dalla memoria. Per SqlWorkflowPersistenceService, ciò significa che tutte le informazioni sullo stato per l'istanza del flusso di lavoro vengono eliminate dal database al termine. Non è possibile ricaricare l'istanza del flusso di lavoro da un punto di persistenza archiviato in precedenza. Quando WorkflowInstance.Terminate() ha esito positivo, il runtime del flusso di lavoro genera l'evento WorkflowTerminated .

WorkflowInstance.Unload()

Scarica l'istanza del flusso di lavoro dalla memoria all'archivio di persistenza. WorkflowInstance.Unload() è sincrono. Blocca fino a quando non viene completato il lavoro pianificato o la fine di un ambito di transazione viene raggiunta, per eseguire correttamente il caricamento. Quando WorkflowInstance.Unload() ha esito positivo, il runtime del flusso di lavoro genera l'evento WorkflowUnloaded . Viene generata un'eccezione InvalidOperationException se viene chiamato Unload() quando non è presente alcun servizio di persistenza registrato.

WorkflowInstance.TryUnload()

A differenza di WorkflowInstance.Unload(), WorkflowInstance.TryUnload() non blocca finché il flusso di lavoro non può essere scaricato. WorkflowInstance.TryUnload() scarica l'istanza del flusso di lavoro dalla memoria all'archivio di persistenza e restituisce true quando l'istanza viene sospesa o inattiva. In caso contrario, la chiamata restituisce false. Viene generata un'eccezione InvalidOperationException se TryUnload() viene chiamato quando non è presente alcun servizio di persistenza registrato.

Per altre informazioni sui vari metodi di controllo in WorkflowInstance, vedere Windows Foundation SDK.

Gestibilità e monitoraggio

Le applicazioni che ospitano i flussi di lavoro sono responsabili della gestione e del monitoraggio dei flussi di lavoro che ospitano ed eseguono. WF offre il supporto per vari strumenti di gestione e monitoraggio. Ad esempio, WF fornisce la traccia end-to-end che è possibile usare per il debug a basso livello e anche il rilevamento dell'infrastruttura per l'estrazione e il monitoraggio dei dati del flusso di lavoro.

Questa sezione illustra l'infrastruttura di gestione e monitoraggio sul posto e su come usarla nelle applicazioni host.

Rilevamento

WF offre un'infrastruttura di rilevamento per l'acquisizione di flussi di lavoro, attività e eventi utente e dati durante l'esecuzione delle istanze del flusso di lavoro. Qualsiasi istanza del runtime del flusso di lavoro può avere più servizi di rilevamento registrati o nessuno. Le informazioni di rilevamento vengono inviate ai servizi di rilevamento registrati. I servizi di rilevamento sono responsabili dell'archiviazione e dell'elaborazione di queste informazioni in base alle esigenze dell'applicazione host. WF fornisce un servizio di rilevamento basato su SQL basato su SQL (SqlTrackingService) che un'applicazione host può usare. Inoltre, gli sviluppatori di applicazioni host possono scrivere i propri servizi di rilevamento personalizzati e usarli per le applicazioni host.

È possibile usare il rilevamento per esaminare la cronologia dell'esecuzione dell'istanza del flusso di lavoro e determinare lo stato corrente delle istanze del flusso di lavoro in esecuzione nel sistema. Inoltre, il rilevamento può fornire informazioni che è possibile usare insieme alla definizione del flusso di lavoro per prevedere i percorsi di esecuzione previsti futuri delle istanze del flusso di lavoro in esecuzione nel sistema. WF fornisce un esempio di applicazione, Esempio di Monitoraggio flusso di lavoro, che usa i controlli SqlTrackingService e Progettazione flussi di lavoro per visualizzare le informazioni sullo stato del flusso di lavoro e dell'attività completate e attualmente in esecuzione.

Per altre informazioni sul monitoraggio dei flussi di lavoro usando il rilevamento, vedere Lo strumento SDK di Monitoraggio del flusso di lavoro nell'esempio di monitoraggio di esempi di applicazioni/flusso di lavoro. Per esempi che illustrano come creare un servizio di rilevamento personalizzato, vedere l'esempio consoleTrackingService e il servizio di rilevamento file e l'esempio di query in Esempi/rilevamento tecnologici. Per esempi che illustrano come usare SqlTrackingService out-of-box, vedere l'esempio di rilevamento semplice e query usando l'esempio SQLTrackingService in Esempi di tecnologia/Trackingout-of-box.

Traccia e traccia end-to-end

È possibile usare le tracce per monitorare l'integrità dell'applicazione e isolare e risolvere i problemi senza disturbare un sistema in esecuzione. WF usa le API System.Diagnostics per tracciare informazioni sull'esecuzione del runtime del flusso di lavoro e sull'esecuzione dell'istanza del flusso di lavoro, incluse le informazioni sulla valutazione del set di regole. Per impostazione predefinita, le tracce vengono disattivate, ma è possibile attivarle se si desidera.

Inoltre, WF partecipa alla traccia end-to-end. Le funzionalità di traccia end-to-end consentono ai visualizzatori di traccia di visualizzare le informazioni sulla traccia di continuazione tra vari componenti e le transizioni tra tali componenti. Ciò facilita il debug end-to-end.

Se si usa un file di configurazione dell'applicazione, è necessario aggiungere quanto segue per abilitare la traccia di registrazione per diversi spazi dei nomi WF:

<system.diagnostics>
    <switches>
        <add name="System.Workflow LogToTraceListeners" value="1" />
        <add name="System.Workflow.Runtime" value="All" />
        <add name="System.Workflow.Runtime.Hosting" value="All" />
        <add name="System.Workflow.Runtime.Tracking" value="All" />
        <add name="System.Workflow.Activities" value="All" />
        <add name="System.Workflow.Activities.Rules" value="All" />
    </switches>
</system.diagnostics> 

Quando viene usato LogToTraceListeners , WF enumera ogni TraceListener creato all'interno dell'applicazione host e li invia tutte le informazioni di registrazione. Le righe rimanenti nell'esempio consentono di specificare gli spazi dei nomi per acquisire informazioni di registrazione e anche la quantità di informazioni tracciate. I valori possibili per l'attributo value includono All, Off, Critical, Error, Warning, Information e Verbose. Per altre informazioni sull'uso degli attributi del valore, vedere WF SDK.

Eventi di runtime del flusso di lavoro

Gli eventi di runtime vengono generati dal runtime del flusso di lavoro e forniscono all'applicazione host i mezzi per gestire il ciclo di vita delle istanze del runtime del flusso di lavoro e del flusso di lavoro. I gestori eventi vengono definiti nella classe WorkflowRuntime e l'applicazione host deve sottoscrivere tali eventi per usarli.

Gli eventi di runtime fungono da sistema di notifica leggero quando l'applicazione host deve agire su un evento specifico anziché archiviare tali eventi e i relativi dati associati a scopo di query. Per questi ultimi è consigliabile usare l'infrastruttura di rilevamento.

Un'istanza di WorkflowRuntime potrebbe essere in esecuzione di più istanze del flusso di lavoro; ogni istanza del flusso di lavoro ha un proprio ciclo di vita. Di conseguenza, gli argomenti dell'evento per gli eventi dell'istanza del flusso di lavoro contengono l'ID istanza del flusso di lavoro e altre informazioni. Queste informazioni possono essere usate per correlare l'evento con l'istanza del flusso di lavoro che causa la generazione di questo evento dal runtime del flusso di lavoro.

Le sezioni seguenti descrivono gli eventi di runtime del flusso di lavoro disponibili.

WorkflowRuntime.ServiceExceptionNotHandled

Questo evento viene generato quando il thread di proprietà del servizio genera un'eccezione. Un servizio derivato dalla classe WorkflowRuntimeService può chiamare il metodo RaiseServicesExceptionNotHandledEvent() per informare i sottoscrittori dell'evento ServicesExceptionNotHandled che si è verificata un'eccezione durante l'esecuzione e che non è stato in grado di gestire questa eccezione. I servizi predefiniti generano questo evento in tali condizioni. L'applicazione host può sottoscrivere questo evento per implementare un meccanismo di ripristino. L'argomento dell'evento associato a questo evento è ServicesExceptionNotHandledEventArgs.

WorkflowRuntime.Started

Questo evento viene generato all'avvio dell'istanza specificata di WorkflowRuntime . L'argomento dell'evento associato a questo evento è WorkflowRuntimeEventArgs.

WorkflowRuntime.Stopped

Questo evento viene generato quando viene arrestata l'istanza specificata di WorkflowRuntime . L'argomento dell'evento associato a questo evento è WorkflowRuntimeEventArgs.

Tabella 1. WorkflowInstanceEvents

Event	Descrizione	Argomento evento
WorkflowAborted	Generato quando l'istanza del flusso di lavoro viene interrotta.	WorkflowEventArgs
WorkflowCompleted	Generato al termine dell'istanza del flusso di lavoro.	WorkflowCompletedEventArgs
WorkflowCreated	Generato quando l'istanza del flusso di lavoro è completamente costruita, ma prima dell'elaborazione delle attività; ovvero prima dell'avvio dell'esecuzione del flusso di lavoro.	WorkflowEventArgs
WorkflowIdled	Generato quando l'istanza del flusso di lavoro entra in uno stato di inattività; ovvero, l'istanza del flusso di lavoro è in attesa di un evento esterno (ad esempio, un timer, un messaggio e così via) per continuare l'esecuzione.	WorkflowEventArgs
Flusso di lavoro caricato	Generato quando l'istanza del flusso di lavoro viene caricata in memoria, in genere da un archivio di persistenza.	WorkflowEventArgs
WorkflowPersisted	Generato quando l'istanza del flusso di lavoro è persistente.	WorkflowEventArgs
WorkflowResumed	Generato quando l'istanza del flusso di lavoro viene ripresa, in genere da uno stato sospeso o interrotto.	WorkflowEventArgs
WorkflowStarted	Generato all'avvio dell'esecuzione dell'istanza del flusso di lavoro.	WorkflowEventArgs
WorkflowSuspended	Generato quando l'istanza del flusso di lavoro viene sospesa.	WorkflowSuspendedEventArgs
WorkflowTerminata	Generato quando l'istanza del flusso di lavoro viene terminata.	WorkflowTerminatedEventArgs
WorkflowUnloaded	Generato quando l'istanza del flusso di lavoro viene scaricata dalla memoria a un archivio di persistenza.	WorkflowEventArgs

Vedere la sezione "Gestione del ciclo di vita del flusso di lavoro" più indietro in questo articolo per altre informazioni sui vari eventi e sul modo in cui il flusso di lavoro entra in vari stati.

Per informazioni su come usare vari eventi di runtime del flusso di lavoro, vedere Gli esempi di Windows Workflow Foundation SDK.

Contatori delle prestazioni

È possibile monitorare le prestazioni del flusso di lavoro usando lo strumento per le prestazioni di Windows. È composto da due parti: Monitoraggio di sistema e log delle prestazioni e avvisi. Tramite i log delle prestazioni e gli avvisi, è possibile configurare i contatori delle prestazioni per registrare i dati sulle prestazioni e impostare avvisi di sistema per notificare quando il valore di un contatore specificato è superiore o inferiore a una soglia definita.

WF fornisce un set di contatori delle prestazioni con l'oggetto prestazioni WF che è possibile usare per tenere traccia delle prestazioni di un flusso di lavoro. Per un elenco completo dei contatori delle prestazioni, vedere la sezione Contatori delle prestazioni del flusso di lavoro in WF SDK.

Per informazioni dettagliate su come aggiungere contatori delle prestazioni allo strumento Prestazioni, vedere il sito Web Microsoft TechNet.

Scarica criteri

I sistemi potrebbero avere migliaia di flussi di lavoro in esecuzione simultaneamente in un determinato momento. Può diventare poco pratico per consentire a tutti di rimanere in memoria. Per gestire meglio le risorse di un sistema, è possibile impostare un criterio di scaricamento per rendere persistenti gli stati del flusso di lavoro e scaricarli dalla memoria.

WF fornisce un scaricamento nei criteri di inattività se si usa il servizio di persistenza predefinita. Il criterio è attivo quando si imposta la proprietà UnloadOnIdle nella classe SqlWorkflowPersistenceService per indicare al motore di runtime di scaricare il flusso di lavoro quando è inattiva. Se l'applicazione host abilita SqlWorkflowPersistenceService tramite un file di configurazione, è possibile farlo impostando il flag UnloadOnIdle su true. Se SqlWorkflowPersistenceService viene costruito e abilitato tramite codice, l'applicazione host deve crearla usando il costruttore SqlWorkflowPersistenceService (String, Boolean, TimeSpan, TimeSpan). L'applicazione host potrebbe implementare altri criteri di scaricamento complessi.

È anche possibile chiamare il metodo WorkflowInstance.Unload() per richiedere di scaricare questa specifica istanza del flusso di lavoro dalla memoria e renderla persistente. L'applicazione host può successivamente chiamare il metodo Load() sulle istanze per continuare a eseguirle dall'ultimo punto di persistenza. Quando le istanze del flusso di lavoro vengono scaricate, viene generato un evento di runtime, l'evento WorkflowUnloaded .

Affidabilità e disponibilità elevata

WF supporta gli host che scelgono di essere affidabili e a disponibilità elevata fornendo supporto per quanto segue:

SQL Clustering

I servizi basati su SQL predefiniti supportano l'installazione del clustering. I servizi predefiniti di WF basati su SQL forniscono nuovi tentativi durante il commit del batch in SQL Server. Pertanto, supportare scenari di failover o server SQL temporaneamente inaccessibili. La logica di ripetizione dei tentativi può essere impostata su una combinazione di uno dei servizi seguenti:

• DefaultWorkflowCommitWorkBatchService
• SharedConnectionWorkflowCommitWorkBatchService
• SqlTrackingService
• SqlWorkflowPersistenceService

Per impostazione predefinita, la logica di ripetizione dei tentativi è OFF. L'applicazione host deve attivare in modo esplicito la logica di ripetizione dei tentativi per usare la funzionalità. Le applicazioni possono scegliere di abilitare nuovi tentativi per servizio o in tutti i servizi indicati in precedenza. A tale scopo, è possibile impostare la proprietà EnableRetries nelle classi di servizi o tramite il file di configurazione. Con un file di configurazione, l'applicazione host può usare un flag condiviso, EnableRetries, per impostare i tentativi su ON o OFF su tutti i servizi interessati. Se la proprietà EnableRetries è impostata su un servizio, il relativo valore sovrascrive il valore del flag condiviso EnableRetries . I servizi basati su SQL predefiniti di WF riprovano per un numero costante di volte. Il numero di tentativi non è configurabile. Tuttavia, le applicazioni possono modificare il timeout della connessione nella stringa di connessione dei servizi per regolare parzialmente il tempo tra i tentativi.

Impostazione di tentativi

Nell'esempio seguente viene illustrato come impostare EnableRetries per tutti i servizi predefiniti aggiungendo un parametro comune, EnableRetries e impostandone il valore su True. Illustra come disabilitare EnableRetries per SqlWorkflowPersistenceService aggiungendo un flag EnableRetries per questo servizio e impostandolo su False.

<WorkflowRuntime Name="SampleApplication" UnloadOnIdle="false">
    <CommonParameters>
        <add name="ConnectionString" value="Initial Catalog=WorkflowStore;Data Source=localhost;Integrated Security=SSPI;" />
        <add name="EnableRetries" value="True" />
    </CommonParameters>
    <Services>
        <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, 
System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" EnableRetries="False"  />
    </Services>
</WorkflowRuntime>

In genere, è consigliabile impostare nuovi tentativi su tutti i servizi su ON o OFF.

Si noti che la classe WorkflowCommitWorkBatchService è responsabile della ripetizione di tutti i commit batch correlati alle attività non TransactionScopeActivity (punti di persistenza). La classe WorkflowCommitBatchService non può eseguire nuovi tentativi di commit batch di lavoro per le attività TransactionScopeActivity . Ciò è dovuto al fatto che in questo caso non ha avviato la transazione e pertanto non è proprietaria. I tentativi di commit batch di lavoro per le attività TransactionScopeActivity devono essere modellati nel flusso di lavoro. Questa operazione viene in genere eseguita sotto forma di ciclo while e di un gestore di eccezioni all'esterno di TransactionScopeActivity.

Ritenta in SqlTrackingService predefinita, se eseguito in modalità non transazionale e SqlWorkflowPersistenceService controlla il lavoro correlato a SQL non correlato ai commit batch di lavoro. Sono inclusi il controllo dei timer scaduti e il caricamento delle istanze del flusso di lavoro.

Bilanciamento del carico e ridimensionamento Front-End

L'applicazione che ospita WF è responsabile della gestione degli scenari di bilanciamento del carico e degli scenari di scalabilità front-end. WF offre il supporto nel motore e nei servizi predefiniti basati su SQL per consentire a istanze diverse dell'applicazione host di puntare allo stesso database SQL di persistenza o rilevamento.

Se sono presenti più applicazioni host connesse allo stesso archivio di persistenza, ognuna di esse potrebbe caricare qualsiasi tipo di istanza del flusso di lavoro dal database. SqlWorkflowPersistenceService non supporta l'assegnazione di tipi di flusso di lavoro o istanze da caricare in host specifici quando condividono lo stesso archivio di persistenza. Se questo comportamento non soddisfa le esigenze dell'applicazione host, è necessario implementare un servizio di persistenza personalizzato.

Il motore di runtime di WF fornisce la semantica di blocco per supportare scenari di scalabilità front-end quando più applicazioni host usano lo stesso archivio di persistenza. La semantica di blocco impedisce alle applicazioni di caricare un'istanza del flusso di lavoro già caricata da un'altra applicazione. La classe WorkflowPersistenceService consente di supportare questa funzionalità del motore di runtime del flusso di lavoro fornendo un parametro al metodo 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 le informazioni sullo stato del flusso di lavoro bloccate in precedenza. In un servizio di persistenza che implementa il blocco, una chiamata al metodo LoadWorkflowInstanceState() deve bloccare le informazioni sullo stato per un'istanza del flusso di lavoro.

Per altre informazioni sulla semantica di blocco delle istanze del flusso di lavoro, vedere le sezioni Windows Workflow Persistence Services e Creazione di Servizi di persistenza personalizzati in WF.

Servizi di runtime di base

Il motore di runtime di WF esegue flussi di lavoro usando i servizi di runtime. Il modello di servizio di runtime offre all'applicazione host la flessibilità necessaria per fornire vari servizi al motore di runtime di WF. Questa sezione descrive i servizi di runtime forniti da WF e le implementazioni predefinite di tali servizi.

Per altre informazioni sulle implementazioni del servizio di runtime, vedere le sezioni Windows Workflow Foundation Services e Sviluppo di Windows Workflow Foundation Services nella Guida alla programmazione di WF.

Il runtime di WF fornisce quattro servizi. Questi servizi hanno implementazioni predefinite o applicazioni host possono implementare i propri servizi e fornirli al runtime del flusso di lavoro.

Servizi transazioni flusso di lavoro

Lo scopo dei servizi di transazione del flusso di lavoro di Windows (WorkflowCommitWorkBatchService) è quello di abilitare la logica personalizzata relativa all'impegno dei batch di lavoro (noti anche come punti di persistenza). Quando viene eseguito il commit di un batch di lavoro, il runtime chiama nel servizio transazioni corrente e passa un delegato da chiamare per eseguire il commit effettivo del batch di lavoro. Il runtime è ancora il principale responsabile dell'esecuzione del commit, ma consentendo al servizio di inserirsi nel processo permette la personalizzazione del processo di commit.

Il framework WF non supporta la possibilità di trasferire la propria transazione dall'esterno in un'istanza del flusso di lavoro. Gli unici tipi di transazioni di ambiente supportate da WorkflowCommitWorkBatchService sono transazioni originate dall'istanza del flusso di lavoro. Le transazioni di ambiente originate dall'applicazione host che esegue il runtime del flusso di lavoro vengono rimosse temporaneamente dal thread corrente per ridurre gli effetti collaterali. Dopo l'inattività del flusso di lavoro, la transazione di ambiente originale dell'applicazione host contenuta da viene inserita nuovamente nel thread.

WF offre due implementazioni predefinite per i servizi di transazione: DefaultWorkflowCommitWorkBatchService e SharedConnectionWorkflowCommitWorkBatchService.

Il motore di runtime di WF richiede un servizio di transazione del flusso di lavoro. Per impostazione predefinita, usa DefaultWorkflowCommitWorkBatchService. L'applicazione host può scegliere di sostituire DefaultWorkflowSchedulerService con SharedConnectionDefaultWorkflowCommitWorkBatchService o con un servizio personalizzato.

DefaultWorkflowCommitWorkBatchService

All'avvio del motore di runtime del flusso di lavoro, viene creata un'istanza di DefaultWorkflowCommitWorkBatchService e aggiunta a WorkflowRuntime se non viene aggiunto alcun altro servizio di transazione. Questo servizio crea transazioni .NET Framework per ogni connessione al database. Ad esempio, le connessioni tra SQL Tracking Services e SQL Persistence Services non vengono condivise. È possibile usare questo servizio nei flussi di lavoro per supportare le transazioni necessarie per l'integrità dei dati.

SharedConnectionWorkflowCommitWorkBatchService

Questo servizio viene utilizzato per le transazioni di database che utilizzano una connessione condivisa tra oggetti diversi. Se l'applicazione host vuole usare questo servizio, deve aggiungerla a WorkflowRuntime usando il metodo AddService o tramite il file di configurazione.

Servizi utilità di pianificazione del flusso di lavoro

I servizi dell'utilità di pianificazione del flusso di lavoro gestiscono la pianificazione delle istanze del flusso di lavoro dal motore di runtime del flusso di lavoro, indipendentemente dal fatto che vengano gestiti in modalità asincrona o manuale sincrona. WF offre due implementazioni predefinite per WorkflowSchedulerService: DefaultWorkflowSchedulerService e ManualWorkflowSchedulerService.

Per eseguire flussi di lavoro, il motore di runtime di WF richiede un servizio utilità di pianificazione del flusso di lavoro. Per impostazione predefinita, usa DefaultWorkflowSchedulerService. L'applicazione host può scegliere di sostituire DefaultWorkflowSchedulerService con ManualWorkflowSchedulerService o un servizio personalizzato.

Defaultworkflowschedulerservice

DefaultWorkflowSchedulerService crea e gestisce i thread che eseguono istanze del flusso di lavoro in modo asincrono nel motore di runtime del flusso di lavoro e include il supporto predefinito per la coda di più istanze del flusso di lavoro nel pool di thread di runtime. Se nessun'altra istanza del servizio dell'utilità di pianificazione del flusso di lavoro viene aggiunta a WorkflowRuntime, per impostazione predefinita usa DefaultWorkflowSchedulerService .

ManualWorkflowSchedulerService

ManualWorkflowSchedulerService viene usato per l'esecuzione sincrona delle istanze del flusso di lavoro. Se questo servizio viene usato, le istanze del flusso di lavoro vengono eseguite nel thread chiamante dall'applicazione host, bloccando quindi l'esecuzione dell'applicazione host fino a quando l'istanza del flusso di lavoro non diventa inattiva.

Servizi di persistenza del flusso di lavoro

I servizi di persistenza sono responsabili dell'archiviazione e del recupero (caricamento e scaricamento) dello stato dell'istanza del flusso di lavoro. WF offre un'implementazione predefinita basata su SQL del servizio di persistenza: SqlWorkflowPersistenceService.

SqlWorkflowPersistenceService

Questa implementazione predefinita archivia le informazioni sullo stato e sul timer per SQL Server/MSDE. SqlWorkflowPersistenceService partecipa alle transazioni del flusso di lavoro e implementa l'accesso di blocco. SqlWorkflowPersistenceService offre inoltre funzionalità per abilitare i tentativi quando SQL Server non è disponibile. Questo controllo può essere controllato impostando la proprietà EnableRetries nel servizio. Per altre informazioni su SqlWorkflowPersistenceService, vedere la Guida alla programmazione di WF.

Servizi di rilevamento del flusso di lavoro

I servizi di rilevamento gestiscono i profili di rilevamento e l'archiviazione delle informazioni di rilevamento. WF fornisce un'implementazione predefinita basata su SQL di un servizio di rilevamento implementato nella classe SqlTrackingService .

SqlTrackingService

Questa implementazione archivia i profili di rilevamento e i dati in SQL Server/MSDE. Il servizio supporta quanto segue:

• Partecipa alle transazioni del flusso di lavoro per impostazione predefinita; il comportamento è controllato dalla proprietà SqlTrackingService.IsTransactional .

• Fornisce un meccanismo per usare i profili di rilevamento predefiniti per tutti i tipi o associare profili di rilevamento per ogni tipo di flusso di lavoro o istanze del flusso di lavoro.

• Supporta la manutenzione dei dati fornendo funzionalità di partizionamento in tempo reale e su richiesta.

  Informazioni dettagliate sulla manutenzione dei dati sono disponibili nella sezione Manutenzione dati con SqlTrackingService della Guida per programmatori di WF.

Inoltre, WF fornisce API SqlTrackingQuery che è possibile usare per eseguire query sui dati di rilevamento archiviati in SqlTrackingService. Per altre informazioni su SqlTrackingService, vedere la Guida alla programmazione di WF.

Conclusione

WF fornisce un motore di runtime e servizi per eseguire flussi di lavoro e gestirli. È necessario scrivere un'applicazione host o un processo per ospitare flussi di lavoro di WF. Questa applicazione host è responsabile della fornitura di vari servizi di runtime al motore di runtime del flusso di lavoro. I servizi di runtime predefiniti di WF sono destinati a risolvere scenari comuni. Tuttavia, se i servizi predefiniti non soddisfano le esigenze dell'applicazione host, l'applicazione host deve implementare servizi personalizzati e fornirla al runtime del flusso di lavoro.

Inoltre, WF fornisce l'infrastruttura per gestire e monitorare le istanze del flusso di lavoro in esecuzione e per supportare le applicazioni host che scelgono di essere affidabili e a disponibilità elevata. Le applicazioni host devono decidere come usare le varie opzioni in base agli scenari specifici dell'hosting.

Ulteriori informazioni

Questo articolo, insieme alle risorse seguenti, dovrebbe aiutare gli sviluppatori che non hanno esperienza con la tecnologia del flusso di lavoro a conoscere la tecnologia e diventare rapidamente produttivi nell'uso.

• MSDN Workflow Developer Center
  • Contiene documenti e collegamenti a webcast e lab.
• Esempi di sito della community
• Documentazione di Windows SDK
  • Se Windows Foundation SDK non è disponibile, scaricarlo dal sito di Windows SDK. Windows Workflow SDK fa parte di Windows SDK. Contiene riferimenti alla guida per programmatori WF, riferimenti api e vari esempi di tecnologia e applicazioni.
• Forum sul flusso di lavoro MSDN
  • Forum di discussione che può fornire risposte alle domande relative all'hosting di runtime di WF o WF in generale.

 

Informazioni sull'autore

Moustafa Khalil Ahmed è un Program Manager con il team WF presso Microsoft Corp., Redmond, WA. Da quando si è unito a Microsoft nel 2000, ha lavorato allo sviluppo di vari componenti server e ha contribuito a distribuire quattro prodotti server, tra cui Microsoft BizTalk Server. Prima di lavorare presso Microsoft, Moustafa era un Software Engineer, Business Analyst e Account Manager presso ITWorx, Cairo, Egitto.