Ne avevo parlato come novità annunciata ad Ignite 2017, e annunciata qualche mese fa come terminata nelle fasi di sviluppo. Ecco finalmente in arrivo i nuovi HUB Sites di Office 365.

Il rilascio partirà, già entro la fine di marzo, partendo come sempre dai Tenant Office 365 che aderiscono all’opzione “Targeted Release” (ossia alla possibilità di ricevere in anteprima le nuove funzionalità), per completarsi per tutti i clienti Office 365 verso metà maggio 2018.

Questa nuova funzionalità potrà giocare un ottimo ruolo nella riorganizzazione dei siti SharePoint Online e della progettazione dell’architettura delle informazioni delle intranet o dei sistemi Office 365.

Oltre al mio post, dove annunciavo la funzionalità, segnalo un paio di video (il primo è introduttivo del concetto ed il secondo è un webinar più esteso):

Una delle più classiche critiche/osservazioni verso il proliferare di site collection e siti su SharePoint Online è quella dell’assenza di una vera e propria “Site Directory”, soffrendo poi delle difficoltà di rendere coerente il branding e la navigazione, di fatto separati nelle diverse site collection.

In molti caso abbiamo costruito delle pagine con delle search result, filtrando l’esecuzione della query sugli oggetti sito, creando così una bella lista… rispettosa delle autorizzazioni, ma non sempre semplice da utilizzare per un’eccessiva “piattezza”.

Office 365 sta per rilasciare i nuovi HUB Sites.
Si tratta di nuovi siti “concentratori”, pensati per aggregare siti e site collection, offrendo loro un look & feel e una navigazione comune.

Il meccanismo sfrutta anche le logiche di “classificazione” offerte dai nuovi modern sites, creando di fatto una categorizzazione per aggregare i siti associati ad un Hub site comune.

Alcune delle raccomandazioni suggeriscono di evitare la gestione di site collection con livelli multipli di subsites, cercando di conservare una struttura il più possibile flat.

I nuovi Hub Sites, come tutti i nuovi modelli “modern”, garantiranno una buona responsività, adatta per fruizione da mobile, sia attraverso browser che SharePoint mobile app.

Si prospetta quindi un’importante novità in arrivo per chi progetta architetture dell’informazione su SharePoint Online, alla quale è bene porre attenzione sin da ora.
Alcune ulteriori indicazioni sono già note:

• un sito potrà essere associato ad un solo Hub Site (e non a più di uno)
• il meccanismo aggregherà siti moderni (Modern Team Sites, Communication Sites), mentre per i Classic Site occorrerà fare un giro un po’ più articolato, ma sarà possibile aggregare anch’essi… a patto di create Modern Pages anche in essi (su questo scriverò sicuramente qualche suggerimento in futuro)
• l’Hub Site determinerà una navigazione comune tra i siti, un tema e un logo unico, un solo search scope, opportunità di rollup di contenuto, …
• un Hub site non potrà collegarsi (o essere collegato) da un altro Hub Site
• i nuovi Hub Site saranno rilasciati solo su Office 365, e non è ancora noto se saranno introdotti come funzionalità anche su SharePoint Server 2019 (che verrà rilasciato verso la fine del 2018)

I nuovi Hub Sites sono attualmente in Preview, e si prevede il rilascio pubblico nella prima metà del 2018.

Non mi stanco mai di ripetere che prima di creare qualsiasi cosa su SharePoint (site collection, web, library, lista…) è indispensabile analizzare e progettare “la struttura dei contenitori”.

Questo argomento rientra nel grande tema dell’Architettura dell’Informazione, e deve fare i conti con le limitazioni del prodotto. In particolare quando si parla di Software boundaries.

Si tratta di temi fondamentali in fase di progettazione e capacity planning.

Mi capita troppo spesso di incontrare architettura mal (o per niente) progettate presso i clienti che incontro, dove interi sistemi documentali sono realizzati in un’unica Site collection o –ancora peggio (ma giuro che è vero)- in un’unica Document library!

Desidero riprendere su questo post un paio di “grandi classici”.

Mai solo una Site collection…

Disporre di una sola Site collection significa far nascere il sistema con un limite di scalabilità sullo storage (e sulle performance). Una solo Site collection significa poter disporre di un massimo di un solo Content DB…

Le best practices di Microsoft suggeriscono di non oltrepassare i 200 GB nella crescita del singolo Content DB (anche se personalmente, per ragioni di migliore gestibilità, tendo a suggerire valori molto al di sotto).
Una sola Site collection == Un solo Content DB == Crescita massima 200 GB.

Nelle tante decine di infrastrutture SharePoint analizzate posso dirvi che il limite dei 200 GB l’ho visto più volte superare (ne ho trovati cresciuti fino a 500 GB!), e SharePoint “respirava ancora”… ma questo non significa poter ignorare le buone pratiche.

Non far crescere fuori controllo le liste/library

Una lista o library dispone di un limite fisico di crescita di 30 milioni di elementi. Tuttavia è ben noto il tema del List Threshold, che impone la progettazione dei contenitori e l’organizzazione dei contenuti tenendo conto che SharePoint non gradisce effettuare query su grosse quantità di elementi.
Il valore di default del List Threshold limita ai primi 5.000 items l’esecuzione delle query degli utenti (20.000 items per gli amministratori).

Rimando chi non avesse ancora afferrato il problema alla lettura dell’articolo di Claudio Brotto.

E’ troppo comodo, oltre che sbagliato, intervenire a posteriori sui settings dei Lists Threshold per “risolvere il problema” (nei giorni scorsi ho trovato una Web Application con impostato il valore a 10,5 milioni!).

Il problema non è il fatto che la lista contiene più di 5.000 oggetti, ma il vero problema è che qualcuno non l’ha progettata bene!
Se si prevede una crescita del numero degli oggetti… mai pensare a una sola lista/library, ragionare con logiche di frazionamento degli scopes in folder (magari utilizzando i nativi meccanismi di Autofoldering), ed infine pensare anche alle logiche archiviazione/storicizzazione: i contenuti non sempre ha senso conservarli tutta la vita.

E su SharePoint Online?

Se qualche sviluppatore o sistemista poco attento può anche cercare di riuscire ad eludere parte dei vizi di progettazione, intervenendo con modifiche delle impostazioni della Farm, su SharePoint Online… ci sono poche speranze.

Sapete bene che sull’ambiente Office 365 le nostre Site Collection convivono su un’infrastruttura SharePoint condivisa con altri clienti (tenant). Di conseguenza molte delle impostazioni che su una Farm On-premises sono definibili intervenendo sui server o agendo sulle impostazioni delle Web Application… possiamo scordarcele.

I 5.000 items come limite di list threshold ad esempio? E’ quello, punto e basta.

Non fraintendetemi, non intendo con questo dire che è meglio non usare SharePoint Online… voglio semplicemente dire che avendo a che fare con Office 365 è ancora più importante conoscere i limiti del prodotto e progettare bene.

A proposito, ecco il link ai limiti di SharePoint Online (pagina che ogni tanto viene aggiornata da Microsoft, come è avvenuto nei mesi scorsi innalzando alcuni valori).