After lots of screwing around, including uninstalls, registry tweaks, bios updates…
I am working with SharePoint and Project Server CSOM (Client-Server Object Model) for both SharePoint and Project Server for some months now. This API is a replacement for the traditional XML/WCF web services exposed by both products for years now. The APIs are rational, consistent, and do not require the usual rigging for a web service (endpoint configuration, proxies, and the various other scaffolding required to consume the web services). These are all great improvements.
Note that the CSOM for both SharePoint and Project Server, to date, implement a subset of the functionality of the traditional web services—and performance work is ongoing in the product groups. Like anything new out of these SDKs, it takes investment to reach parity in feature completeness and performance. That being said, get on it Microsoft!
I found CSOM is repetitive and while vastly less costly in terms of key strokes, it is nonetheless bulky and disjointed. Also, because I tend to use both the SharePoint CSOM and the Project Server CSOM in the same project, I decided I was ready to put something together like mpFx. The term “mpFx” means “Microsoft Project Effects” or, what I prefer “Microsoft Project Feature eXtensions”, which is more descriptive.
I set out to design a single API for accessing SharePoint and Project Server through a single library, with the ability to request services from Azure such as Cloud Storage, Cloud Services, DocumentDB, Managed Cache Services, and others through a “late-bound factory”, so as not to burden the basic API. In addition to CSOM, the library will expose oData from both SharePoint and Project Server.
This new API is call OSoFx, pronounced OH-SO-FX—Office Server Online Feature eXtensions. OSoAFx maybe, as in Office Server Online and Azure Feature eXtensions—pronounced OH-SO-A-FX?
A combined API allows for myriad benefits, but in today’s post I want to demonstrate the differences in syntax and the brevity of the API.
The following operations are performed by both straight CSOM and OSoFx (both servers are Office Online):
1.) Setup credentials
2.) Create a connection to Project Server
3.) Create a connection to SharePoint Server
4.) Present the version numbers for both servers
5.) List the projects
6.) List the sites
7.) Show how long it took to do this
Here is a side-by-side, the first straight CSOM and the second OSoFx
There is a bit of work behind the scenes in OSoFx to make this work, but the fruits of labor can be used by others. More on this later!
In 2007, with the advent of Project Server 2007, I started the mpFx project to provide a simplied API for the Project Server Interface. That work has taken me a long way, including landing me a job in Microsoft Consulting Services and further down the road, a lead role at forProject Technologies. These days, I am focusing most of my technical effort on SharePoint/Project Server Online and Azure.
In the tradition of mpFx, I have started a new project called OSoFx, pronounced “oh-so F X”, which provides a single interface into SharePoint Online, Project Onine (including CSOM, oData, and PSI) and Azure.
More to come!
Starting with SharePoint 2010, a new integration technology was introduced called CSOM, or Client Side Object Model. The API is an alternative to using web services. It is a much cleaner API. Not only can you utilize CSOM in a .NET application such as WinForms or WPF, you can use it in your browser-based apps. If you prefer REST, you are in luck as it too is supported.
When Microsoft released Project Server 2013, the product group embraced the CSOM model . It is important to understand what it is capable of and its limitations. In Project Server 2013, many of the PSI web services you are accustomed to programming against are still available. Visit this page for the full set of types and examples to get you started.
Project Server 2013 supports both online and on-premise implementations. Using oData is really the best way to get at data which was once stored in the Reporting Database. Project Server’s oData reference can be found here.
One thing you will notice right away is that Project Server 2013 ships with a single database. The drafts, published, archive, and reporting database are combined and schemas are used to separate the various content containers.
The introduction of the Project Calculation Service puts the server-side scheduling engine to closer parity with the scheduling engine implemented in Project Professional. This a great new feature. For an overview of Project Server 2013’s architecture, visit this page.
In Project Server 2016, which is heading toward RTM, introduces even more changes. You can download Beta 2 here.
In 2016, Project Server is included in the SharePoint install by default—much like the Visio, Excel, and Access services. You still have to purchase a server license. Install SharePoint and run the configuration wizard just as you normally would.
To enable Project Server use the SharePoint PowerShell commandlet enable-projectserverlicense Y2WC2-K7NFX-KWCVC-T4Q8P-4RG9W. This will give you a fully featured 180 trail.
The PWA site provisioning UI is mostly gone. To create a PWA site, follow the steps below: