Toolkit CASI (Claims, Azure and SharePoint Integration) parte 5
Toolkit CASI (Claims, Azure and SharePoint Integration) parte 5
In questo post è inclusa la quinta e ultima parte di una serie di informazioni sul kit per l'integrazione di attestazioni, Azure e Sharepoint (CASI, Claims, Azure e SharePoint Integration). Nella Parte 1 viene fornita una panoramica introduttiva completa del framework e della soluzione e una descrizione dei contenuti illustrati nella serie di post. La Parte 2 include una guida per la creazione di applicazioni WCF in grado di riconoscere le attestazioni e per lo spostamento di tali applicazioni in Windows Azure. Nella Parte 3 viene illustrata la classe di base da utilizzare per l'associazione del sito di SharePoint ai dati di Azure tramite l'aggiunta di un nuovo controllo personalizzato a una pagina nella directory _layouts. La Parte 4 contiene documentazione relativa alla Web part fornita con il kit CASI e descrive le relative modalità di utilizzo, le diverse proprietà e altro ancora. In questo post conclusivo vengono descritti altri due scenari fondamentali relativi al kit. Nel primo scenario viene illustrato l'utilizzo del controllo personalizzato creato nella Parte 3 per recuperare i dati di Azure e archiviarli nella cache ASP.NET per l'uso con altri controlli. Nel secondo, l'utilizzo del controllo personalizzato in un'attività di SharePoint, in questo caso in un processo timer personalizzato di SharePoint.
Utilizzo del controllo in altre Web part
Uno degli scenari fondamentali che si è desiderato supportare è l'uso del framework del kit CASI per recuperare i dati e utilizzarli in altre Web part di SharePoint. In tale scenario si è tuttavia tenuto in considerazione anche un altro obiettivo di progettazione, ovvero NON introdurre chiamate di routine sul lato server a endpoint WCF remoti potenzialmente latenti. Per gestire queste due esigenze diverse, la classe di base implementa il supporto per il recupero dei dati e per l'archiviazione di tali dati direttamente nella cache ASP.NET. Ciò consente di sviluppare altre Web part personalizzate e seguire uno schema relativamente semplice:
1. Verificare se i dati si trovano nella cache ASP.NET.
a. Se si trovano nella cache, recuperarli da qui.
b. Se non si trovano nella cache:
i. Creare un'istanza del controllo personalizzato.
ii. Impostare il tipo OutputType su ServerCache, impostare ServerCacheName e ServerCacheTime con i valori appropriati.
iii. Chiamare il metodo ExecuteRequest e ottenere i dati.
Avviare innanzitutto un nuovo progetto di Visual Studio, in questo caso si presume l'utilizzo di Visual Studio 2010 così da poter creare un nuovo progetto di SharePoint 2010. Configurare il progetto per la creazione di una nuova Web part e quindi aggiungere due riferimenti: uno alla classe di base del kit CASI e l'altra al controllo personalizzato creato nella Parte 3. Si noti che se non si aggiunge un riferimento alla classe di base del kit CASI, quando si tenta di impostare una qualsiasi proprietà sul controllo creato, in Visual Studio vengono visualizzati una sottolineatura rossa ondulata e un messaggio che informa che è impossibile trovare la proprietà. La visualizzazione di questo tipo di errore indica che non è ancora stato aggiunto il riferimento alla classe di base del kit CASI.
Dopo avere impostato i riferimenti, è possibile scrivere il codice appropriato per la Web part. Quando si raggiunge il punto in cui è necessario effettuare il pull di dati da Azure (contenuto, informazioni di configurazione o altro ancora), fare riferimento all'esempio indicato di seguito in cui viene descritta l'implementazione dello schema precedente.
string CACHE_NAME = "AzureConfigConsumerCacheSample";
int CACHE_TIME = 10;
//create a var of the type of configuration data we want to retrieve
AzureWcfPage.CustomersWCF.Customer[] Customers = null;
//look for our item in cache
if (HttpContext.Current.Cache[CACHE_NAME] != null)
{
//if we find, it cast it to our type and pull it out of cache
Customers =
(AzureWcfPage.CustomersWCF.Customer[])
HttpContext.Current.Cache[CACHE_NAME];
}
else
{
//if it's not in cache, then retrieve it and put it into cache
//create an instance of the control
AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();
//set the properties to retrieve data
cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";
cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.ServerCache;
cfgCtrl.ServerCacheName = CACHE_NAME;
cfgCtrl.ServerCacheTime = CACHE_TIME;
cfgCtrl.MethodName = "GetAllCustomers";
//execute the method
bool success = cfgCtrl.ExecuteRequest();
if (success)
{
//get the strongly typed version of our data
//the data type needs to come from the control we are creating
Customers =
(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;
//if you wanted the Xml representation of the object you can get
//it from QueryResultsString
string stringCustomers = cfgCtrl.QueryResultsString;
}
else
{
//there was some problem; plug in your error handling here
}
}
Si osservino alcune parti del codice in dettaglio. La prima cosa importante da notare è che nella nuova Web part NON è necessario aggiungere all'endpoint WCF un riferimento al servizio. Tutto ciò è incapsulato nel controllo personalizzato, pertanto è possibile utilizzare i tipi restituiti dell'applicazione WCF esposti tramite il controllo personalizzato. Questo è dimostrato dalla riga di codice seguente:
//create a var of the type of configuration data we want to retrieve
AzureWcfPage.CustomersWCF.Customer[] Customers = null;
In questo esempio, AzureWcfPage è l'assembly del controllo personalizzato. CustomersWCF è il nome del riferimento al servizio WCF. Customer è il tipo di classe restituita dal metodo WCF. Tutti questi elementi fluiscono nella nuova Web part quando si aggiunge il riferimento all'assembly del controllo personalizzato.
Innanzitutto è necessario verificare se i dati si trovano nella cache. Se si trovano in questa posizione, è sufficiente eseguirne il cast nella matrice delle istanze Customer archiviate nella cache in precedenza. Se i dati non si trovano nella cache, è sufficiente scrivere le sette righe di codice necessarie per creare un'istanza del controllo personalizzato e per recuperare i dati. Sarà necessario:
a. Creare una nuova istanza del controllo.
b. Impostare le proprietà WcfUrl, MethodName, OutputType, ServerCacheName e ServerCacheTime.
c. Chiamare il metodo ExecuteRequest.
Questo è tutto. Se il metodo viene completato in modo corretto, il valore restituito dall'applicazione WCF verrà archiviato nella cache ASP.NET e all'esecuzione successiva del codice l'elemento verrà individuato in questa posizione. Nel frattempo, è possibile eseguire il cast della variabile locale Customers nella proprietà QueryResultsObject del controllo personalizzato. Quindi è possibile eseguire con i dati tutte le operazioni richieste dalla Web part. Nell'insieme, l'implementazione dovrebbe risultare semplice e immediata per la maggior parte degli sviluppatori di Web part.
Utilizzo del controllo in un'attività
In questa sezione viene illustrato come utilizzare il controllo personalizzato sviluppato nella Parte 3 per recuperare da Azure contenuto e/o dati di configurazione da usare in un'attività. L'esempio che segue include il codice necessario per la creazione di un processo timer di SharePoint personalizzato e per il recupero di dati da Azure. Lo schema è simile alla Web part descritta in precedenza. Tuttavia in questo caso, così come in molte attività, non si dispone di un HttpContext e quindi non è possibile utilizzare la cache ASP.NET. In tale caso OutputType sarà None, perché non è necessario eseguirne il rendering in una pagina né archiviarlo nella cache. Verrà invece effettuato il pull della directory del valore da QueryResultsObject e/o da QueryResultsString. Di seguito un codice di esempio per questa operazione. Il codice è relativo all'override del metodo Execute nella classe del processo timer personalizzato.
SPWebApplication wa = (SPWebApplication)this.Parent;
//create an instance of the control
AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();
//set the properties to retrieve data
cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";
cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.None;
cfgCtrl.MethodName = "GetAllCustomers";
//since there's no Http context in a task like a timer job, you also need to
//provide the Url to a claims-enabled SharePoint site. That address will be used
//to connect to the STS endpoint for the SharePoint farm
cfgCtrl.SharePointClaimsSiteUrl = wa.Sites[0].RootWeb.Url;
//execute the method
bool success = cfgCtrl.ExecuteRequest();
//check for success
if (success)
{
//now retrieve the data and do whatever with it
AzureWcfPage.CustomersWCF.Customer[] Customers =
(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;
string AzureResults = cfgCtrl.QueryResultsString;
//this is where you would then do your tasks based on the data you got from Azure
foreach(AzureWcfPage.CustomersWCF.Customer c in Customers)
{
Debug.WriteLine(c.Email);
}
Debug.WriteLine(AzureResults);
}
else
{
//do something to log the fact that data wasn't retrieved
}
Segue ora la spiegazione relativa al codice. Il processo timer è un processo con ambito applicazione Web, quindi si inizia ottenendo un riferimento alla SPWebApplication per la quale il processo viene eseguito tramite il riferimento alla proprietà Parent. Il passaggio successivo consiste nel creare il controllo personalizzato definito nella Parte 3 e nell'impostare le proprietà minime necessarie per recuperare i dati da Azure. Nella riga successiva di codice viene impostata la proprietà SharePointClaimsSiteUrl. Come illustrato nella Parte 3, quando la classe di base del kit CASI viene eseguita tramite il metodo ExecuteRequest, viene verificato se è disponibile un HttpContext. Se disponibile, il contesto viene utilizzato per individuare l'URL del sito SharePoint corrente e per effettuare la connessione al servizio token di sicurezza di SharePoint tramite tale sito. Tuttavia come sopra descritto, in genere quando si esegue il codice in un'attività, non è disponibile un HttpContext. In tale caso, la classe di base non sarà in grado di determinare quale URL utilizzare per la connessione al servizio token di sicurezza di SharePoint, pertanto sarà necessario fornire l'URL a un sito in un'applicazione Web con attestazioni abilitate. Nel codice del processo timer di questa implementazione si presuppone che tale processo venga eseguito SOLO in applicazioni Web con attestazioni abilitate, per questo motivo si ottiene il riferimento all'applicazione Web corrente e quindi viene passato l'URL alla prima raccolta siti. Non è importante quel raccolta siti viene utilizzata, purché si trovi in un'applicazione Web con attestazioni abilitate.
Dopo avere impostato la proprietà SharePointClaimsSiteUrl è possibile chiamare il metodo ExecuteRequest come dimostrato in precedenza. Se l'esecuzione del metodo viene completata senza errori, sarà quindi possibile effettuare il pull dei dati direttamente dal controllo tramite le proprietà QueryResultsObject e/o QueryResultsString.
Entrambi i progetti Web part e processo timer sono inclusi nel file con estensione ZIP allegato a questo post.
Riepilogo
Questo è l'ultimo post della serie, mi auguro di aver favorito una buona comprensione del kit CASI e di come utilizzarlo per connettersi in modo semplice ai dati ospitati in un'applicazione WCF in locale o nella cloud utilizzando inoltre un token di identità nell'applicazione e anche entro i limiti del centro dati. In sintesi, lo schema è relativamente semplice da implementare:
1. Creare un front-end WCF per il contenuto e/o i dati di configurazione. Abilitare le attestazioni e facoltativamente spostarlo nella cloud. Facoltativamente, implementare decisioni basate su autorizzazioni specifiche in base all'identità e alle attestazioni dell'utente chiamante.
2. Scrivere il codice di un controllo personalizzato che eredita dalla classe di base del kit CASI. Eseguire l'override di un metodo e scrivere cinque righe di codice. Aggiungere il controllo a una pagina di layout semplice ed effettuare la distribuzione.
3. Aggiungere la Web part a una pagina, impostare una o più proprietà e avviare il rendering dei dati WCF. Facoltativamente, utilizzare il controllo per recuperare il contenuto o i dati di configurazione in una Web part o un'attività personalizzata, ad esempio in un processo timer personalizzato.
Questo è tutto. Mi auguro che il kit CASI consenta di rendere più semplice e immediata la connessione tra una farm di SharePoint a i dati archiviati in qualsiasi posizione remota. Il kit consentirà inoltre di recuperare in modo altrettanto efficace i dati relativi alla configurazione o personalizzazione, nonché il contenuto stesso per la visualizzazione nei siti di SharePoint. Tramite il kit sarà inoltre possibile utilizzare in modo flessibile il sistema di sicurezza implementato nell'organizzazione entro i limiti dell'applicazione e del centro dati. Definire, progettare e sviluppare questo progetto è stato per me un piacere, spero che tutte queste informazioni vi siano utili. Come sempre, trattandosi della versione 1 sono certo che ci sia spazio per ulteriori miglioramenti. È possibile aggiungere i vostri commenti a questi post, verranno esaminati periodicamente e tenuti in considerazione per lo sviluppo della prossima versione di prodotto.
Questo è un post di blog localizzato. Consultate l'articolo originale: The Claims, Azure and SharePoint Integration Toolkit Part 5