• Pros and Cons of the Access App for SharePoint 2013

    Why are Access 2013 Apps Great? Here are a few reasons…

    • They have a SQL Server backend
    • You can use SQL Server Reporting Services, Excel or any other tools that support SQL Azure or SQL Server over ODBC to generate reports on the Access App data
    • Views and navigation are created for you when you use App Templates or Tables
    • There are some new Related Item controls that make building views easy and they have a consistent look and feel
    • One Click Launch!
    • The Search functionality is built in and is intuitive

    What are SharePoint 2013 Apps?

    Before diving into the details on this new Access App, we should do a quick overview on SharePoint 2013 Apps in general. Included in this most recent version of SharePoint is the App Model. It enables developers to create custom apps that can be published to the Office Store for public download or to the Corporate Catalog which is an organization's internal App Catalog Site then users can download them to their SharePoint sites. Each app, whether custom or out-of-box, targets a specific set of features and are lightweight and easy to use. Included in the out-of-box apps is an Access App that enables Access 2013 databases to be added to SharePoint 2013 sites.

    What is the Access App?

    This out-of-box, no-code app enables us to put Access databases into SharePoint and includes some really great features (listed above) that I will get into a bit more detail in the following sections. The purpose of the app is to provide a more reliable, faster and robust solution for putting relational data into SharePoint without the hassle of designing and developing something from scratch. Microsoft Office Access 2013 includes a few templates for Access Web Apps and tables that will get you started.

    The Best Access App Feature

    The favorite is that its backend is SQL Server, or SQL Azure if you're using Office 365. This design allows data to display faster, is more reliable and robust plus long-term it's more manageable. It's a great alternative to creating a list in SharePoint when you know it will grow to be a "large list". Not only does it help manage large lists and provide quick access to the data, it also allows outside SQL Server and SQL Azure supported tools to gain access to the data.

    Want to know how it works?

    • When you create the app in Microsoft Office Access 2013, you choose the site where it will live.
    • In the process launching the app to SharePoint, a SQL database is provisioned that will house all the objects and data that the app requires.
    • The database that is created is specific to your app and by default not shared with other apps.
    • When you create a table in your app, a table is created in the database.
    • When you create a query in your app, a SQL Server View is created or if your query takes a parameter, a table-valued function is created.
    • When you create a Standalone Macro in your app, a Stored Procedure is created in SQL Server.
    • Views in Access are the parts of your app that display the data in the browser. These are also stored in the database but as text since they are HTML and JavaScript rather than SQL objects.

    Other Really Great Features that are Worth Mentioning

    When creating the Access App, you can select from one of the quick and easy templates or start from scratch with a custom app. When using one of the templates, Access automatically creates tables and related views around those tables. Also, the navigation is created for you so your database is ready to use. You would only need to add your customizations if you require any then click Launch App. That's it, in just a few clicks you have a working SharePoint App. Even if you're going with the Custom option, you still get a lot of automatic features like table templates that include multiple tables with relationships, related views and navigation. Either way, once you've designed your database, click Launch App and you have a no-code app in SharePoint that includes a search tool.

    Wondering about Workflows?

    The data in the Access App is stored in a SQL database and SharePoint doesn't have a mechanism that can get notified when items change in the external data source so the workflow couldn't be directly associated with one of the tables in your app. Using the linked table feature in Access to connect to a SharePoint list isn't going to help because that creates a read only connection. A possible solution would be to consume the external data in a workflow. You could create a site workflow or a list workflow and have it read or update from an external list. Basically it can be done but isn't going happen without some difficulty.

    Wrap it up…

    With this app, you can create web-based applications that use the power of SQL Server on-premise or in the cloud. You don't have to worry about deployment challenges, software installation issues or operating system compatibilities. You just build your app and share it across the web with SQL Server or SQL Azure. This new architecture increases performance and scalability and opens up new opportunities for SQL Developers to extend and work with the data. It has potential of being a really great app. Add built-in features like full read/write when connecting to SharePoint lists and workflows and you've got a truly awesome out-of-box solution.

    A Note on SharePoint 2010 vs. SharePoint 2013 Access Services

    SharePoint 2010 also has Access Services but the process around how the Access databases are put into SharePoint is very different. The tables in the 2010 database are converted into SharePoint lists so you don't get the SQL backend. These Web Databases are compatible with SharePoint 2013 and Access 2013 but you cannot create new Web Databases in Access 2013, you are only able to manage existing ones and publish them to either SharePoint 2010 or 2013. Also, there is no way to automatically convert the Web Database into an Access App. You will have to do this manually which consists of importing the data from the Web Database into the new Access App then recreate the interface and business logic.
  • Planning for a SharePoint Migration

    1. Document Existing SharePoint Server's Topology (preferably in Visio format, use Visio diagrams to represent the existing SharePoint Farm topology),Roles, Hardware/Software Specifications, Installed Updates, Software installed, Language Packs, etc.

    2. Prepare a List of SharePoint Web Applications, Site collections, Managed paths, Host headers, Content /Service Application Databases, service application proxies & service application groups.

    3. Document Central Administration Settings like User Policies, Quota Templates, Data connections, Zones, AAM, Quota Templates, Blocked File Types, Log file paths, etc.

    4. Document All Third-party Software installed on top of SharePoint (Like Nintex workflows, Axceler ,Metalogix Control Point

    5. Document Inventories & customizations like Solutions( wsp files), Workflows, Event Handlers, Web Parts, Features, Assemblies, Site Templates, Site Definitions, Custom Timer jobs, etc. (stsadm -o enumallwebs -includewebparts -includefeatures)

    6. Document Active directory Domains/Forest details. This will help in configuring User Profile Import connection sources, People Picker configurations.

    7. Document Current environment Out of the box Features enabled (Such as Publishing), Enterprise feature Enabled (such as InfoPath Farm Services)

    8. Document Outgoing, Incoming E-mail settings of the SharePoint server

    9. Document all IIS customizations made manually, like Web.config modifications, Add-ons installed in IIS (like Compression, URL Rewrite, HTTPHandlers etc)

    10. Document SQL Server configurations, Content DB sizes, Mirroring, Clustering configuration details

    11. Document any custom solutions deployed in Layout's folder or BIN folder.

    12. Prepare a report on User base with Total no. of users, avg concurrent users, etc

    13. Document custom scripts, automation tools you are running from SharePoint servers (like Monthly storage report generation script, scheduled with windows task scheduler)

    14. Make a Note of current environment's Information Architecture, including Managed Paths, Top navigation, etc.

    15. Document existing Farm's service accounts. Authentication method for all web application .Kerberos applied?

    16. Document Search Settings, including content sources, schedules, Keywords, Best-bets.

    17. Document Email Enabled Lists and Libraries

    18. What is the current Disaster recovery plan? How often backups are taken? Third party software integrated with SharePoint (Like AvePoint, DPM, etc)

    19. Document Infrastructure details such as Load balancer, DNS, IPs, SSL Certificates, Publishing configurations (Like F5, TMG, ISA Server, etc)

    20. Document 12/14 hive Layout folder customizations, File system changes if any

    21. Make a note of all InfoPath Form libraries. You have to update the Form Template URL and You may have to Change the data connections, etc.

    22. Existing Branding Artifacts like Master pages, Themes, CSS Files, Logos, etc.

    23. Document the custom authentication providers (Forms, LDAP, etc) if any

    24. Document the current Monitoring setups like SCOM.

    25. Last but not least - Make sure you have the version control system (like CVS, SVN, TFS, etc) which has all the artifacts including source code, installers, deployment guides.
  • What is Office Web apps server and why do you need to care?

    Office Web apps is an online office suite offered by Microsoft that can allow users to create and edit Office files using lightweight , web browser-based versions of Microsoft Office applications : Word ,Excel ,PowerPoint and One Note.

    So as mentioned above Office Web apps ( currently knows as Office Online) is a product that was developed by Microsoft to interact with SharePoint Server 2013 ,Exchange Server 2013 and Lync Server 2013 which can help the users in viewing/editing and sharing office files.

    Let’s take a look at how Office Web apps work with each of this product separately:

    Office Web apps with SharePoint Server 2010:

    So until SharePoint Server 2010, Office Web apps used to be a component of SharePoint and it was not a standalone product as it is currently. Deploying Office web apps for SharePoint 2010 includes the below mentioned steps.

    1. Installing Office Web apps setup.exe
    2. Activating the Office web apps services –>Starting the required service in CA , creating the service application and service application proxies
    3. Activating the Office Web apps feature in the site collection.

    Also in SharePoint Server 2010 there was no need to patch Office web apps separately as the SharePoint patches also included the Office Web apps patches. So any issue that happens to SharePoint as a product will have an impact on Office web apps as well.

    Office Web apps with SharePoint Server 2013:

    So with SharePoint Server 2013, Microsoft took a big step ahead and removed Office web apps from SharePoint .What this means is, the bits and binaries that install SharePoint Server 2013 will not have Office web apps as part of it. Its standalone product now and needs to handled and taken care separately.

    Note: I’ve noticed a lot of customers who think that Office web apps can support Visio files as well. That’s never ever the case and SharePoint Server 2013 uses Visio service to do that .Please refer to my post on Visio Service to know more about it.

    So in a nutshell, SharePoint Server 2013 when integrated with Office Web apps provides updated versions of Word Web App, Excel Web App, PowerPoint Web App, and OneNote Web App. Users can view and, in some cases, edit Office documents in SharePoint libraries by using a supported web browser on computers and on many mobile devices, such as Windows Phones, iPhones, iPads, Windows 8 tablets, and Android devices.

    Later in this article I’ll be discussing more on Office webs apps and SharePoint Server 2013 ….

    Office Web apps with Exchange Server 2013:

    With Exchange 2007 and 2010, Outlook Web Access/App [OWA] users can preview documents attached to e-mails directly from their browser. This feature, known as “Web Ready Document Viewing” which converts supported documents (Word, Excel, PowerPoint or PDF) to HTML and displays them in the web browser, allowing users to read Word documents, for example, without the need to have Word installed or first downloading the file.

    Whenever a user receives an e-mail with a supported attachment, an “Open as Web Page” link appears next to the attachment:

    All the user needs to do to preview the attachment is click on the link and the WebReady Viewing version of the document will open.

    With Exchange Server 2013, there is another method of viewing Office docs. Here you can integrate your Exchange server 2013 with Office web apps .Once that’s done the attached Office document makes a WOPI [Web App Open Platform Interface] call to the Office webs app server to render the document.

    Note: Office Web apps cannot open Office files which are IRM [Information Rights Management] enabled.

    Office Web apps with Lync Server 2013:

    In Lync Server 2010, PowerPoint presentations are viewed in one of two ways. For users who run Lync 2010, PowerPoint presentations are displayed by using the PowerPoint 97-2003 format and they are viewed by using an embedded copy of the PowerPoint viewer. For users who run Lync Web App, PowerPoint presentations are converted to dynamic HTML files then viewed by using a combination of the customized DHTML files and Silverlight. Although generally effective, this approach did have some limitations:

    1. The embedded PowerPoint Viewer (which provided a more optimal viewing experience) is available only on the Windows platform.
    2. Many mobile devices (including some of the more popular mobile telephones) do not support Silverlight.
    3. Neither the PowerPoint Viewer nor the DHTML/Silverlight approach supports all the features (including slide transitions and embedded video) found in the more recent editions of PowerPoint.

    To help address these issues, and to improve the overall experience of anyone who presents or views PowerPoint presentations, Lync Server 2013 uses Office Web Apps Server to handle PowerPoint presentations. Among other advantages, this new approach allows the following capabilities:

    1. Higher-resolution displays and better support for PowerPoint capabilities such as animations, slide transitions, and embedded video.
    2. Additional mobile devices can access these presentations. That’s because Lync Server 2013 uses standard DHTML and JavaScript to broadcast PowerPoint presentations instead of customized DHTML and Silverlight.
    3. Users who have appropriate privileges can scroll through a PowerPoint presentation independent of the presentation itself. For example, while User A is presenting his slide show, User B can scroll through and view any slide she wishes, all without affecting User A’s presentation.

    So with that being said, let’s take a look at the supported Office file formats for Office Web Apps

    Supported file formats:

    Word documents (doc, docx, dotx, dot, dotm extensions)

    Excel documents (xls, xlsx, xlsm, xlm, xlsb extensions)

    PowerPoint documents (ppt, pptx, pps, ppsx, potx, pot, pptm, potm, ppsm extensions)

    *Also once again, please do remember that Office web apps doesn’t support IRM protected files.

    More on Office web apps with SharePoint Server 2013 ……

    Listed below are the features you get when you use Office web apps with SharePoint Server 2013:

    The viewing and editing capabilities of Office webs apps on different devices is given below:

    Now, being a SharePoint Farm Admin/Site collection admin you get to decide how your users can view office files in the document library. There are two ways to change the default behavior so that files open in the client applications (or the default PDF reader) instead:

    For the entire SharePoint 2013 farm : You ( The Farm admin) can adjust the default open behavior on a per-file-type basis for the SharePoint 2013 farm by using the New-SPWOPIBinding and Set-SPWOPIBinding Windows PowerShell cmdlets. These cmdlets can also be used to adjust the behavior of PDF documents.

    In site collections or document libraries : Site collection administrators and users can use the OpenInClient feature in SharePoint 2013 to specify whether Office files will be opened in the client application or in the browser. Users can change this setting in the document library properties, and site collection administrators can change it in Site Collection Administration or by using the “Enable-SPFeature” cmdlet to enable the OpenInClient feature.

    Now there are certain things which you might need to pay attention to being an IT Pro, you can configure Office web apps for your SharePoint server 2013 farm so that the Office files in the document library make a WOPI call to Office web apps server (a single machine/farm processing the request for all type of Office file i.e. word,excel,powerpoint and One note) to render the document or you can configure an Office web apps farm so that each machine in that farm can take care of processing the request for each file types.

    PowerPoint–>A single Office web apps machine to process the request for PowerPoint files alone

    Word –>A single Office web apps machine to process the request for Word files alone

    Excel–>A single Office web apps machine to process the request for Excel files alone

    One Note–>A single Office web apps machine to process the request for One Note files alone.

    This option can give you better scalability, however it’s going to cost you a lot.

    How to know whether I’m using Excel online, Excel services or Excel Web app while I’m opening an Excel file? If the URL resembles “http://[servername]_layouts/15/xlviewer.aspx?id=/Documents/…” then Excel Services is used to render the workbook.

    If the URL resembles “http://[servername]/_layouts/15/WopiFrame2.aspx?sourcedoc=/Documents/…” then Excel Web App is used to render the workbook.

    Difference between Excel Web App and Excel Services in SharePoint:

    Excel Web App and Excel Services in SharePoint have a lot in common, but they are not the same. Excel Services is available only in the Enterprise edition of SharePoint Server 2013. Excel Web App is available in SharePoint Server 2013 and SharePoint Foundation 2013. Both applications enable you to view workbooks in a browser window, and both enable you to interact with and explore data.

    But there are certain differences between Excel Web App and Excel Services in SharePoint. For example, Excel Services supports external data connections, data models, and the ability to interact with items that use data models (such as PivotChart reports, PivotTable reports and timeline controls). Excel Services provides more business intelligence functionality than Excel Web App, but Excel Services does not enable users to create or edit workbooks in a browser window.

    If your organization decides to use Excel Services instead of Excel Web App to view workbooks in the browser, you can use the Windows PowerShell New-SPWOPISuppressionSettings cmdlet to turn off Excel Web App for Excel workbooks.

    Office Online File Support:

    Here are file types and formats supported in each of the four Office Online applications.

    Word Online:

    Supported for viewing and editing Supported only for viewing Cannot be opened
    Word Document (.docx) Word 97-2003 Document (.doc)** Rich text format (RTF)
    Word Macro-Enabled Document (.docm)* Word 97-2003 Template (.dot) Hypertext Markup Language (HTML)
    OpenDocument Text (.odt) Word Template (.dotx) Multipurpose Internet Mail Extensions HTML (MHTML)
    Word Macro-Enabled Template (.dotm)* IRM-protected documents
    Portable Document Format (PDF)** Password-protected documents
    Documents with digital signatures

    *The document can be opened, but macros do not run.

    **For editing, Word Online saves a new copy of the document in .docx or .dotx format. Word Online can’t save documents in the .doc or .dot formats.

    Excel Online:

    Supported for viewing and editing Supported only for
    Cannot be opened
    Excel workbook (.xlsx) Portable Document Format (PDF) Excel 97- Excel 2003 Workbook (.xls) **
    Excel binary workbook file (xlsb) Excel 97- Excel 2003 Template (.xlt)
    Excel macro-enabled workbook (.xlsm)* Excel Template (.xltx)
    OpenDocument Spreadsheet file (.ods) Comma separated values (CSV)
    IRM-protected documents
    Password-protected documents
    Documents with digital signatures

    *The workbook can be opened, but macros do not run.

    **On OneDrive.com this format can be viewed. To edit, Excel Online saves a new copy of the document in .xslx format. Excel Online can’t save documents in the .xls format.

    PowerPoint Online:

    Supported for viewing and editing Supported only for
    Cannot be opened
    PowerPoint Presentation (.pptx) PowerPoint Template (.potx) PowerPoint Add-in (.ppam)
    PowerPoint Show (.ppsx) PowerPoint 97-2003 Template (.pot) Rich Text Format (RTF)
    OpenDocument Presentation (.odp) (.odp) PowerPoint 97-2003 .ppt and .pps* Portable Document Format (PDF)
    PowerPoint Macro-Enabled .pptm, .potm, and .ppsm** PowerPoint 97-2003 Add-in (.ppa)
    Portable Document Format (PDF) IRM files
    Password files
    Files with digital signatures

    * The presentation can be opened, but macros do not run.

    ** For editing, PowerPoint Online saves a new copy of the document in .pptx format. PowerPoint Online can’t save documents in the .ppt or .pot formats.

    OneNote Online:

    Supported for viewing and editing Cannot be opened
    OneNote 2010 and later notebooks (.one) OneNote 2003 or OneNote 2007 notebooks (.one)
    OneNote Package (.onepkg)
    Portable Document Format (PDF)

    I guess this pretty much sums up everything you need to know about Office Web apps. Thanks for reading this post. Happy Share Pointing!!!!
  • Installing Office Web Apps

    Office Web Apps 2013 is a stand-alone server web application that provides capabilities to open and render a Microsoft Office Word, Excel, PowerPoint, or OneNote document as a web page. Microsoft SharePoint 2013, Exchange 2013, and Lync 2013 can share the rendering service to display Office documents in those applications as a web page. Additionally, when accessed from within a SharePoint 2013 farm, Office Web Apps also enables rich editing features for those documents.

    Note: You cannot install Office Web Apps on the same server as SharePoint 2013

    Please follow the server preparation process in the following sections for the appropriate server, either Windows Server 2008 R2 or Windows Server 2012.

    Windows Server 2008 R2 Preparation

    Start by installing the following prerequisite software for Windows Server 2008 R2:

    Open a PowerShell command running as an Administrator and execute the following commands to install the required roles and services for Office Web Apps.

    Import-Module ServerManager
    ## Run the following command as a single line
    Add-WindowsFeature Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,Web-Security,Web-Windows-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Ink-Handwriting,IH-Ink-Support

    Please continue with the “Office Web Apps Installation” section below.

    Windows Server 2012 Preparation

    To begin, open a PowerShell command running as an Administrator and execute the following commands to install the required roles and services for Office Web Apps.

    Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices

    Please continue with the “Office Web Apps Installation” section below.

    Office Web Apps Installation

    Open and run the Office Web Apps setup.exe media to launch the setup wizard.

    1. In the Office Web Apps Server 2013 Wizard, on the Read the Microsoft Software License Terms page, select I accept the terms of this agreement and then select Continue.

    2. On the Choose a file location page, select the folder where you want the Office Web Apps Server files to be installed (for example, C:\Program Files\Microsoft Office Web Apps), and then select Install Now. Note that, if this folder does not exist, Setup will create it for you.
    The Choose a file location screen on the Office Web Apps install wizard.

    3. When Setup finishes installing Office Web Apps Server, choose Close.

    After installing the Office Web Apps 2013 server software, you are ready to install any additional add-ins and updates. You can also install any language packs your farm requires. To install the language packs, run the setup media for each of the language packs you desire.

    If applicable, install the latest service pack Microsoft has released for Office Web Apps 2013 and then apply the latest service packs Microsoft has released for Office Web Apps 2013 language packs.

    Finally, check for updates on Microsoft Update in the server’s control panel.

    Configuring Office Web Apps

    This section describes how to configure an Office Web Apps farm and join servers to it.

    Important: Low memory conditions can cause Office document previews to fail in Office Web Apps. Verify that any servers that run Office Web Apps have sufficient memory.

    On the first server for the Office Web Apps farm, execute the following PowerShell command to provision the farm:

    New-OfficeWebAppsFarm -InternalUrl "https://office1.contoso.com" -ExternalUrl "https://office.contoso.com" -SSLOffloaded –EditingEnabled

    The SSLOffloaded command switch configures Office Web Apps for hardware load-balancing, where the load-balancing device manages the SSL certificate and then relays the request to an Office Web Apps server over HTTP unencrypted traffic. This improves the overall performance but does require a secure network between the load-balancer and the Office Web Apps servers.

    The following image provides an example of the expected output from the PowerShell command.

    PowerShell results from configuring an Office Web Apps farm

    Critical: Before you can use the Office Web Apps farm, you must add your domain to the list of allowed hosts.

    Run the following PowerShell command to add your domain to the list of allowed hosts, substituting your domain for “contoso.com.”

    New-OfficeWebAppsHost -Domain contoso.com

    Once you have provisioned an Office Web Apps farm and allowed your domain, you can join additional Office Web Apps servers to the farm. To join additional servers, install the Office Web Apps software by following the steps in the previous section and then execute the following PowerShell command.

    New-OfficeWebAppsMachine –MachineToJoin “office1.contoso.com

    You can test the Office Web Apps configuration by navigating to this URL and verifying it displays a Web app Open Platform Interface (WOPI)-discovery XML file:

    (replacing office.contoso.com with your OWA external domain)

    Note: For more information on deploying and configuring Office Web Apps, please see this TechNet article: http://technet.microsoft.com/jj219455

    Configuring the Windows Firewall for Office Web Apps Traffic

    On each Office Web Apps 2013 Server, you will need to set a firewall rule to allow Office Web Apps inter-farm traffic and HTTP/HTTPS traffic. Alternatively, you can disable the Windows Firewall if you choose and if you have another firewall solution.

    You can set the Windows Firewall rules by navigating to the Control Panel, then click System and Security, then click Windows Firewall, and finally click Advanced settings. In the Inbound Rules area, ensure that the server allows connections on port 80 (HTTP) and port 443 (HTTPS). Add the port for the Office Web Apps inter-farm communication by following these steps:

    1. In the Windows Firewall with Advanced Security window, click Inbound Rules.
    2. In the Actions panel, click New rule…
    3. In the New Inbound Rule Wizard window, select Ports as the Rule Type and click Next.
    4. Select TCP and enter “809” for the Specific local ports. Click Next.
    Windows Firewall Port Rule for Office Web Apps communication

    5. Click Next. On the Profile screen, uncheck Public and click Next.
    6. On the Name screen, enter “Office Web Apps Inter-Farm Communication” and click Finish.

    Configuring a SharePoint 2013 Farm for Office Web Apps

    Logon to the SharePoint application server that hosts Central Administration and open the SharePoint 2013 Management Shell (PowerShell), running it as an administrator. Next, enter the following PowerShell command:

    New-SPWOPIBinding -ServerName “office1.contoso.com

    Run the following PowerShell command to enabled OAuth over HTTP.

    $config = (get-spsecuritytokenserviceconfig)
    $config.allowoauthoverhttp = $true

    Run the following PowerShell command to change the WOPI zone to external-https.

    Set-SPWOPIZone –zone “external-https”

    Finally, verify that Office Web Apps is working by navigating to a SharePoint 2013 document library and verify that you can open a document as a web page.

    Note: For more information on how to configure a SharePoint 2013 farm to use Office Web Apps and for troubleshooting information, please see this TechNet article: http://technet.microsoft.com/ff431687
  • The SharePoint 2013 app model provides two broad approaches to hosting your apps for SharePoint:
    • SharePoint-hosted
    • Cloud-hosted
    Within the cloud-hosted approach there are two important subcategories:
    • Provider-hosted
    • Auto-hosted
    These are not exclusive categories: An app for SharePoint can have both SharePoint-hosted and remotely hosted components. Each approach has key features you should consider when deciding how to host your apps.

    SharePoint Hosted App

    Figure 1: SharePoint-hosted apps

    SharePoint hosted app runs within the context of SharePoint, but there is no server side code. Any kind of logic is going to run in the client side using JavaScript. You can leverage some of the SharePoint artefacts like lists, document libraries, pages without code behind and out of the box web parts. SharePoint-hosted apps for SharePoint are installed on a SharePoint 2013 website, called the host web, and that have their resources hosted on an isolated subsite of a host web, called the app web.

    Cloud-hosted apps

    Figure 2: Cloud-hosted apps

    In cloud hosted apps, the logic resides outside of SharePoint. The logic can reside either on IIS server OR Windows Azure OR some other cloud solution and it is going to talk to SharePoint using client side object model (CSOM) or REST services and have to be granted permission to SharePoint using OAuth.

    Within this category there are two types of apps:
    • Provider hosted
    • Provider-hosted apps for SharePoint includes components that are deployed and hosted outside of the SharePoint farm, usually by the developer. The provider-hosted app for SharePoint interacts with a SharePoint 2013 site but also uses resources and services that reside on the remote site.This approach enables you to use any hosting service you want, but it places the responsibility for creating the installation, upgrade, and uninstallation logic of the remote components on the developer.

    • Auto-hosted
    • Apps that include a Windows Azure Web Site, and possibly also a SQL Azure database, that are automatically installed when the app is installed. The Windows Azure web site and optional SQL Azure database can be included in app package, such that when you provision the app, it automatically creates Windows Azure web site and optional SQL Azure database in Azure. If you are using auto hosting for your app, each installation of the app provisions its own Windows Azure web site. The Windows Azure web sites infrastructure handles load balancing, multi-tenancy, and other important maintenance tasks for you.

    Note: Cloud-hosted app is the most preferred hosting model for almost all apps. You can get full power of the web, you can choose your infrastructure and technology, you can run in IIS or in Windows Azure or even on other non-Microsoft infrastructure. Whereas SharePoint hosted apps is good for smaller apps with limited resource storage.

    App Shape and Branding

    When you build SharePoint apps, one of the design decision is how apps are going to look like and be presented to the user. To design the user experience of the app, you need to understand the following:
    • App Shape
    • Branding
    Apps for SharePoint fit seamlessly into the SharePoint website where they are installed.
    Figure 3: App Shapes option

    As shown in figure above, the apps can have three possible type of shapes:

    Immersive: An app for SharePoint provides a fully immersive experience and optionally can extend some of the existing UI, such as in menus, or by providing embeddable parts for other pages. Immersive apps will take entire browser experience.

    App Part: App parts surface an IFrame element that contains content from your app. Imagine these apps as the ones which add something like a web part to the SharePoint site e.g. weather monitor app. An App Part is nothing but a type of Web Part that is represented by the ClientWebPart class. This kind of Web Part is essentially a wrapper for an IFrame that would host a page of the app.

    Extension App: You need to use extension app when you create new actions for documents or list items. Ribbon or context menu extensions make your app available on list items, documents, or anywhere else a ribbon is shown. An app can add links like ribbon, custom actions or ECB menu to the host web. When user will click on the link, user will be redirected to the app web.

    All apps have a default page which might take the full page. Apps show custom action or app part in the host web. The app might take the full page by redirecting user from host web url to app web. For example, the host web url is http://www.hostweb.com and an app is installed in the host web which adds a custom action. When user clicks the custom action, the user will be navigated to a new url (say, http://www.appweb.com). So the app takes the full page (so it’s called Immersive Full page). However user will not notice the url changes as the new app site will have the same UI look and feel. The idea of having the app web to have similar look and feel like host web is achieve thorough a new concept in SharePoint 2013 – called Chrome Control. This is a javaScript based object that allows custom app to consume and import the css and stying of the hosting parent appweb. Also the chrome control create a SharePoint 2013 ribbon bar in the app site, so that user can navigate back to the hot web.
    Figure 4: Chrome control in a web page

    Apps Branding

    Microsoft has recommended design process as well as basic guidelines for developing quality user experiences for apps. Refer to this link UX design for apps in SharePoint 2013 to understand the recommended UX design process for apps for SharePoint.

    Developers are going to primarily use three different types of branding:

    App Template: The app template is the default branding option in Visual Studio when you create an app web and pages within that web. The app template can be used only for SharePoint-hosted ASPX pages. The template includes the app.master master page.

    Chrome Control: This is a JavaScript based object that allows custom app to consume and import the css and stying of the hosting parent appweb. If you’re not building SharePoint-hosted ASPX pages, but you still want your app to fit in naturally with the host site that it is used from, the chrome control is the right choice.

    Custom Branding: If, instead of aligning to the host site’s theme and fitting into the SharePoint site where your app is installed, you want to use your own brand inside your app, you will have to build your chrome from scratch. However, you should still have a “back to site” link in the upper-left corner of the page that redirects the user back to the site where the app is installed.
2013 © SharePoint Engine All rights reserved. Developed By Binary Republik