How to develop social applications for SharePoint 2013
•
3 gostaram•2,989 visualizações
The presentation i gave at SharePoint Extreme 2013 about how to develop social applications using SharePoint 2013. The accompanied
Recomendados
Recomendados
Mais conteúdo relacionado
Último
Último (20)
Destaque
Destaque (20)
How to develop social applications for SharePoint 2013
- 1. Developing Social Apps with SharePoint 2013 Johnny Tordgeman @ E4D
- 2. ME • Linkedin
- 4. What are we going to talk about? • What is social all about? • Why do we need it? • What does it looks like? • Can I extend it? • How?
- 6. asking and working with answering documents questions and sites “Liking” all sort of content finding out more about people
- 7. • Social helps employees engage with each other • Social helps teams collaborate • Social drives business agility • Social is fun!
- 11. Write
- 12. Write Write Write Write Write Write Write Write Write Write Write
- 13. Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write
- 14. Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write Write
- 17. central storage of all recent Read activity Write Read Read
- 18. central storage of all recent Read activity Write Read Write Write Read
- 28. Get profiles and properties Get feeds and replies (require some extra assembly work) Update the current user picture Create posts for the current user
- 29. Find out if an account exists Create a user profile Change a user profile (other than its image) Delete a user profile Create posts for another user ()
- 30. RESTFul http://<siteUri>/_api/ Namespace: SP.UserProfiles SP.UserProfiles.PeopleManager Class library: SP.UserProfiles.js
- 31. • DEMO – Fun with user profiles!
- 32. The user profiles client APIs are read-only, other than setting the user’s image. No extra files are needed to work with the user profile with REST or JSOM, for C# client object model use Microsoft.SharePoint.Client.UserProfiles.dll Remember to set the request header correctly when working with REST: application/json;odata=verbose If working from an App remember to request correct permissions:
- 34. User Profile Service Social DB Content DB Profile DB (per- (per- service) service) (site collection(per-user) Content DBs per-user) People User Site and Personal Feed and tag profile Social tags document storage posts following properties following space
- 35. Get followers and followed profiles Add an actor (followed entity) Check if an actor is followed Stop following an actor Get following suggestions
- 36. RESTFul http://<siteUri>/_api/ Namespace: SP.UserProfiles Social.following/my Class library: SP.UserProfiles.js
- 37. • DEMO – Fun with following!
- 38. Almost anything can be done with the following API on the client side. No extra files are needed to work with the user profile with REST or JSOM, for C# client object model use Microsoft.SharePoint.Client.Social.dll Remember to create a new SocialActorInfo when you wish to follow an actor. If working from an App remember to request correct permissions:
- 40. Feeds storage overview Persisted personal site content Site’s feed DB content DB Cached feed Person Site Document Tag
- 41. Creating aggregate feeds on- demand Post Reply Reply
- 42. Feed data structure SocialThread[] Actors[] Attributes ID SocialPost[] (RootPost and Replies[]) Attachment Author ID LikerInfo Text
- 44. RESTFul http://<siteUri>/_api/ Namespace: SP.UserProfiles Social.feed/my Class library: SP.UserProfiles.js
- 45. • DEMO – Working with feeds!
- 46. Everything related to feeds can be done on both JSOM and REST APIs. No extra files are needed to work with the user profile with REST or JSOM, for C# client object model use Microsoft.SharePoint.Client.Social.dll Remember to create a new SocialPostCreationData when you wish to create a post. If working from an App remember to request correct permissions:
- 48. So, what is Social? (other than sharing photos and wasting company time) Tags and Documents Following @Mentions Sites Share Likes Followers Discussions and badges
- 49. Data-driven and platform independent Easy to use REST and CSOM APIs deliver on any device with a network connection Separate form from function Focus on consumer applications Mobile and desktop applications, web portals, providing social information in other contexts Everything is live No gatherers or timer jobs getting between you and the latest information
Notas do Editor
- Few things before we get started:SP13 is client oriented and as such all the demos from here on will be shown using CSOM and RESTNo c# will be used, just JavaScript.All the demos will be available on my blog
- Feed posts are presented in both persisted and cached positions. The cache holds the everyone and following feeds. Cache feed is app fabric.When I write a new microblog, its going to get written first to the content db, and then the cached feed. Anyone who follows me will see this post instantly because of the cache. Posting to team site is the same. When I reply to someone post, and I as a use see that post I expect to see the reply as well. If im following the person who created the post, I shold see the reply, if im only following the person who wrote the reply I also should see the post. This is achieved by using the reference threads.If bender posts something on his wall it is stored on his feed. When fry comes and reply to that post, that reply is also stored on benders feed. This is how we keep conversation. In the replier feed there is a post that is called a reference thread. A reference thread refers to the original post. This is how people following only the replier will know about his reply. The reference post is just a guid. All the data is in the original post. This is the same for tags and mentions.Notice the gaps for document and tags. They don’t have persisted storage.That causes two things:You cant write to a document or tag feed directly.You cant consume a document or tag feed directly as well.Only if you follow a tag or document you can see its feed.Anything you see in a document feed is replicated to a persisted feed, like a users feed.Tag feed only shows referenece posts. To get a feed of a tag you can use search! (all the data is already indexed) this is how the tag profile page works.Posting on behalf of is not supported at the moment. Posting can only be done as a context of a user. Might be added in the future.
- First of all the information is gatherd. In our case the following feed. Every post has its time stamp available so posts can be sorted and know how recently it was updated. The feed is kept in the cache. Now the feed get sorted (by default newer on top). This is were similar data is removed. For example if you follow a person and he updated a tag you also follow, you wont see this update twice. Next is trim. First is pulling reference post data. If we are unable to get the information in time, the post wont show. Showing data quickly is top priority. Next is security trimming. If a user watching my feed cant see a document im following (by url) he wont see this post. Content of micro blog posts is NOT security trimmed. If I put a link in my post its not getting checked against other users.Last step is seeing the post. There is always a root post and the latest 2 replies.
- Social thread has a collection of actors so if a user replied twice to a post, his user data (image, name etc) is only saved once.