Contrôler la période d’affichage des éléments à la minute en KQL

Contrôler la période d’affichage des éléments à la minute en KQL


Note: Ce billet de blog est directement issu du module #5 de l’étude de cas sur la réalisation d’intranet avec le Cross Site Publishing disponible sur ce même site.


Dans un contexte de communication entre une entreprise et une audience cible (employés dans un contexte d’intranet ou grand public dans celui d’un site web), il peut être souhaitable d’avoir un contrôle précis sur le moment où seront affichés les informations et celui où elles seront retirées. De même, considérez tout simplement les périodes de vacances, il peut être intéressant de planifier la publication des futurs articles pour ne pas dépendre d’une action physique de l’utilisateur pour la mise en ligne et ainsi garder un rythme de publication constant.

Pour les pages et les documents, le contrôle de la période d’affichage est pris en charge nativement dans SharePoint via une fonctionnalité dédiée : la planification des éléments, disponible dans les options d’une bibliothèque:

Activation de la planification des éléments pour une bibliothèque

Activation de la planification des éléments pour une bibliothèque

Concernant les listes, la fonctionnalité de planification des éléments n’existe tout simplement pas ! Vous devrez ajouter les champs de « Date de début de publication » et « Date de fin de publication » manuellement à vos types de contenus et configurer les requêtes d’affichage en conséquence (CAML ou recherche). Cependant certaines limitations apparaissent dès lors que l’on souhaite s’appuyer sur la recherche SharePoint.

Limitations avec le langage KQL

La valeur des colonnes « Date de début de publication » et « Date de fin de publication » créée par la fonctionnalité de planification des éléments autorise un réglage à l’heure et la minute près, en plus de la date (format date et heure). Dès lors que l’on souhaite exploiter ces valeurs via la recherche SharePoint, certaines problématiques apparaissent :

Problématique #1 : Le type des propriétés gérées de recherche auto générées n’est pas le bon pour les dates

Par défaut, les propriétés de recherche générées automatiquement pour les colonnes « Date de début de publication » et « Date de fin de publication » sont de type « Texte » :

Les propriétés de recherche pour la planification par défaut sont de type "Texte"

Les propriétés de recherche pour la planification par défaut sont de type « Texte »

Or, le filtrage par date avec le langage KQL ne fonctionne qu’avec des propriétés gérées de recherche dont le type est « Date et Heure », comme le montre l’illustration suivante :

La recherche par dates nécessite des propriétés de type « Date et Heure »

La recherche par dates nécessite des propriétés de type « Date et Heure »

DateAndTime_ManagedProperties_Example

Notez que vous ne pouvez pas modifier le type de ces propriétés. Vous devrez la supprimer, puis la recréer avec le bon type et le même nom.

Problématique #2 : Le langage KQL ne permet pas un filtrage plus précis que la date

Si l’on se réfère à la documentation de référence sur la syntaxe du langage KQL, voici ce que l’on peut lire :

Syntaxe de dates supportées par le langage KQL

Syntaxe de dates supportées par le langage KQL

Ce que l’on oublie de vous dire, c’est que, certes ces formats sont reconnus dans les requêtes, mais que seule la date est considérée lors de l’exécution

Limitation du KQL pour le filtrage par date

Limitation du KQL pour le filtrage par date

Utilisation du FQL (Fast Query Langage)

Le seul moyen de filtrer au-delà de la date en utilisant la recherche SharePoint 2013 est d’utiliser le langage FQL (Fast Query Langage). En effet, ce langage permet bien plus de facéties au niveau des conditions de requêtes que son homologue. Attention toutefois : il n’est pas aussi accessible que ce dernier et nécessite une connaissance bien plus poussée de la recherche SharePoint. Disons-le clairement, le FQL, est avant tout une affaire de développeurs pour besoins bien plus complexes!

Pour les conditions impliquant des dates, le FQL fournit l’opérateur « range » :

range(start, stop [,from= »GE »| »GT »] [,to= »LE »| »LT »])

Les opérateurs internes s’appliquent de la manière suivante :

Opérateurs GE/GT et LE/LT de la condition « range »

Opérateurs GE/GT et LE/LT de la condition « range »

Voici plusieurs exemples de l’utilisation de l’opérateur « range », appliqués à l’exemple précédent (requête sur une seule propriété de date):

Éléments dont la valeur de la propriété est parfaitement égale à cette date

CustomStartDateOWSDATE:2015-07-24T18:00:00.0000000Z

Éléments dont la valeur de la propriété est supérieure ou égale à cette date

CustomStartDateOWSDATE:range(2015-07-24T18:00:00.0000000Z,max,from=ge)

CustomStartDateOWSDATE:range(2015-07-24T18:00:00.0000000Z,2015-07-24T18:00:00.0000000Z,from=ge) (Ne fonctionne pas)

Éléments dont la valeur de la propriété est inférieure ou égale à cette date

CustomStartDateOWSDATE:range(min,2015-07-24T18:00:00.0000000Z,to=le)

CustomStartDateOWSDATE:range(2015-07-24T18:00:00.0000000Z,2015-07-24T18:00:00.0000000Z,to=le)

CustomStartDateOWSDATE:range(2015-07-24T18:00:00.0000000Z,2015-07-24T18:01:00.0000000Z,to=le)

CustomStartDateOWSDATE:range(2015-07-24T18:01:00.0000000Z,2015-07-24T18:01:00.0000000Z,to=le) (Ne fonctionne pas)

Éléments dont la valeur de la propriété est strictement supérieure à cette date

CustomStartDateOWSDATE:range(2015-07-24T17:59:00.0000000Z,max,from=gt)

Éléments dont la valeur de la propriété est strictement inférieure à cette date

CustomStartDateOWSDATE:range(min,2015-07-24T18:01:00.0000000Z,to=lt)

Éléments dont la valeur de la propriété est comprise entre deux dates (incluses)

CustomStartDateOWSDATE:range(2015-07-24T18:00:00.0000000Z,2015-07-24T18:01:00.0000000Z,from=ge)

CustomStartDateOWSDATE:range(2015-07-24T17:59:00.0000000Z,2015-07-24T18:00:00.0000000Z,to=le)

Éléments dont la valeur de la propriété est comprise entre deux dates (exclues)

CustomStartDateOWSDATE:range(2015-07-24T17:59:00.0000000Z,2015-07-24T18:01:00.0000000Z,from=gt)

CustomStartDateOWSDATE:range(2015-07-24T17:59:00.0000000Z,2015-07-24T18:01:00.0000000Z,to=lt)

Pour pouvoir utiliser le langage FQL, deux solutions s’offrent à vous:

1ère solution : activer explicitement le FQL dans la requête de recherche

Pour cela, il vous faudra suivre les étapes suivantes :

  1. Configurer une source de résultats de recherche selon cette procédure. Notez bien que vous avez bel et bien deux possibilités distinctes pour configurer votre source de résultats (un peu ambiguë dans la documentation)
  1. Activer le support du FQL dans l’objet KeywordQuery via la propriété « EnableFQL» avant de faire votre requête (valable pour SSOM, REST ou CSOM).

Avantages

Inconvénients

  • Utilisation exclusive du FQL permettant les requêtes de recherche complexes.
  • Nécessite obligatoirement du développement. Il n’est pas possible d’utiliser FQL via l’interface des  WebParts par défaut (l’option EnableFQL n’existe pas).
  • Solution un peu « overkill » pour simplement faire un filtre par période de dates à la minute près…

Astuce: Débogage de requêtes FQL en utilisant l’outil « Search Query Tool » :

Configuration du « Search Query Tool » pour les requêtes FQL

Configuration du « Search Query Tool » pour les requêtes FQL

  1. La requête est au format FQL sans guillemets
  2. La requête est faite à partir d’une source de résultat ayant le FQL d’activé
  3. L’option « EnableFQL » est activée

2ième solution : utiliser les affinements de recherche en plus de la requête principale KQL

Les affinements de recherche de SharePoint 2013 ont la particularité de fonctionner nativement avec le langage FQL. Couplés à du KQL, ils permettent ainsi de préciser un peu plus la requête initiale.

Avantages

Inconvénients

  • Les sources de résultats peuvent rester en KQL facilitant la manipulation et surtout la compréhension pour la plupart des humains.
  • Nécessite du développement pour la construction de l’affinement de recherche.

Pour permettre le filtrage des éléments à la minute près dans le portail en utilisant la recherche, nous avons opté pour cette solution. La raison est simple : s’étant aperçus de ce problème en cours de projet, nous ne voulions pas remettre en question toute la définition des sources de résultats de recherche juste pour satisfaire cette contrainte.

Notre solution consiste donc à étendre les possibilités des Web Parts de recherche par défaut de SharePoint 2013 pour leur permettre de supporter ce cas. Le code complet de cette fonctionnalité est disponible à l’adresse suivante :

GitHub Reposidget for WordPress

GSoft-SharePoint / Dynamite-SearchWebPartsWithFineScheduling

Provides enhanced OOTB search web parts allowing you to do accurate time scheduling using FQL search refinements

DISCLAIMER: il ne s’agit ici que d’un exemple qui n’est pas destiné à être déployé en production

Fonctionnement pour les Web Parts de recherche

SearchWP

Pour les Web Parts « Recherche de contenu » et « Résultats de recherche », nous avons ajouté deux propriétés personnalisées dans les options disponibles.

Celles-ci permettent de définir les propriétés gérées de recherche à utiliser pour déterminer la période d’affichage (début et fin). Leur valeur correspond directement à celle entrée par l’utilisateur lors de la création d’un élément dans un catalogue.

En arrière, une fonction se charge de construire dynamiquement le filtre de recherche FQL à partir de la date courante puis de l’appliquer en tant qu’affinement de la requête KQL principale.

Voici le détail du fonctionnement des Web Parts :

1. Construction des affinements de recherche par rapport à la date courante :

2. Utilisation de la propriété « FallbackRefinementFilters» de la Web Part pour l’application après la requête KQL principale :

3. Enregistrement de fonction dans le OnLoad() de la Web Part pour être exécutée avant que les résultats soient présentés aux utilisateurs :

Problématique avec le Web Part d’affinements de recherche

Avec cette solution, un problème survient assez rapidement : lorsque l’utilisateur affine sa recherche via la Web Part de raffinement par défaut, le filtrage de date est tout simplement effacé et la requête réinitialisée, ce qui conduit à voir des éléments qui ne sont, en théorie, pas encore publiés…

La cause en est simple : lors d’un affinement de recherche manuel, il n’y a aucun POSTBACK sur la page et donc pas le calcul du filtre de la période d’affichage, le code des Web Parts étant exécuté en « code-behind » dans le OnLoad().

Voici ce que nous avons fait pour remédier à ce problème;

  1. Le Web Part possède encore deux propriétés personnalisables permettant de spécifier les propriétés gérées de recherche à prendre en compte pour la période (début et fin)
  1. Un modèle d’affichage (« Display Template ») adapté, récupère ces propriétés depuis le Web Part en JavaScript :
  1. Une fonction dédiée permet d’appliquer un affinement de recherche via CSOM :
  1. La fonction est appelée lors d’une clique sur l’élément correspondant au filtre d’affinement et y ajoute les conditions d’affinements par dates :
Remarque importante!

Étant donné que le filtrage est au niveau des Web parts eux-mêmes, l’application des affinements se fait en mode « tout ou rien ». Si vous les utilisez, vous devez alors être certains que les types d’éléments retournés possèdent bel et bien les métadonnées de dates configurées dans les Web parts. Dans le cas contraire, vous ne les verrez jamais!

+ There are no comments

Add yours