Nintex Workflow Platform Preview for SharePoint 2013

Una delle novità introdotte nella Wave 15 di Office (client e server) è il concetto delle App e del relativo marketplace, o App store che dir si voglia. In questo momento non voglio però parlare di aspetti tecnici o di strategia (per questo vi rimando al blog del team dedicato e questi due video introduttivi, uno e due), quanto del fatto che Nintex abbia già rilasciato (e non è l’unica, date voi stessi un occhiata allo store), a pochi giorni dalla disponibilità della beta pubblica, una prima Platform Preview di Nintex Workflow per SharePoint 2013 (faq e condizioni del servizio).

App Store

E’ bene precisare che non si tratta di una beta della prossima versione del prodotto, ma un prototipo “cloud-based” (hostato su Windows Azure) che dimostra il grande lavoro di ricerca e sviluppo portato avanti da Nintex.

Le azioni disponibili in questa platform preview sono le activity out-of-the-box disponibili in SharePoint Designer 2013 e le azioni basate su servizi nel cloud erogati tramite Nintex Live. Per questa versione non è prevista alcuna forma di supporto, se non quello “volontario” offerto tramite i forum di Nintex Connect.

Nintex Worklow Platform Preview App

Purtroppo non sono ancora riuscito a toccare con mano questa app nella mia VM di test a causa di un “fastidioso” errore (Sorry, apps are turned off…) che, vista l’ora, cercherò di risolvere nei prossimi giorni (so, stay tuned :)).

Nel frattempo visto che il modello delle app è disponibile tanto on-premises che nel cloud proverò ad installare la Platform Preview di Nintex Workflow per SharePoint 2013 nell’ambiente di test del nuovo Office365.

A presto per le prime impressioni 😉

– Riccardo

Annunci

Refinement Panel: errore nel link Show more

Poche settimane fa sono incappato in un problema a dir poco “curioso”. Cliccando sul link “show more” nel refinement panel di una pagina dei risultati di ricerca personalizzata, al posto di mostrare un numero più ampio di scelte, non succedeva proprio niente.

Refinement Panel

Controllando con la developer toolbar ho notato l’errore di script seguente (The value of the property “SearchEnsureSOD” is null or undefined, not a Function object).

L’errore mi è sembrato molto strano, perchè XSLT e CSS a parte avevo solo rimosso la web part relativa al box di ricerca.

Dopo una breve ricerca ho scoperto che il punto è proprio questo. Senza la Search Box Web Part (o analgo controllo in master page) viene sollevata questa eccezione.

A questo punto mi sono incuriosito e ho cercato nel mio piccolo di approfondire un pò l’argomento. La prima cosa che ho notato analizzando le chiamate http della pagina con Fiddler è stata che con la web part in pagina vengono caricati due file javascript in più, il search.js e ajaxtoolkit.js.

Fiddler Results

Controllando l’output della pagina ho inoltre notato che, oltre a non effettuare la chiamata al file search.js, nella versione della pagina senza box di ricerca (web part o controllo non fa differenza) mancano una serie di funzioni javascript.

HTML

A pensarci bene avrei potuto fare un’altro paio di verifiche, ad esempio richiamare “a mano” il file search.js dal page layout, peccato non mi sia venuto in mente prima, maybe next time 🙂

SearchEnsureSOD(-Riccardo)


Operation caused a stack overflow

Qualche settimana fa, preparando una demo su FAST Search for SharePoint 2010, ad un certo punto alcune delle web part della pagina dei risultati della ricerca (search refiner e core result web part) hanno cominciato ad andare saltuariamente in errore. L’errore era il “classico” Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

L’errore, comune quando si commette un errore nella personalizzazione dell’XSLT di una Data Form Web Part, mi è parso molto strano a causa del fatto che non avevo affatto modificato i template XSLT di quelle Web Part.

Verificato il Correlation ID con le informazioni presenti nel ULS log ho trovato questo messaggio:

Error while executing web part: System.StackOverflowException: Operation caused a stack overflow.
at Microsoft.Xslt.NativeMethod.CheckForSufficientStack()
at <xsl:template match=”Result”>(XmlQueryRuntime , XPathNavigator )
at <xsl:apply-templates>(XmlQueryRuntime , XPathNavigator )
at <xsl:template name=”dvt_1.body”>(XmlQueryRuntime , XPathNavigator )
at Root(XmlQueryRuntime )  … (continua)

La causa di questo errore era nota da qualche tempo a Microsoft, di fatto se la trasformazione dei template XSLT impiega più di 1 secondo viene sollevata questa eccezione. Nel mio caso, date le risorse della VM, questo era assolutamente possibile, ma in vista della demo con il cliente dovevo assolutamente risolvere l’errore.

A partire dalla Cumulative Update di Febbraio 2012 è stato aggiunto un nuovo metodo grazie al quale, tramite Powershell, è possibile aumentare il timeout. E’ sufficiente uno script di tre righe, eccolo:

$farm = Get-SPFarm
$farm.XsltTransformTimeOut = 5
$farm.Update()

Data la soluzione, vale la pena comunque soffermarsi sulle motivazioni che portano a questo errore, cioè verificare attentamente le performance della farm e  revisionare i propri template XSLT.

– Riccardo


Aggiornare campi publishing images con Powershell

Di recente ho avuto l’esigenza di aggiornare tutti i valori di un campo di tipo “publishing images“. Anche se non si trattava di un numero esagerato di immagini ho provato a cercare un alternativa, trovo che l’update di questi campi da UI sia infatti molto “noioso”. L’alternativa è ovviamente Powershell :).

Ho scoperto che bastano verametne poche righe per completare l’operazione e, soprattutto, lo stesso script contiene tanti spunti utili in molti altri scenari.

Ma veniamo al dunque. Cominciamo a memorizzare nelle “solite” variabili gli oggetti site collection e web.

$spSite = Get-SPSite http://sharepoint
$spWeb = $spSite.RootWeb

Tocca ora all’elenco che contiene le immagini da aggiornare.

$spList = $spWeb.Lists[“Links”]

A questo punto, facendo un ciclo su tutti gli elementi dell’elenco, memorizziamo nella variabile $image il campo PublishingPageImage. Trattandosi di un tipo di dato “complesso” la nostra variabile avrà diverse proprietà. Una di queste è ImageUrl che contiene le informazioni relative al path dell’immagine.

Nel mio caso l’aggiornamento prevedeva il campio di origine dell’immagine mentre il nome del file doveva rimanere invariato. Di conseguenza ho aggiornato la proprietà ImageUrl sostituendo il vecchio path con quello corretto. Per questa operazione ho utilizzato l’operatore replace.

In un primo momento pensavo che questo, seguito solo dal comando $listitem.Update(), bastasse per aggiornare le mie immagini, ma mi sbagliavo. A questo punto abbiamo aggiornato solo una proprietà dell’oggetto ed è quindi necessario reimpostare correttamente il valore del nostro campo. Il codice di esempio della pagina su MSDN mi è stata molto utile per capire questo passaggio.

foreach($listitem in $spList.Items){
$image = $listitem[“PublishingPageImage”]
$image.ImageUrl = $image.ImageUrl -replace “/SiteAssets/”, “/SiteCollectionImages/”
$listitem[“PublishingPageImage”] = $image;
$listitem.Update()
}

Alla fine dello script rilasciamo l’oggetto “web” e abbiamo finito.

$spWeb.Dispose()

Potete scaricare lo script qui.

Happy Posh
– Riccardo


Modifica e test del server SMTP con Powershell

Chissà perchè nel passaggio 2007 > 2010 Microsoft non abbia ritenuto di mettere a disposizione una cmdlet per la configurazione del server di posta in uscita (SMTP), corrispondente al vecchio comando stsadm -o email. Technet riporta infatti ancora lo stesso comando (http://technet.microsoft.com/en-us/library/cc263462.aspx) e anche nella pagina relativa ai mapping stsadm / Powershell (http://technet.microsoft.com/en-us/library/ff621084.aspx) non si trova corrispondenza.

Questo non signifca però che non si possa fare, bastano poche righe 🙂

Prima di tutto memorizzo i dati da configurare all’interno di quattro variabili.

$smtpServer = ‘mail.sharepoint.corp’
$smtpFrom = ‘admin@sharepoint.corp’
$smtpReplyTo = ‘admin@sharepoint.corp’
$smtpCharset = 65001

In una nuova variabile memorizzo l’oggetto “Web Application” corrispondente alla Central Administration*.

$caWebApp = Get-SPWebApplication -IncludeCentralAdministration | ?{ $_.IsAdministrationWebApplication }

e utilizzo infine il metodo UpdateMailSettings di questo oggetto per configurare il server di posta in uscita.

$caWebApp.UpdateMailSettings($smtpServer, $smtpFrom, $smtpReplyTo, $smtpCharset)

* Dato che la configurazione del server SMTP può essere personalizzata per Web Application basterà selezionare la web application desiderata al posto della Central Administration per modificarne la configurazione.

Una volta apportata la modifica al server di posta è consigliabile effettuare un test per verificare che tutto funzioni a dovere. Anche per questo possiamo usare poche righe di Powershell. Tramite il metodo SendMail dell’oggetto SPUtility (http://msdn.microsoft.com/en-us/library/ms477270.aspx) invieremo un email sfruttando la configurazione SMTP di un sito SharePoint. Più facile a farsi che a dirsi.

$web = Get-SPWeb “http://intranet
$sent = [Microsoft.Sharepoint.Utilities.SpUtility]::SendEmail($web,$false,$false,”riccardo@sharepoint.corp”,”Oggetto del messaggio”,”Corpo del messaggio”)

La variabile $sent assumerà il valore di True o False a seconda che l’invio del messaggio riesca o meno. Semplice no?

– Riccardo


Elencare tutti gli utenti Site Collection Administrator (con Powershell)

Navigando tra i thread dei forum dedicati a SharePoint su Technet spesso incontro domande che stimolano la mia curiosità. E’ successo anche oggi quando un utente chiedeva come poter ottenere un elenco di tutti gli utenti site collection administrator per poter inviare loro un e-mail. Il punto non era tanto l’invio della mail quanto il poter ottenere una lista di utenti e indirizzi e-mail.

Utilizzando Powershell l’operazione risulta molto semplice:

Get-SPWebApplication | Get-SPSite -Limit All | ForEach-Object{
Get-SPUser -Web $_.URL | ?{$_.isSiteAdmin -eq “$true” -and $_.Email -ne “”} | select DisplayName, Email
}

Questo script cicla tutte le Site Collection di tutte le Web Application della farm selezionando gli utenti Site Collection Administrator con un indirizzo e-mail e ne mostra Display Name e E-mail. Volendo potremmo completare il tutto esportando i nostri dati utilizzando la cmdlet Export-Csv, ottenendo quindi:

Get-SPWebApplication | Get-SPSite -Limit All | ForEach-Object{
Get-SPUser -Web $_.URL | ?{$_.isSiteAdmin -eq “$true” -and $_.Email -ne “”} | select DisplayName, Email | Export-Csv C:\temp\SiteCollectionAdministrators.csv
}

Beat the Heat
– Riccardo


FAST Search e Powershell ISE

Anche durante l’installazione e la configurazione di FAST Search for SharePoint 2010 Powershell ha un ruolo molto importante. Al pari di SharePoint 2010 anche FAST Search ha la sua shell e proprio come sua “sorella” in alcuni casi è un pò limitativa. Perciò, lavorando su SharePoint uso molto spesso Powershell ISE aggiungendo come prima cosa il/lo/la snap-in Microsoft.SharePoint.Powershell con il comando seguente:

Add-PSSnapin Microsoft.SharePoint.Powershell

Anche per quanto riguarda FAST Search, bisogna fare lo stesso, ma aggiungendo ovviamente il/lo/la snap-in corrispondente, cioè:

Add-PSSnapin Microsoft.FASTSearch.Powershell

Beat the Heat
– Riccardo