SharePoint 2013 App's Configuration, Design, Development & Deployment

SharePoint 2013 apps are one of the coolest feature which everyone wants to have a look into it.The most important change in SharePoint 2013 for developers is the introduction of SharePoint apps. An app for SharePoint is a small and isolated application that provides a specific bit of functionality. SharePoint apps can and have to be added to or removed from a site by the site owner.  Apps have their own, isolated URLs, which are separate from the URLs of the sites where the app is being deployed to and where the app is being used. In order to provide isolation apps run in their own domain, instead of in the same domain name as your farm. Using a different domain name for apps helps prevent cross-site scripting between apps and SharePoint sites.
Each installation of an app has its own unique URL within the app domain. The app’s URL is based on a template “http://[app prefix][app ID].[app domain]/[relative site url]/[app name]. When you add an app to a site, a subweb of that site is created to host the app content. This subweb is not visible on the Site Contents page though.

Because apps run in their own app domain you will have to configure Domain Name Services (DNS) in your environment in order to be able to host apps.

Configure an environment for apps for SharePoint (SharePoint 2013).
Before you begin

 

•  You must purchase a domain name from a domain name provider for your apps, for example: polasoft.com.
• You must be a member of the Farm Administrators group to perform the steps in this article. For some steps, you must also be a domain administrator on the domain controller.
• Confirm that the SharePoint Administration (spadmin) and SharePoint Timer (sptimer) services are running.
• To verify this, click Start, point to Administrative Tools, and then click Services. In the Services list, verify that the SharePoint Administration and SharePoint Timerservices are running.

Configure the domain names in DNS (all hosting options)

You must configure a new name in Domain Name Services (DNS) to host the apps. To help improve security, the domain name should not be a subdomain of the domain that hosts the SharePoint sites. For example, if the SharePoint sites are at polasoft.com, consider polasoftApps.com instead of App.Polasoft.com as the domain name. When an app is provisioned, it provisions a unique DNS domain name (for example, Apps-12345678ABCDEF.polasoftApps.com, where 12345678ABCDEF is a unique identifier for the app).

To create a forward lookup zone for the app domain name

1.     Verify that the user account that performs this procedure is a domain.administrator on the domain controller.

2.     Click Start, point to Administrative Tools, and then click DNS.

3.     In DNS Manager, right-click Forward Lookup Zones, and then click New Zone….

4.     In the New Zone Wizard, click Next.

5.     In the Zone Type page, accept the default of Primary zone, and then click Next.

6.     In the Active Directory Zone Replication Scope page, select the appropriate replication method for your environment (the default is To all DNS servers in this domain), and then click Next.

7.     In the Zone Name page, in the Zone name box type the name for your new app domain name (for example, polasoftApps.com), and then click Next.

8.     The New Zone Wizard shows the new domain name for apps.On the Dynamic Update page, select the appropriate type of dynamic updates for your environment (the default is Do not allow dynamic updates), and then clickNext.

9.     On the Completing the New Zone Wizard page, review the settings, and then click Finish.

To create a wildcard Alias (CNAME) record for the new domain name

1.             Verify that the user account that performs this procedure is a domain administrator on the domain controller.

2.             In DNS Manager, under Forward Lookup Zones, right-click the new app domain name, and then click New Alias (CNAME).

3.             In the New Resource Record dialog box, in the Alias name (uses parent domain if left blank) box, type *.

The Fully qualified domain name (FQDN) box displays *. followed by the domain name that you created for apps. For example, *.polasoftApps.com or *.polasoft-Apps.com.

4.             Next to the Fully qualified domain name (FQDN) for target host box, type the FQDN of the server that hosts the SharePoint sites.

For example, SharePoint.polasoft.com.

Or:

a.             Next to the Fully qualified domain name (FQDN) for target host box, click Browse and navigate to the Forward Lookup Zone for the domain that hosts the SharePoint sites.

For example, polasoft.com.

b.            And then navigate to the record that points to the server that hosts the SharePoint site.

For example, SharePoint.

5.             Click OK.

Verify the new domain name

1.             Verify that the user account that is performing this procedure is a domain administrator on the domain controller.

2.             Click Start, and then click Command Prompt.

3.             At the command prompt, type ping followed by a subdomain of the domain that you created, and then press ENTER.

For example, ping Apps-12345678ABCDEF.polasoftapps.com

If the ping command returns the correct IP address, then your wildcard for the domain name was configured successfully.

Configure the Subscription Settings and App management service application

To configure these services, you first start the services in Central Administration. After the services are started, you use Windows PowerShell to create the Subscription Settings service application, and then use either Windows PowerShell or Central Administration to create the App Management service application.

To start the Subscription Settings and App Management services in Central Administration

1.             Verify that you are a member of the farm administrators group in Central Administration.

2.             In SharePoint 2013 Central Administration, click System Settings.

3.             On the System Settings page, under Servers, click Manage services on server.

4.             On the Services on Server page, next to App Management Service, click Start.

5.             On the Services on Server page, next to Microsoft SharePoint Foundation Subscription Settings Service, click Start.

6.             Verify that the App Management and Microsoft SharePoint Foundation Subscription Settings services are running. The following illustration shows the Services on Server page where you can verify that the App Management and Subscription Settings services are running.

Services on Server showing the App Management and Subscription Settings services running.

 Configure the Subscription Settings service application by using Windows PowerShell

1.             Verify that you have the following memberships:

o        securityadmin fixed server role on the SQL Server instance.

o        db_owner fixed database role on all databases that are to be updated.

o        Administrators group on the server on which you are running the Windows PowerShell cmdlets.

An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15 Products cmdlets.

 Create the App Management Service and Subscription Service application using the below script

$account = Get-SPManagedAccount "farm account>>" # ex: polasoft\administrator

$appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account

$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName Appmanagement_Service_DB

$proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

$appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolAppSvc –Name SettingsServiceApp –DatabaseName SubscriptionSettings_Service_DB

$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc

Configuring SharePoint to use App domain:

To configure the Apps for SharePoint. Go to an Apps section in Central admin.

 

Click on Configure Apps URLs and then enter the App domain you set up. In my example I am using same domain where my SharePoint running.

In addition, you need to decide on an App prefix that all App DNS names will get. Anything will do if you follow the description of Characters allowed.

For each instance of an App you install and activate, SharePoint creates a unique URL to access the App. The unique URL starts with the prefix you choose followed by a unique identifier set by SharePoint and Finally the App domain you have created.

Click ok.

We are one step away to use Apps and the SharePoint Store.

For that we need to create an App catalog site collection to hold our Apps. When you add an App by uploading an App package, this is where you will do that.

From the Apps section of Central Administration, select Manage App Catalog. Leave the Create a new app catalog site choice selected and hit OK to advance to the Create App Catalog step.

 

Enter the Title, website address and primary site collection administrator details. It is similar like creation of site collection. Once it got created it will be redirected to “Manage App Catalog” section.

You can see in the below screens App catalog has been created.

 


Click on the site URL to access the App catalog.

Why An App Store?

Microsoft is introducing this model for a couple of different reasons, the first of which is technical. SharePoint is most effective when it can be customized to a company’s particular needs. SharePoint offers a number of out-of-the-box, ‘zero-code’ customizations, but these can only cover a subset of the almost endless specific requirement of businesses around the world. Custom-coded solutions are, therefore, extremely popular and highly effective. Cloud based environments, however, are multi-tenant. This can present a huge problem because poorly-written or malicious custom code can quickly bring a server to its knees, and all of the tenants housed on that server are then adversely affected by the outage. As such, the SharePoint App Model moves all custom code execution off the server and relies on either client-side execution or execution on an external server.

The second reason is financial. In addition to charging companies to host their SharePoint sites on Office 365, Microsoft also opened the Office Marketplace. The Office Marketplace is very similar to the App Store on an iPhone or iPad, except that, instead of buying apps for a mobile device, you can buy apps for your SharePoint sites. Imagine a small company that needs an IT Support Ticket System, a Time-Off Request Manager, a HR Forms library, or any other application that can help them accomplish their goals. A SharePoint App that helps them in very specific areas can be up and running on their Office 365 instance with a few clicks and a couple of bucks spent. Of course, Microsoft will skim a bit off the top just as Apple or Google do in their Marketplaces, but if you are a developer with an awesome business app then this is a small price to pay for the exposure.

The final reason is usability. Microsoft cannot build a SharePoint app for every possible niche business scenario, so the Marketplace is a way to let developers fill the void. Ultimately, it makes Office 365 more useful to businesses and provides a great deal of value to Microsoft in terms of marketability of Office 365 as a whole.

At any rate, an individual SharePoint 2013 developer definitely has the potential to make a small fortune if they can build an app and position it accordingly.

Why App Model?

In SharePoint 2010, with farm solutions, custom code was deployed into server. All the things will deployed to the server means an IT consultant with console access would need to upload the solution package to the server. So that the Access must be required to deploy the solution in farm level. This will only works On Prem environment. It will not suitable for hosted deployment. Both Farm and Sand Boxed solutions developer need to have full understanding on the server and command on sever API.Farm solutions are not suitable for cloud environment. We can use sand boxed solution on cloud environment, but there is lot of limitations put users off from it. For example we cannot call External Web services from sand boxed solutions and we can only access limited set of SharePoint API's.

App model is mainly designed for cloud hosting. It will not use server side code. It will use only client script like java script or jQuery, and will work on top of share point framework. So that it will keep environment light. you can easily migrate the apps and easily add the apps from app store.

Key points about SharePoint Apps

Everything is in a SharePoint site is now an app

Yes, everything in a SharePoint site is an app. This includes lists and libraries. Though the actual implementation of lists and libraries has not changed. They are referred in user interface as apps, to create a more unified experience. For e.g. if you would like to create a new document library, you need to create an app and pick document library and then name it. 

No custom code on SharePoint server

As per the new SharePoint 2013 App Model, SharePoint apps do not live in SharePoint, rather they execute within a browser client, or in non-SharePoint server such as IIS server or in cloud server such as Windows Azure. SharePoint apps are granted permissions to get back into SharePoint sites via OAuth and communicate with SharePoint via REST/CSOM.

Easier to upgrade to future versions of SharePoint

This is possible because the apps are running against client side service 

Reduces the ramp-up for those developing apps

Developers building SharePoint apps don't need to be familiar with SharePoint specific things  e.g. object model. If they want to work with data from SharePoint, then they have the option to leverage some of the standard services or CSOM.

Leverage hosting platform features in new apps

If you develop an app which is going to run in another hosted platform (like Windows Azure OR non-SharePoint server such as IIS server OR any other infrastructure) but it's going to use SharePoint UI such that end user feels that he is in SharePoint and the app looks like SharePoint. However, since the app is running in another environment like Windows Azure, then you can use the capabilities of hosting platform i.e. Windows Azure, which you normally cannot do in SharePoint.

This enables taking SharePoint apps to different levels - further than what can be done with farm/ sandboxed solutions

Provides additional approach for development

The app model does not replace the solution based approach of development/deployment, it is an additional option. Thus, in SharePoint 2013 for development, we can use either of the following approach:

SharePoint Apps  

Fully trusted solutions

Sandboxed solutions

Apps for SharePoint hosting options

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

Scope of an App

There are two choices to build the app scope

Web Scoped: Web scoped apps will live only with in the app web.

Tenant scoped: we can publish the app to the entire company or to the public scope.

Availability of Apps :

Just like Mobile apps we have a market for share point apps and we can acquire or buy the apps from app market. There is a private market place for employee in corporate company. Microsoft is having market place in cloud. Developers can develop their apps and sell it through Microsoft app market. There is more chances to launch third party market places and sell the apps. This will get more spice to the app market and help boosting the competition.

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(Custom Action): 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.

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.

Beware of host headers:

You are now ready to deploy your apps. Because of all this extra domain stuff though there are a few things you should know about your web applications and site collections.
If you are using a host header for your web application apps won’t just work for that web application. Because of how the redirect for the app domain works IIS will try to resolve the app url by using the default IIS web site, which of course doesn’t work. If you want to use host headers for your web applications you have to create an extra web application that is listening on port 80 (or 443 if you are using https) and that doesn’t have a host header.
This means that you have to create a web application like you normally would. You have to make sure that you select port 80 (or 443 if you are using https) and you should not fill in a host header. Note that you have to stop the Default Web Site in IIS in order to be able to do this. The web application will use the server name as its url. The web application can be empty except for a root site collection.