#SPC2012 : Step by step, building search driven applications with SharePoint 2013

Session de 15h15 à 16h30 animée par Scot Hilier

Il a du succès ce Scot, y a foule qui se fait refouler à l’entrée. Pas de bol !

// intro

Les évolutions de SharePoint 2013 côté search pour Scot sont principalement à chercher dans les choses qu’on était obligé de coder avant et qui sont maintenant dispo par le navigateur sans code.

(surcharger la search result webpart par exemple).

// overview pour les développeurs

La session va montrer des choses qui marchent onPrem et dans le cloud. Donc pas de code coté serveur.

Pour accéder aux données : plus de caml, spquery, linq, spsitedatquery, etc… Car c’est du code serveur.

Il faut seulement du caml et csom, du rest et du SEARCH ! Le search sait trouver l’info dans les moindres recoins.

Les managed properties :

Elles sont toujours mappées sur des crawled properties extraites par le crawl. Les managed properties sont des aggrégats de crawled properties.

Pas de nouveauté, comme en 2010. Les sites columns deviennent des managed properties « ows_xxx », « ows_taxId », etc.

La nouveauté : les managed properties ont des properties : Sortable, queryable, refinable, etc… Ces propriétés permettent d’activer ou non la possibilité de trier, requéter, raffiner, etc.

Queries:

On avait 3 languages :

  • Keyword query language, -> the one !
  • Fast query language (ne pas utiliser).
  • Sql query language n’est plus dispo.

 

Keywords:

Pas mal de keywords sont disponibles pour construire sa query. Exemples :

Fileextension:docx pour restreindre un type

Contentclass:sts_web pour retourner seulement les site SharePoint

Path:url pour restreindre sur une url

Contentclass=sts_sts_listitem_events calendarEventDate>2012/01/01  calendarEventDate<2012/12/31

Xrank(…) fileextension:docx pour booster les docx sans retirer le reste

Plusieurs concepts Sur lesquels on va pouvoir jouer lors du paramétrage :

Results sources : analogue aux scopes

Query rules : modifie la query selon un condition

Result type : détermine comment le résultat est affiché

Search navigation: les onglets pour definir ses verticals (people, videos, etc.)

export/import search settings:

Comment on fait pour passer ce qu’on fait coté search du dev en prod ?

On peut maintenant importer/exporter les rules, sources, managed properties, etc.  Et on peut packager tout ça dans une app. Top !

Mais ne prend pas en compte webparts, master pages et templates.

// DEMO NO CODE : content by search

1er exemple avec une cswp qui montre les upcoming events qui est paramétrée pour n’afficher que la source « events ».

2eme exemple avec un search center etendu où il a ajouté des onglets « my tasks », « my events », « my portals », « my documents », etc…

Pour les events, il a modifié le rendu dans la recherche et dans le over panel. De plus les événements sont triés par date et non par relevançe car cela a du sens dans ce cas ci.

* site settings > results sources :

Pour my events, il a ajouté une query transformation  :

{searchTerms} Contentclass=sts_listitem_events calendarEventDate>{today-30}

En gros, cela remonte les événements du mois passé ou dans le futur.

Maintenant il faut ajouter les pages au search center pour chacun des result sources. Il suffit ensuite de modifier la cswp qui affiche les resultats pour afficher ce que l’on veut.

* Si on veut aller plus loin, on peut changer les results types : site settings > result types

Il en ajoute un « my events », il choisi la source et il applique un template en saisissant l’url du js du display template.

Il montre maintenant un exemple de display template custom sur visual studio. Plus de xslt, les gens sont contents 🙂

Les displays template sont stockés dans la master page gallery. Le html est uploadé et le javascript est généré automatiquement. Ce js n’a pas a être touché par le dévellopeur.

* query rules

Si un mot est détecté, la query est remplacée pour pousser du contenu.

Exemple: « training » est détecté, la query est modifiée pour n’afficher que les résultats basés sur une liste SharePoint contenant les trainings officiels.

* search setting

C’est accessible depuis les sites settings et cela permet d’ajouter des onglets au search center.

* configuration export

C’est accessible depuis les sites settings, et cela génère un fichier xml.

// REST et CSOM

Les options de développement :

  • JS et REST
  • C# et CSOM
  • Mais les autres combinaisons sont possibles.

Des exemples d’url REST pour la recherche. On peut choisir les managed properties a retourner, le tri. JQuery est ton ami quand tu choisi ce mode de développement. Des exemples de CSOM en js. On peut faire la même chose, ca dépend ce qu’on préfère.mEncore des exemple de CSOM en C#. idem.

// démo d’une app win8 

Il a une « employee directory » app avec la liste des employés de a à z.

La requête est super simple : lastname:A* sur la page A.

// sharepoint apps

Il nous montre la version sharepoint de l’employee directory.

Permission :

Si on fait une recherche juste sur le contenu de son app, pas besoin de permission. Sinon il faut penser à ajouter des permission.

Les search settings peuvent être packagés dans l’apps pour les déployer facilement.

Il va très vite Scot 🙂

Fabien

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s