Preset refinements when calling a SharePoint 2013 search results page

In a recent SharePoint 2013 publishing portal project for a customer, we had to use a content query web part to display news on an intranet portal. The news elements are all of the same content type which contains a taxonomy field used to specify the type of news. In the CQWP, the news are grouped by type and the customer wanted a link with «View all the XYZ news» for each group. Considering the many requirements, the way we did it was to link to a search page and to preset the refinement web part to automatically filter on the type of news.

The query string syntax for the refinement is a bit weird since it’s actually a JSON request that is URL encoded but once decoded it looks like this:

/Pages/results.aspx?k=YOUR_SEARCH_TERM#Default={"k":"YOUR_SEARCH_TERM","r":[{"n":"MANAGED_PROPERTY_NAME","t":["string(\"#GUID_FOR_THE_TERM_VALUE\")"],"o":"and","k":false,"m":null}]}

To use this solution, it means we have to get the term’s GUID for each type of news inside the CQWP’s XSLT. The main problem is that the taxonomy field only returns the name of the term, not its GUID.

We could have hardcoded the GUIDs but since our development process include deployment across many development environments, that wasn’t really doable (MMS term’s GUID are generated by SharePoint i.e. different for each environment). After a bit of thinking and searching, what we ended up doing was to access the hidden note field associated with every taxonomy field (something along the lines of «TaxonomyFieldName_0»). When called in a CQWP, the hidden field returns a string in the «term value|term GUID» format. Once we found that out, a simple string manipulation, URL encoding and some basic XSLT gave us the result we wanted. The result is something along the lines of:

<xsl:variable name="newsTypeGuid">
	<xsl:value-of select="substring-after(@TaxonomyFieldName_0,'|')" />
</xsl:variable>

<xsl:variable name="newsTypeUrl">
	<xsl:value-of select="concat('/Pages/results.aspx?k=%2A_YOUR_SEARCH_TERM_#Default=%7B%22k%22%3A%22_YOUR_SEARCH_TERM_%22%2C%22r%22%3A%5B%7B%22n%22%3A%22_MANAGED_PROPERTY_NAME_%22%2C%22t%22%3A%5B%22string(%5C%22%23', $newsTypeGuid, '%5C%22)%22%5D%2C%22o%22%3A%22and%22%2C%22k%22%3Afalse%2C%22m%22%3Anull%7D%5D%7D%0A')" disable-output-escaping='yes'/>
</xsl:variable>

<a href="{$newsTypeUrl}"><xsl:value-of select="@TaxonomyFieldName" /></a>

I really hope it helps / saves some time to someone!

 

* Il est assez rare que je publie des articles en anglais. Vu le caractère plutôt technique du billet courant j’ai choisi de faire cette publication dans la langue de Shakespeare pour simplifier le vocabulaire et afin de rejoindre un maximum de développeurs.

Advertisements

Développement SharePoint… sur Amazon!?!

Les solutions pour mettre en place des environnements de développement SharePoint sont multiples. Avec quelques collègues, nous avons récemment réfléchi pour trouver une solution abordable et flexible. Voici quelques critères que nous avons identifiés :

  • permet d’avoir autant d’environnements SharePoint que nécessaire;
  • permet d’avoir accès à un domaine central (pas attaché à l’une ou l’autre des machines de développement);
  • avoir un coût mensuel raisonnable;
  • ne nécessite pas l’installation de serveurs physiques;
  • est performante;
  • disponible partout;
  • ne nécessitant pas d’avoir une machine physique très performante (et très lourde dans le cas d’un portable).

Après avoir analysé les diverses pistes de solution, Metalogique a décidé d’opter pour une infrastructure dans le cloud basée sur l’offre d’Amazon. Dans un premier temps, nous avons mis en place un VPC permettant d’avoir un réseau privé dans le cloud d’Amazon et de permettre la communication entre les diverses machines par leur interface réseau privé. Ensuite j’ai fait l’installation d’un contrôleur de domaine et d’un serveur TFS en utilisant des instances EC2 de petite taille. Ces deux serveurs roulent 24/7 et sont suffisamment performants pour notre équipe d’une dizaine de développeurs.

Ensuite, chaque développeur peut gérer sa (ou ses) machine de développement SharePoint. La configuration initiale de celle-ci est entièrement scriptée et prend moins d’une heure. On utilise des instances r3.large (6.5 ECU, 15GB ram) qui sont très performantes et relativement économiques (0.30$ / h incluant Windows et SQL Express). Il est aussi très facile d’augmenter la capacité d’une instance dans le cas où cela serait nécessaire.

Un seul problème avec cette solution. Si les machines de développement roulent 24/7, on paie entre trois et quatre fois trop cher car les employés ne les utilisent que 7-8h par jour. À moins de donner l’accès à tous les employés à la console de gestion Amazon (avec tous les droits sur le compte), il est impossible pour un développeur d’arrêter ou de démarrer son instance à la demande.

Encore une fois, la solution est assez simple. J’ai développé une application web MVC .NET utilisant le SDK AWS .NET afin de se connecter au compte AWS de Metalogique et de présenter au développeur uniquement les machines lui étant assignées (en utilisant les tags). Le développeur n’a qu’à se connecter à l’application MVC, et démarrer ou arrêter sa machine au début ou à la fin de sa journée de travail.

Il serait également possible d’automatiser le démarrage ou la fermeture des instances selon un horaire prédéfini, mais la solution actuelle convient à nos besoins pour le moment.

Depuis l’implantation, la solution fonctionne très bien. La performance est intéressante, on peut se connecter en RDP aux machines de n’importe où, le coût est accessible à une PME, pas besoin de faire l’entretien de serveurs physiques, plus besoin de trainer un portable de 15lbs (vive les ultrabooks) et ça peut fonctionner avec d’autres applications (j’ai récemment créé une instance Linux pour un collègue en mandat).

Je vous invite à me contacter si vous avez des questions ou des commentaires. Si l’intérêt est là, je ferai un autre billet sur les aspects plus techniques de la configuration.