Integrazione di SQL Azure con SharePoint 2010 e Windows Azure
Integrazione di SQL Azure con SharePoint 2010 e Windows Azure
Questo post si rivela utile soprattutto se utilizzato come integrazione alla serie in cinque parti sul kit CASI (Claims, Azure and SharePoint Integration).
· Parte 1: vengono fornite una panoramica introduttiva del framework e della soluzione completi e una descrizione dei contenuti illustrati nella serie di post.
· Parte 2: in questa parte sono contenute indicazioni generali sul kit CASI. Si inizierà con l'impostare WCF come front-end per tutti i dati, che possono essere set di dati, codice Xml, classi personalizzate o semplice codice Html. Nella fase 1 il servizio WCF standard sarà reso compatibile con le attestazioni, consentendo in tal modo di inviare il token utente da SharePoint alle nostre applicazioni WCF personalizzate attraverso i confini di applicazioni o del centro dati. Nella fase 2 illustrerò l'elenco di tutto ciò che occorre fare affinché questa tipica applicazione WCF on-premise venga ospitata in Windows Azure. Dopo aver completato questa fase, si disporrà del back-end per supportare un ambiente con più applicazioni e più data center con l'autenticazione integrata.
· Parte 3: viene descritto l'assembly del toolkit personalizzato che rappresenta l'elemento agglomerante per la connessione dell'applicazione WCF in grado di riconoscere attestazioni nella cloud e la farm di SharePoint. Illustrerò come utilizzare l'assembly, descriverò il semplice controllo personalizzato che dovete creare (circa 5 righe di codice) e come ospitarlo in una pagina nella directory _layouts per consentire il recupero e il rendering dei dati nella web part. Verranno pubblicati anche l'intero codice sorgente per il controllo personalizzato e la pagina _layouts di esempio.
· Parte 4: questa parte è relativa alla web part che verrà inclusa nel kit CASI. Verrà fornita una soluzione out of the box senza codice che potrete collegare e connettere con una query asincrona sul lato client per recuperare dati dal servizio ospitato nella cloud e visualizzarli quindi nella web part. La soluzione contiene inoltre associazioni integrate che potete personalizzare e quindi utilizzare le vostre funzioni JavaScript per il rendering dei dati.
· Parte 5: è inclusa una breve procedura dettagliata per alcune applicazioni di esempio in cui vengono illustrati altri scenari di utilizzo del controllo personalizzato che è stato creato in base alla descrizione nella parte 3 in altri scenari personalizzati. In uno scenario il controllo verrà utilizzato per recuperare un tipo di dati utente o di configurazione, archiviarli nella cache di ASP.NET e quindi utilizzarli in una web part personalizzata. Nell'altro scenario il controllo verrà utilizzato per recuperare dati da Azure e utilizzarli in un'attività personalizzata, in questo caso un processo timer di SharePoint. Anche per queste applicazioni di esempio verrà pubblicato l'intero codice sorgente.
Con il kit CASI sono stati forniti alcuni strumenti e alcune indicazioni per consentire di connettersi facilmente e rapidamente a Windows Azure da SharePoint 2010, inviando contemporaneamente il token dell'utente corrente in modo da poter prendere decisioni di sicurezza estremamente granulari. Nell'applicazione WCF originale utilizzata dal kit CASI veniva utilizzata solo una raccolta di dati esposta specificata a livello di codice. In una build successiva (e non documentata nei post relativi al kit CASI) è stata aggiornata la parte relativa ai dati in modo che l'archiviazione e il recupero dei dati avvenissero tramite l'archiviazione tabelle di Windows Azure. Ora è stato apportato un ulteriore miglioramento creando i dati in SQL Azure e facendo in modo che WCF in Windows Azure recuperasse i dati da tale posizione. In questo modo si ottiene effettivamente una famiglia di prodotti multi-cloud: Windows Azure, SQL Azure e (visibilmente) SharePoint Online. Lo scopo di questo post è semplicemente condividere alcuni suggerimenti per l'utilizzo di SQL Azure in modo da poterlo incorporare più rapidamente nei progetti di sviluppo.
Suggerimenti per l'integrazione
1. È assolutamente necessario effettuare l'aggiornamento a SQL 2008 R2 per poter aprire i database di SQL Azure con lo strumento SQL Server Management Studio. È possibile tecnicamente far funzionare SQL Server 2008, ma per ottenere questo risultato sarebbe necessario eseguire diverse operazioni complicate. Questa funzionalità invece è incorporata in SQL 2008 R2, che consente così di ottenere risultati ottimali. Se al contrario si desidera eseguire il processo che consente di utilizzare la versione 2008, accedere all'indirizzo seguente: https://social.technet.microsoft.com/wiki/contents/articles/developing-and-deploying-with-sql-azure.aspx. In questo articolo sono contenuti alcuni ottimi suggerimenti e pertanto è comunque consigliabile leggerlo, indipendentemente dalla scelta effettuata.
2. Prepararsi a utilizzare T-SQL per eseguire tutte le operazioni. Gli strumenti grafici non sono disponibili per l'utilizzo con i database, le tabelle e le stored procedure di SQL Azure. Dal momento che non sono esperto di T-SQL, si è rivelato utile creare innanzitutto un database di SQL Server locale. Nello strumento SQL Management ho creato due connessioni, una all'istanza locale di SQL e una all'istanza di SQL Azure. Nell'istanza locale di SQL ho creato tabelle, stored procedure e così via in modo da poter utilizzare gli strumenti grafici. Ho quindi utilizzato lo script [whatever Sql object] As…CREATE to…New Sql Query Window. In questo modo è stato generato lo script SQL per la creazione di oggetti personali che può essere incollato in una finestra della query aperta nel database di SQL Azure.
3. Questa indicazione è importante. La durata predefinita del timeout spesso non è sufficiente per connettersi a SQL Azure. È possibile modificarla se si utilizzano le classi .NET SqlClient nella stringa di connessione. Aggiungere ad esempio "Connection Timeout=30;". Se si utilizza SQL Server Management Studio, fare clic sul pulsante Avanzate nella finestra di dialogo in cui si immettono le credenziali e il nome del server e modificare l'impostazione specificando almeno 30. L'impostazione predefinita è 15 secondi e genera spesso errori, mentre 30 secondi sembra funzionare piuttosto bene. Non esiste purtroppo un modo per modificare l'impostazione del timeout di connessione per un tipo di contenuto esterno (ad esempio una definizione di applicazione BDC) a un'origine dati SQL Azure.
4. Non utilizzare l'account di amministratore di database per la connessione ai database (ad esempio l'account utilizzato per creare il database stesso). Creare un account separato per utilizzare i dati. SQL Azure purtroppo supporta solo gli account SQL e pertanto non è possibile utilizzare direttamente l'identità dell'utente richiedente per le decisioni sull'accesso ai dati. È possibile ovviare a questo problema utilizzando un'applicazione WCF come front-end dei dati in SQL Azure e utilizzando l'autenticazione basata sulle attestazioni in Windows Azure, il che corrisponde esattamente al modello utilizzato dal kit CASI. È inoltre necessario effettuare alcune operazioni per creare un account di accesso da utilizzare per connettere un database specifico ai dati. Viene riportato di seguito un esempio:
-create the database first
CREATE DATABASE Customers
-now create the login, then create a user in the database from the login
CREATE LOGIN CustomerReader WITH PASSWORD = 'FooBarFoo'
CREATE USER CustomerReader FROM LOGIN CustomerReader
-now grant rights to the user
GRANT INSERT, UPDATE, SELECT ON dbo.StoreInformation TO CustomerReader
-grant EXECUTE rights to a stored proc
GRANT EXECUTE ON myStoredProc TO CustomerReader
Per ulteriori esempi e dettagli, tra cui l'impostazione dei diritti a livello di server per gli account in SQL Azure, vedere https://msdn.microsoft.com/en-us/library/ee336235.aspx.
5. È necessario creare regole del firewall in SQL Azure per ogni database di cui si dispone in modo da consentire le comunicazioni da client diversi. Se si desidera consentire le comunicazioni da altri servizi Azure, è necessario creare la regola del firewall MicrosoftServices (operazione che può essere eseguita automaticamente da SQL Azure la prima volta che si crea il database), con un intervallo iniziale compreso tra 0.0.0.0 e 0.0.0.0. Se non si crea questa regola, nessuna delle applicazioni di Windows Azure sarà in grado di leggere, aggiungere o modificare dati dai database di SQL Azure. È consigliabile inoltre creare una regola del firewall per consentire le comunicazioni con qualsiasi server utilizzato per il routing a Internet. Se ad esempio si dispone di un router via cavo o DSL o di un server RRAS, è possibile utilizzare l'indirizzo esterno o l'indirizzo NAT per RRAS.
Questi suggerimenti dovrebbero consentire di creare dati immediatamente utilizzabili.
Accesso ai dati
Per l'accesso ai dati dal codice personalizzato, ad esempio WCF o web part di Windows Azure, si procede fortunatamente quasi esattamente come per il recupero dei dati da un computer SQL Server locale. Di seguito viene riportato un esempio di codice, di cui verranno illustrate alcune parti in dettaglio più avanti:
//set a longer timeout because 15 seconds is often not
//enough; SQL Azure docs recommend 30
private string conStr = "server=tcp:foodaddy.database.windows.net;Database=Customers;" +
"user ID=CustomerReader;Password=FooBarFoo;Trusted_Connection=False;Encrypt=True;" +
"Connection Timeout=30";
private string queryString = "select * from StoreInformation";
private DataSet ds = new DataSet();
using (SqlConnection cn = new SqlConnection(conStr))
{
SqlDataAdapter da = new SqlDataAdapter();
da.SelectCommand = new SqlCommand(queryString, cn);
da.Fill(ds);
//do something with the data
}
In realtà l'unico elemento che necessita di una spiegazione in questo esempio è la stringa di connessione. Gli elementi principali da evidenziare perché probabilmente diversi da una connessione tipica a un computer SQL Server locale sono i seguenti:
· server: anteporre "tcp" al nome del database di SQL Azure.
· Trusted_Connection: questo valore deve essere impostato su false poiché non si utilizza la sicurezza integrata.
· Encrypt: questo valore deve essere impostato su true per tutte le connessioni a un database ospitato nella cloud.
· Connection Timeout: come descritto precedentemente, il timeout predefinito è 15 secondi e spesso non è sufficiente. L'ho impostato su 30 secondi.
Un altro scenario che desidero menzionare brevemente è l'utilizzo della migrazione di dati. È possibile utilizzare lo strumento BCP fornito con SQL Server per spostare dati da un computer SQL Server locale a SQL Azure. La routine di base per la migrazione di dati è simile alla seguente:
1. Creare un file di formato. Verrà utilizzato sia per l'esportazione dei dati locali che per l'importazione dei dati nella cloud. In questo esempio verrà creato un file di formato per la tabella Region nel database Test e il salvataggio verrà effettuato nel file region.fmt.
bcp Test.dbo.Region format nul -T -n -f region.fmt
2. Esportare dati dal computer SQL locale. In questo esempio verrà esportata la tabella Region del database Test in un file denominato RegionData.dat. Verrà utilizzato il file di formato region.fmt creato al passaggio 1.
bcp Test.dbo.Region OUT RegionData.dat -T -f region.fmt
3. Importare dati in SQL Azure. È importante segnalare in questo scenario che l'importazione di dati nella cloud DEVE includere "@Nomeserver" con il parametro nome utente, altrimenti l'importazione avrà esito negativo. In questo esempio verranno importati dati nella tabella Region del database Customers in SQL Azure. L'importazione verrà eseguita a partire dal file RegionData.dat in cui sono stati esportati i dati locali. Il nome del server (parametro -S) è il nome del database di SQL Azure. Come nome utente (parametro -U) verrà utilizzato il formato nomeutente@nomeserver, come descritto precedentemente. Viene indicato di utilizzare il file di formato region.fmt creato al passaggio 1 e viene impostata una dimensione di batch (parametro -b) di 1000 record per volta.
bcp Customers.dbo.Region IN RegionData.dat -S foodaddy.database.windows.net -U speschka@foodaddy.database.windows.net -P FooBarFoo -f region.fmt -b 1000
Questo è tutto per il post. Mi auguro di aver illustrato in modo esaustivo il meccanismo di base per creare un database di SQL Azure, per connettersi a esso e per utilizzarlo nel sito di SharePoint. Come annotazione, segnalo di aver utilizzato il kit CASI per recuperare i dati tramite il front-end WCF di Windows Azure in SQL Azure ed eseguirne il rendering nel sito di SharePoint. Ho seguito il blog sul kit CASI per la creazione del kit in modo da provare e convalidare tutte le informazioni precedentemente pubblicate in esso ed è risultato tutto perfettamente funzionante. Ho apportato alcune correzioni di piccola entità nella parte 3 aggiungendo inoltre un'ulteriore sezione rapida sulla risoluzione dei problemi. Sono stati impiegati in tutto circa 30 minuti per creare un nuovo controllo personalizzato e probabilmente 15 minuti per creare una nuova web part visiva. Ho utilizzato la web part del kit CASI per visualizzare un set di dati di SQL Azure da WCF e nella web part visiva ho creato a livello di programmazione un'istanza del controllo personalizzato per recuperare un set di dati, che è stato quindi associato a una griglia ASP.NET. Tutti questi elementi sono stati raccolti in una pagina di esempio dall'aspetto gradevole, che può essere estesa senza difficoltà per la visualizzazione di dati in diversi modi. La pagina è simile alla seguente:
Questo è un post di blog localizzato. L'articolo originale è disponibile in Integrating SQL Azure with SharePoint 2010 and Windows Azure.