Search Engine Optimization for SharePoint 2013 Sites (Part II)

searchengineoptimziation.xml

SEO features in SharePoint 2013 are bundled into a SearchEngineOptimization feature. Its feature.xml file references two element files - searchengineoptimization.xml(SEO.xml) and searchengineoptimization1.xml(SEO1.xml). SEO.xml defines elements that make up its UI by extending ribbon interface. It also registers few candidate web controls with AdditionalPageHead delegate control. Delegate control is a powerful mechanism to alter application behavior declaratively. One or more candidate controls are added to control tree dynamically based on the sequence number(lower sequence number will be added first) depending upon the configuration of a delegate control. All web controls are defined under Microsoft.SharePoint.Publishing namespace. SEO.xml also adds an SEOSettings application page(_layouts/15/SEOSettings.aspx) where you can configure canonical URL and verify site ownership.  SEO1.xml defines all SEO properties for page such as browser title, meta description, sitemap priority, sitemap change frequency as site columns. It means you can access these fields pragmatically like any other site columns. Note that "Sealed" property for all fields is set to true which means that they aren't extensible.

searchengineoptimziation1.xml

Another SEO feature, XmlSiteMap, adds XmlSiteMapSettings application page(_layouts/15/XmlSiteMapSettings.aspx) where you can specify paths not be crawled by search engines. Anonymous access must be enabled for the web application to generate Sitemap otherwise following message will be displayed on the page.

Sitemap Timerjob

     

When XmlSiteMap feature is activated, it registers the site collection with Search Engine Sitemap timer job which runs daily by default. Of course, you can run this timer job anytime like any other time job and configure its frequency. When run, it generates the XML site map for the site collection and adds it to robots.txt. In process, it reads sitemap priority, sitemap change frequency and other fields of pages and includes them in the sitemap.

Read More

Search Engine Optimization for SharePoint 2013 sites

SharePoint 2013 introduces several new WCM capabilities and one of the addition is native support for SEO(Search Engine Optimization). In absence of any native support for SEO in earlier versions, developer community relied on custom solutions. However with out-of-box SEO capabilities in SharePoint 2013, now you can

• Configure Canonical URLs
• Verify site ownership with web master tools of search engines
• automatically generate Sitemap for your site
• Add and edit SEO metadata for pages with SharePoint ribbon interface
• Add SEO properties for a manged navigation
• Alter priority and change frequency for individual page

Canonical URL Configuration and Site ownership verification

SEO capabilities are available only for publishing sites and activated during publishing feature activation. To configure SEO, go to Site Settings -> Site Collection Administration -> Search Engine Optimization Settings. Search engines often references the page content with its URL. This means if two URLs refer to the sam content, content will be indexed twice. SharePoint 2013 allows you to configure canonical URLs(In SEO world, the URL that uniquely represents a content is called Canonical URL) so duplicate indexing can be avoided. It also helps consolidate popularity of content represented by multiple URLs which would be tracked separately otherwise.
Sometimes the same URL can render different content depending upon the query string parameters present. The SEO settings page allows you to add such query string parameters into Filter Link Parameters list which essentially tells a search engine that parameters in this list can influence search results.

SEO settings page also lets you verify your site ownership with search engines. Typically you sign up with the web master tools of your search engine and copy provided meta tag and paste it on SEO settings page. There are several other methods to verify site ownership but this is the most popular among all and SharePoint supports it.

For instance, Meta tag for Bing  -  <meta name="msvalidate.01" content="... Meta tag for Google -  <meta name="google-site-verification" content="

Sitemap Generation

When XML Sitemap path is specified in robots.txt, search engines use it to further discover content on your website. In absence of native support in earlier versions, developers built custom solutions to generate Sitemap which will periodically iterate through all sites and pages. In case of small, less frequently changing sites, Sitemaps were manually created and maintained. In SharePoint 2013, automatic Sitemap generation can be turned on by activating Search Engine Sitemap feature at site collection level. Activating it registers a site collection with Search Engine Sitemap timer job which generates a Sitemap when run and updates robots.txt with its path.

SEO Properties

With SharePoint 2013 SEO, you can add SEO metadata to your page right from browser interface. Out of all most notable fields are, Sitemap priority - Not all pages in your site are of equal priority. You can specify priority on scale of 0.0(low) to 1.0(high) which will be taken into account when Sitemap is generated. Sitemap change frequency - some pages change frequently while others such as news release don't. This field like previous filed is used during Sitemap generation and allows you to set the frequency from hourly to never. This will help search engine learn how often content on the page changes. Exclude from Internet Search Engines - If set, exclude a page from Sitemap file.

Other fields you can set are,

BrowserTitle - Title in the browser title bar MetaDescription - Appears in search results as description next to the URL. However it is never used by search engine to calculate rank Keywords - Keywords are widely abused by traffic redirection web sites and never used by major search engines as they often don't represent the content on the page

SEO in Managed Navigation

SharePoint 2013 allows a term set representing logical hierarchy to be used as site navigation. When using manged navigation, you can specify SEO properties for a term. Manged  navigation yields SEO friendly URLs. A URL doesn't have .aspx extension and /Pages in it. Also accessing default page for the site doesn't result into HTTP redirection(HTTP 302) anymore.   Go to Site Settings -> Site Administration -> Term Store Management and select a term from the left to access its SEO properties under tab Term Driven Pages

      Please keep checking this space for the second and final part in SEO series where I will be discussing architecture and internals of SEO.

Read More

SharePoint 2013 - Farm and App level ECTs in BCS

SharePoint 2013 introduces the concept of App level External Content Type(ECT) which allows model representing external entities to be packaged along with app in single unit so later it can be accessed by app to understand and integrate external data without outer dependencies.

External Content Types(ECTs) and External List - BCS(Business Connectivity Services) is an umbrella term in SharePoint referring to functionalities and activities for modeling, management and manipulation of external data. Schema of an external entity or business concept is represented in SharePoint by an external content type much like a content type describes native SharePoint entities. External List can then hold items of specific external content type, again the way List can have items of one or more content types. The major difference is External list can contain items of only one external content type.

What is inside BDC model?
Business Data Connectivity(BDC) model primarily contains information about,

1. How to connect to external data source
2. How to translate credentials if the user has a distinct identity in external system
3. Metadata of one or more external entities

Farm and App Level External Content Types in SharePoint 2013

Farm Level vs App Level ECTs - In SharePoint 2010, model representing one or more ECTs, called BDC(Business Data Connectivity) model is stored in a relational database, called BDC Metadata Store. However this metadata store isn't directly accessibly and managed by BDC service application. Adminsitrator or someone who has an access to Central Administration web site must upload the model and then it is available to any web application configured to use that instance of BDC service application. ECTs represented in such a way are called Farm Level ECTs.   Farm level ECTs works great for farm solutions and sandboxed solutions but not for apps in SharePoint 2013 as app is an isolated, compartmentalized unit and all data that app accesses including BDC model must be packaged along with it in a single unit so later it can be deployed to catalog or SharePoint Store without any external dependencies. App level ECT in SharePoint 2013 solves that problem. Here is how it does: For Apps, model is stored in a file in a document library rather than in BDC metadata store. SharePoint then leverages less known feature FileBackedMetdataCataog, first introduced in SharePoint 2010, to read metadata from this file into in-memory BDC runtime which can be read by an external list. Like BDC server runtime, this BDC runtime can connect to variety of data sources through out-of-box connectors such as SQl Connector, Web services connector and OData connector. Custom connectors and .net assembly connectors cannot be used along with this runtime and hence with App level ECTs. This may sound limiting but actually it is consistent with overall App idea which doesn't allow any custom code to run on SharePoint server. App Level ECTs

• Allows granular isolation of external content types for an App
• An app can have only one BDCM file and that is referenced in ListInstance definition by MetdataCatlogFileName property.
• Doesn't need an access to BDC service application

App level ECTs empower a SharePoint App to access and manipulate publicly available data sources without any configuration on the consumer's part. App can work with external data right after it is installed.

Read More

Client data access with OData and CSOM in SharePoint 2013

SharePoint 2013 has improved OData support. In fact, it offers full-blown OData compliant REST based interface to program against. For those who aren't familiar with OData, OData is an open standard for querying and updating data that relies on common web standard HTTP. Read this OData primer for more details. The obvious benefits are: 1. SharePoint data can be made available on non-Microsoft platforms and to mobile devices 2. SharePoint can connect and bring in data from any OData sources

Client Programming Options: In SharePoint 2010, there were primarily three ways to access SharePoint data from the client or external environment.  

1. Client side object model(CSOM) - SharePoint offers three different set of APIs, each intended to be used in certain type of client applications.

• Manged client object model - for .Net client applications
• Silverlight client object model - for client applications written in Silverlight
• ECMAScript(JavaScript) object model - for JavaScript client applications

Each object model uses its own proxy to communicate with the SharePoint server object model through WCF service Client.SVC. This service is responsible for all communications between client models and server object model.

2. ListData.SVC - REST based interface to add and update lists.

3. Classic ASMX web services - These services were used when parts of server object model aren't available through CSOM or ListData service such as profiles, publishing and taxonomy. They also provided backward compatibility to code written for SharePoint 2007.

4. Custom WCF services - When a part of server object model isn't accessible through all of above three options, custom written WCF services can expose SharePoint functionalities.

Architecture:

In SharePoint 2010, Client.svc wasn't accessible directly. SharePoint 2013 extends Client.svc with REST capabilities and it can now accepts HTTP GET, POST, PUT, MERGE and DELETE requests. Firewalls usually block HTTP verbs other than GET and POST. Fortunately, OData supports verb tunneling where PUT, MERGE and DELETE are submitted as POST requests and X-HTTPMehod header carries the actual verb. The path "/_vti_bin/client.svc" is abstracted as _api in SharePoint 2013.

CSOM additions: User profiles, publishing, taxonomy, workflow, analytics, eDiscovery and many other APIs are available in client object model. Earlier these apis are available only in server object model. ListData.svc is still available mainly for backward compatibility. 

Atom or JSON response - Response to OData request could be in Atom XML or JSON format. Atom is usually used with managed clients while JSON is the preferred format for JavaScript client as the response is a complex nested object and hence no extra parsing is required. HTTP header must have specific instructions on desired response type otherwise it would be an Atom response which is the default type.

Read More

Consuming OData sources in SharePoint 2013 App step by step

SharePoint 2013  has an out-of-box supports for connecting to OData sources using BCS. You no longer are required to write .Net assembly connector to talk to external OData sources.

1. Open Visual Studio 2012 and create a new SharePoint 2013 App project. This project template is available after installing office developer tools for Visual Studio 2012.

Create App

 Select App Settings

2. Choose a name for the app and type in the target URL where you like to deploy the App. Also choose the appropriate hosting option from the drop-down list. For on promise deployment select "SharePoint-Hosted". You can change the URL later by changing "Site URL" property of the App in Visual Studio.

3.Add an external content type as shown in the snapshot below. It will launch a configuration wizard. Type in OData source URL you wish to connect to and assign it an appropriate name. For this demo purpose, I am using publicly available OData source NorthWind.

Read More

SharePoint 2013 Issues Log

Infinite authentication prompts issue when launching SharePoint 2013 on local machine

After setting up on premise SharePoint 2013 environment, isolated application domain must be configured to install and run SharePoint 2013 App. Ofcourse the application domain has to be added into the bypass list and trusted sites list to avoid authentication prompts. Despite of right configuration and entering right credentials, if you are presented with infinite authentication prompts, you may have to disable loopback check. The problem occurs only when trying to lauch app from the server, usually a development VM. App can be launched from browser in client machine without any issue.

Loopback

What is Loopback Check? Loopback check security features block reflection attacks on the server by comparing the address it is trying to access with the local server name. If both addresses are same, it is a loopback and then the authentication fails. Such check prevent running fake version of a web site and redirecting incoming request to itself. Loopback doesn't occur if FQDN(Fully Qualified Domain Name) or host header isn't used. However, for apps, configured isolated application domain must be FQDN. Loopback check shouldn't be disabled in production environment or a public facing site as it makes it vulnerable to reflection attacks.  

Disabling Loopback Check:
1. Backup registry of the target machine.

2. Open registery editor(by typing regedit.exe or regedt32.exe in Start->Search program and files)

3. Add DWORD registry value DisableStrictNameChecking HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters and set it to 1 with base type Decimal

4. Add DWORD registry value DisableLoopbackCheck at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and set it to 1 with base type Decimal

5. Close registery editor. Restart the machine

6. Deploy the app again.

7. Launch the app locally. You can also modify registry values by using powershell. New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword

SharePoint 2013 Deployment Error: Failed to Install App for SharePoint

Please make sure your SharePoint environment has isolated application domain configured to run apps. You can verify this by looking for following errors in ULS logs:

• Error occurred in deployment step ‘Install App for SharePoint’: Failed to install App for SharePoint.
• Cannot complete this action. Please try again.<nativehr>0×80004005</nativehr><nativestack></nativestack>
• App domain must be configured prior to completing this operation.

Follow instructions to set up application domain here (under section Create an isolated app domain on your development computer)  

Read More

SharePoint Evolution - Agility matters! so the augmentation!

SharePoint has been around for years and has gained incredible popularity in last few years in a time where many products, including some of its competitors, vanished quickly after reaching a peak. So how does SharePoint, or any product for that matter, remain persistent in an ever changing technology world? How it successfully evolved from separate products, SharePoint portal server 2001 and content management server 2002 to a true enterprise product? I started contemplating SharePoint in retrospect after watching a more than 2 year old presentation by Mike Fitzmaurice. I stumbled upon it when I was randomly browsing thorough videos on channel 9. The video was so thought provoking that I decided to jot down some of the thoughts.

Extensibility

Before I answer the questions I asked earlier, here is one more: What is SharePoint?

• Content management system?
• Portal?
• Rapid site building tool?
• Repository of documents?

Read More

SharePoint 2013 - Cross Site Publishing step by step

1. Create at least two site collections - authoring site collection called 'Authoring' where content exists and publishing site collection called 'publishing' where content will be published.

2. Turn on Cross Site Collection Publishing(XSP) feature on authoring site collection. [Site Settings -> Site Collection Features -> Click Activate right next to XSP feature]

Activate Cross Site Publishing feature on authoring site collection

3. Go to the list or document library in authoring site collection you want to publish.

 A list, shared as catalog

4. Make sure that the list/library contains items and the crawler has indexed them. If not, run full or incremental crawl.

List Settings -> Catalog Settings

5. Go to Catalog Settings under List/Library Settings and share it as Catalog. Here I am granting anonymous access on the content as authoring site collection is meant to be consumed by all publishing site collections I have. Catalog sharing warning dialog will be displayed on clicking ok. Click ok to close the dialog.

Catalog Sharing warning

Catalog Settings

 6. Go to publishing site collection. Click on Catalog connections[Site Settings -> Catalog Connections] . All available catalogs will be listed here. Click on 'connect' next to the catalog you want to publish.

Catalog Connections

7. Configure the connection details. Select the tagging field, choose navigation settings and fields to be included in the url.

8.Add a web part page in Pages library or any other library and insert a Content Search web part. Configure it to display contents from the shared catalog

 

Read More

Cross Site Publishing in SharePoint 2013

SharePoint 2013 cross site publishing allows content authors to create content in a site collection, called Authoring site collection, different from the one where content is published. The clear separation of content from its presentation allows authors to write and manage content without worrying about how and where it will be published. The other obvious benefit is that the content can be consumed by many publishing sites and presented differently. So how does SharePoint 2013 achieve that its predecessors couldn't? It leverages already in place, powerful search infrastructure which is capable of indexing diverse range of data sources. The presentation is typically built using Search web parts that are configured to query content in authoring site collection. Authoring site collection and publishing site collection must be prepared for cross site publishing. See step by step configuration of cross site publishing here.  

Preparing authoring site collection:

1. Share the content: Not all content in an authoring site collection is available for publishing. In fact the content meant to be shared must be marked explicitly. It is done by configuring lists and libraries to use as catalogs and then configuring catalog connections which allows you to specify which sites or site collection can access them. Alternatively, anonymous read access can be granted.
2. Tag the content: Terms can be used to associate metadata with the content in authoring site collection which will be indexed later along with the content. The same term set can be pinned in publishing site collection to build managed navigation.
3. Turn on search service: Ensure that the search service is enabled as the content won't be available to publishing site collection until it is indexed.

Preparing publishing site collection:

1. Catalog Connections: With catalog connections, you can specify catalogs to be used in a publishing site collection.
2. Create presentation Elements: Use existing master pages, page layouts or create your own elements to build the chrome.The term set in authoring site collection can be pinned and used as a navigation. Then create pages, drop search web parts and configure them to access the content

Notes:

1. Only HTML content is indexed. Other content such as PDFs, BLOBs such as images and videos aren't indexed and must be referenced directly. Even word and excel documents are treated as BLOBs.
2. Metadata associated with an item are represented as crawled properties when content is indexed. Later these crawled properties are mapped to manged properties. SharePoint automatically creates these managed properties for you. Check this for more details

Read More

Discover content and act on it with eDiscovery

In today's world, information is fairly scattered within an organization, mostly in form of emails, documents, file share, third-party repositories and it could be a challenge for an organization and its legal teams to find relevant content in an event of legal action, litigation or simply for compliance to standards and policies. eDiscovery in SharePoint 2013 enables organizations to retrieve content from various data sources and respond to events by taking an immediate action such as placing a temporary hold on specific SharePoint site.

Logical Components - eDiscovery

eDiscovery Architecture: eDiscovery functionality can be added to any web application by creating a site out of eDiscovery Center site template. Discovery Center allows you to manage sources, create cases(using eDiscovery Case site template) and export content. eDiscovery feature works upon the foundation laid by SharePoint search infrastructure. In fact, it relies on search service application(SSA) associated with the web application and the content that it can discover is crawled and indexed by the SSA. If there are more than one SSA in a farm or an organization, corresponding Discovery Centers need to be provisioned.    
Discovery Center allows you to gather content from:

• SharePoint sites
• File Shares
• Exchange mailboxes
• Archived Lync content

Typical Life Cycle - eDiscovery

Once sources are identified, you must create a eDiscovery Set where you specify sources, queries and whether the content is preserved. Queries allow you filter content based on various search criteria.     Holds: You can put a hold on entire SharePoint site and preserve the state of site content at that time. If you wish to place a hold only on a portion of your site, you can create a query that limits the content. In an event of hold, users see the captured state of the content even when the content is changed, moved or deleted. Only the authorized users with permissions to perform eDiscovery can view both preserved and original content.  

How does hold work? SharePoint marks the content as 'preserved' at the time discovery performed. When the content changes, it is moved to a Preservation Hold Library , a document library that requires site collection administrator permissions or web application permissions. If an item changes again, only the current version and the original version when the hold was applied are saved. This not only saves storage but also improves efficiency.  

Removing a hold: Closing a case automatically removes a hold from the content.  

Export: Results of eDiscovery can be exported and reviewed in a review tool. Content will be exported in following formats. Later all can be printed or exported to PDF.  

 

Read More

Navigation goes managed in SharePoint 2013!

Out of box navigation in SharePoint was always bound to site hierarchy until now and implementing a custom navigation around another logical structure or business concept such as hierarchy of units in an organization, categories of product or any custom hierarchy was challenging. Creating a custom source for navigation and maintaining it was even more challenging as adding, moving or deleting a page must be reflected in the navigation source. Sometimes that was done by writing a custom navigation provider, manually updating a source or both.This didn't make much sense as most of the contents were already classified with terms in SharePoint 2010. Finally SharePoint 2013 solves this challenge by allowing you to create a managed navigation. The concept is simple: Build a logical hierarchy using terms that suits to your business concept and then use it for navigation. Not only that SharePoint 2013 allows you to specify the intended use of the hierarchy you create but also choose to use the same hierarchy for multiple purposes. For instance same hierarchy can be used to refine the search results. This certainly offers higher degree of flexibility without moving site content just to build navigation.

Specify an intended use for a term set

Cross site collection navigation:
Another challenge was to extend navigation beyond site collection. Site collection is a vital abstraction in SharePoint and many SharePoint features including Navigation, Security, Content Database are built around it. However that poses another challenge as most real world solutions comprises of more than one site collection for various reason from isolation, architectural boundaries and other limitations. Whatever be the reason, storing everything in one site collection isn't practical for large implementations. As navigation is confined within the boundaries of a site collection, building site wide navigation was a complex undertaking in earlier versions. In SharePoint 2013, Managed navigation combined with pinning and cross site publishing makes it possible to scale navigation beyond a site collection. Pinning allows you to reuse terms defined in another site collection. You may create a term set in authoring site collection and use that hierarchy in one or many site collections. Neat aspect of pinning is that when a term is updated or moved, it is automatically reflected at all places where it is used. Pinning was existent in SharePoint 2010 but had of little use because of the change wasn't applied automatically. Automatic update is possible in SharePoint 2013 because terms are read only when they are pinned. Pinning is also useful when creating multilingual sites using variations. Entire term hierachy can be translated in all languages used for variation labels. Private term sets Sharing of term set can be restricted only to a specific site collection by creating a local terms set. Creating global term set makes it available to all site collection connected to managed metadata service SEO friendly URLs Nice side effect of using terms for navigation is neat, shorter, extension free, SEO friendly URLs. Courtesy to managed navigation provider, URL are rewritten behind the scene.

Read More

Branding and Customization - SharePoint 2013 style!

Customizing look and style of a SharePoint site is much different from traditional web site and anyone who did brand a site earlier with SharePoint 2007 or SharePoint 2010 would quickly agree with it. One must possess knowledge of master pages and page layouts, different placeholders a master page has and the default styles a master page uses to style elements. And it always imposed a learning curve for a designer new to SharePoint world. In SharePoint 2013, branding and customization tasks are significantly simplified with the help of Design Manager. Think of it as a place to,

1. Manage branding assets - master page, page layouts, ribbon, custom components css, images, JavaScripts etc
2. Preview your design
3. Convert an entire design to html and an html to functioning design

Design Manager

Design Experience
Previewing a site in progress is the biggest addition. Not only you can preview with design manager but also with your favorite client side editor. Just map your SharePoint site ({your site}/_catalogs/masterpage/ - for instance, http://sp2013/publishingsite/_catalogs/masterpage/) to a network drive and then you are all set to design with a client side editor. Please note, it doesn't include any of master page or page layout elements. Just pure HTML. Designer can continue working on HTML and can save HTML version of the maste page. SharePoint 2013 will take care of updating your changes into master page. This enables a designer to work on SharePoint 2013 site without stepping into realm of a SharePoint developer.

View and edit master pages with Design Manager

 

Packaging Experience
All branding elements can be bundled into a single package(.wsp) and then saved to hard drive. Later this package can be imported to other site collection to give a new look. This process may sound similar to existing process in SharePoint 2010 but unlike SharePoint 2010, you are not required to add this solution to solution gallery and deploy it. Instead you just import a package using Design Manager.

Design manager let you export all customized content

Import a design package

 

You can examine the contents of the package simply renaming its extension from .wsp to .cab.

Content of exported package

  Overall I feel Microsoft did a great job by clearly segregating the tasks of developing master pages and page layouts from rest of the branding tasks and keeping them for SharePoint developer instead of designer.

Few notes:

1. Design Manager is available only in publishing sites.
2. Like earlier versions of SharePoint, you can pick any master page to start with so you don't have to start from scratch. It's always better to copy the HTML file associate with the master page so you still have original master page.Copying HTML, copies associated master page automatically for you.

Read More

SharePoint hosted Apps with "Napa" & Visual Studio 2012

As discussed in the post earlier, SharePoint 2013 allows you to write Apps which can extend the functionalities your SharePoint website provides. Primarily an App can be divided into two categories depending upon where its components reside:

1. SharePoint hosted App – Major pieces of an App are on SharePoint server with business logic and presentational pieces in form of JavaScript/CSOM and HTML executed at the client respectively executed on the client. Please note that such App doesn’t run any custom code on SharePoint server
2. Cloud hosted App – Some or all of business logic and presentation reside in cloud or on premise server different from the SharePoint server. The custom code doesn’t have to be in SharePoint or .Net, it could be anything that can be consumed through common web standards.

In this post, I am going to solely focus on how start building a SharePoint hosted app while internals of cloud hosted apps that require understanding complex multi-party authorization will be covered in subsequent posts.

Development tools that you need for building SharePoint hosted apps: “Napa” Office 365 development tools,

• If you are developing an app targeted for Office 365 environment, you don’t need to download anything on your development machine not even Visual Studio. In fact, all you need is just a standard browser and “Napa” Office 365 development tools which requires a subscription to Office 365, free during SharePoint 2013 preview. “Napa” provides you a web-based interface to author, test and deploy your Apps.

 

• If you find “Napa” web tools limiting, you may download a Visual Studio 2012 and install on your development machine followed by installation of Office Developer Tools and SharePoint client components. Visual studio allows you build your app locally and then deploy and test on Office 365 developer site. Office 365 provisions a separate web site solely for deploying and testing called developer site. You aren’t allowed to deploy your app to any other site in Office 365.

Alternatively, you may build your own development environment that hosts SharePoint 2013 preview and Visual Studio 2012 preview and other necessary prerequisites. You must also configure isolated app domain for your App (discussed below). Find more details on installation here.  

Scope and Isolated App domain: When App is installed, a separate site(SPWeb) called AppWeb is created within the hosting site often referred to as Host web. An App can be scoped at web level or tenant level. Unlike Cloud hosted apps, SharePoint doesn’t support tenant scoped apps which may contain data for multiple tenants so SharePoint hosted Apps are always scoped at web level and cannot exchange information with other apps. AppWeb has a unique address which in turn uniquely identifies an App.     When App is launched, observe the long URL in the address bar. First thing between two forward slashes and a hyphen is the tenant name when the site was provisioned. 14 digit unique identifier before the domain name (in Office 365, an address always ends with sharepoint.com) which identifies the app installation in that tenancy and make App domain unique. The content in green box is the name of the SPWeb where the app is installed. Deploying an app in isolated domain helps

• Blocking cross site scripting attacks
• Enforcing App permissions when App talks back to SharePoint using CSOM.

When using Office 365, you don’t need to worry about configuring App isolation domain as it’s already configured for you when the instance was provisioned. In next post, we will walk through series of steps to create SharePoint hosted apps using Napa and Visual Studio 2012.

Read More

SharePoint 2013 Apps

With SharePoint 2013, Microsoft introduced yet another paradigm for developing applications. Applications (or Apps)??!!! Yes. ‘Solutions’ are called Apps now! In fact everything in SharePoint including its primitive constructs such as Lists, Libraries are Apps in SharePoint 2013. However that doesn’t change how they behave and they continue function in same way. So what happened to old school development model, farm solutions and sandboxed solutions that were introduced with SharePoint 2010. Well, they are still there.

Motivation behind sandboxed solutions was to gain more stability and achieve increased robustness in the farm by deploying it into partially trusted environment - “Sandbox”. Unlike farm solutions, the code doesn’t have full access to the entire server side object model and further, the access to resources through code is restricted with CAS(code access security) policies. For those who have developed or dealt with farm solution must be aware with the fact that a ‘bad’ piece of custom code in a web part can easily destabilize the entire farm and hence all other applications sharing the farm. Running  custom code in User Code service helped achieving the goal up to an extent but sandboxed solutions were never became popular as there is still custom code running on the server and developer can get away with the restrictions by writing a full trust proxy.

True stability and isolation can be achieved only with keeping all custom code out of SharePoint server and that’s what precisely Apps in SharePoint 2013 offer. SharePoint Apps(Apps from here on) don’t contain any custom code on the server. You may be thinking then they are good only for solutions tailored with out-of-box components with no code. But wait, you can place your custom code at the client in for CSOM(Client side object model). Well one can’t put everything especially critical business logic at the client side so where does that go? The answer is you can move that code in the cloud. With all your custom code running outside SharePoint environment, not only best farm performance and highest degree of isolation can be achieved but also you get a liberty to write your business logic in the environment and programming language of your choice including non-Microsoft technologies such as Java and PHP. Yes, your read it right. Use of common web standards such to communicate between SharePoint and Cloud(or servers on premise or wherever your custom business logic is) makes this possible. Moving business logic outside of SharePoint allows you to treat SharePoint as data store so if code outside SharePoint has ever need to talk back to the SharePoint, it can use REST calls to communicate along with OAuth tokens! What other benefits does new App model bring to us? Developers within an organization can build solutions for larger audience and publish them in Corporate Catalog so other departments can benefit from using it. Independent developers and third party organizations can make their solutions available to whole world by publishing them in SharePoint Store. Apps open up so many new possibilities for your SharePoint solutions to integrate it and communicate with other solutions in and outside your organization.

Read More