jQuery – Fetching the Email address for people picker for SharePoint 2010, 2013 or Office 365

For one of the project we found the challenge of Email of the selected employee to be fetched without any post back.

On analysis of many approaches, we have adopted the below approach of creating a promise object and making an ajax call RestFull API GET call to fetch the properties from UserInformationList dynamically and displaying the email to the respective textbox as required.

Below is the code to add to hearder section of the HTML by adding the script tag,

Prior to the same steps add the reference of jquery-21.4.min.js.

/// <reference path=”../Scripts/jquery-2.1.4.min.js” />

function LoadEmail() {
var objPPL = $(“#ctl00_PlaceHolderMain_peopleEditor_upLevelDiv”);

var sText = $(‘div.ms-inputuserfield’).text();
sText = sText.replace(‘;’,”).trim();

if (sText.trim() !== ”) {

var urlService = “/EmployeeResources/_vti_bin/ListData.svc/UserInformationList?$filter=Name eq%27”;
urlService = urlService + sText.trim();
urlService = urlService + “%27&$select=Email,Name,Id”;

//Create the Promise object – it may return success or fail object by differer

var promise = $.ajax(
url: urlService,
type: “GET”,
dataType: “json”


// In case of success of promise object below code will executed

promise.done(function (resp) {


// In case of Failure of promise object below code will executed

promise.error(function (err) {
alert(“Fail Promise”);
alert(“Error:” + err.status);



Add below code snippet to your people picker control as attribute to make call on lost focus,

onfocusOut=”return LoadEmail();”

This code can be modified to display multiple properties like Location, Phone number, Mobile number etc  from UserInformationList.


Capacity Planning and Sizing of SharePoint 2013

What is Sizing term for Capacity planning?

Sizing describes to selection and configuration of appropriate,

  • Data Architecture
  • Logical Architecture
  • Physical Architecture
  • Hardware for Solution platform


There is a range of capacity management and usage considerations that affect how you should determine the most appropriate hardware and configuration options.

Steps you should take to undertake effective capacity management

Step 1 – Model :

Modeling your SharePoint Server 2013-based environment begins with analyzing your existing solutions and estimating the expected demand and targets for the deployment you are planning to set up.

Gather the information about

  1. user base,
  2. data requirements,
  3. latency and throughput targets,
  4. document the SharePoint Server features you want to deploy.

Use this section to understand what data you should collect.

Understand your expected workload and dataset,


Workload describes the demand that the system will need to sustain, the user base and usage characteristics.

Workload Characteristics Value
Average daily RPS
Average RPS at peak time
Total number of unique users per day
Average daily concurrent users
Peak concurrent users at peak time
Total number of requests per day
Expected workload distribution No. of Requests per day %
Web Browser – Search Crawl
Web Browser – General Collaboration Interaction
Web Browser – Social Interaction
Web Browser – General Interaction
Web Browser – Office Web Apps
Office Clients
OneNote Client
SharePoint Workspace
Outlook RSS Sync
Outlook Social Connector
Other interactions(Custom Applications/Web services)
  • Concurrent users – It is most common to measure the concurrency of operations executed on the server farm as the number of distinct users generating requests in a given time frame. The key metrics are the daily average and the concurrent users at peak load.
  • Requests per second (RPS) – RPS is a commonly used indicator used to describe the demand on the server farm expressed in the number of requests processed by the farm per second, but with no differentiation between the type or size of requests. Every organization’s user base generates system load at a rate that is dependent on the organization’s unique usage characteristics. It is most common to measure all requests except authentication handshake requests (HTTP status 401) over a 24 hour period.
  • Total daily users – Total users is another key indicator of the overall load the system will need to handle. This measurement is the actual number of unique users in a 24 hour period, not the total number of employees in the organization.
    The number of total daily users can indicate the growth potential of the load on the farm. For example, if the number of potential users is 100k employees, 15k daily users indicates that the load may significantly grow over time as user adoption increases.
  • Workload Distribution – Understanding the distribution of the requests based on the clients applications that are interacting with the farm can help predict the expected trend and load changes after migrating to SharePoint Server 2013. As users transition to more recent client versions such as Office 2013, and start using the new capabilities new load patterns, RPS and total requests are expected to grow. For each client we can describe the number of distinct users using it in a time frame of a day, and the amount of total requests that the client or feature generates on the server.For example, the chart below shows a snapshot of a live internal Microsoft environment serving a typical social solution. In this example, you can see that the majority of the load is generated by the search crawler and typical end user web browsing. You can also observe that there is significant load introduced by the Outlook Social Connector feature (6.2 percent of the requests).Typical daily load distribution of requests

Estimating your production workload

In estimating the required throughput your farm needs to be able to sustain, begin with estimating the mix of transactions that will be used in your farm. Focus on analyzing the most frequently used transactions the system will serve, understanding how frequently they will be used and by how many users. That will help you validate later whether the farm can sustain such load in pre-production testing.

The following diagram describes the relationship of the workload and load on the system:

Capacity - Workload Diagram

To estimate your expected workload, collect the following information:

  1. Identify user interaction such as,
    • Typical web page browses
    • File uploads and downloads
    • Office web application views and edit in browser
    • Co-authoring interactions
    •  SharePoint workspace site sync
    • Outlook Social connection, RSS sync (in Outlook or other viewers),
    • PowerPoint Broadcasts,
    • OneNote shared notebooks,
    • Excel Service shared workbooks,
    • Access Service shared applications etc.
  2. Identify system operations such as,
    • Search incremental crawls,
    • daily backups,
    • profile sync timer jobs,
    • web analytics processing,
    • logging timer jobs etc.
  3. Estimate the total number of users per day that are,
    • expected to utilize each capability,
    • derive the estimated concurrent users and high level Requests per second,
    • there are some assumptions you will be making such as present concurrency and the factor of RPS per concurrent users that is different across capabilities,
    • you should use the workload table earlier in this section for your estimates. It is important to focus on peak hours, rather than average throughput. Planning for peak activity, you are able to proper size your SharePoint Server 2013-based solution.

Dataset :

Dataset describes the volume of content stored in the system and how it can be distributed in the data store. The following table provides some key metrics that are helpful in determining your dataset. You can use this table to record these metrics as you collect them.

Object Value
DB size (in GB)
Number of Content DBs
Number of site collections
Number of web apps
Number of sites
Search index size (# of items)
Number of docs
Number of lists
Average size of sites
Largest site size
Number of user profiles
  • Content size – Understanding the size of the content that you expect to store in the SharePoint Server 2013 system is important for planning and architecting the system storage, and also for properly sizing the Search solution that will crawl and index this content. The content size is described in total disk space. If you are migrating content from an existing deployment you might find it simple to identify the total size that you will move; while planning you should leave room for growth over time based on the predicted trend.
  • Total number of documents – Other than the data corpus size, it is important to track the overall number of items. The system reacts differently if 100 GB of data is composed of 50 files of 2 GB each versus 100,000 files of 1 KB each. In large deployments, the less stress there is on a single item, document or area of documents, the better performance will be. Widely distributed content like multiple smaller files across many sites and site collection is easier to serve then a single large document library with very large files.
  • Maximum site collection size – It is important to identify what is the biggest unit of content that you will store in SharePoint Server 2013; usually it is an organizational need that prevents you from splitting that unit of content. Average size of all site collections and the estimated total number of site collections are additional indicators that will help you identify your preferred data architecture.
  • Service applications data characteristics – In addition to analysing the storage needs for the content store, you should analyse and estimate the sizes of other SharePoint Server 2013 stores, including:
  • Total size of the Search index
  • The profile database total size based on the number of user in the profile store
  • The social database total size based on the expected number of tags, colleagues and activities
  • The metadata store size
  • The size of the usage database
  • The size of the Web Analytics data base

One of the deliverables of Step 1: Model is a good understanding of the performance and reliability targets that best fit the needs of your organization. A properly designed SharePoint Server solution should be able to achieve “four nines” (99.99%) of uptime with sub-second server responsiveness.

The indicators used to describe the performance and reliability of the farm can include:

  • Server availability – Usually described by the percent of overall uptime of the system. You should track any unexpected downtime and compare the overall availability to the organizational target you set. The targets are commonly described by a number of nines (i.e. 99%, 99.9%, 99.99%)
  • Server responsiveness – The time it takes the farm to serve requests is a good indicator to track the health of the farm. This indicator is usually named server side latency, and it is common to use the average or median (the 50th percentile) latency of the daily requests being served. The targets are commonly described in sub seconds or seconds. Note that if your organization has a target to serve pages from SharePoint Server 2013 in less than two seconds, then the server side goal needs to be sub seconds to leave time for the page to reach the client over the network and time to render in the browser. Also in general longer server response times are an indication of an unhealthy farm, as this usually as an impact on throughput and rarely can RPS keep up if you spend more than a second on the server on most requests
  • Server spikiness – Another good server side latency indicator worth tracking is the behaviour of the slowest 5% of all requests. Slower requests are usually the requests that hit the system when it is under higher load or even more commonly, requests that are impacted by less frequent activity that occur while users interact with the system; a healthy system is one that has the slowest requests under control as well. The target here is similar to Server Responsiveness, but to achieve sub-second response on server spikiness, you will need to build the system with a lot of spare resources to handle the spikes in load.
  • System resource utilization – Other common indicators used to track the health of the system are a collection of system counters that indicate the health of each server in the farm topology. The most frequently used indicators to track are % CPU utilization and Available Memory; however, there are several additional counters that can help identify a non-healthy system; more details can be found in Step 5: Maintain.


Step 2 – Design :

Now that you have finished collecting some facts on the solution you need to deliver, you are ready to start the next step of designing a proposed architecture that you predict will be able to sustain the expected demand.

By the end of this step you should have a design for your physical topology and a layout for your logical topology, so you should be able to go ahead with any necessary purchase orders.

The hardware specifications and the number of machines you layout are tightly related, to handle a specific load there are several solutions you can choose to deploy.

Scale Up: 

It is common to either use a small set of strong machines (scale up)

Scale Out:

A larger set of smaller machines (scale out).

Scale Up and Scale Out both solution has its advantages and disadvantages when it comes to capacity, redundancy, power, cost, space, and other considerations.

We recommend that you begin this step by determining your architecture and topology. Define how you plan to layout the different farms and the different services in each farm, and then pick the hardware specifications for each of the individual servers in your design. You can also execute this process by identifying the hardware specifications you are expected to deploy (many organizations are constrained to a certain company standard) and then define your architecture and topology.

Use the following table to record your design parameters. The data included is sample data, and should not be used to size your farm. It is intended to demonstrate how to use this table for your own data.

Role Type (Standard or virtual) # of machines Procs RAM IOPS need Disk size OS+Log Data drive
Web servers Virtual 4 4 cores 8 N/A 400 GB N/A
Content database server Standard 1 cluster 4 quad-core 2.33 (GHz) 48 2k 400 GB 20 disks of 300GB

@ 15K RPM

Application servers Virtual 4 4 cores 16 N/A 400 GB N/A
Search Crawl Target Web server Virtual 1 4 cores 8 N/A 400 GB N/A
Search Query server Standard 2 2 quad-core 2.33 (GHz) 32 N/A 400 GB 500 GB
Search Crawler server Standard 2 2 quad-core 2.33 (GHz) 16 400 400 GB N/A
Search Crawl database server Standard 1 cluster 4 quad-core 2.33 (GHz) 48 4k (tuned for read) 100 GB 16 disks of 150GB @ 15K RPM
Search Property Store database + Administration database server Standard 1 cluster 4 quad-core 2.33 (GHz) 48 2k (tuned for write) 100 GB 16 disks of 150GB @ 15K RPM


Step 3 – Pilot, Test and Optimize:

The testing and optimization stage is an extremely important component of effective capacity management. You should test new architectures before you deploy them to production and you should conduct acceptance testing together with following monitoring best practices in order to ensure the architectures you design achieve the performance and capacity targets. This allows you to identify and optimize potential bottlenecks before they affect users in a live deployment. If you are upgrading from an Office SharePoint Server 2007 environment and plan to make architectural changes, or are estimating user load of the new SharePoint Server features, then testing particularly important to make sure that your new SharePoint Server-based environment will meet performance and capacity targets.

Once you have tested your environment, you can analyze the test results to determine what changes must be made in order to achieve the performance and capacity targets you established in Step 1: Model.

These are the recommended sub steps that you should follow for pre-production:

    • Create the test environment that mimics the initial architecture you designed in Step 2: Design.
    • Populate the storage with the dataset or part of the dataset that you’ve identified in Step 1: Model.
    • Stress the system with synthetic load that represents the workload you’ve identified in Step 1: Model.
    • Run tests, analyze results, and optimize your architecture.
    • Deploy your optimized architecture in your data center, and roll out a pilot with a smaller set of users.
    • Analyze the pilot results, identify potential bottlenecks, and optimize the architecture. Retest if it is required.
    • Deploy to the production environment.

Testing is a critial factor in establishing the ability of your system design to support your workload and usage characteristics. See Performance testing for SharePoint Server 2013 for detailed information about how to test your SharePoint Server 2013 deployment.

  • Create a test plan
  • Create the test environment
  • Create Tests and Tools

Before you deploy SharePoint Server 2013 to a production environment, it is important that you first deploy a pilot environment and thoroughly test the farm to make sure that that it can meet capacity and performance targets for your expected peak load. We recommend that the pilot environment is first tested with synthetic load especially for large deployments, and then stressed by a small set of live users and live content. The benefit of analyzing a pilot environment by using a small set of live users is the opportunity to validate some assumptions you made about the usage characteristics and the content growth before you go fully into production.


If you cannot meet your capacity and performance targets by scaling your farm hardware or making changes to the topology, you may have to consider revising your solution. For example, if your initial requirements were for a single farm for collaboration, Search and Social, you may have to federate some services such as search to a dedicated services farm, or split the workload across more farms. One alternative is to deploy a dedicated farm for social and another for team collaboration.

 Step 4 – Deploy:

Once you have executed your final round of tests and confirmed that the architecture you have selected can achieve the performance and capacity targets you established in Step 1: Model, you can deploy your SharePoint Server 2013-based environment to production.

The appropriate rollout strategy will vary depending on the environment and situation. There are certain suggested activities that may come out of the capacity planning exercise. Here are some examples:

  • Deploying a new SharePoint Server farm: The capacity planning exercise should have guided and confirmed plans for a design and deployment of SharePoint Server 2013. In this case, the rollout will be the first broad deployment of SharePoint Server 2013. It will require moving or rebuilding the servers and services that were used during the capacity planning exercises into production. This is the most straight-forward scenario because there are not any upgrades or modifications needed to an existing farm.
  • Upgrading an Office SharePoint Server 2007 farm to SharePoint Server 2013: The capacity planning exercise should have validated the design for a farm that can meet existing demands and scale up to meet increased demand and usage of a SharePoint Server 2013 farm. Part of the capacity planning exercise should have included test migrations to validate how long the upgrade process will take, whether any custom code must be modified or replaced, whether any third-party tools have to be updated, and so on At the conclusion of capacity planning you should have a validated design, and understanding of how much time that it will take to upgrade, and a plan for how best to work through the upgrade process – for example, an in-place upgrade, or migrating content databases into a new farm. If you’re doing an in-place upgrade then during capacity planning you may have found that additional or upgraded hardware will be needed, and considerations for downtime. Part of the output from the planning exercise should be a list of the hardware changes that are needed and a detailed plan to deploy the hardware changes to the farm first. Once the hardware platform that was validated during capacity planning is in place, you can move forward with the process of upgrading to SharePoint Server 2013.
  • Improving the performance of an existing SharePoint Server 2013 farm: The capacity planning exercise should have helped you to identify the bottlenecks in your current implementation, plan ways to reduce or eliminate those bottlenecks, and validate an improved implementation that meets your business requirements for SharePoint Server services. There are different ways in which performance issues could have been resolved, from something as easy as reallocating services across existing hardware, upgrading existing hardware, or adding additional hardware and adding additional services to it. The different approaches should be tested and validated during the capacity planning exercise, and then a deployment plan designed depending on the results of that testing.
Step 5 – Monitor and Maintain:

To maintain system performance, you must monitor your server to identify potential bottlenecks. Before you can monitor effectively, you must understand the key indicators that will tell you if a specific part of your farm requires attention, and know how to interpret these indicators. If you find that your farm is operating outside the targets you have defined, you can adjust your farm by adding or removing hardware resources, changing your topology, or changing how data is stored.

See Monitoring and maintaining SharePoint Server 2013 for a list of the settings that you can change to monitor your environment in its early stages, which will help you determine whether any changes are needed. Keep in mind that increasing your monitoring capabilities will affect how much disk space that your usage database will require. Once the environment is stable and this detailed monitoring is no longer required, you may want to reverse the settings below to their default settings.

For more information about health monitoring and troubleshooting using the health monitoring tools built into the SharePoint Server Central Administration interface, read the following:

Monitor health in SharePoint 2013

Solving problems and troubleshooting (http://technet.microsoft.com/en-us/library/ee748639(office.14).aspx)

jQuery promise object based implementation for ajax

jQuery promise object based implementation of the ajax call



type: ‘GET’|’POST’|’PUT’|’DELETE’,
‘AUTHORIZATION’, ‘basic_’+bton(username:password) OR


//Create Service Layer for Ajax calls

var promise = $.ajax();’

//Create a Call Layer (ViewModel)
Use the Promise Object and Write Success and Fail Callback



Example :

Add below code to Service.js

this.getEmployees = function () {
var promise = $.ajax({
url: url,
return promise;

Use of Promise object

var servObj = new service();

function loadData() {
var promise = servObj.getEmployees();
promise.done(function (resp) {
self.Message(‘Call Completed Successfully….’);
promise.error(function (err) {
self.Message(‘Error ‘ + err.status);

jQuery REST API Service call to GET items

To fetch the data byb making RESTful API call use below code,

//Function to Make an Ajax call to Read all items from list or API
function loadData() {
var Employees = [];
url: “http://<Site URL>/api/<API Service Name>”,
type: “GET”
}).done(function (resp) {
$.each(resp, function (index, value) {
$(“#dvmsg”).html(‘Call Completed successfully…’);
}).error(function (err) {
$(“#dvmsg”).html(‘Call Failed…’ + err.status);

Load Table data

function loadTable(emps) {
$(“#tbldetails tbody”).html(”);
var tbody = “”;
$.each(emps, function (index, value) {
tbody += ‘<tr><td><input type=”checkbox” class=”c2″></td>’;
tbody += ‘<td>’ + value.EmpNo + ‘</td>’;
tbody += ‘<td>’ + value.EmpName + ‘</td>’;
tbody += ‘<td>’ + value.Salary + ‘</td>’;
tbody += ‘<td>’ + value.DeptName + ‘</td>’;
tbody += ‘<td>’ + value.Designation + ‘</td></tr>’;

$(“#tbldetails tbody”).append(tbody);



jQuery Custom plugin

In order to implement the jQuery Custom Plugin add below code to HTML,

Step I:  TML Page Code

<!DOCTYPE html>

I am the Custom Plug-In

<input type=”button” id=”btn” value=”Custom”/>
<hr />
<input type=”button” id=”btnevent” value=”Click Me”/>

I will be set the Background on the button Click


Step II: Add the Nuget installation package of jQuery 2.1.4

Step III: Add references of jQuery-2.1.4.min.js to Logic.JS

Step IV: Add below code to Logic.JS

/// <reference path=”../Scripts/jquery-2.1.4.min.js” />
/// <reference path=”../Scripts/jquery-ui-1.11.4.min.js” />

//1. IIFE
(function ($) {
$.fn.setColor = function (color) {

//click.<plugInName> : Means that the click event is suv=bscribed
//with the plug in Name
(function ($) {
$.fn.setColorEvent = function (color,ele) {
$(this).on(‘click.setColorEvent’, function () {
$(ele).css(‘background-color’, color);


Step V: Update the HTML Page code as below

<!DOCTYPE html>

$(document).ready(function () {
$(“#btnevent”).setColorEvent(‘yellow’, “#dv”);


I am the Custom Plug-In

<input type=”button” id=”btn” value=”Custom”/>
<hr />
<input type=”button” id=”btnevent” value=”Click Me”/>

I will be set the Background on the button Click


Step VI : Now run your HTML page to Browser and test on click button


MVVM Architecture Understanding

It is challenging to understanding the concept of MVVM, it is architectural style, find here detailed explanation of MVVM architecture,

Below are few terms to understand,

  • MVVM (We worked with View)
    • Model – the Data (or Domain) Model
    • View – the View (UI)
    • ViewModel –
      • a “model of the view” or Presentation Model :
      • Bridge between Model and View- it managed view refresh
      • This is responsible for making Model and View as loosely coupled

Detailed architecture of MVVM,


jQuery Notes

These days Apps are the need of time, most of the server side application is targetting to transform into client side Apps, so need of jQuery is equally getting important on these days.

Let us understand what, why, how jQuery is useful and important for us.

What is jQuery?

jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers. With a combination of versatility and extensibility, jQuery has changed the way that millions of people write JavaScript.

Why is jQuery?

avaScript and jQuery usage are always up for discussion. Let’s start with basics of of the two and why jQuery might be a better option.

JavaScript is a raw programming language which has been used for a long time by professional IT programmers. It allows the client-side to interact with the user, alter the document content, communicate asynchronously etc. It uses syntax, and programming skills are needed. Thus, one needs to be professional to use it.

jQuery is a Javascript library designed to ease the client-side scripting of HTML. It is fast, concise and very flexible. There are so many libraries available, that we usuallly don’t need to write query for it… unlike Javascript. There are various plugins available for jQuery too, but these are some of the more broad reasons to choose jQuery.

For modern web developers, jQuery is a blessing.  Let’s discuss some of these advantages:

  1. Open Source – jQuery is developed by and available in the Open source community, thus it is free to use (like most programming languages)
  2. Endless Tutorial – There are a ton of tutorials to help any novice developer to design a web page. These tutorials will help you step-by-step to use each plugin or a tool.
  3. Huge Library – From simple items like border radius, image slider, design forms, to placing grids, and display audio/videos… the resources are endless. These plugins are so simple to use that you can can plug and play the code in just a few minutes.
  4. Cross-platform – jQuery is great at handling all cross-browser issues. Some Javascript’s have problems in early versions of IE and Firefox. But, jQuery has helped eliminate this issue. This avoids having to write different codes for different browsers. It results in high efficiency and less hassles.
  5. SEO -jQuery effects are like Flash and can’t really be utilized for SEO. The larger benefit of jQuery is that the files are very small and can be easily optimized for site speed. This is especially beneficial for mobile-friendly sites too. There are plugins to display images and audio-video files easily on a page instead of embedding them directly.
How to use jQuery effectively?

Downloading jQuery
– Download jQuery Files from jQuery Site (Development)
– NuGet Package Manager
– Install-Package jQuery
– Node Package Manager
– npm install jQuery
– Content Delivery Network (CDN) (Production)
2. IDE
– Visual Studio 2010+
– Visual Studio Code (VSCode)
– SublimeText
– Bracket
– Eclipse JavaScript IDE
Continue reading