Workflow Foundation

L'arte di lavorare con Workflow Foundation - #3

Fabio Carucci — Mon, 20 Oct 2008 09:53:41 GMT

Tempo fa scrissi un articolo dal titolo “Simulare un operatore di call center con Windows Workflow Foundation”.

Da un paio di settimane, a puntate (ben 7), l’articolo è visibile su Programmazione.IT

Buona lettura.

Technorati Tags: WF,Windows Workflow Foundation,C#,NET 3

Meglio Moss2007 oppure Groove...?

Fabio Carucci — Thu, 05 Jul 2007 09:57:00 GMT

Questo post nasce da una domanda posta da un mio PartnerClienteCollega.

Il titolo è provocatorio, non credo sia possibile metterli a confronto, credo invece più adeguato valutare le esigenze e decidere, conoscendone i vantaggi e i limiti, di adottare l'uno anzichè l'altro.

MOSS 2007 è un ambiente Web-based dotato di un backend scalabile in cui è possibile effettuare ricerche di informazioni, quindi ideale per condividere in azienda;

Groove 2007 è un rich client, installato su ogni pc, per piccoli team, quindi ideale per decentralizzare la collaborazione.

MOSS 2007 permette di sviluppare applicazioni con workflow mediante Windows Workflow Foundation;

Groove 2007 facilita la comunicazione diretta per la maggior parte mediante il peer-to-peer (si, esatto), permette di lavorare disconessi per poi riconnettersi in un secondo momento e sincronizzare il lavoro eseguito offline.

MOSS 2007 va utilizzato da aziende che devono fare attività di searching di dati condivisi, deploy di portali, sviluppo di business forms e processi di workflow;

Groove 2007 va utilizzato da team che hanno bisogno di condividere non un portale ma un banco di lavoro per frequenti scambi di informazioni.

Ora però, anche per rispondere al mio PartnerClienteCollega, vediamo alcuni limiti di Groove rispetto a MOSS.

La fonte dei dati seguenti è un post pubblicato sul blog del team TechNet di Groove: http://blogs.technet.com/groove/default.aspx

Maximum individual file size (in a Files tool or otherwise):	2Gb
Maximum total content size that can be serialized to others during invitation	2Gb
Maximum total File size in a SharePoint Files Tool	1Gb
Maximum total File and Folder count in a SharePoint Files Tool	5,000
Meetings Tool limits text input to:	Meeting title to 256 chars
	Meeting location to 256 chars
	Action item names to 256 chars
	Agenda item names to 256 chars
	Agenda item duration to 24 hours
Account Configuration limits text input to:	Key field to 37 chars
	Account name to 256 chars
	Account name to 256 chars
	Password limits text input to 256 chars
	Calendar subject limits text input to 256 chars
In Forms we only allow 1 attachments field per Form
Maximum Total File Size in a Folder Sharing workspace	2Gb (can be overriden)
Maximum Total File and Folder count in a Folder Sharing Workspace	5,000 (can be overriden)
Maximum Number of Members in a Workspace	100 (can be overriden)

L'arte di lavorare con Workflow Foundation - #2

Fabio Carucci — Tue, 27 Feb 2007 01:19:00 GMT

Molto tempo fa scrissi un articolo sullo User Interface Application Block in cui parlai di grafi navigazionali, dare la possibilità ad un applicativo di "guidare" e mostrare la propria interfaccia utente mediante l'uso di un file xml dotato di un apposito schema in cui potevo scrivere il percorso delle transizione che le singole forms della mia applicazione potevano fare secondo ciò che l'utente sceglieva di volta in volta. Bello.

Mi rendo conto solo ora che ciò è possibile anche con WF.

Posso progettare e implementare una activity che funga da navigatore del mio grafo. Molto bello.

Mi occorrono fondamentalmente tre cose: il punto di partenza, il punto di arrivo e una "memoria storica" dei percorsi precedenti, una sorta di segnalibri; penso quindi, in maniera semplificata, ad una classe NavigationManager di tipo CompositeActivity e a due property TheFirstIs e TheNextIs - la raccolta di segnalibri, poi, non è altro che una collection di Activities. Bellissimo.

Ora penso al #3 di questo post.

Recensione: "Essential Windows Workflow Foundation"

Fabio Carucci — Tue, 30 Jan 2007 01:27:00 GMT

Link al libro su Amazon

Scritto a quattro mani da un architetto e da un progettista di WF (Shukla & Schmidt), consiglio la lettura di questo libro a chi desidera acquisire i concetti che sono alla base di quello che considero essere un "framework nel framework".

L'obiettivo del libro non è quello di elencare e disquisire a 360° sui 350 e passa tipi presenti nei tre assemblies che costituiscono il Windows Workflow Foundation, infatti il libro non è un manuale o una reference guide, bensì si pone come spunto di riflessione sui concetti e principi che hanno spinto i due autori a dedicarsi alla progettazione di WF, e lo fa anche con una moltitudine di esempi di codice sparsi nel libro.

Il primo capitolo è dedicato alla descrizione di concetti, quasi astratti, del modello di programmazione di WF;

Nel secondo capitolo si inizia a parlare di activities, cosa sono nel mondo reale, come si implementano nel codice, come si creano workflows composti da activities e come si esegue una applicazione "pilotata" da workflows.

I capitoli 3 e 4 descrivono le features interne delle activities, come si aggiungono activities durante l'esecuzione di un programma, come si gestiscono le exceptions, cosa è la compensation, insomma il ciclo di vita di una activity.

Il capitolo 5 spiega come costruire applicazioni che fungono da hosting per il runtime di WF, mentre nel capitolo 6 si affronta in dettaglio come sia possibile gestire le transazioni in un ambiente come quello di WF.

Infine i rimanenti 2 capitoli danno una idea delle potenzialità di estensione del WF e dei suoi workflows.

A complemento del libro vi sono due appendici molto utili poichè elencano una serie di porzioni di codice relative ai diversi tipi di workflow e alle activity composite.

In conclusione, "Essential Windows Workflow Foundation" è un testo adatto a coloro che vogliono iniziare un percorso di studio su WF ma che hanno necessariamente basi consolidate di .NET e C# 2.0.

L'arte di lavorare con Workflow Foundation - #1

Fabio Carucci — Thu, 25 Jan 2007 00:35:00 GMT

Dopo aver definito e disegnato un workflow, lo poniamo in esecuzione. Immaginiamo di aver creato un workflow che ci permette di prendere le prenotazioni per mandare un nostro pony express in giro per la città a fare consegne.

Il nostro workflow tiene conto dell'orario di arrivo della richiesta, quindi gira al pony l'elenco, in ordine di arrivo, degli indirizzi a cui recarsi. Se volessimo rendere più ottimizzato il workflow potremmo inserire uno step intermedio (activity) che mette in ordine di vicinanza/lontananza gli indirizzi e fornisce una stima del tempo di arrivo del pony al cliente.

Il workflow è in esecuzione, ma grazie alla classe WorkflowChanges possiamo aggiungere a runtime la nuova activity senza dover interrompere nulla.

InvokeWorkflowActivity newWorkflow = new InvokeWorkflowActivity();
WorkflowChanges changes = new WorkflowChanges(this);
 
Type type = typeof(ReservationWorkflow);
newWorkflow.Name = "NewReservationWF";
newWorkflow.TargetWorkflow = type;
 
DelayActivity delay = changes.TransientWorkflow.Activities["delay1"] as DelayActivity;
delay.Parent.Activities.Add(newWorkflow);
 
this.ApplyWorkflowChanges(changes);

Ci sono però delle restrizioni riguardo ai cambiamenti che possono essere compiuti su un workflow in esecuzione:

Le activities possono essere aggiunte o rimosse da un WF ma le proprietà di una attività esistente (regole escluse) non possono essere modificate;
Una activity composita non può avere al suo interno delle sotto-attività aggiunte o rimosse dinamicamente;
Una activity con una o più istanze nello stato di Executing, Fault, Canceling o Compensating non può essere rimossa da una istanza di un workflow in esecuzione.

Nei prossimi post scruteremo, con il passare del tempo sempre più in dettaglio, le numerose features di questo nuovo 'framework nel framework'.