SharePoint Online: An Introduction to Office Delve
Introduction
Microsoft has been talking about “codename Oslo” and Office Graph since the SharePoint conference in March 2014. Office Delve (previously codenamed “Oslo”) was launched by Microsoft on September 8. For anyone unfamiliar with Office Delve, let us briefly discuss about what Office Delve is before we dive into fetching data from Office Graph Using Graph Query Language.
What is Office Delve?
According to Microsoft, “Office Delve is a new way to discover relevant information and connections from across your work life. Delve displays information that is most relevant for each person based on the work they are doing and the people with whom they are engaging. With Delve, information finds you versus you having to find information.”
This information is presented in a card format which is visually appealing and catches your attention immediately. You don’t have to search for information as using Office Delve, information comes to you based upon how closely it is linked to you. Say you have to find the location where a particular document that was shared by one of your colleagues to you is lying then under normal circumstances, you need to know the exact location where the document is lying or you need to search for it. But this is not the case when it comes to Office Delve. The information shared to you i.e. the document shared with you in this case is presented on your Delve page and you don’t have to navigate here and there to search for it.
Office Delve is powered by Office Graph which uses machine learning techniques to map the relationships between people, content and activity that occurs across Office 365.
Delve is a new breed of intelligent and social work experiences. It is a proactive search for information relevant to you. It is a personalized search for you where you are presented with what you are most likely to be interested in knowing based upon what you are working on, what is trending around you, what has been shared with you, the actions of people in your network.
If the user clicks on the Delve link in the suite bar and then click on My work section in the left navigation then he/she will be presented with all the things that the user has worked on.
The above screenshot shows all the documents/presentations that have been created by the logged in user (Geetanjali Arora) under the My work section in Delve screen. Left hand side also shows the People section which shows all the people closely linked to the logged in user.
The above image shows all the documents that have been shared with me by my colleagues.
What is Office Graph?
Office Graph is an innovation in Search. It is a game changer in a way that information comes to you based upon its relevance to you. It uses Machine learning to find information relevant to you from different sources like OneDrive, Outlook, Yammer and OneDrive. The Office graph contains information about enterprise objects such as people and documents and their relationships with each other. These relationships and interactions are termed as edges. Now these edges can constitute a single interaction or multiple interaction.
A simplified view of the search aspect of Office graph and Delve
(Image Source : http://msdn.microsoft.com/en-us/library/office/dn783218(v=office.15).aspx#bk_actiontypes)
Single interaction are like below
- **Modified - **User modified a document.
Edges computed based upon multiple interactions are like below
- **WorkingWith - **People whom you frequently interact with.
There are some edges which are relationships between enterprise objects like OrgManager.
In the above image, left hand side of the edge is the source node or the Actor and the right hand side is the target node or the Object. Therefore each edge has a source node and a target node.
Using Graph Query Language with Search REST API to query Office Graph
Graph Query Language (GQL) is used to query Office Graph with the help of SharePoint Online Search REST API. It is used to filter normal search queries to return content which is highly relevant to the user. This relevant content is calculated based upon the relevance score which is decided based upon the EdgeWeight property.
A sample graph query call via REST api looks like below.
**https://<tenant_address>/_api/search/query?QueryText=’*’&Properties=’GraphQuery:ACTOR(<Actor Id> [, filter]) **
Now if you look at the above REST call, the first section till QueryText is just like a normal Search REST api call where you are fetching content based upon the filter parameter given in the Querytext.
The new thing to note in the above call is the GraphQuery. The ACTOR operator finds all the actions of the given actor.
The syntax for the ACTOR operator is as below
ACTOR(<ActorId> [, filter])
Here the ActorId is the ID of the node you want to look up the actions for. The filter is a predicate applied to all outgoing edges of the actor. The result of the query is the objects of all the edges that match the filter.
Say you want to query all documents who have been modified by actor XYZ whose actor id is 12345 then the query will look like below
https://<tenant_address>/_api/search/query?QueryText=’*’&Properties=’GraphQuery:ACTOR(12345, action:1003)
Action Type of Modified is denoted by an ID of 1003.
Similarly there are many other Action types like WorkingWith, OrgManager etc which we will discuss shortly.
Before we actually jump into all these different actor types and how they can be accessed using REST api let us discuss about another ActorId which you can use for the currently logged in user. You can use the macro ME for the actor id of logged in user.
So the below syntax is used to fetch all the documents modified by the logged in authenticated user.
ACTOR(ME, action:1003)
Exploring the different available Actor Types
Modified – This action type is used to fetch items that the actor has modified in last three months. It has an action type id of 1003. Below is the REST api call to fetch all the documents modified by logged in user. https://<tenant_address>/_api/search/query?Querytext='*'&Properties='GraphQuery:ACTOR(ME\ action\1003)'
If you have a look at the above screenshots, there are four documents one from the site and three from the user’s one drive that have been modified by the user. The XML returned from the REST api call shows row count as four. Expanding all the four rows shows the documents.
**OrgColleague - **This action type is used to fetch all the colleagues who reports to the same manager as the actor. The action id for this action type is 1015. Below is the REST api call for fetching all the colleagues who have the same manager as the authenticated user.
https://<tenant_address>/_api/search/query?Querytext='*'&Properties='GraphQuery:ACTOR(ME\ action\1015)'
In the above screenshot, logged in user is Geetanjali Arora. This user has the manager as Gaurav Arora. Also there is another user named Geetika Arora who has the manager as Gaurav Arora. So this Graph Query REST api call will fetch one user i.e. Geetika Arora on executing the above REST call.
The above image shows the data row that depicts the user who has the same manager as the logged in user.
**OrgDirect - **This action type fetches the actor’s direct reports. The action type for this is 1014.
https://<tenant_address>/_api/search/query?Querytext='*'&Properties='GraphQuery:ACTOR(ME\ action\1014)'
The image above shows the profile of a user who has the manager as Geetanjali Arora.
The above image shows the Organization Hierarchy where we can see the user (Vardhaman Deshpande) as direct report for user (Geetanjali Arora).
The same result can be seen as in the image below by exceuting the graph query with action type for OrgDirect.
**OrgManager - **This action type fetches the person whom the actor reports to. This has an action type id of 1013. Below is the REST call for the same. The images are self explanatory.
https://<tenant_address>/_api/search/query?Querytext='*'&Properties='GraphQuery:ACTOR(ME\ action\1013)'
**OrgSkipLevelManager - **This action type fetches the actor’s skip level manager. This has an action type id as 1016. Below is the REST call executed for logged in user (Vardhaman Deshpande).
https://<tenant_address>/_api/search/query?Querytext='*'&Properties='GraphQuery:ACTOR(ME\ action\1016)'
The below images are self explanatory.
**WorkingWith - **This action type fetches the people whom the actor works or communicates with frequently. This has an action type id of 1019.
https://<tenant_address>/_api/search/query?Querytext='*'&Properties='GraphQuery:ACTOR(ME\ action\1019)'
The above image shows two people whom the logged in user works with frequently.
Viewed - This action type fetches the items viewed by the actor in the last three months. This has an action type id of 1001.
https://<tenant_address>/_api/search/query?Querytext='*'&Properties='GraphQuery:ACTOR(ME\ action\1001)'
References
- http://msdn.microsoft.com/en-us/library/office/dn783218(v=office.15).aspx
- http://blogs.office.com/2014/09/08/milestone-office-delve/
- http://blogs.msdn.com/b/richard_dizeregas_blog/archive/2014/09/15/developing-apps-against-the-office-graph.aspx?utm_content=bufferdf5a8&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
- http://blogs.msdn.com/b/richard_dizeregas_blog/archive/2014/09/17/developing-apps-against-the-office-graph-part-2.aspx