We have developed this training as an answer to a question that plagues a lot of ASP.NET developers.

 Is it appropriate for me to learn SharePoint?

Our answer is a big yes and a small no.

A big yes because “SharePoint is just another ASP.NET application“.  A small no because the learning curve for SharePoint (SP hereafter) can be large as the developers need to learn technologies that SP interacts with. The development process in SP is much more involved, hence it requires determination and interest. So, let’s start with some basics that can encourage you to get hands-on with SP.

__________________________________________

What is SharePoint?

SharePoint is a framework or a platform that enables an enterprise portal. An enterprise portal services everything related to an enterprise. For instance, an ordinary user of MSN or Yahoo can use multiple services such as news, entertainment, weather, videos and stock tickers.

If we observe the same portal in an enterprise context, then a person working in a company will not be interested in such stuff. Enterprise users are more interested towards seeing things like how many leaves they have already availed and how many are remaining. So, an enterprise portal will have a particular HR model in which this information is stored.

Similarly, it can be job specific as well. For instance, an accountant manages the accounts and may want to see customized widgets regarding the back-end accounting software such as Microsoft Dynamics. The accountant will need information related to that software. An end portal  processes enterprise related queries. This whole thing is enabled by SharePoint as a framework or platform.

3 Main Characteristics

In an earlier training session, we discussed that to fulfill all these enterprise requirements, SP needs certain characteristics. If you make an APS.NET application of HR, there will be three main building blocks that are:

1. User Interface (UI)
2. Business Logic
3. Database Layer

For any enterprise application, these three building blocks are common.

SP is a framework that enables development of customized applications on the enterprise portal. The framework should have the quality that it offers certain out-of-the-box ready made workflows in each layer that we can utilize. When you are creating a leave request application on SP, you do not face much problem in UI design, nor regarding the business logic (now this is subjective to the complexity of business logic). SP offers limited options to implement the business logic, but since it is a framework, it has some limitations as well. You can only get ready-made things up to a certain extent.

Basic/fundamental building blocks of SharePoint

Just as when we are developing a new software, we have to identify entities and their designation, same is the case for SP.

Lists

If you develop a leave application in SP, you will have to design its database. For doing this in SP, there is a concept called list. Everything and anything in SP is saved as a list. We discussed this thing in the last session when we spoke about structured and non-structured data. SP stores data in a structured format (just as a spreadsheet in form of rows and columns). To save structured data in SP, lists are the basic building block in SP.

So if you are to make a list of leave request, there will be employee name,  data from to which date and approved column as well. Basically, it will have a structure just like in excel. When you are designing the database for this leave request application, so essentially you are creating a list for that application so it will have these columns and the instance of particular data will be in rows; it is the same concept as you make tables in a database.

If you are searching a table of leave request in the database, there will be no such thing in the DB. Everything in SP has its own stuffed structure. You will not be able to decode that this instance of the row is lying here. Even if you know, every version of SP has a changed database. Trying to insert a direct query in the SP’s database is not of much value in the long-run as it can easily break in the next version. Whenever you want to work with this data, work with lists.

Back-end Databases in SharePoint

We are just setting the platform for you that what actually SP is, then we will discuss the technicalities, what are its features, how many databases does SP has, why they are formed and so forth.

One of our participants asked that can we make relationships in the database? For instance, if you have to create a parent-child relationship on a table, can we do the same in the lists as well. In SP, instead of adding a column, you can add a lookup column. So if you leave request application in which data of all employees reside (age, gender, location), you may want that SP has a look-up column through which data is managed. You can make relationships in SP using lists same as in case of databases. You can make parent-child columns using look-up columns.

We looked that SP is a platform. The official documentation of SP mentions the jargon such as what collaboration means in a SP environment. You can also put constraints that this particular column of a list is weak, so if anyone tries to put duplicate information SP will not allow.

For instance, you have made list and using search (SP has done indexing on databases) SP gives indexing support and retrieves the result for you. Does SharePoint deliver faster services using the in-built indexing support? Yes, it does. Otherwise, there will be no use of the framework.

SP is just another ASP.NET application

From a technology perspective, SP is just another ASP.NET application, the only difference is that it is an elaborate one. If you try to make such an app in ASP.NET it may take you 5-6 years 🙂  For ease of understanding, ASP.NET is the platform on which SP is built, SQL server is used as a back-end database and front-end pages are built in ASP.NET.

The difference is that if you want to make a page in SP, it is usually saved in the DB, just as in content management system that loads the pages by picking them from database in the run time. Most of the stuff in SP is the same.

Anything and everything that holds true for ASP.NET also holds true for SP, barring few exceptions

SP can have JQuery, it can run HTTP modules, etc. Being a consultant, you will encounter very few instances of ASP.NET that can not be used in the SP framework. Such instances are scarcely used.

That is a very significant capability that .NET developers can you visualize. It opens multiple avenues for ASP.NET consultants as  the kind of stuff you can do with SP is limitless.

Compare this with SAP. If anyone has worked in SAP, you must be aware that it has a closed framework in which you cannot do customization easily.

The avenues of customization in SP are limitless. This very thing is the selling point of SP as well as the downside. A lot of people I hear during work say that there are 3-4 ways of doing everything in SP, so beginners keep guessing what way is the optimal. It basically adds to the confusion. We will also discuss that how the immense extensibility of SP also adds to some confusion for developers.

It essentially means that SP has a lot of stuff that holds true for ASP.NET also. Its DB is SQL Server, it has same in UI the ASP.NET+HTML+JS+CSS.

Farm Based Environment

A farm-based application is one that is built in the farm based environment that has multiple servers. A more technical expression for this is LAYERS (TEARS). Farming in ASP means that you scale out when you are increasing number of servers to fulfill more requests.

Essentially means at the UI layers, there will be multiple web-front-end services.

So web front end server will be one in which windows and SP will be installed. Then there is an application server, this can be one or more, similarly there can be clustering of one or more servers on the database.

Load Balancing is an important, but un-related concept

Load balancing takes place at the front end server and data clustering takes place at the database server.

All of this holds true for an ASP.NET NTL application as well. So, the reader can gauge the similarities between an ASP.NET app and SharePoint. This is what a typical SP installation looks like.

Layers/Tiers of SharePoint

1. Config DB (only 1 instance)
2. Content DB (multiple instances)
3. Service APP DBs (dependent on the number of services running)

When you install SP the very first database that gets created is the configuration database. SharePoint installation related data are located in the config DB and SP cannot function without a config DB.

The second database is content DB, things such as lists, libraries, pages, forms, and tables are in the content DB, all data in SP is in the Content DB. There is only 1 config DB in one installation of SP. But there can be multiple content DBs.

The third is the service application database. There are different services running in SP and every service has its own DB.

If you put up the architectural hat on, you can say that if the content is separate from config, it implies that there is another installation of SP. This is the install 2 and this is install 1 geographically dispersed. You can take the content database and replicate it here, the config will pick the content as long as both locations have the same versions of SP.

During copying content from the content DB, we are actually porting one environment into another. The main benefit of the architectural segregation of these databases is that we can keep the whole content away from config, In case that your installation become corrupt, you just pick your config DB and restore it in new installations.

FAILOVER

The concept of fail-over varies between each layer. At web front it is called Load Balancing, if you have 100 users,

When the browser hits this web front end, if there are three web front ends, one fails, the load balancer that automatically sends requests to the other one.

There are some hardware load balancers and software load balancers, however, these things fall within the domain of IT administrators.

An interesting question is that how can we achieve fail over by balancing the load when an instance fails .This is relatively easy at the web front ends. Because web front end only has to search pages, so load balancing and achieving fail-over at the web-front-end is not much challenging. Since, every web front is serving the same content, load balancing can be accomplished at the web front end because all three servers are doing the same thing. It is therefore possible to balance their load.

To achieve fail-over at the service application layer, you will have to maintain the duplicate copies of the same service.

Can we apply the concept of load balancing at the third layer, the config DB layer? What are alternatives, if not?

We cannot balance the load of state of the application. We cannot do that one version of our database lays in one server and the other one in a separate server. It is not possible that one request goes here, and another goes there. This is because at any given time all credentials will be in one primary server.

The state of the application cannot be distributed, this is where true fail over comes into play. In the event that this server goes down that server will come into service. There are different ways of achieving fail over at this layer. Database health is monitored at the config DB level and in case that config DB health is not optimal, the server is taken offline.

So fail over at web-front-end is achieved through load balancing, but at DB layers it is achieved through clustering. At services layer it is done by duplicating the instances of the same service.

Stay tuned for the next session.