Everyone knows the
technical differences, but this blog will explain the impact of each on a real
world scenario. The Agora Bulk Updater was developed in both technologies and
we will look at the strengths of each.
I will briefly touch on the technical differences of each
just for the sake of completeness.
Provider Hosted Apps:
The web site and all functionality are hosted on
a server (in the cloud or in house)
Any technology can be used to develop the site
(because it’s just a plain web server)
A SharePoint app must still be installed on the
SharePoint site, but it acts as a link to the web site running on the external
server (no “App Web” is created)
Typically given the above options, developers would prefer
provider hosted because they can use any technology to develop the web site,
while people that sign cheques would prefer the SharePoint hosted option
because hosting and maintaining a server is more expensive than not doing so.
This debate happened at Agora and it was decided to create the Bulk Updater as
a SharePoint hosted app (to my disappointment).
From a developer perspective there is very little
documentation around the Client-Side Object Model (CSOM), and zero documentation
challenging to say the least. “Coding” in this case was the process of reading
a result that I could work with. This made the progress slow, difficult, and
tedious. It’s worth mentioning this fact because it is what Project Server
developers will have to face if creating a SharePoint hosted app.
The app worked as below.
Step 1) Choose fields & filters
Step 2) Pick new values for projects (lookup fields show as
drop downs, date fields as date pickers etc.)
Step 3) Click Publish and be redirected to the project
The look and feel was cool. All of the UI elements we
commonly use are jQuery based, so a SharePoint hosted app did not limit us in
this way. From a functional point of view the solution was lacking in some
No Error Handling
Yes. You read correctly. The JSOM did not throw any errors
if the project could not be published. Once you perform step 3) (click publish)
the only way to determine if the JSOM accepted the request was to check the
Project Server queue. If the project was not there, the user would have to
perform all the steps again and hope for the best.
To test if it was my code or a bug in the JSOM, I purposely
assigned the wrong data to certain fields (numbers to date fields, invalid
lookup values etc.), and not once did the JSOM return any error or yield any
feedback on what was wrong. This was a huge red flag for SharePoint hosted
Some of you might be thinking “OK, but why not create a web
service, call it using standard jQuery, and have it use the CSOM from C#? You
can’t say SharePoint hosted apps are bad just because of the JSOM”. Remember
the whole reason why SharePoint hosted apps are attractive in the first place?
No hosting. Creating a custom web service to be hosted somewhere would defeat
Let’s say you are a Project Server admin and you need to
update all of your projects to assign a value to a new custom field. Because of the size
of the update, you need to run this process on the weekend. A SharePoint hosted
just a simple web page. Most organizations (in my experience) would not dare to
run a tool like this during business hours on a large scale. In this case, you
would have to login in at night/weekend to schedule the job and babysit its
Who changed what and when? What percentage of updates fail?
These are critical questions that need to be answered. It is unacceptable in a
real world scenario to perform a large update and have no record of what
happened afterwards. Sure, you could look at the project server queue and see
which projects were updated, but not which fields, or which values they had
Eventually, these three issues were too much to ignore and
the decision was made to convert this to a provider hosted app. This is where
it became awesome.
The look and feel remained the same, but the back-end changed
dramatically. With a server running IIS and a windows service monitoring a
database queue, we solved all the issues mentioned above.
We now had full visibility with the CSOM to determine which
projects and fields failed to update. These errors were logged to the database
and used for post-update analysis.
Step 3) changed from “Click Publish” to this window:
The user can choose the time to process, to skip checked-out
projects (as opposed to forcing them in), and whether they want an email
notification when the job is done. The windows services handles all of this functionality,
none of which would be possible from a SharePoint hosted app.
Furthermore, we can store complex settings in the database
like processing windows, this way you can ensure that any large update jobs
will only be processed during off hours (or whatever you configure).
This problem as well was resolved. Simply by logging
information to a database, users can see what happened and what is going to
happen (and even cancel future jobs as well).
As a developer I need to stress that developing a provider
hosted app was much easier to produce and it also allowed us to create more
functionality in less time. I understand that for a project sponsor deciding NOT to host a server is always cheaper than hosting one, but I challenge that. The alternative is a half-baked app that will add little
value to any organization.