Glancing over the new entries at MSDN for SharePoint, I noticed an article by the name of “Capitalizing On the Social Network Capabilities of SharePoint Server 2007 User Profiles”, written by Antoine Atallah and Martin Gagné from Microsoft.
The article is compact and easy to follow. It outlines the architecture of user profiles, with special attention to social relations such as peer, colleagues, direct reports, managers and group membership. It also provides quick code samples for user profile management.
The article was of interest to me because I am very familiar with user profiles of MOSS. I recently developed a set of SharePoint Designer workflow activities that expose user profile properties.
A couple of weeks ago, Microsoft, EMC and IBM announced that they agreed on a joint specification of interoperability between their content management platforms. This new protocol is called Content Management Interoperability Services (CMIS) and it is based on SOAP, Atom and REST, all of them public and well-known. It will enable service-oriented architecture in a heterogeneous ECM environment.
What will this mean for SharePoint? Probably Microsoft will launch a CMIS-compliant connector for SharePoint that will expose its content for CMIS-capable applications and consume their content for indexing or query, as announced vaguely on SharePoint ECM blog. It will surely ease the life of a integration-project developer that juggles the information between different ECM systems (SharePoint, Documentum, FileNet…).
This new protocol also allows for rich mashups to be created while technology-agnostic (at least, in theory). The protocol also caters for security trimming and authorisation.
I’ll be tuned for the news around this new protocol. In the meanwhile you can download the draft specification yourself and take a look.
An annoying “design bug” that happened to me today.
SPListItem item = …(get a valid SPListItem)…
SPField fieldDef = item.Fields[“FieldInternalName”];
raises a ArgumentException: “Value does not fall within the expected range” error. The property indexer does not accept internal names (StaticName property of the field) as valid index.
If you access the Fields property with the field’s display name, which was localized in my case, then it works well. However, as localization was a must, I couldn’t rely on the display name to be the same in all deployments.
Luckily, there’s a method in SPFieldCollection class called GetFieldByInternalName. Just substitute
and the error is gone.