#SPC2012 : How to Extend Social in SharePoint 2013

Wednesday, 9h00, Andrew Harris, Program Manager Social SharePoint, Microsoft

Résumé :

La session est une introduction aux objets de développements permettant d’intéragir avec le newsfeed principalement.

Il explique également la structure et l’architecture de stockage des différents éléments de la brique Social sur le SharePoint.

Il présente la session comme présenter les APIs et fonctions AJAX pour étendre les fonctionnalités du Social par le développement.

// Qu’est-ce que le Social

Composantes du Social :

* UserProfiles avec les profils et les propriétés utilisateurs

* Following : avoir nos centres d’intérêts, et pouvoir les suivre.

* Feeds : selon les following, le plus gros investissement de cette version de SharePoint

Architecture de stockage : User Profile Service

* BDD Profile (par service)

* People et tags following

* Propriétés utilisateurs

* BDD Social (rôle réduit maintenant)

* Social tags uniquement

* BDD Content (collection de sites par utilisateurs)

* Feeds posts

* Sites et documents followés

* Espace personnel

Il revient sur ces choix d’architectures où la content database peut être parcourue par le search, peut être étendue en termes de volumétrie.

Il explique qu’une autre composante est App Fabric Distributed Caching : qui permet de facilité la récupération d’activité rapidement.

Une différence par rapport à 2010, est que nous avons un réseau social en live, il n’y a pas de latence de crawl comme en 2010 où il fallait attendre x temps pour récupérer nos activités dans le newsfeed.

// Développement

CSOM, JSOM, et API REST (OAuth et OData) sont utilisés pour le développement.

Il renvoie à la session de 10h sur l’utilisation de Ruby On Rails pour attaquer les données de SharePoint en REST.

// DEMO : authentication et profiles

Il a une application simple qui utilise un ClientTexte Il y a besoin de référencer microsoft.sharepoint.client.runtime (clientcontext par ex), microsoft.sharepoint.client.userprofiles.

Il récupère le contexte via un ClientContext et l’URL.

Il passe un objet SharePointOnlineCredentials ave clogin et mot de passe en disant que ce n’est pas une best practice mais pour le besoin de la démo, c’est simple. Il existe un moyen d’ouvrir une iframe pour se connecter sur SharePoint Online et retourner le credentials dans l’application.

Il revient sur les namespaces dans userprofiles : social et userprofiles.

Il insiste sur le namespace Social qui contient les méthodes qui font le travail en arrière plan et facilite le travail.

Pour gérer les éléments de personnes (propriétés etc.), utiliser le namespace UserProfiles.

Il retourne sur le code, et utilise l’objet PeopleManager en passant le contexte. Avec cela il récupère un utilisateur pour avoir son nom.

// Retour sur les slides : Key features

Les éléments les plus utilisés seront sûrement l’objet PeopleManager. En général il explique qu’on ne trouvera pas le moyen de définir la propriété utilisateur d’un profil.

// DEMO : Follow

Il va récupérer les followers et les personnes qu’il follow afin de les afficher.

Il utilise le SocialFollowingManager dans le namespace Social.

Il existe plusieurs types d’éléments à follow : Documents, Sites, Tags, Users : représenté par l’objet SocialActor.

Il fait un GetFollowers() sur le manager et récupère un ClientResult<SocialActor[]>.

Ensuite il exécute la requête et pour  chacun des SocialActor retourné.

Ensuite il sort du contexte de développement et présente le fait que de follow quelqu’un va être instantané dans les compteurs, dans les feeds retourne sur notre newsfeed.

// Retour sur les slides : Feeds

Stockage des feeds.

Il y a un stockage persisté, et un stockage en cache.

Les personnes, site, document et tags sont stockés dans le cache feed.

Il explique que pour un post et une réponse, on stocke toutes les entrées au niveau d’un site personnel de la personne qui a posté. Ce post est également repris et stocké dans le site personnel de la personne qui a répondu mais en tant que référence de thread (thread ID) Il explique qu’il est impossible de poster de la part de quelqu’un d’autre.

// Création des feeds agrégés sur demande

Le processus est de récupérer les feeds depuis les feeds en cache et persisté. Ensuite il y a un tri possible sur par exemple les posts les plus récemment répondus. Ensuite, parce que les feeds sont récupérés de deux listes différents, il y a une consolidation pour appliquer la gestion de sécurité sur les éléments que l’utilisateur qui les requêtes, a droit de voir. Enfin, il y a l’affiche du post et de ses réponses.

En code, on récupère un feed (SocialFeed) qui récupère un SocialThread correspondant au fil de discussion. Il contient un post racine et des réponses en SocialPost[] qui peuvent être des RootPost ou Replies[].

// DEMO : récupérer des feeds

On va utiliser Social et Microfeed namespace. Il conseille d’utilise le SocialFeedMAnager . Nous allons utiliser CreatePost() et GetFeed().

Pour GetFeed, il y a des types de feeds, les news, les personal feeds (activités personnels), timeline (il ne s’étend pas dessus), et likes.

Sur le SocialFeedManager, il y a un GetMentions() permettant de récupérer les mentions, éventuellement lues ou indifférenciées.

On peut faire un GetFeedFor() pour avoir les feeds, tels qu’on les aurait en allant sur la page d’un utilisateur.

Il va faire un Getfeed() de type news avec des options avec un compteur max à 5 renvoie en ClientResult<SocialFeed> Pour chaque SocialThread, dans les feed.Value.Threads il va récupérer les SocialActor[] thread.actors.

Il va afficher le post racine (thread.RootPost.AuthorIndex dans le tableau) ainsi que toutes les réponses.

// DEMO : création de post

Utilisation de SocialFeedManager toujours.

Il va utiliser un SocialFeedCreationData qui permet de définir les options de création. Il y définit le contenttext avec des références {0} etc.

Il va remplir les ContentItems par un tableau de SocialDataItem. Le premier est un utilisateur SocialDataItemType.User avec l’accountName. Le deuxième est un lien avec SocialDataItemType.Link avec le text et l’URI. Enfin un tag avec SocialDataItemType.Tag avec un text. Il note qu’il faut que le text commence par un #, sinon il y a une exception.

Enfin grâce au SocialFeedManager.CreatePost() il peut passer la possibilité de poster dans le newsfeed d’un utilisateur ou poster dans un Team Site.

Ensuite il ajoute des réponses via CreatePost toujours, en passant le resultThread.Value.Id en paramètre.

// Retour sur les slides : Fonctionnalité conversations

On peut créer des post, supprimer, like des posts.

// Conclusion :

Les applications peuvent être développées avec les APIs REST ou le CSOM ou JSOM.

Enfin il insiste sur le fait que contrairement à 2010, 2013 retourne les informations en live.

Christian

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