Search This Blog

Wednesday, April 1, 2015

SharePoint online - Provider hosted Apps - Part 1

This is a series of posts that gives an insight into design / development of provider hosted apps using SharePoint Online - Office 365 and Azure cloud.

Will include issues / challenges and best practices on the way. Please drop in your comments / questions / and feel free to forward the link.

-------------- Here we go..

There are only 2 choices to develop a SharePoint cloud app i.e.
SharePoint hosted and Provider hosted (Autohosted used to be another option earlier).

 .Net CSOM has its advantages for few reasons below (while there are good reasons for a preference on REST based apps also):

a)  Working with .Net client side libraries in Visual Studio gives good intellisense (which is also  available in JavaScript to an extent however not that good when compared with .Net)
Objects are strongly typed,  no typo issues in properties / methods.

b)  Working with azure side code - you get other useful features available from Azure i.e. Caching, Scheduled jobs which is not available if it is a SharePoint hosted app

c) IPR: Since .Net code runs on Azure Web Sites (now called Web Apps) it is not visible to end users specially if this is a product you are making. JavaScript also can be obfuscated however it is not as protected as code that is not visible on Azure.  All the dynamic UI functionality would still be in jQuery / JavaScript and that can not be avoided (unless you do not have any dynamic UI stuff in the app which is rare).

d)  Using 3rd party libraries is possible since we can add a reference to it in web project and use it from server side and/or client side. For example: i have used Telerik controls, Newtonsoft JSON.Net serializer. Please check if the 3rd party .Net dll can run on Azure. The above two i used on Azure web sites and they ran okay. The other option is to create a VM on azure where you can run any legacy software as well.

e)  Making modifications to App becomes easier if it being used by Multiple Tenants. We make changes in Azure and everyone gets the updated UI or business logic next time they run the app.

f) Scalable: Given it is on Azure - we can easily scale the application as needed.

Side Note: There are comparisons on Rest versus JSOM versus .Net CSOM which are plenty out there there on web. Using Rest or JSOM  is also fine - it is more of a suitability for a given requirement as well personal choice.


a) Need subscription to Azure which may add to the cost.

Note: While you may use your own App server on Internet also however setting up OAuth, security, patch management of server and other things may make that a complicated process. Also tight integration with VS.Net for Azure makes it very easy to work. Hence using Azure is recommended for a provider hosted app.

Now once we have design document ready for the App we come to using tools and processes that can be used for building the app.

UI Design Tool Choices
a) For prototyping UI - the best tool i have used is Axure. Provides even dynamic UI interface
and you can very quickly realize the benefits.

a)  Do we need any 3rd party control for UI. Example: complex hierarchical grid, server side binding of data to grid - then we can use a 3rd party control suite like Telerik / Component One etc.
They also have client side programming model available for UI controls which can be used thru JavaScript. Using those can save time in building our custom UI components. All the dynamic UI functionality would still be in jQuery / JavaScript on client side (browser). 3rd party DLLs will run on Azure web apps.

b) Design the UI just with jQuery and CSS - use Napa app by Microsoft.
It's a free app available from App Store in Office 365.
  1. For using data binding i.e. bind HTML to data from SharePoint -  get JSON data from JSOM / REST and use Knockout library to bind to that JSON. This is a different approach than the focus of this post and need another  blog post all together to describe the design / implementation.
  2. We can also use Napa to just build the UI and later move the UI to project. Could also help when multiple team members are working on the project. One on UI and other Azure side code. There are potential issues which need to be taken care while integrating (ToDo..write integration issues and solution link here...)
  3. For using Napa - we just need internet connection and a modern browser (and of course a office 365 account).  Also no need for VS.Net installed on your machine for this. Coming to browser - my preference is Firefox because of quick CSS mods within browser and a neat JavaScript debugger. One could have a browser preference and you are right if you have a different one.  
  4. The Napa app can be converted to a VS.Net project using a link within the napa tool on the left side. This will be app project of VS.Net solution. The other is the web project which contains the Azure code.

Question: Is it necessary to use Napa tool for a provider hosted App?
Answer: Not at all. We can build all the UI within VS.Net also.

To be continued in next Post...

Please write back with questions / comments.

-- Mohan

No comments: