Nuove CU per SharePoint 2007 e 2010

La scorsa settimana Microsoft ha rilasciato nuovi cumulative updates (October 2010 CU) per SharePoint 2007 (WSS e MOSS) e SharePoint 2010 (SPF, SharePoint Server e Project Server). Di seguito trovate i link alle pagine di descrizione delle kb relative a questi aggiornamenti.

  • KB 2412268 – WSS 3.0
  • KB 2412267 – MOSS 2007
  • KB 2394323 – SharePoint Foundation 2010
  • KB 2394320 – SharePoint Server 2010
  • KB 2394322 – SharePoint Server 2010 con Project Server

Ed ecco anche i link per scaricare i pacchetti completi delle CU di ottobre 2010:

Oltre a ricordare la consueta dose di prudenza e cautela nell’installazione di questi update, che ricordo essere relativi alla correzione di problemi specifici descritti nelle rispettive kb, ricordo anche che per SharePoint Server 2010 è sufficiente installare i soli pacchetti di SharePoint Server in quanto sono già comprensivi degli update per SharePoint Foundation.

Consiglio anche di aggiungere ai preferiti il link al centro aggiornamenti relativo alla famiglia di prodotti Office e Office Server.

Happy patching :)

– Riccardo

Aggiornamento per Nintex Workflow 2007

Penso che ormai tutti, chi più chi meno, abbiate sentito parlare di Nintex Workflow.

Nintex ha rilasciato già da qualche mese la nuova versione del prodotto per SharePoint 2010, Nintex Workflow 2010. In realtà non è su questa versione più recente di cui voglio parlare, ma di quella precedente: Nintex Workflow 2007.

Proprio questo lunedì Nintex ha rilasciato un nuovo aggiornameto del prodotto (versione 1.11). La prima nota è relativa ai contenuti di questa nuova build. Le principali innovazioni a mio avviso sono relative all’interfaccia utente. Finalmente, anche sulla versione 2007, sarà possibile ingrandire o rimpicciolire l’are di workflow designer grazie a funzionalità di zoom-in / zoom-out e stampare l’intero flusso senza dover ricorrere ad arti orientali della manipolazione della carta :)

Sono state introdotte anche 4 nuove activity per l’integrazione con Microsoft Dynamics CRM (Query, Create, Update e Delete CRM records) più una quinta, Get Meeting Suggestions, che si aggiunge alle activity di integrazione con Microsoft Exchange.La pubblicazione della nuova build è arricchita inoltre da diverse migliorie apportate ad alcune activity di workflow e ai tool di sviluppo e amministrazione.

In questo momento è disponibile solo la versione inglese di questo update, ma è già programmata per fine Settembre la pubblicazione degli aggiornamenti localizzati nelle diverse lingue.

Una seconda ed ultima nota, se volete più futile, riguarda il fatto che mi ha fatto piacere notare che nonostante Nintex abbia una nuova versione già in commercio, lo sviluppo sulla “wave 2007” prosegua. Sicuramente non è solo una questione “etica”, è quasi sicuramente pura logica di mercato visto l’alto numero di farm SharePoint 2007 “up and running”. Dal mio punto di vista è un (altro) punto a favore di Nintex :).

Nel caso in cui non conosceste Nintex Workflow o anche solo per un approfondimento l’indirizzo è http://www.nintex.com.

– Riccardo

SharePoint Web Services e DataForm

In molte occasioni, in mancanza di altri mezzi, mi è capitato di utilizzare i web services di SharePoint per la visualizzione di dati cross site collection o cross farm. Se a qualcuno dovesse suonare nuovo quello che ho scritto si tratta di utilizzare i vari servizi che si trovano nella virtual directory _vti_bin di ciascun sito SharePoint e sfruttare uno dei metodi messi a disposizione come data source (XML Web Services) di una Data Form Web Part. Uno di questi servizi è lists.asmx, uno dei suoi metodi GetListItems (es. http://www.ilmiosito.it/_vti_bin/lists.asmx?op=GetListItems).

L’utilizzo di questo tipo di origine dati nasconde però molte insidie (che qualcuno chiama “configurazioni” :)). Vediamo alcuni dei parametri che devono essere compilati e come:

  1. listName [Obbligatorio]: il nome è parlante, si tratta del nome (nome visualizzato) della lista da cui si vogliono leggere i dati;
  2. viewName [Opzionale]: in questo caso il nome trae in inganno, non si tratta del nome della vista, ma del suo GUID. Ci interessa? Eccome! Tramite l’impostazione di questo valore possiamo scegliere quali dati saranno visibili nella dataform, con quali filtri e in che ordine. In pratica ci permette di spostare la logica di selezione ed ordinamento dei dati sulla visualizzazione e non sulla query, dall’interfaccia grafica e non da SharePoint Designer. In teoria ci sarebbe un parametro specifico per ciascuna di queste funzionalità, ma in pratica non sono mai riuscito ad utilizzarli (mancanza mia? bug? Più probabile la prima, ma è da molto che regolarmente faccio dei tentativi, tutti vani…). Se non impostato viene considerato come valore di default la visualizzazione predefinita;
  3. rowLimit [Opzionale]: Permette di specificare il limite di elementi da selezionare. Mooolto importante dal mio punto di vista in quanto sovrascrive il limite impostato nella visualizzazione specificata in precedenza. Ad esempio, se la vostra visualizzazione ha un limite di 100 elementi visualizzati potrete impostare quì un valore molto più alto, per essere certi che vengano mostrati tutti i dati. Da quello che ho potuto constatare, per quanto riguarda il limite di elementi nella visualizzazione, non si tratta di un valore assoluto, ma anche del valore di elementi per pagina. Di conseguenza, per evitare di correre il rischio di avere visualizzazioni con un numero eccessivo di elementi trovo importantissimo valorizzare questo parametro.Questa caratteristica non è un bug, ma è dovuto al fatto che il metodo GetListItems supporta la pagina lato server. Oggi ho scoperto (mio malgrado) un’altra caratteristica che deriva da questo parametro, cioè che anche per i campi di lookup pare valga la stessa logica. Mi spiego: tra i dati che visualizzo è presente una colonna di tipo lookup. La lista di riferimento di questo metadata ha più di 100 elementi e nella visualizzazione di default è impostato proprio questo limite di elementi per pagina. Bene (‘nsomma), nella mia dataform venivano visualizzati solo i dati di lookup presenti nella prima paginazione. In questo caso ho dovuto scegliere la strada più veloce, modificare cioè le impostazioni sulla vista, ma sicuramente in un momento di maggiore calma provvederò a correggere i parametri della dataform;
  4. WebId [Opzionale]: Se valorizzato permette di ridefinire lo scope di azione del servizio, agendo cioè su siti differenti da quello utilizzato per la connessione;

Ho omesso da questo elenco quei parametri che mi hanno sempre causato errori (query, viewFields, QueryOptions). Nel caso dovessi riuscire nei prossimi giorni sarò più che lieto di farvelo sapere :)

-Riccardo

XSLT e comparazione tra date

Di recente un’amica mi ha chiesto se, e come, fosse possibile gestire una sorta di scadenza degli elementi visualizzati in un DataForm utilizzando XSLT. La necessità è quindi quella di verificare che la data impostata come scadenza in un custom metadata sia maggiore dell’ora attuale. Mi aspettavo che una banale comparazione tra date funzionasse correttamente, si tratta in fondo di data type uguali (in teoria…), ma anche no.

E’ necessario normalizzare le date nel formato che più ci conviene. Prima cosa ottengo la data (ed ora) corrente utilizzando l’estensione ddwrt:TodayIso() e memorizzo il valore in una variabile.

<xsl:variable name="cheoresono" select="ddwrt:TodayIso()"></xsl:variable>

A questo punto creo altre due variabili nelle quali memorizzo le due date da paragonare “trasformate” in un valore numerico. L’obbiettivo è quello di ottenere una stringa del tipo 201007261734 (YYYYMMAAHHmm) – @TEST è la mia colonna di tipo Data e ora:

<xsl:variable name="testconverted" select="number(concat(substring(string(@TEST),1,4), substring(string(@TEST),6,2), substring(string(@TEST),9,2), substring(string(@TEST),12,2), substring(string(@TEST),15,2)))" />
<xsl:variable name="cheoresonoconverted" select="number(concat(substring($cheoresono,1,4), substring($cheoresono,6,2), substring($cheoresono,9,2), substring($cheoresono,12,2), substring($cheoresono,15,2)))" />

A questo punto posso effettuare il confronto delle due date con il semplice xsl:if

<xsl:if test="$testconverted &gt; $cheoresonoconverted">@TEST è maggiore di questo momento (secondi esclusi)</xsl:if>

Non volendo inserire all’interno del template XSL questo tipo di filtro (forse più utile per formattazione condizionale che per filtro) potrei applicarlo allo stesso modo nella query XPath presente nella dataview all’interno del template dvt_1: 

<xsl:variable name="cheoresono" select="ddwrt:TodayIso()"></xsl:variable>
<xsl:variable name="cheoresonoconverted" select="number(concat(substring($cheoresono,1,4), substring($cheoresono,6,2), substring($cheoresono,9,2), substring($cheoresono,12,2), substring($cheoresono,15,2)))" />
<xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row[number(concat(substring(string(@TEST),1,4), substring(string(@TEST),6,2), substring(string(@TEST),9,2), substring(string(@TEST),12,2), substring(string(@TEST),15,2))) &lt; $cheoresonoconverted]"/>

Per quanto riguarda XSLT è tutto. E per quanto riguarda CAML… (traggo spunto da una maglietta di mio figlio che raffigura la Banda Bassotti) Maybe Next Time :)

-Riccardo

– UPDATE –

Con Barbara abbiamo scoperto un comportamento “strano” di ddwrt:TodayIso(). In alcuni ambienti questa funzione mostra data e ora della time zone GMT, nel nostro caso quindi risulta indietro di due ore. Per risolvere questo “problema” basta memorizzare la variabile cheoresono già formattata utilizzando l’estensione ddwrt:FormatDate(ddwrt:TodayIso(),1040,5). Una volta fatto questo bisogna solo prestare attenzione a modificare i parametri della funzione substring utilizzata nella conversione della data in formato AAAAMMGGHHmm.

Ringrazio ovviamente Barbara per avermi fatto notare questo comportamento :)

Formattazione condizionale nei page layout (o quasi)

L’argomento di questo post è un piccolo trick da cui spero possiate prendere spunto per le più disparate varianti. Partiamo come sempre dal descrivre l’esigenza: formattare diversamente un elemento di un page layout a seconda del valore di un page field. In questo esempio andremo a cambiare lo stile del titolo della nostra pagina a seconda del valore di un page field visibile unicamente in fase di edit della pagina.

Abbiamo quindi (almeno) due page field: Titolo – single line of text – e Categoria – choice -. In base al valore di Categoria il titolo avrà caratteristiche (font, colore, dimensioni, ecc…) differenti.

Per prima cosa inserisco nel page layout un elemento HTML (div) che conterrà il valore del page field di controllo.

<div id=”valoreCategoria” style=”display: none”>
<SharePoint:FieldValue FieldName=”Categoria” runat=”server” />
</div>

Definisco quindi la posizione nel page layout del titolo della pagina.

<div id=”titoloPagina” class=”Default-Style”>
<SharePoint:FieldValue FieldName=”Title” runat=”server” />
</div>

Subito dopo aver definito questo elemento richiamo la funzione JavaScript che si occuperà della modifica dello stile del testo.

<script language=”javascript” type=”text/javascript”>CambiaStile();</script>

Immagino che a questo punto abbiate già capito cosa fa questa funzione, i passaggi sono semplici:

  1. Selezione del contenuto dell’elemento “valoreCategoria”
    1. var myDivContent = document.getElementById(“valoreCategoria”).innerText
  2. Impostare in base al valore della variabile myDivContent la classe CSS dell’elemento “titoloPagina”
    1. switch (myDivContent){
    2. case “Categoria 1”:
    3. document.getElementById(“titoloPagina”).style.className = “Categoria1-Style”;
    4. break;
    5. case “Categoria 2”:
    6. document.getElementById(“titoloPagina”).style.className = “Categoria2-Style”;
    7. break;
    8. default:
    9. document.getElementById(“titoloPagina”).style.className = “Generico-Style”;
    10. }
  3. Voilà! :)

Questo come ho già detto è un piccolo trick, non applicabile a tutte le esigenze di formattazione condizionale, e soprattutto è un esemepio che se utilizzato in ambienti di produzione deve essere ottimizzato, sia dal punto di vista della compatibilità browser (FireFox non mi pare supporti innerText ad esempio), ma soprattutto dal punto di vista delle performance. La mia intenzione in questo caso è solo quella di farvi accendere qualche lampadina :)

– Riccardo (virtualmente in nave verso la Sardegna…)