What a week it was! I am referring to the last week spent at Sitecore Symposium North America and Annual MVP Summit that took place in Las Vegas. There was plenty to absorb with as much as seven sessions in progress at the same time. Sessions were divided into three different tracks: Product, Business and Developer. Obviously I couldn’t make it to all, but I did attend a good mix of them. All sessions were diverse in terms of subject matter. However, from opening keynote to closing keynote, the emerging theme was clear, and it was the Connected Consumer Experience!
Well, the concept of the consumer experience is not entirely brand new. At the symposium, stronger emphasis was placed on the term ‘connected’. The digital marketing landscape is continuously shifting as customers are engaging in doing business across several channels – email, website, mobile sites, apps. social media, CRM etc., and it poses at least two immediate questions for any organization that takes their customers seriously.

1. Are we ready, as an organization, to do business with customers across these diverse channels?
2. And, if so, do we have the infrastructure and solutions in place that drive for us a single view of our customer across online and offline touch points so that we can offer them a connected and meaningful experience?

Chris Nash and Ron Person, during the business keynote on Day 1, talked about a three-stage maturity model that describes the organization maturity journey:

1. Attracting visitors by rendering consistent content across channels
2. Converting them into customers by presenting an experience relevant to their needs
3. Turning them into an advocate by offering real-time and the most meaningful, intelligence and prediction-based experience.

I was further submersed into the connected consumer philosophy when, in the same week, I was reading my complimentary copy of “Connect- how to use data and experience marketing to create lifetime customers” by Chris Nash, Ron Person and Lars Peterson. It was given to all symposium attendees. It was a nice read. The authors describe optimization as a “low-hanging fruit” of experience marketing, and they recommend working toward quick wins. Also it stages the path for long-term success as insights gained over a period of time can be leveraged in real-time later.
The last point is important. If the information is properly gathered over a variety of channels, then over a period of time it can become knowledge and can be used in real time to transform your customer into a lifelong customer. Last week at a Spanish restaurant while waiting for dinner, I was chatting with Chris Nash from Sitecore, one of the authors of the above book. It was kind of a planned event so I had specified my vegetarian meal preference when I registered for the event on their website 3 days prior, and then Sitecore must have provided this information to the restaurant, mostly by phone. I was expecting salad and grilled vegetables to be served for me but to my surprise, I got vegetable paella and I haven’t had it ever before since it is typically not cooked as a one-person dish. When I asked the manager, “Did you really make vegetarian paella just for me?” his response was, “I want you to experience paella in a Spanish restaurant, yes.” He went the extra mile to offer me a personalized experience relevant to my needs. What impact did it leave on me? I did feel that I am a valued customer, and I am more likely to recommend this restaurant to my friends. It instantly turned me into advocate.
The next and last step in bridging the disconnect is to further optimize the customer experience though advice and recommendations with learning and predictive analysis. At this level, information served to the customer at every touch point is meaningful and relevant. It is not just session, IP address or campaign visit but about considering and treating your customer as human. The more your organization adopts this philosophy, the more it is going to get loyal customers that bring repeat business. The key is experience – a connected consumer experience!
Perficient has been addressing the need for a “Connected Consumer” experience in our consumer markets practice in a variety of ways. Read more:
Download our white paper:  The Retailer’s Guide to the Connected Consumer
Read our Consumer Markets blog post: Trends that are shaping the expectations of the connected consumer

I am back to blogging after a long pause – way too modest term for more than 7 months of break. But you know the days when you are swamped too deep into the project and don’t do anything other than breathing and work. Everyone, almost everyone, goes through it. Anyway, back to business now. Today’s blog post is about mapping search results with Glass.Mapper pulled from search index(Lucene, SOLR etc.) to actual items in content database without writing single line of imperative code. If you don’t know about Glass.Mapper, it is an amazing OOM(Object-Object Mapping) and ORM(Object-Relational Mapping) tool that significantly cuts down both the development and testing effort through declarative programming. Check out its home to learn more about it.
Let’s talk about motivation first. I was dealing with a problem involving aggregate object where information needed to be retrieved seamlessly from various and diverse data sources including search index without spreading data access code into my models and views. Does’t it sound like classic case of data mapping problem? In fact, Sitecore 7 content search APIs similar approach where indexed content is filled into specified .Net object(typically into SearchResultItem or its derivative). And mapping is directed through IndexField, IgnoreIndexField and few other attributes. Now it begs an obvious question, why would I use Glass.Mapper? Consider following scenario:

Say you are dealing with an item with large number of fields and not all of them are being indexed(indexing comes at a cost so you like to index select item fields, for instance fields that appear in search results). And while processing search results, some of those non-indexed fields need to be referenced. One way is to make sure that the ID field gets indexed and then using ID, you retrieve related item from database. However the process could be non-transparent and messy, particularly if field is complex or nested field type and there are several fields. So instead of you pulling information from database with Sitecore APIs, Glass.Mapper can do it for you, with the help of mapping attributes. Consider following model for an article where its number, title and summary are retrieved from index and content and images are retrieved from database.

 
And add few lines of code in your search module and you have ArticleModel filled with information from index and database. As I may need to use mapping for any type, I have abstracted in under generic method “Map”. SitecoreService in following snippet is Glass type that determine which database(e.g. master, web) it is mapping against.
 

 
Mapping is immensely powerful and keeps your code flexible so it can evolve with nor or little impact on other components. In above example, if a business forces me to index ArticleContent field, I can simply replace SitecoreField attribute with IndexField. It could even alleviate burden on indexing if used smartly.  In above example, if ArticleContent gets updated several times in a day and it is required to return only the latest content in search results, it can be achieved by by employing the most aggressive indexing strategy which is usually CPU and/or IO intensive. Or you can configure less aggressive indexing strategy and use mapping to pull the latest content from database before returning search results. Of course, content in index would be stale from few seconds to minutes but it is significantly less taxing on your server resources.
Mapping promotes loose coupling between layers and modules and hence make your code extensible and testable. In above example, the code that consumes Article type is completely unaware of underlying data source(s) and makes it easy to substitute mock data for testing purpose. Also it doesn’t need to be changed if field name in database or index changes.
 
 

Last week, Sitecore announced acquisition of commerceserver.net from SMITH(formerly Ascentium), a global digital agency that develops and supports it. Commerceserver.net is a continuation of Microsoft Commerce Server. Acquisition of commerceserver.net complements well as it brings B2B and B2C e-commerce capabilities to Sitecore’s Customer Experience Platform(CXP). As per Sitecore press note, “Sitecore’s acquisition lays the foundation for the industry’s first .NET based, enterprise-grade Customer Experience Management (CXM) platform with a native, fully integrated e-commerce engine.”

 
 
 
 
Commerceserve.net is developed on .Net stack and integrates well with Microsoft technologies so existing customers can choose to integrate it tightly with Sitecore’s customer experience platform. Sitecore will continue to offer it as a stand alone product as well. Commereceserver.net’s cloud offering is currently available through AWS market place and it has plans to make it available for Windows Azure. Read the full anouncement here
 

Yet another win for Sitecore! Sitecore wins Critic’s Choice Award in “Best Enterprise CMS” category after winning People’s Choice Award in the same category last month.  Sitecore and winner of the last year, Adobe CQ5 which is re-branded as Experience Manager were running neck and neck for People’s Choice Award but Sitecore won it in the end. Unlike People’s Choice Award, Critic’s Choice Award isn’t based on nominations and as per CMSCritic, a panel comprised of reputable judges consider and evaluate all CMS products. Read the full announcement here .

CMSCritic further notes that strong content management capabilities coupled with digital marketing components makes Sitecore a well rounded platform for enterprises. Predictive personalization, ability to serve personalized content based on analytics gathered across different channels, have become the major reason for enterprises to choose Sitecore over other CMS products as this usually translates into increased customer engagement and hence better ROI. Gartner also noted it in its latest Magic Quadrant report and has recognized Sitecore as an industry leader. Read full Gartner report here.
 

What is Sitecore Azure?

In simple words, it is your Sitecore implementation running in Windows Azure, a popular cloud computing platform from Microsoft. Sitecore Azure provides development and deployment tools to support Sitecore CMS and DMS(Digital Marketing System)  in Windows Azure.
Windows Azure: As you may already know, Windows Azure services are available both as IaaS (Infrastructure as a service) and PaaS(Platform as a service). To be precise it offers four execution models for your application:

1. Virtual machines(IaaS)
2. Cloud Services(PaaS)
3. Web sites
4. Mobile services

Please see Window Azure page to know more of various execution models and other information.

Sitecore – PaaS and IaaS

Sitecore Azure – PaaS: Your Sitecore environment in Azure is maintained and patched automatically, instead of you working with virtual machines directly and managing them. Your implementation can be scaled out by adding large building blocks such as instances, web roles and farms.
Sitecore in Windows Azure – IaaS: You can get a virtual machine, created out of a standard disk image or your own disk image and you are responsible for patching, installing updates and maintaining it. It offers you more control, with added maintenance liability though.

Subscription Options

Sitecore Azure subscription – It is a PaaS offering where your Sitecore installations were managed by automated Sitecore features.  You can also use your existing Windows Azure subscription for Sitecore Azure installation.
Windows Azure subscription: You could choose to subscribe to Windows Azure directly and manage Sitecore on your own. You can still use deployment tools that Sitecore Azure uses.

Deployment Topologies

Following three topologies are currently possible with Sitecore Azure module 3.0:
On-premise content editing; delivery from cloud
In this topology, “Content Editing” farm (or “Editing” farm) is placed on premise, usually behind corporate firewall and one or more “Content Delivery” farm(s) (or “Delivery” farm(s)) are hosted in Windows Azure.

Content authors have access to Editing farm and content is authored and edited in this farm. When content is ready to be pushed, it is published to one or several Delivery farms. Deployment is taken care by Sitecore Azure. You will see in a moment how it is accomplished.
Live mode: Content editing and delivery from same farm in the cloud
A single farm is used as editing and delivery farm. It is called live mode as changes made by content authors are immediately available for delivery.

Editing and delivery from different farms in the cloud
Editing farm in cloud is different than the Delivery farm. Content is published from this farm to one or more Delivery farms in the cloud.

DMS and Sitecore Azure

Module 3.0 supports DMS inside Azure now. Earlier versions didn’t support DMS as it requires subsequent user requests to be directed to the same server which first served the request and this means a sticky session. Unfortunately Windows Azure doesn’t support sticky sessions to utilize resources better by allocating them uniformly to ensure optimal performance. One can obtain a hotfix from Sitecore to support DMS with module 2.0.
You may have to consolidate analytics from various farms if your Sitecore Azure implementation has more than one delivery farms. Alternatively, you can configure all your delivery farms to gather analytics at single location. For instance, there are three delivery farms, one in Europe, another in east coast of USA and third in west coast of USA. You could configure all three farms to store analytics information at one location, for instance, in east coast USA farm.

DMS, Caching and Scalability

Windows Azure  allows applications including Sitecore applications to persist state data into SQL Azure, Tables and/or BLOBs. However sometimes quicker lookup is necessary and that is where caching helps. Windows Azure support:

1. Co-located role caching – A cache shared by multiple instances making up a web role.
2. Dedicated role caching – Dedicated worker role instances are used exclusively for caching

More instances should be added to a web role to scale computing resources while more web roles needs to be added to scale cache if co-located role caching is used. It is advised to add a content delivery farm to database throughput needs to be scaled.

Development and Test Environments

Windows Azure charges you based on the data usage so it is not cost effective to have your test environment hosted inside Windows Azure. Instead you can use local emulator for Windows Azure to test your deployment. Not only it is free but also faster as deploying to Azure could take 15-20 minutes easily.
You also need to have an on premise environment to support Sitecore development typically with Visual Studio and other development tools installed.

Limitations and Considerations

1. Sitecore Azure permits only one Content Editing farm in the cloud.
2. Sitecore Azure can support up to 99 Content Delivery farms per location.
3. You can create up to 149 SQL databases in each database server inside SQL Azure.
4. Each database in SQL Azure can grow up to maximum 150 GB.

It is very trivial to retrieve items from Sitecore content repository. Like any other CMS, Sitecore provides APIs for reading and enumerating items and item fields and there is nothing special about it. Without wasting time, let’s talk code straight away. Consider following two lines of code typically found in code behind of a SubLayout:

 Sitecore.Data.Items.Item item = Sitecore.Context.Database.GetItem("/sitecore/content/home/products/tv");
            if (item != null)
            {
                String title = item["Title"]; //Sharp 47.9" LED TV
                double price = Convert.ToDouble(item["Price"]); //1200
                double size = Convert.ToDouble(item["Size"]);// 47.9
            }

Assume the following data template inheritance:

Technically there is nothing wrong with above two lines of code and it is going to work as expected. However a production level Sitecore implementation typically has several items in its content tree and relationship among them is often anything but simple. Code similar to above isn’t intuitive until you read few lines and also it involves accessing fields through string constant. Having object oriented programming around us for several years, your first reaction would be to hide item under a logical entity, say class Product and then consume a Product instance so fields can be accessed through object properties in strongly typed fashion:

Television sharpLEDTV = new Television("/sitecore/content/home/products/tv/sharp47");
            String title = sharpLEDTV.Title;
            double price = sharpLEDTV.Price;

The implementation of a sublayout may look something like this(see implementation code for Product and Television classes below.  Details are omitted for brevity):

Model, View and Controller

1. Loosely coupled implementation: as you see, view (.ascx file) and controller(.ascx.cs file) don’t reference Sitecore item as it is encapsulated within the model. It helps writing presentation and controller independently without mixing Sitecore items and fields into it. This is very helpful in a team of multiple developers where presentation is developed in parallel to data access logic.
2. Extensibility and Testability: Separation of concerns adds flexibility to the implementation. If data access and/or mapping implementation changes, views and controllers don’t need to be updated. Such implementations are easily extensible. Models can be easily mocked to support development of views and controllers.
3. Better readability – One can easily figure out that a product is being read, just by looking at first line.
4. Strongly typed access – As you see, field names are being accessed through strongly typed properties so less runtime and ugly “Object reference not set to an instance…” errors.

    public class Product
    {
        public Sitecore.Data.Items.Item Item
        {
            get;
            protected set;
        }
        public Product(String path)
        {
            Item = Sitecore.Context.Database.GetItem(path);
        }
        public String Title
        {
            get
            {
                return Item["Title"];
            }
        }
        public double Price
        {
            get
            {
                return Convert.ToDouble(Item["Price"]);
            }
        }
        ...
    }
    public class Television : Product
    {
        public Television(String path) : base(path)
        {
        }
        public double Size
        {
            get
            {
                return Convert.ToDouble(Item["Size"]);
            }
        }
        ...
    }

Isn’t it a waste of time to write similar logic to read items especially if there are hundreds of item types? That is where mapping framework such as Glass.Mapper proves useful. In simple words, it is an ORM for Sitecore items. Your code with glass will look like this:

[SitecoreType(AutoMap=true)]
public class Product
{
public virtual String Title { get; protected set; }
public virtual float Price { get; protected set; }
public virtual String Description { get; protected set; }
}
[SitecoreType(AutoMap=true)]
public class Television
{
public virtual String Size{get; protected set};
}

And code behind(.ascx.cs) will change to:

protected void Page_Load(object sender, EventArgs e)
        {
            SitecoreContext context = new SitecoreContext();
            TV = context.GetItem<Television>("/sitecore/content/home/products/tv/sharp47");
        }

Beyond defining business types or concepts by creating classes, you don’t have to write more than single line of imperative code. Additionally these classes are reusable and can be loaded with any other item or even from other data sources such as Salesforce, SAP and databases. It greatly reduces the development and testing effort as data access logic which is a big chunk of any Sitecore implementation is taken care by the framework.
Will write more in coming posts about Glass and other frameworks that promotes extensibility and testability in your code.

Gone are days when going online for an enterprise was considered a proud moment and the only purpose its public facing website served was an instant ‘brochure’ for visitors about its products and offerings. Nowadays visitors can not only browse the information but also can purchase directly on the website or show an interest into particular product or service. Predictive personalization, among many powerful capabilities Sitecore has, is the most notable one as it tracks visitor’s behavior and maps to a predefined pattern which is used then to show relevant content to the visitor.
If your company’s public facing website like ours is powered by Sitecore CMS and a tool of choice for sales folks in your company is Salesforce.com, wouldn’t it be nice to share an intelligence and analytics gathered by Sitecore with Salesforce.com and turn a casual visit into a lead? Wouldn’t it help your sales guy to better understand customers’ behavior and buying patterns? You can essentially drive your Salesforce.com through your public facing website. Similarly showing information stored in Salesforce.com on to Sitecore web site or utilizing it to personalize the content could result into rich experience for web site visitors. Empowering visitors to search documents and information stored in Salesforce.com(SFDC) or view SFDC reports can help your sales people stay focused by not requiring them to manage content through Sitecore CMS.
Enabling information exchange between these two vast systems can truly leverage your company’s investments into Sitecore and Salesforce.com. SFDC objects such as leads, accounts, contacts, opportunities and custom objects are accessible through REST APIs. These APIs are categorized into two: customer APIs and partner APIs. Customer APIs are for a project that is specific to a customer or a situation while partner APIs can be used to develop if a project is meant to be used by several customers. Similarly Sitecore exposes information stored into it such in form of APIs or web services. One may write a custom layer that can bridge two systems. Also a third party connector called S4S(Sitecore for Salesforce) from FuseIT can be used to connect two systems. To the best of my knowledge, it is the only such connector available in the market.

So how does S4S work?

S4S connector for Salesforce.com and Sitecore CMS

1. Data Connector – Captures data from Sitecore web site and serializes it to SFDC

2. DMS Connector – Transfers information in Sitecore’s Analytics Engine to SFDC

3. Reports Connector – Makes it possible to view and search SFDC reports from Sitecore website

4. Security Connector – This is the most interesting one and if you opt to install it, you need to install a SFDC package which adds a section to a SFDC contact where a Sitecore username and password is stored. Other fields are also added to a contact where you can specify a Sitecore landing page, Sitecore user profile and areas of interest. Basically SFDC acts as a data source for a custom Asp.Net role-membership provider for Sitecore CMS. This is particular helpful if your Salesforce.com users want to log in to Sitecore using SFDC credentials. It also enables SFDC users to drive Sitecore CMS directly from SFDC.

<

p style=”text-align: left;”>Appropriate integration between Salesforce.com and Sitecore can result into increases leads and opportunities and more recurring business revenue for your organization. I will write detailed instructions to setup and configure S4S connector in a separate blog post.

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.

searchengineoptimziation.xml

searchengineoptimziation1.xml

Sitemap Timerjob

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.

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 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 and App Level External Content Types in SharePoint 2013

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

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.

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.

 4. Select the entities you would like to import. Select only entities that you need for the app otherwise not only App will end up with inflated model but also all data associated with each entity will be brought into external lists.Hit finish. At this point, Visual Studio has created a model under “External Content Types” for you.  Feature is also updated to have new modules.

5.Expand “NorthWind” and you should see customer.ect. This is the BCS model. It doesn’t have a “.bdcm” extension like its predecessor. However it doesn’t alter its behavior as the model is still defined with XML. If you open the .ect file with ordinary XML editor, you can observe similarity in schema.

Customer BDC model representing OData entity

6. Deploy the App. And browse to the http://sp2013/ListCustomers/Lists/Customer({BaseTargetUrl}/{AppName}/Lists/{EntityName}) . You should see imported customer data in external list.

 
 
 
 
 
 
 
 
 
 
 
 
7. You can program against this data like any other external list.