Posts tagged MOSS

Credo che con questo titolo abbia tirato in ballo molte più cose di quelle che una normale mente umana possa in qualche modo gestire attraverso l’interconnessione incestuale di neuroni nella materia grigia. E’ vero anche che una delle prime lezioni del mio prof di Informatica alla superiori, sui word processor mi illuminò a tal punto da farmi innamorare immediatamente di questa materia,  attraverso l’enuciazione delle seguenti verità di fede:

• Non tutto quello che si vede sul video viene riportato su carta nel processo di stampa;
• Il peso in byte di un documento a parità di parole contenute nel testo varia a seconda di quante tabulazioni esso contiene;
• Non riuscirete ma a spiegare il vostro lavoro a vostra suocera;

I primi due punti per farvi capire quanto sia lontana la definizione di *applicazione* se posizionata trasveralmente ai software commerciali, quindi quanto sia affascinante un lavoro per il quale c’è sempre spazio per posizionare differenze, siano esse funzionali o applicative, appunto. L’ultimo punto l’ho aggiunto io ed è altrettanto vero!

Cosa c’entra SharePoint con tutto questo? Quasi nulla, solo non mi andava di scrivere un post serioso, quindi ho cazzeggiato un pò!

Passiamo ora invece alla comprensione di alcune particolarità architetturali di MOSS, la cui consapevolezza, credo vi possa fare comodo in situazioni di disegno ed implementazione di una architettura medio-grande.

L’argomento, come avete capito è *Site Collection* e quando si parla di queste entità siamo al punto del non ritorno o almeno dovremo iniziare a parlare di Site Collection dopo che il problema scalabilità sia stato affrontato in maniera seria dal nostro reparto IT.

SPSite VS SPWeb

Oramai siamo abituati al concetto di Site Collection, per i dev SPSite che rappresentano l’insieme di Site (per i dev SPWeb) di cui condividono la root. La root di un SPSite è a suo stesso tempo un Site (Root Web). Le Site Collection possono avere dei settings ma non dei documenti o liste di alcun tipo. Ogni SPSite può contenere n SPWeb.

Web Application & Content DB

Nell’attuale versione di MOSS ogni SPSite è associato ad una Web Application ma non è sempre vero il contrario, cioè ogni Web Application può ospitare più SPSite. La stessa relazione che hanno le Site Collection con le Web Application la ritroviamo nei relativi database di configurazione.

Attenzione, molti per comodità dicono che ogni Web Application può avere un solo contenet db: vero (solo in parte). Questa spiegazione, comunque non è esplicativa, infatti dal paragrafo sopra si intuisce (spero) che ogni Web Application può ospitare più Site Collection e se è vero che ogni Site Collection può avere un proprio content db, allora si arriva al punto di dire che: ogni instanza di webapplication ha un proprio content db nel quale saranno inseriti i contenuti di tutte le Site Collection che sceglieranno di convidere lo stesso content db, se altrimenti non specificato.

Affermato questo, ci rendiamo conto di quanto SharePoint in scenari architetturali medio-grandi sia un prodotto *abbastanza* scalabile, dico abbastanza in quanto fino a che non risolvono il vincolo di una architettura NLB e per di più con l’index server che passeggia per i cavoli suoi, non possiamo dire che sia scalabile su tutti i fronti … anzi sarebbe ancora meglio se dalla prossima versione tutti i servizi fossero clusterizzabili cosi da predisporre un ambiente, dal punto di vista architetturale pienamente rispondente a requisiti di scalabilità e fault tollerance.

 Managed paths

Come facciamo a creare più Site Collection per una Web Application? La risposta è nell’utilizzo dei managed paths! Non so se ve ne siete mai resi conto ma le più comuni managed paths che utilizziamo sono essenzialmente due:

• http://myserver/ (root)
• http://myserver/sites/ (sites)

Non perchè ci stiano particolarmente simpatiche ma perchè sono quelle di default. Normalmente un SPSite può essere creato dalla root della Web Application in cui ha il riferimento oppure utilizzando una lista di managed paths che possiamo anche personalizzare. Da *Central Administration\ Application Management\Define Managed Paths* possiamo scegliere quali managed paths utilizzare per la gestione delle Site Collection interne alla FARM ed eventualmente crearne altre di due tipi:

• Wildcard inclusion, rappresenta un path *sotto* al quale possiamo creare n Site Collection. Se proviamo ad accedere direttamente da browser al managed path avremo una pagina di errrore. provate ad accedere direttamente a http://myserver/sites ne rimarrete a bocca sciutta (come si dice in questi casi).
  • http://myserver/sites/departmentA
  • http://myserver/sites/departmentB
• Explicit inclusion, rappresenta il path puntuale nel quale sarà creata la Site Collection. Se proviamo ad accedere direttamente da browser al managed path, previa estensione della Site Collection, accederemo al sito root.
  • http://myserver/departmentA
  • http://myserver/departmentB

In definitiva quando SharePoint riceve un url in entrata, scandisce le varie Site Collection parsando l’uri ed effettuando un check nella lista di managed path che abbiamo utilizzato. Molto importante è sapere che una managed path può contenere anche chiavi di valore molto estese, infatti si possono creare dei managedpath del tipo (sites/ departments) ed anche (sites/ departments/ areas). Dato un url non si può definire manualmente a quale Site Collection corrisponde il path a cui si cerca di accedere, tutto viene gestito internamente da SharePoint.

Managed Path & Content DB

Utilizzando una architettura basata sulla differenziazione tra managed path (SPSite) e content db si può raggiungere un alto livello di scalabilità e risolvere parecchi problemi dovuti al size dei vari DBs coinvolti e dal numero di SPWeb che possono esistere all’interno di un’unica Site Collection. Un utile articolo per capire di ciò di cui si sta parlando è il Plan for performance and capacity di MOSS 2007.

Abbiamo visto come differenziare la gestione di >1 Site Collection per ogni Web Application, vediamo ora come effettuare la gestione separata anche per i content db. Per una nuova Site Collection a cui si desidera associare un nuovo content db, ci vien utile in questo caso utilizzare il comando stsadm nel modo seguente:

   1: stsadm -o createsiteinnewdb 

   2:        -url http://myserver/sites/departmenta 

   3:        -owneremail suocerca@cucina.com 

   4:        -ownerlogin DOMAIN\FarmAdmin

   5:        -databaseserver DBServer 

   6:        -databasename departmentA-Content-DB

Le ultime due istruzioni che di norma sono opzionali, in questo caso ci permettono di implementare una politica di diversificazione per ogni Site Collection che si andrà a creare.

Object Model

In questo specifico caso l’OM di SharePoint si comporta in maniera confusionale, non rispetta a mio personale avviso una corretta implementazione della sintassi del costrutto dell’oggetto SPSite. Di seguito condivido alcune linee guida per non incappare in errori che vi faranno perdere nottate intere svegli davanti al PC!

Per essere maggiormente esplicativo vi pongo un esempio: ipotizziamo di aver creato un managed path per la Web Application (http://myserver) del tipo Explicit Inclusion con il nome di (departmentA). La root della Web Application è già stata estesa e contiene un SPWeb dal nome (office1), quindi avremo la seguente situazione:

• http://myserver (SPSite)
• http://myserver/office1  (SPWeb)
• http://myserver/departmentA (SPSite)

ed abbiamo la necessità di creare un sito nell’ultima Site Collection dal nome (office1). Nella logica ci aspettieremo un risultato del tipo:

• http://myserver/departmentA/office1 dove http://myserver è un SPSite come del resto anche http://myserver/departmentA ed in ultimo http://myserver/departmentA/office1 come SPWeb.

Utilizzando gli oggetti messi a disposizione da MOSS notiamo che l’ultima Site Collection su cui creare il sito (office1) dovrà essere trattata come Root Web, quindi essere inizializzata come un SPWeb! Altrimenti non potremo creare il sito (office1) in quanto risulterebbe già esistente nella Site Collection Root della Web Application. Tutto questo per il semplice motivo, molto errato, di gestione dei managed path a livello di OM.

Di seguito un esempio corretto di aggiunta del un nuovo sito. Non ho aggiunto commenti ed ulteriori controlli, credo che il codice sia auto esplicativo. L’unica cosa impostante da notare sta nel modo in cui viene gestito il controllo della presenza o meno dell’oggetto SPWeb all’interno dei webs di *_web* che in questo caso rappresenta l’oggetto site della root della Site Collection. Controllare la presenza di sub webs del sito della root è un modo per non incappare nella tentazione di credere che l’oggetto SPSite inizializzato in precedenza sia in grado di posizionarsi automaticamente nella seconda Site Collection del path: http://myserver/departmentA.

   1: static  void CreateSite(string url, string title)

   2:         {

   3:         using (SPSite site = new SPSite(url))

   4:         {

   5:            site.AllowUnsafeUpdates = true;

   6:            using (SPWeb _web = site.OpenWeb())

   7:             {

   8:                 _web.AllowUnsafeUpdates = true;

   9:                 if (_web.Webs[title].Exists)

  10:                 {

  11:                     return;

  12:                 }

  13:                 using (SPWeb web = _web.Webs.Add(title))

  14:                 {

  15:                     web.Title = title;

  16:                     web.Update();               

  17:                 }

  18:                 _web.AllowUnsafeUpdates = false;

  19:             }

  20:             site.AllowUnsafeUpdates = false;

  21:         }

  22:        }

  23:     }