As a continuation from my first post about my talk at SharePoint Saturday Atlanta 2010, this part will focus on using the .Net Client Object Model to import data into SharePoint 2010. This is a great way to avoid the BCS/Enterprise features if you have just a Foundation site.
Here is a high level of things about the Client Object model:
- Provided for Silverlight, ECMA/Javascript, and .Net
- Lightweight server version (limited objects/less property objects within a Site Collection and down)
- Built into SharePoint Foundation, so available for all of the WSS users out there.
- Develop solutions off of the server, both in Visual Studio, and while running, the solutions do not need to be on the server
- Following point #3, no deployment.
- Connect to the Site via the URL
- Batch queries, and limited included properties means less chatter and less data transfer on requests.
- Manage installed Site Collection and Site features
- Manage most Site Collection and Site properties
- Manage web parts and pages
- Manage Site Collection and Site Security
The list goes on…
Now there are some limitations too:
- Can only work within a Site Collection
- Cannot create Web Applications or Site Collections
- Cannot interact with SharePoint Service Applications
- Cannot install or deploy solutions
- Cannot install features
For the SharePoint Saturday presentation, I focused on the .Net Client Object Model specifically.
You can find the .Net Client Object model dlls in the 14 hive ISAPI folder (\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI)
Microsoft.SharePoint.Client.dll
Microsoft.SharePoint.Client.Runtime.dll
Drop them into your VS project as references and add the using statement for the namespace “Microsoft.SharePoint.Client” and you are ready to code.
Pass in the Url to the ClientContext constructor to setup your object. As seen above, I am going to use the Web (Just like a little brother of SPWeb). Something to note, you cannot interact with the properties of your objects until you can called Load from the Context, and also ExecuteQuery. “Load” simply adds the call to fill the object to the batch, then ExecuteQuery actually fills out the object details.
Next, I am going to test the list to check and make sure it was not empty.
As long as I have the list, I am going to query it for items. When working in the Client Object model, it is better to trim down the items you return with a CAML query (since it filters server side, and transfers less data), but in my case, I want all of the list items back. There is a CreateAllItemsQuery() method, that does just that for me.
Then just pass your query into your list… and call Context.Load() to batch up the request. Here I have restricted the fields I am going to return from the list to save data in the items being returned. Since I am only going to check the TweetId value of items before I insert new Tweet data into the list, I have only selected TweetId and ID.
I go ahead and call ExecuteQuery() to fill my listItems collection. Next, I am going to drop the list items returned into a List object of the (SP)ListItem. Since I plan to create new items, I new up a ListItemCreationInformation object. This object, along with a handfull of others like it, allow for creation of new Webs, Lists, ListItems, Content Types, Fields, etc… Finally, I am going to keep a count of new items I am adding, just to show for a sanity check and something to show during the demo.
Finally, I am going to run through the items I have, check to see if I can find the TweetId, and if not, add the Tweet to the List.
I add some values to the fields that exist on the list, and call listItem.Update(). This method does not commit the change immediately, rather batches up the inserts/changes until we call ExecuteQuery() again.
Execute the push back to SP, and comment to the console, just to let me know how many things went in, from the items I got from Twitter. This whole class is wrapped into a single DLL for my purpose, and I call it from a console application that can run on a Windows scheduled job, takes parameters for SiteUrl, Twitter Search Term, etc. This was also used in a Windows forms application to show the insert of data.
Finally, when you start working with this off the server, and happen to not be on the domain… well what happens?
Luckily, the other end of the wire is basically a WCF endpoint, so you only need to work with it like you have used web services in the past.
After you create the context object, set the ClientAuthenticationMode to Anonymous, Default (windows), or Forms. And set the credentials to our old friend the NetworkCredential. (This was my case for a windows domain.)
Compile everything up, make sure to drop everything into try-catch blocks, and you now have Twitter data in your list… if you have not created your list yet, you can create a list from the custom template, just add the columns listed in the code above, and it should work just fine. Alternatively, you could create the list using the Client Object model as well! Just check for the list, if not there, create it in code, then connect to it.
Another alternative is post #3 which will come out tomorrow or Friday, in which I cover the last part of my talk, BCS .Net connector for the Twitter data.