Partie 4: L’accès à l’information : le nerf de la guerre

Partie 4: L’accès à l’information : le nerf de la guerre


If you can’t explain it simply, you don’t understand it well enough.

Albert Einstein

Aperçu de l’article

Notions clés

SharePoint propose une multitude de composants pour afficher et interagir avec l’information. Cependant, tous n’utilisent pas les mêmes technologies et il est important de les comprendre car elles conditionneront la plupart de vos choix futurs dans la plateforme.

Je vais tenter dans ce chapitre de vous expliquer les forces en présence, leurs avantages et leurs inconvénients et surtout les cas d’utilisation où elles se prêtent le mieux.

Langage de recherche

 Langage CAML

 


Comment SharePoint accède-t-il à ses données?

En premier lieu, il est important de préciser que la méthode d’accès à l’information déterminera pratiquement tous vos choix de solutions dans SharePoint. En effet, dans SharePoint comme dans toutes les applications, l’information est au centre de tout.

L’aspect le plus important de toute architecture d’information est sa capacité à accéder facilement aux données. En ce sens, une architecture d’information non optimale peut être responsable des difficultés des utilisateurs à retrouver l’information dans un portail SharePoint.

Cependant, il faut garder à l’esprit que toute architecture d’information est intimement liée aux mécanismes d’accès qu’offre le système de stockage de données sur lequel s’appuie notre application. Celle-ci doit donc être adaptée en conséquence. Par exemple, toute application qui utilise une base de données relationnelle voit son accès à l’information limité par le langage propre à celle-ci (SQL, la plupart du temps) et les contraintes inhérentes.

La même situation se produit dans SharePoint. Bien que SharePoint soit déjà un produit en soi, il est toujours nécessaire de faire une architecture d’information et surtout, d’en comprendre les mécanismes sous-jacents.

Par la suite, vous verrez que la plupart des choix que vous faites dans SharePoint sont conditionnés par les possibilités d’accès à l’information qu’offre l’outil. C’est la base de toute application dans SharePoint, il est essentiel de bien la comprendre.

La recherche, le nouveau « buzz word »

Avant de se pencher plus en détails sur la méthodologie à proprement parler, il est important de survoler les nouveautés de SharePoint 2013. Depuis que cette version est disponible sur le marché, un fort accent a été mis sur la recherche, celle-ci est devenue peu à peu le mot à la mode quand on parle de SharePoint dans sa version 2013. Il n’y a qu’à regarder sur Internet pour voir bon nombre d’articles traitant des nouvelles fonctionnalités de recherche et les façons dont elles fonctionnent (qui a dit « Content Search WebPart » ou « Product Catalog »?). Ces informations sont très enrichissantes,  une fois que l’on sait pourquoi on veut les utiliser !

En réalité, la recherche est une des méthodes d’accès à l’information que propose SharePoint et celle-ci existe depuis bien longtemps.

N’oublions pas une chose, la recherche est un moyen d’accéder à de l’information et donc de répondre à un besoin, au même titre qu’un autre moyen. Tout est une question de cas d’utilisation et de besoin. Je vous invite à lire la suite du document avant de vous précipiter dans la lecture d’articles plus techniques sur le sujet.

La vraie avancée de SharePoint 2013 à ce niveau est qu’il rend accessible ce moyen (auparavant un peu obscur) aux super utilisateurs, leur permettant de l’exploiter désormais de manière autonome et efficace (par le biais de nouveaux assistants par exemple).

Cependant, je ne doute pas que plusieurs d’entre vous n’ont pas attendu 2013 pour utiliser le potentiel de la recherche de SharePoint dans leurs applications 😉

L’accès à l’information dans SharePoint

Il existe plusieurs moyens fondamentaux d’accéder à l’information dans SharePoint qui peuvent être regroupés en deux modèles de requêtes distincts:

  • Le langage de requête structurée
  • Le langage de recherche

Voici un schéma présentant le principe appliqué à SharePoint :

Méthodes d'accès à l'information en SharePoint

Chacun de ces deux langages est adapté à une ou plusieurs situations dans SharePoint et il s’agit de déterminer le bon langage pour le bon usage. C’est ce que nous allons voir par la suite.

À propos des autres langages (REST Query API, LINQ, etc…), il est important de noter que la requête finale exécutée dans SharePoint sera toujours en SQL et par conséquent, en langage de requête structurée. C’est  pour cette raison que je n’en fais pas mention ici, préférant mettre l’accent sur leurs différences.

Les langages de requête structurée

Lorsqu’il est question de langage de requête structurée, on entend bien sûr SQL, et par conséquent la technologie SQL Server, sur laquelle est basé SharePoint pour le stockage de ses données. Cependant, il est important de noter que Microsoft n’autorise pas l’utilisation des requêtes SQL par les tiers. C’est d’ailleurs une raison de perte de support du produit. Dans la plupart des cas, un langage de surcouche à travers des composants WebParts (en mode « Out Of The Box »), communément le CAML  – (Collaborative Application Markup Language), et son schéma de requête, sera utilisé.

Note : Il existe d’autres schémas CAML mais celui qui nous intéresse est bien celui qui nous permet d’accéder à de l’information dans SharePoint, à savoir le schéma de requête. L’important ici n’étant pas de détailler les bases du langage CAML, mais plutôt de comprendre son fonctionnement et surtout, ses limitations et avantages.

En langage de requête structurée, c’est comme si vous accédiez directement aux éléments d’une table dans une base de données relationnelle, ce qui a comme avantage d’exposer la dernière version des éléments stockés au moment de la requête.

En d’autres termes, votre requête vous offre un résultat représentant la réalité de l’élément dans SharePoint à l’instant où vous le récupérez. Par exemple, c’est ce langage qui est utilisé quand vous visualisez des éléments dans une liste ou une bibliothèque dans SharePoint ou que vous configurez le WebPart de requête de contenu.

Maintenant, avec ce langage, et pour accéder à vos éléments, il est impératif de se plier au formalisme classique de type SQL, à savoir:

  • Champs à récupérer
  • Conditions de récupération
    • Champs de conditions
    • Opérateurs
    • Valeurs de conditions
  • Formatage des résultats

Pour bien comprendre ce mécanisme, voici un exemple de requête en langage CAML faite sur une source de données (une liste SharePoint par exemple) :

Voici ce que donnerait cette requête en SQL:

Pour que vous visualisiez mieux la chose, imaginez que vous vouliez faire un filtre sur une colonne de liste SharePoint:

Filtre sur une liste SharePoint classique

 

La requête sous-jacente sera de la forme CAML vue plus haut.

À noter qu’en CAML, la requête doit porter sur une source de données précise (une liste ou une bibliothèque SharePoint au sein de la même collection de sites). C’est comme si vous requêtiez sur une table SQL (de manière extrapolée n’est-ce pas ;)).

Alors maintenant, pourquoi savoir cela? En réalité, ce qu’il faut retenir de ce principe est qu’il est impératif de connaitre le nom du ou des champs sur lequel(s) votre requête porte.

Vous voyez peut être où je veux en venir : imaginons que je veuille récupérer les documents qui contiennent « toto » dans n’importe quelle de leurs métadonnées.

Je vais devoir faire une requête incluant toutes les métadonnées correspondant au type de ce document avec la valeur que je veux tester et l’opérateur adéquat. Il s’agit d’une grosse requête pour accomplir une tâche minime. Tout cela, sans compter sur les limitations des opérateurs du CAML.

En revanche, ce principe a pour avantage de permettre la récupération des relations entre les éléments facilement. En effet, les données sont structurées dans une base de données relationnelle où les sources sont liées entre elles par des clés primaires et étrangères. Vous pouvez par exemple observer ce principe quand vous configurez les connexions entre WebPart dans une page SharePoint.

Cet exemple sert à démontrer que le langage de requête structuré n’est pas adapté à la récupération d’éléments par mots clés en général, du fait de la limitation induite par le langage lui-même.

Si l’on souhaite réaliser des requêtes de ce type, il va falloir se tourner vers le deuxième moyen d’accès à l’information dans SharePoint : la recherche.

Les langages de recherche

La recherche SharePoint, à la différence des langages de requête structurée, se base sur un index et non une base de données relationnelle. Cela change fondamentalement l’approche de requête, qui n’est plus basée sur la connaissance exacte des champs représentant la donnée, mais plutôt sur un contenu agrégé la décrivant.

Un index contient aussi bien des données provenant des bases de données relationnelles de SharePoint que des informations provenant d’autres types de source de contenu, par exemple des systèmes de fichiers.

Un bémol subsiste toutefois : pour que les éléments soient accessibles par ce mécanisme, il est impératif qu’ils soient insérés dans un index par le biais de ce qu’on appelle le crawler (opération d’indexation). En d’autres termes, votre requête vous offre un résultat ne représentant pas nécessairement la réalité de l’élément dans SharePoint à l’instant où vous le récupérez mais celle de cet élément dans l’index de recherche. Par exemple, dans le cas d’un nouvel élément, il apparaitra seulement après qu’il ait été inséré dans l’index.

De plus, contrairement au langage de requête structuré, SharePoint ne fournit aucun mécanisme pour mettre en relation des éléments par le biais de la recherche, en partie à cause des contraintes inhérentes au langage lui-même, qui se base sur des données non structurées.

En revanche, l’avantage majeur de ce type de mécanisme est la flexibilité de requête qu’il offre. Il ne vous lie plus avec le nom des champs obligatoirement et vous permet de récupérer des éléments sur la base de mots clés. C’est ce que l’on appelle de la récupération d’éléments en « Free text ». Il est toutefois possible, à la manière du langage de requête structuré, de requêter sur un ou plusieurs champs spécifiques.

Il existe plusieurs langages se basant sur les mécanismes de recherche, KQL (Keyword Query Langage),FQL (FAST Query Langage) ou SQL (Search Query Langage) (à ne pas confondre avec celui de SQL Server!). Cependant, dans la plupart des cas, vous serez amenés à utiliser le premier (KQL) pour sa simplicité d’utilisation, les deux autres étant plus spécifiques.

Voici un exemple de requête en langage KQL :

<Propriété> <Opérateur> <Valeur>  <Opérateur> <Propriété> <Opérateur> <Valeur>  …

À noter que contrairement au CAML, la source de données cible sera systématiquement l’index global de recherche SharePoint et qu’il n’est pas possible de contrôler les propriétés à récupérer depuis la requête en KQL.

Alors dans quel cas utiliser quoi?

Maintenant que nous connaissons les moyens d’accéder à l’information dans SharePoint et la façon dont ils fonctionnent, abordons les cas dans lesquels ils sont les plus adaptés tout en faisant un résumé des différences majeures (avec également quelques exemples) :

 

Langage de recherche

Langage de requête

Avantages

 Ne nécessite pas de connaitre le nom des champs dans lesquels rechercher l’information.

 Facilité de construction des requêtes

 Représente la réalité SharePoint des éléments accédés à l’instant de la requête.

 Permet de récupérer des éléments liés facilement.

Inconvénients

 Représente la réalité de l’index des éléments accédés à l’instant de la requête et non la réalité dans SharePoint.

 Nécessite de définir chaque champ impliqué dans la requête.

Adapté à

 Accès par mots clés en « Free Text »

 Accès à du contenu relativement statique.

 Accès à des métadonnées ciblées

 Accès à du contenu sujet à des modifications continuelles.

Cas d’utilisation

 Référentiel documentaire

 Annuaire d’entreprise

 Tableaux de bord sur des données collaboratives

Pour la suite de cette série, j’aborderai des spécificités clés à prendre en compte pour ces deux mécanismes d’accès à travers la méthodologie proposée.

+ There are no comments

Add yours