La forte integrazione presente tra Office 2003 e Sharepoint è ormai nota. Ma vi siete chiesti come ciò avviene praticamente ? Ecco svelato l'arcano: ... lo scambio di dati tra i due pacchetti software avviene attraverso dei web service, esposti da Sharepoint.
Questi servizi, 16 per Windows Sharepoint Services e 5 aggiunti da Sharepoint Portal, permettono di accedere a delle informazioni dall'esterno dei rispettivi ambienti, che in altro modo sarebbero inaccessibili; inoltre, in alcuni casi, questi possono essere interrogati da utenti con accesso anonimo (chiaramente almeno appartenenti al gruppo Reader del sito Sharepoint).
Tuttavia, le caratteristiche offerte da questi servizi, non coprono tutte le funzionalità proprie del modello ad oggetti di Sharepoint; per ovviare a questo problema, è possibile però creare dei propri web service, utili a colmare la maggior parte delle mancanze.
Ora, fermiamoci per un attimo e chiariamo un secondo una cosa: questo non vuole essere un articolo che spiega passo per passo il funzionamento di ogni web service (la cui lista può essere trovata sull'sdk); l'obbiettivo è invece quello di prendere un web service d'esempio, vedere quali sono le funzionalità offerte e quelle omesse, e infine cercare di implementare un servizio personalizzato in base alle nostre necessità.
Il web service preso in considerazione è il "Webs Service", ovvero il servizio che si occupa della gestione di siti Sharepoint. Questi i metodi esposti:
:: GetAllSubWebsCollection
:: GetListTemplates
:: GetWeb
:: GetWebCollection
:: WebUrlFromPageUrl
Un possibile utilizzo può essere quindi quello di stampare, all'interno di una web part, l'elenco dei sub-sites di un sito padre. Attenzione però. Sicuramente vi starete chiedendo di quale sito padre stiamo parlando. Ebbene, dovete sapere che i web service esposti da sharepoint vanno chiamati a seconda del sito da cui prelevare le informazioni. Quindi se chiamo il web service:
http://[server_name]/_vti_bin/webs.asmx
decido di prelevare informazioni riguardo il sito creato all'indirizzo: http://[server_name]. Se invece chiamo il web service:
http://[server_name]/sites/mioWeb/_vti_bin/webs.asmx
decido di prelevare informazioni riguardo il sito "mioWeb", creato sotto la sitecollection "sites".
Detto questo, vediamo come prelevare i sottositi del sito padre scelto, chiamando il metodo GetWebCollection.
Webs.Webs webs = new Webs.Webs();
webs.Credentials = CredentialCache.DefaultCredentials;
webs.Url = "http://<server_name>/sites/mioWeb";
XmlNode subwebs = webs.GetWebCollection();
foreach(XmlNode node in subwebs.ChildNodes)
{
string title = node.Attributes["Title"].Value;
string url = node.Attributes["Url"].Value;
}
Come possiamo notare, il metodo GetWebCollection ritorna un oggetto di tipo XmlNode, contenente un frammento di codice xml, dal quale possiamo prelevare nome e indirizzo di tutti i sottositi. Salta subito all'occhio il fatto che non mi trovo più ad avere a che fare con le API di Sharepoint, ma con informazioni in formato stringa, e decisamente limitate in confronto, per esempio, a ciò che è offerto da un oggetto di tipo SPWeb.
Proprio a causa di questo, ci perdiamo delle funzionalità parecchio utili; prima fra tutte la possibilità di farci ritornare solamente i siti in cui l'utente corrente abbia permessi, o la possibilità di vedere il tipo di template di ogni sottosito o, magari, il suo ID.
Per ovviare a queste mancanze, dobbiamo per forza implementare un web service personalizzato, che sfrutti nel modo più appropriato il modello ad oggetti di Sharepoint.
Questo il metodo GetSubWebsForCurrentUser che ho pensato di sviluppare. Il tipo di ritorno è sempre lo stesso (un oggetto di tipo XmlNode), e può essere letto con lo stesso codice visto prima; l'unica differenza, appunto, è che vengono ritornati solamente i siti Sharepoint in cui l'utente che fa la richiesta al web service ha diritti.
[WebMethod]
public XmlNode GetSubWebsForCurrentUser(string siteUrl)
{
XmlDocument doc = new XmlDocument();
doc.AppendChild(doc.CreateElement("Webs"));
try
{
SPWeb web = new SPSite(siteUrl).OpenWeb();
foreach(SPWeb childWeb in web.GetSubwebsForCurrentUser())
{
XmlNode childNode = doc.CreateElement("Web");
XmlAttribute name = doc.CreateAttribute("Name");
name.Value = childWeb.Title;
XmlAttribute url = doc.CreateAttribute("Url");
url.Value = childWeb.Url;
childNode.Attributes.Append(name);
childNode.Attributes.Append(url);
doc.DocumentElement.AppendChild(childNode);
}
}
catch(Exception exe)
{
throw new Exception(exe.Message, exe);
}
return doc.DocumentElement;
}
Ecco invece due metodi per ampliare ancora le funzionalità del nostro web service personalizzato. Il primo ritorna il nome del template utilizzato per la creazione del sito passato come parametro e il secondo ne ritorna l'ID:
[WebMethod]
public string GetTemplateName(string siteUrl)
{
SPWeb web = new SPSite(siteUrl).OpenWeb();
return web.WebTemplate;
}
[WebMethod]
public int GetTemplateID(string siteUrl)
{
SPWeb web = new SPSite(siteUrl).OpenWeb();
return web.WebTemplateId;
}
Dove installare il web service ?
Ok, una volta implementato il web service, vediamo che ubicazione assegnargli. Questa operazione, a mio parere, è la più importante di tutte. Questo perchè un'applicazione web che tenta di prendere informazioni da Sharepoint, per far si che essa funzioni, deve essere su di un web site IIS che abbia un Application Pool che giri con un utenza che ha permessi sui database di Sharepoint posti su Sql Server.
La cosa più immediata è quindi quella di inserire i file del web service all'interno di una nuova Virtual Directory posta sotto il sito IIS che gestisce Sharepoint; poiché gia quel sito ha un Application Pool che gira con le credenziali giuste per l'accesso al database. Fatto questo, bisogna aggiungere la nuova directory virtuale tra le "Unmanaged Path" di Sharepoint (raggiungibili seguendo questo percorso: Sharepoint Central Administration > Windows Sharepoint Services > Change Virtual Server General Settings > Unmanaged Path), in modo tale da poterne visualizzare le pagine ed evitare che queste vengano gestite direttamente da Sharepoint stesso (Es: se abbiamo deciso di chiamare la virtual directory "Webservices", basta inserire questo nome tra i percorsi esclusi).
Svolte queste operazioni, non ci rimane altro che consumare il nostro nuovo web service.
|
|
|