[GREENPOINT#1] STSADM Extension: gp-getalloc
Inizia la serie "vera" (le premesse le potete leggere qui).
Vi illustro brevemente il primo "artifact" che trovate in GreenPoint.
E' una custom extension per STSADM che abbiamo mostrato (molto rapidamente) alla SharePoint Conference.
Un po' di ordine :-)
STSADM
Non credo abbia bisogno di presentazioni, è *il* tool di amministrazione di SharePoint da riga di comando. Ok, è altro, se lo vogliamo vedere dal punto di vista architetturale/developer. Ma per ora accontentiamoci. Anche perchè possiamo scrivere delle...
STSADM Extensions
Sono classi .NET che implementano l'interfaccia Microsoft.SharePoint.Administation.ISPStsadmCommand, definendo quindi i metodi GetHelpMessage e Run.
Condizione, questa, necessaria ma non sufficiente a renderle utilizzabili "come fossero" operazioni out-of-the-box.
La condizione numero due è che il sistema sia reso edotto della loro presenza.
Occorre semplicemente distribuire in [12]\CONFIG un file xml, con i seguenti requisiti:
- Sintassi opportuna :-)
- Nome rispondente ad un pattern preciso: stsadmcommands.*.xml (dove * deve essere sostituito da un identificatore univoco
Provare per credere :-)
Questo il link ad un breve tutorial su MSDN.
gp-getalloc
L'esempio che trovate su CodePlex è realizzato con un duplice obiettivo:
- Illustrare le genericità di una custom extension
- Essere utile anche a chi le extension non le scrive, ma le usa :-)
Tipicamente, nel momento in cui si iniziano a sviluppare extension, l'appetito vien mangiando e il refactoring è il dolce a fine pasto :-) Si estrae una classe di base che esponga funzionalità di validazione dei parametri o helpers di contesto, si astrae la generazione dell'help message, ...
In questo caso la custom extension è "nuda", cosa significativa forse solamente a scopo didattico... ma almeno così si vede bene che "non c'è trucco, non c'è inganno".
Utile, si diceva, forse anche senza doverne per forza ispezionare il codice.
Eseguendo stsadm -o gp-getalloc (ehm... eseguendo il deploy della extension e poi stsadm!!) la console suggerisce i parametri di invocazione:
GREENPOINT Extensions: Get Storage Allocation
(Display the storage space for the specified files)
Parameters:
-url (the url of the web site)
[-user] (a string which contains the user display name)
[-outputFile] (the file you want your output to be stored in)
gp-getalloc ritorna all'utente (in standard output o, se specificato, anche memorizzando un outputFile su file system) un documento XML che descrive lo spazio allocato dai documenti delle document library di un sito. Quello che segue è un frammento generato sulla mia macchina di sviluppo:
<?xml version="1.0" encoding="utf-8"?>
<Allocation Web="http://spdemo.devlizard.inc/areas/sb" User="none" Space="4684274" Files="120">
<Web Title="Site Builders" Url="http://spdemo.devlizard.inc/areas/sb" Space="231523" Files="72">
<List Name="Converted Forms" Space="0" Files="0" />
<List Name="Form Templates" Space="0" Files="0" />
...
<Web Title="Virtual Earth" Url="http://spdemo.devlizard.inc/areas/sb/dataviews/virtualearth" Space="22665" Files="2">
...
</Web>
</Web>
</Allocation>
L'esecuzione prosegue in maniera ricorsiva, riportando lo spazio occupato per ogni sottosito e, ovviamente, i totali ad ogni livello, memorizzati come attributi della struttura XML restituita in output.
La versione attuale *non* tiene in conto il versioning (aspettatevelo in una prossima release) e non discrimina tra library "utente" e library di sistema (master page gallery, data sources, ...).
Ma è già uno strumento mediamente indicativo :-)
(continua...)
Prossimamente su questi schermi: custom fields e utilities :-)