Insight

Insight from Agora Consultants

SharePoint Hosted vs Provider Hosted Apps

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.

SharePoint hosted apps:

  • Written using JavaScript, HTML, and CSS

  • Hosted in SharePoint

    • When you install an app on a SharePoint site, a subsite is created called the “App Web”, this is where the app lives.

    • The “Host Web” is the site that you selected to install the app

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).

SharePoint Hosted Problems

From a developer perspective there is very little documentation around the Client-Side Object Model (CSOM), and zero documentation around the JavaScript Object-Model (JSOM) which made the creation of this app challenging to say the least. “Coding” in this case was the process of reading through the Microsoft JavaScript files calling different functions until I got 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 server queue.

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 areas.

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 apps.

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 the purpose.

No Scheduling

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 JavaScript app does not have the power to schedule and run timers because it’s 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 progress.

No Reporting

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 before.

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.

Provider Hosted Solution

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.

Error handling

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.

Scheduling

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).

Reporting

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).

Wrap Up

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.



 
Comments are closed