Guide relatif aux contenus d’aggrégation des portails SharePoint Online

Chaque création de portail inclut une suite de composants d’affichage qui localisent dynamiquement du contenu pour les afficher sur les pages du portail. Le concept lié à cette opération de ces contrôles consiste au concept de l’agrégation du contenu que, à des fins de cet article, nous définissons en tant que processus pour localiser le contenu souhaité de manière dynamique au moment de l’exécution. La technique utilisée pour exécuter l’agrégation de contenu peut avoir une incidence significative sur les performances de votre portail et les pages de celui-ci.

Ce qu’il ne faut surtout pas faire

La liste suivante contient les éléments clés pas à suivre si vous souhaitez avoir une bonne expérience d’agrégation de contenu.

À ne pas faire :

• Utiliser la méthode d’agrégation de contenu en temps réel chaque fois que cela est possible. et où cela est possible.
• Placer une douzaine de contrôles d’agrégation de contenu ou plusieurs contrôles mal conçues sur une page du portail en volume élevé (par exemple, la page d’accueil).
• Utiliser un Objet de Stratégie de Groupe (GPO) pour forcer tous les navigateurs à charger de la page du portail problématique par défaut.
• Ne pas appliquer des limites de ligne dans les résultats d’agrégation de contenu.
• Ne pas cacher des résultats d’agrégation de contenu.
• Cibler le service web (SOAP) de listes d’historique . Pour des problèmes supplémentaires, transmettre des requêtes CAML mal conçues.

Agrégation de contenu défini

Il est important d’établir une définition claire de l’agrégation de contenu pour le contexte de cet article.

Agrégation de contenu est le concept de localisation dynamique et extraction de contenu pour les afficher sur la page active lorsque ce contenu existe de manière autonome de la page active dans un ou plusieurs emplacement(s) dans le portail.

L’agrégation de contenu n’inclut pas de contenu créé au sein de la page active.

L’agrégation de contenu est principalement destinée à l’affichage de l’interface utilisateur du portail (par opposition au mode d’affichage de l’interface administrateur).

Exemples des emplacements où l’agrégation de contenu peut être utilisée :

• La page d’accueil du portail contient un contrôle des dernières actualités qui affiche une liste de liens vers des articles les plus récents publiés dans le portail.
• Les pages du portail contiennent un contrôle de navigation globale qui affiche les liens de navigation gérés dans une liste SharePoint personnalisée.

Configuration requise de l’agrégation de contenu en temps réel

Dans l’agrégation de contenu en temps réel, les modifications apportées à une source d’agrégation de contenu apparaissent immédiatement dans les contrôles d’agrégation de contenu ciblant cette source.

Exemples de l’emplacement où une attente d’agrégation de contenu en temps réel peut se produire :

• Un auteur de contenu publie un article et s’attend à ce que son lien apparaisse immédiatement dans le contrôle des dernières actualités de la page d’accueil du portail.
• Un administrateur du portail ajoute un lien vers la liste de navigation globale et s’attend à ce qu’ils apparaissent immédiatement dans le contrôle de navigation globale.

Tandis que les informations urgentes requièrent une distribution absolue et en temps réel, un portail de publication ne doit être pas le premier choix pour une distribution de ce type d’informations. Un certain nombre d’autres systèmes (par exemple, cellulaire, radio, satellite, téléviseur, sirène, alarmes et haut-parleurs) est mieux adapté à cette tâche. Le portail est mieux adapté pour la distribution des informations de suivi, le contexte et les détails; par inférence, cette distribution ne doit pas forcément se produire en temps réel.

Avec ce contexte en tête, vous pouvez cette pratique recommandée : Aucun contenu de portail n’est suffisamment important pour justifier le coût d’agrégation de contenu en temps réel.

Malheureusement, la position par défaut de l’équipe de gestion de presque chaque équipe de portail de gestion de contenu est à prendre en considération, de même pour son contenu le plus commun considéré comme urgent et digne de l’agrégation de contenu en temps réel.

Le défi est précisément pour le portail architecte : succomberiez-vous à ces pressions et à l’exécution du portail de réduction de risques ou est-ce que vous convainquez l’équipe dans le cas contraire et fournissez un portail performante? Nous vous encourageons à les convaincre dans le cas contraire.

L’agrégation absolue de contenu en temps réel n’est pas techniquement possible dans n’importe quel système publication. Même si vous respectez les comportements par défaut du portail de publication, les retards et la mise en cache se produisent à des points différents dans le pipeline d’agrégation/de rendu; certaines de celle-ci sont visibles et configurables (par exemple, cache côté client personnalisé, cache de sortie côté serveur, cache d’objets côté serveur) et certaines de celle-ci sont masquées et immuables (par exemple, les plans de requête de base de données, caches application interne).

Les auteurs de contenu sont généralement les seules personnes qui remarquent les délais d’attente d’agrégation de contenu. Les utilisateurs finaux n’ont aucune attente en matière d’agrégation de contenu en temps réel en raison de leur manque de perception du processus de publication de contenu.

Une fois que vous acceptez qu’une agrégation de contenu en temps réel ne peut se produire avec succès, tout ce qui reste négocie ce qui suit :

• Combien de temps êtes-vous prêt à attendre pour afficher le contenu ?
• Quelle quantité êtes-vous prêt à « payer » pour afficher le contenu un peu plus vite ?

Les Retards d’agrégation de contenu sont inévitables dans une solution de portail performante. Si vous acceptez un délai acceptable, vos utilisateurs du portail vous remercieront.

Techniques d’agrégation de contenu

Les sections suivantes décrivent les deux techniques d’agrégation de contenu disponibles pour SharePoint Online.

Agrégation de contenu CAML.

La technique d’agrégation de contenus CAML sur l’utilisation des requêtes duLangage collaboratif CAML (Collaborative Application Markup Language).

Vous pouvez créer des requêtes CAML et les utiliser pour effectuer des opérations d’agrégation de contenu au sein de SharePoint. Les requêtes sont exécutées dans les bases de données de contenus SharePoint. Les requêtes CAML sont alimentées dans l’implémentation de contrôles côté serveur tels que le composant WebPart de contenu par requête à l’emploi. Les requêtes CAML peuvent également servir directement par rapport à la découverte des APIs de contenu différents disponibles à des contrôles JavaScript personnalisés côté client .

CAML vous permet principalement d’approcher le plus possible de l’accomplissement de l’agrégation de contenu en temps réel.

L’inconvénient principal de CAML est qu’il nécessite des connaissances et des compétences de création de requêtes CAML performantes; une modification apparemment anodine peut entraîner une mauvaise exécution de la requête CAML et/ou une série infinie d’échecs dans le cache, une impact de ce qui n’est pas apparente jusqu'à ce que le portail se trouve en chargements importants.

En interdisant le déploiement de code personnalisé, SharePoint Online a éliminé ce qui a été historiquement la pire catégorie unique de dégradation de performances SharePoint :des contrôles personnalisés côté serveur et des composants WebPart qui utilisent des requêtes CAML mal conçues. Toutefois, il est toujours possible d’utiliser CAML de manière abusive via les composants WebPart de contenu par requête à l’emploi, ainsi que via des contrôles personnalisés JavaScript côté client.

Veuillez prendre en compte les éléments suivants:

• Chaque requête CAML côté client résulte en une requête de base de données directe :

  • Les résultats CAML côté client ne sont pas mis en cache sur le serveur.
  • Les requêtes CAML côté client appuient sur le serveur de base de données pour l’exécution (une absence de cache se produit toujours).

• Chaque demande CAML côté serveur risque de devenir une requête de base de données directe :

  • Les résultats CAML côté serveur sont mis en cache sur le serveur, en fonction des ensembles d’autorisations utilisateur similaires.
  • Les requêtes qui contiennent des champs de personnalisation ne sont jamais mis en cache.
  • Les requêtes CAML côté client appuient sur le serveur de base de données pour l’exécution lorsque une absence de cache se produit.
  • Une absence de cache est une certitude proche dans les batteries de serveurs avec un grand nombre de serveurs d’interface utilisateurs.

Instructions relatives à l’aide d’agrégation de contenus CAML

• Éviter son utilisation sur les pages au volume élevé.
• Limiter son utilisation à une classe spécifique de contenu (par exemple, des alertes).
• Définir la requête CAML la plus simple, la plus efficace et vérifiez sa exécution.
• Implémenter des colonnes indexées sur les listes cibles.
• Inclure des limites de ligne sur la requête.
• Vous assurer que des contrôles personnalisés JavaScript côté client fournissent un lienen savoir plusqui redirige les utilisateurs vers une page pour visualiser tous les faibles volumes.
• Vous assurer que des contrôles personnalisés JavaScript côté client tirent parti de l’infrastructure de calque côté Client données Access pour mettre en cache la réponse contenu. Aucun résultatest une réponse valide et doit être également mis en cache.
• Appliquer une expiration du cache situé côté client de moins de cinq minutes.

Pour plus d’informations concernant la couche d’accès aux données côté Client, voirConseils relatifs aux performances pour portails SharePoint Online.

Agrégation de contenu en fonction de la recherche

La méthode d’agrégation de contenu en fonction de la recherche est basée sur l’utilisation de la Recherche Mot-clé des requêtes SharePoint(Keyword Query Language).

Vous pouvez créer des requêtes KQL et les utiliser pour effectuer des opérations d’agrégation de contenu au sein de SharePoint. Les requêtes sont exécutées par rapport à l’indexe de recherche SharePoint. Les requêtes KQL sont alimentées dans l’implémentation de contrôles côté serveur tels que le composant WebPart de contenu par requête à l’emploi. Les requêtes KQL peuvent également servir directement par rapport à la découverte des différents APIs de contenu disponibles pour des contrôles personnalisés JavaScript côté client .

Le principal avantage d’agrégation de contenus recherche est qu’elle tire parti du Service de recherche SharePoint, conçu pour fournir des performances exceptionnelles à grande échelle sous des chargements importants.

L’inconvénient principal d’agrégation de contenus recherche est son dépendance l’index de recherche, ce qui signifie qu’il existe un léger délai avant que des modifications du contenu apparaissent dans l’index de recherche.

Veuillez prendre en compte les éléments suivants:

• Le portail de contenu doit être analysé et ajouté à l’index de recherche afin d’être disponible pour l’agrégation de données en fonction de recherche.

• SharePoint analyse en permanence le contenu du portail pour fournir un index de recherche à jour. Toutefois, il y a un léger délai avant que des modifications du contenu apparaissent dans l’index.

• Le schéma de recherche doit être configuré pour autoriser la découverte des propriétés souhaitées contenues via la recherche.

Instructions relatives à l’utilisation d’agrégation de contenus en fonction de la recherche

• Vous assurer que vos équipes de gestion de contenu comprennent que le contenu doit être analysé avant qu’il soit agrégé.

  • Établir des attentes concernant du retard éventuel de l’agrégation du contenu.

• Configurer le schéma de recherche nécessaire.

  • Sélectionnez une étendue appropriée (client, collection de sites ou web).
  • Déclencher la génération automatique des propriétés analysées et gérées.
  • Tirer parti des propriétés gérées par l’emplacement (par exemple, RefinableInt01) lorsque le tri/affinage est nécessaire.

• Concevoir des requêtes et des sources de résultats appropriées.

  • Cibler les listes, sites Web ou sites selon vos besoins.
  • Cibler les types de contenu individuels selon vos besoins.
  • Cibler des propriétés gérées spécifiques (par exemple, les colonnes de site) selon vos besoins.

• Sélectionnez les contrôles d’affichage souhaités :

  • Contrôles prêts à l'emploi:
    • Utiliser les composants WebPart par recherche de contenu.
    • Renvoyer les lignes minimales et colonnes nécessaires.
    • Développer les modèles nécessaires à l’affichage.
    • Activer le rendu côté client asynchrone si vous le souhaitez.
  • Contrôles personnalisés:
    • Utiliser des contrôles d’affichage JavaScript personnalisés et côté client qui utilisent la recherche de l’API REST.
    • Renvoyer les lignes minimales et colonnes nécessaires.
    • Tirer parti de l’infrastructure de calque côté Client des données Access pour mettre en cache les réponses.

Pour plus d’informations concernant la couche d’accès aux données côté Client, voirConseils relatifs aux performances pour portails SharePoint Online.

Voir aussi

• Création de portails SharePoint Online