Introduction
There truly is some new exciting releases that were part of 2013 release that were targeted for developers. In regards to development for SharePoint Online and Office 365 there are a bunch of new advancements that will allow for more development.
Back in 2004 I started to build Office and SharePoint solutions. I built a solution on InfoPath 2003, SharePoint 2003, BizTalk 2004 and K2.net 2003 that would integrate in a VAX mainframe with Office (solution was finalist at MS Worldwide Partner Conference). At the time I saw a vision how Microsoft was bringing together their enterprise solutions and I loved it. I stuck with it and saw the waves of SharePoint 2007 and 2010 change the industry.
Now with SharePoint 2013 and Office 2013, I have seen tremendous advancement in giving developers platforms to build solutions and supporting more flexibility to rapidly design, build and publish apps in a way I have never seen Microsoft do. I see significant strides in enabling developers to do SharePoint and Office development is rapid fashion. For me personally, the vision has completely come together.
- There are multiple options for developing solutions (Visual Studio, Napa, SharePoint Designer, SharePoint UI) providing me choice in how I can architect my solutions.
- SharePoint / Office have APIs and services that provide common interfaces making it extremely easy to integrate and to have consistency in design.
- The cloud is providing us flexibility in the delivery of software.
In the past I used spend a lot of time writing detailed blogs to explain solution architecture, design considerations, assumptions, etc. This time around Microsoft has actually written a series that has done a fantastic job at explaining this -
http://msdn.microsoft.com/en-us/library/office/apps/jj220030.aspx. This is required reading as far as I am concerned. Solution architects and developers can really use this information them make decisions on how to design and develop their applications. I highly recommend reading every article in the series.
In this blog will capture some of my notes and salient points you should know.
I will be focusing on SharePoint Online and Office 365 development.
SharePoint Apps
It is still possible to do SharePoint development the way many of you know how to do it today on-premise. You can do full trust and farm based development. There is definitely a need to continue to support these sort of high-end, deeply integrated solutions. However full-trust does have limitations:
- I personally feel that sometimes developers jump to0 quickly to full-trust based solutions versus looking at the longer-term solution.
- Cloud based SharePoint Online in Office 365 does not support this.
Initially Sandboxed Solutions, Silverlight and REST services were available to facilitate development in SharePoint Online. Sandboxed Solutions supported a limited set of server-side SharePoint code. What many people found out is that yes it was possible to create SharePoint solutions but there were gaps in development options.
With the new release of SharePoint 2013 in SharePoint Online several new solutions have been provided for us other than just Sandboxed Solutions / Silverlight.
- Client Side Object Libraries - From an App Dev perspective one of the biggest improvements you will see is around Client Side Object Libraries. Specifically .NET and JavaScript libraries have been introduced and can be utilized with SharePoint Online. Client libraries are very robust and provide APIs to work with BCS, lists, libraries, workflow, etc. This also includes new remove eventing models, new mobile development, etc. Here is a reference to those libraries - http://msdn.microsoft.com/en-us/library/office/apps/jj220040.aspx.
- REST Services - As well there is expanded support for REST services with more API support and new OData support. As you will see, this investment is the foundation for the new SharePoint Apps.
- Hybrid – It is not possible to create hybrid solutions with BCS, Search and REST services that unify data across both environments.
- Extending to Office – We will talk more about this later. There were many reasons why the SharePoint product was created by Microsoft. One was to provide a server in which Office could be delivered from. It initially started as a way to deliver and manage Office documents. With Office 2007, 2010 and 2013 clients we have seen direct integration with document library features. This vision was immensely expanded with Office Web Apps. Now with Office Apps, SharePoint and Office can be unified from a custom application perspective. Very exciting as I really think this is uncharted territory.
- The New SharePoint Apps Model – I cannot emphasize how important this is. If you want an overview of it please review this - http://msdn.microsoft.com/en-us/library/office/apps/fp179930.aspx. Apps can he hosted in SharePoint Online, hosted in Azure (auto hosted apps) or hosted on other platforms (Provider Hosted apps). SharePoint Online hosted apps are limited using HTML and SharePoint JavaScript which is very powerful. I would really challenge a developer to start building your SharePoint Online custom solutions there. Auto Hosted Apps is as it sounds, server side code you write is provisioned and executed out of Azure while still utilizing SharePoint to deliver pieces of the solution that the developer is building. Provider Hosted apps can be hosted in on-premise SharePoint, custom .NET applications, ASP.net, Java, PHP, LAMP, etc. It really does not matter where the app lives as long as it can use the API and REST services to integrate. With these new client libraries and OData support we are empowered to do this.
I would like to second here and really focus in on the New SharePoint Apps Model. I think this is great way to move forward. When I was consultant building customer applications on SharePoint 2003, 2007, and 2010 I would find that way too often well intentioned developers would quickly jump to building code for complex business operations and running them on SharePoint directly. Yes you have the power to do this because SharePoint is a platform. However in many cases good software design would have moved those processes off to another resource to run that code. Moving to the new SharePoint Apps model is really going to force developers to decouple their code and create the application layers they should have been doing from the beginning.
This is really where the industry is moving. Creating hosted applications and services that companies can quickly purchase without having own a complex on-premise deployment is what companies seek. This also goes for homegrown custom solutions created internally, build up you custom applications and then manage / deliver them to end users through SharePoint. Yes I know there are exceptions and it totally depends on the context of the solution you are creating. However I see the new SharePoint Apps model as a landmark change for SharePoint. With SharePoint Apps you can build applications on other platforms and then use all the services and API to integrate them. I see environment where companies procure or build solutions which just “hook into” SharePoint Online. SharePoint basically because the corporate portal from providing applications and these applications can leverage a customer’s existing investment in SharePoint. It really is truly exciting. Embrace it. Change for the right reason is good J
To help get your head wrapped around this, I highly recommend you read the following three articles:
Here are some other good reads as you start investigating SharePoint Apps:
Office Apps
From an Office perspective, I personally believe this is one of the areas where I think even more attention needs to be given. Building applications for Office has complete changed in Office 2013; the game has changed. If you recall the days of doing VSTO (Visual Studio Tools for Office) and all the hard work you had to do, those days are gone. The new Office Apps model takes on the same approach as SharePoint Apps.
How has the game changed? Now in you build applications in Office using HTML5, JavaScript, CSS, Rest Services and XML. Yes that is a total change. Now your developers are empowered to using development technologies that many organization have in house. The development is light weight and if you have any sort of web development experience, you will have a starting point for building Office Apps. It is basically a webpage that is hosted inside of an Office client application and it supports the ability for that web application and Office to communicate with each other.
Below probably one of the simplest high-level diagram that explains how Office Web Apps work. Basically a manifest is deployed into Office which knows about the externally hosted application and then provides the ability for the two solutions to integrate with each other. Office Apps can work with ASP.net, PHP, Java, etc. using these client based APIs. You have the flexibility to build Office Apps in the new Napa and Visual Studio.
You can build Office Apps in Word 2013, Excel 2013, Outlook 2013, Outlook Web App (OWA) 2013, PowerPoint 2013 and Project 2013. This really opens the realm of possibilities for apps that organizations of typically avoided because of the older complexities of doing Office development. Remember – it is very common in a business work place that Information Workers user Office at some point in their day. It is even arguable that many people spend several hours a week in Office. In many cases business processes are initiated or people need to go do “something” somewhere else.
For example:
- A user may receive and email, they need initiate a business process. How about providing an automated step to use the data in the email to initiate that business process.
- A user is building a data model in Excel and they need to pull in data using a set of control parameter. How about provide an app that can go retrieve that data and then move it into Excel.
- A user is building a Word document which needs data from various locations. How about an app that review that data and move it into the word document.
- A user is building a project plan and needs rates for users based on their classifications but that sort of information is managed in other financial systems. How about an app that can retrieve that data.
- A user needs to create a Word document and when finished that document needs to be submitted to another system. How about create a simple solution to move that document to that other system.
Hopefully you are seeing the potential. Since users do spend a significant amount of time in Office, why not use Office as a launch point enhance the business productivity experience.
If you are interested in getting started and learning about Office Apps, there are a ton of really good resources that are available to you. Please review the following:
Posts
