My Colleague Tag , or “there is no timer job…”
The question that generated this post was: “What timer job needs to run in order for the Colleagues tag to become in effect and to be displayed as such in the search results page ?”
While this might seem trivial to some, there is a valid point behind the question, now with the multitude of social elements that come in play in SharePoint. Why, sometimes after adding a colleague it is displayed as such within minutes and sometimes within hours? What data needs to be synchronized between the Profile DB and Social DB. What TImer JOb does that?
Well, let’s start with the beginning:
If we are talking about search results, the very first pointer is that the colleague tag MUST be in the index.
How does it get there ? By getting crawled , of course.
How is it indexed ? as People:Colleagues(Text) managed metadata.This is mapped to Crawled Property: urn:schemas-microsoft-com:sharepoint:portal:profile:Colleagues The property is defined in https://technet.microsoft.com/en-us/library/hh134087.aspx as
Property Name |
Type Mapped To |
Included in |
Index |
Multi-valued |
People:Colleagues(Text) |
Text |
Colleagues |
No |
No |
NOTE
On the first SSA Set-up this property is not by default indexed so we need to manually add it
Go to search settings-Managed metadata, crawled properties, search for Colleagues, set it to be “included in index”.
Launch a full crawl. After the crawl is complete, the Ranking phase occurs. During this phase, we compute the relevance of the items based on common properties ( in our case we compute the social relevance of the crawled items(profiles). This also updates the flag that is used in People Core Results WebPart to idfentify a direct colleague or a colleague of a colleague – see below ).
How do we get Colleagues ?
https://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=601 or
https://blogs.msdn.com/b/markarend/archive/2008/05/01/colleagues-social-distance-relevance-in-people-search-social-networking-tools.aspx
“ Immediate colleagues
...automatic: during profile import; comprised of:
o Your manager
o Your peers (others who report to your manager)
o Your direct reports
• Colleagues added by you
...manual: via editing page on your Profile
• Suggested colleagues
...lookup: manually guided via editing page on your Profile; comprised of:
o Sent items in Outlook. Periodically (every 5 days or so, depending on usage) Outlook analyzes Sent Items for common recipients, weighted by frequency of contacts and other factors. This is how Outlook is able to suggest likely recipients when you begin typing their name in the To: line, and in my experience, it seems to work pretty well. When you click Suggested colleagues, it collects these names from Outlook via an ActiveX control, and adds them to the list of suggestions.
o Office Communicator contacts are examined; that is, those contacts that you've added to your Office Communicator client from the company directory. These are also collected from the Communicator client via an ActiveX control.
o Site Memberships are all sites in which you are explicitly included in the "~Members" group for the site (where ~ is your site name). Other users who are also explicitly included in the ~Members group on those sites are suggested as your colleagues. This information is collected by a WSS profile synchronization timer job.
o DG (Distribution Group) Memberships are examined for suggestions. Distribution groups stored in AD are collected during the AD import.
.... “
When we add a user as a colleague, the information is added into the User Profile Service Application database - Table name is UserColleagues , we perform this through the QuickLinksAdd stored procedure: https://msdn.microsoft.com/en-us/library/dd774764(office.12).aspx. Many thought this data needs to be replicated into some additional profile/social related DB before it will be displayed.
No. The data resides only in this db and is getting picked up by the crawl as per above.
To summarize:
There is no timer job that will update the flag. You just need to allow the crawl to complete the Ranking Phase.
Now, since this can take some time , a tip to improve the speed of the process:
Set up a content source that would ONLY Crawl the profiles (sps3://mysitehost). This would ensure the crawl will only execute the ranking for the profiles, faster, not all the items that are crawled.
One additional point, if you want to modify how the end-users get the results, one needs to edit the people core results web-part as per :
https://msdn.microsoft.com/en-us/library/ms544191(v=office.12).aspx
the variables that impact the My colleague Display text and Add to my colleagues Link are:
<xsl:variable name="hascol" select="string-length(colleaguecategory) > 0"/>
<xsl:variable name="hasacu" select="string-length(addtomycolleaguesurl) > 0"/>
and the sections where they are used :
The "My Colleague" text:
<xsl:if test="$hascol">
<div id="ColleagueField">
<xsl:value-of select="colleaguecategory"/>
</div>
</xsl:if>
The Add to my colleagues Link:
<xsl:if test="$hasacu">
<li id="AddColleagueLinkField">
<a id="{concat($currentId, '_AddColleagueLink')}" href="{ddwrt:EnsureAllowedProtocol(string(addtomycolleaguesurl))}">
» <xsl:value-of select="$AddToMyColleaguesText" />
</a>
</li>
</xsl:if>
Some interesting reads:
https://blogs.msdn.com/b/spses/archive/2010/12/23/social-computing-part-1-overview.aspx
V