The SharePoint Server 2010 social data object model enables you to create your own activity types and publish activity events in custom applications. One important limitation, however, is that only users who have User Profile Service Application administrative privileges can publish activity events. You cannot, therefore, create a custom application that publishes activity events directly after a given user takes an action, unless you know for sure that the user will always be a User Profile Service Application administrator. This limitation helps keep unwanted items from overwhelming users’ activity feeds, but it also requires developers to plan ahead, work with administrators, and design custom applications that work around this limitation.
One way to work around the limitation is to store information about activity events in a hidden list. You can then create a timer job that runs at times and frequencies that you and your administrators establish beforehand in order to balance performance considerations with user experience concerns, such as the timeliness of the information in the activity feeds. This timer job would use information in the hidden list to create activity events and then publish these events by using the multicasting methods in the social data object model. If the publication succeeds, the timer job would then clear the list. Because this hidden list might become large, you would need to follow the best practices guidance in the Handling Large Folders and Lists topic.
The Microsoft SharePoint Server 2010: Activity Events for Document Libraries sample on Code Gallery provides a prototype for how this sort of design can work. It publishes an activity event to the activity feeds of a user’s colleagues whenever that user adds a document to a document library. The solution creates the new activity type to which the published activity events belong, along with the hidden list on feature activation.
Take a look at the sample and provide feedback on it by commenting on this post or on the Code Gallery resource itself. In addition to performance considerations, one potential drawback of this approach is that there will be a short interval between the publication of activity events and the clearing of the hidden list, which means that someone could potentially add a document within that interval, the list would be cleared, and the event would not get published. Let us know if you notice other drawbacks, or if you can think of ways to improve upon this design.