Posted on
HomeOffice

Editor’s note: This can be a guest publish by Andrew Connell, Founding father of Voitanos. To learn more about Andrew, visit his website and follow him on Twitter: @andrewconnell.


Microsoft SharePoint, both on-premises version SharePoint Server and also the located online version SharePoint Online, offers developers multiple choices for creating custom solutions that either extend and personalize the knowledge in order to leverage the information and services within the product within exterior applications.

Applications deployed exterior to SharePoint could be implemented using any technology and development stack. These applications can leverage the multiple endpoints supplied by Microsoft to read data to SharePoint in addition to leverage services provided through the product, for example search and collaboration.

For applications made to be deployed to and located within SharePoint, developers must work within specific guidelines for the kinds of applications and development models at hand. SharePoint on-premises and SharePoint Online offer developers multiple choices to personalize and extend the merchandise. The various development models were introduced with every latest version during the last 10+ many years to address different challenges and technologies available at that time. Many of these development models can be found today, although many are only accessible within specific environments.

These different development models affect the scenarios whenever a personalization will reside within SharePoint. Including cases for example web parts or extending the consumer experience. Additionally towards the different development models, developers building custom methods to extend SharePoint have to research, if relevant, where their application-specific data is going to be stored.

Within this publish, I’ll cover the various development models and customizations open to developers and also the different choices for where data could be stored for developers to talk with SharePoint on-premises or Office 365 – SharePoint Online.

Stay tuned in in my next publish where I’ll cover the various APIs readily available for developers to have interaction with SharePoint and Office 365, whether or not the custom applications are deployed and located within SharePoint or if they’re located exterior to SharePoint.

When creating a custom means to fix personalize or extend SharePoint, Microsoft provides developers with four primary options to select from:

  • SharePoint Solutions
  • SharePoint Add-ins
  • JavaScript Injection
  • SharePoint Framework

Each option has different pros and cons, and a few are restricted in where they are offered. These options all affect applications which are deployed and located within SharePoint. Applications located exterior to SharePoint don’t have any limitations because they will talk to SharePoint using well-known and standards-based REST APIs or SDKs.

SharePoint Solutions

The very first personalization options introduced in SharePoint Server 2007, and extended in SharePoint Server 2010, are solutions. A SharePoint option would be a deployable package that could contain compiled code, pages, style sheets, client side code and pictures. Solutions usually include SharePoint features, an accumulation of files comprising a declarative group of actions to do or configure the prospective SharePoint atmosphere.

Certain changes, for example developing a list inside a specific SharePoint site could be narrowly scoped. Other changes will go wider, for instance deploying an internet part to any or all sites inside a site collection or globally scheduling a timer job over the entire SharePoint farm. Only certain customizations can be found within specific scopes, although some can are relevant to multiple scopes.

An answer package is deployed towards the SharePoint atmosphere. Once deployed, SharePoint puts the files inside the solution package within the necessary locations around the SharePoint server. Managers or site proprietors then use the alterations in the answer by activating features incorporated within the package.

Solutions are available in two flavors:

Farm Solutions

SharePoint Server 2007 introduced farm solutions which are deployed towards the server and permit developers full use of SharePoint’s server-side managed API. Developers may use these packages to deploy custom server-side web parts, timer jobs, event receivers, features, feature receivers… essentially anything SharePoint supports.

Pro: The number of options may be the huge advantage for farm solutions simply because they have full accessibility server-side SharePoint API.

Disadvantage: The problem with farm solutions is that they are just helpful in SharePoint Server on-premises deployments. Microsoft doesn’t allow farm solutions in SharePoint Online. This is because apparent: With full accessibility SharePoint API, one farm solution could affect the SharePoint Online multi-tenant atmosphere, and therefore impact some other clients.

Sandbox Solutions

To deal with the disadvantages in farm solutions, Microsoft introduced sandbox solutions in SharePoint Server 2010. Unlike farm solutions, sandbox solutions are supported both in on-premises and SharePoint Online deployments from SharePoint 2010 to the present versions (SharePoint Server 2016 and SharePoint Online). The greatest difference with between farm and sandbox solutions is the fact that sandbox solutions are only able to be scoped to some site collection. What this means is all changes are only able to impact just one site collection and never expand to some bigger scope.

While initially Microsoft supported managed code in sandbox solutions which was scoped to operate only inside the context of the site collection, they’ve since restricted them further with no longer allow custom code in sandbox methods to be deployed to site collections in SharePoint Online. They can nonetheless be accustomed to deploy declarative and client-side customizations to SharePoint Online.

Developers may use sandbox methods to deploy custom pages with custom JavaScript and CSS in addition to declarative customizations for example list templates and instances using sandbox solutions.

SharePoint Add-ins

After solutions came SharePoint Add-ins, initially known as apps. Add-ins are supported both in SharePoint on-premises and SharePoint Online beginning in SharePoint 2013 to current versions.

When installing a SharePoint Add-in inside a SharePoint site, SharePoint typically results in a new subsite having a unique URL (top-level domain) to isolate the code from all of those other customer’s SharePoint atmosphere. The Add-was also given a first-class identity, that you can use to assign unique permissions towards the add-in regardless of you consuming the add-in.

These can be found in two flavors, the SharePoint Located Add-in and also the Provider Located Add-in.

SharePoint Located Add-in

SharePoint Located Add-ins run solely inside a client-side context. Any custom business logic needs to be implemented using JavaScript because the files deployed to SharePoint while kept in SharePoint, aren’t operate on the server. They’re made within the client and run there.

Provider Located Add-ins

Provider Located Add-ins tend to be more open ended. The developer, or provider, from the Add-in, deploys an internet application exterior to SharePoint and may thus use any web design techniques available.

Whatever the kind of add-in your soul create, whenever your add-in needs to talk with SharePoint is going to do it using among the client-side APIs Microsoft has incorporated in SharePoint either the CSOM or robust REST API.

When an add-was manifested inside a SharePoint site like a client part, to control your emotions utilizing an IFRAME. It’s because the very fact the add-in execution context is externalized from SharePoint, running in both the company located web application or inside the special SharePoint site that hosts the SharePoint Located Add-in.

Whenever you, because the developer, package up a SharePoint Add-in, you are taking the resulting package file and upload it towards the SharePoint tenant’s application catalog. Once this is accomplished, the SharePoint Add-in may then be installed within any SharePoint site for the reason that tenant and connected with this application catalog. Therefore, it’s scoped towards the tenant so far as where you can use it, but its’ functionality is scoped towards the site where it had been installed.

Developers may use SharePoint Add-ins to produce web parts, although not web parts the way you accustomed to with solutions. Rather they are produced as webpages which are surfaced within SharePoint sites using IFRAMES.

Developers may also create event custom workflows and declarative workflows according to Workflow Manager and deploy individuals with add-ins. As the logic and implementation is located within an web application exterior from SharePoint, add-ins may also register remote event receivers.

JavaScript Injection

Another SharePoint personalization choice is JavaScript injection, which is often used to personalize existing SharePoint sites. Developers may use the information editor web part, or even more lately the script editor web part, to obtain the customizations to the page.

Due to the very nature of JavaScript injection, these customizations will invariably execute inside a client-side context. What this means is they leverage the user’s context and therefore are made within the native page DOM.

By extension, because JavaScript injection involves client-side based development, these customizations have can leverage SharePoint’s client-side APIs to leverage SharePoint data within the customizations.

JavaScript injection doesn’t involve specific developer tools. All developers require is a text editor and a method to upload the files to SharePoint. This really is typically done while using browser, so developers can use any tool that they prefer to produce their customizations when leveraging JavaScript injection.

These customizations are put into each SharePoint page on the page-by-page basis, meaning these customizations are scoped to some specific page.

Because JavaScript injection customizations are carried out on the manual basis, typically there’s no packaging model, there isn’t any deployment model, and there isn’t any provisioning model supplied by Microsoft.

SharePoint Framework

The newest accessory for the SharePoint developer’s toolbox may be the SharePoint Framework. The objective of the SharePoint Framework to create client-side customizations the official development model for SharePoint developers. Developers can create client-side customizations which are packaged and deployed to SharePoint sites much like SharePoint solutions and SharePoint add-ins were in the past versions.

These customizations can also get quick access to SharePoint data using APIs incorporated using the SharePoint Framework. But it doesn’t mean they’ll be restricted to being able to access just SharePoint data… they’re client-side solutions that may use any technology to gain access to other data sources, such as the Microsoft Graph, Office Graph, or any other accessible APIs.

Components built while using SharePoint Framework will run in the present context, unlike their predecessor add-ins that ran inside the context of the IFRAME. What this means is not simply will they load faster, but they’ll run inside the context of the present user and taking advantage of the present connection within the browser.

SharePoint Framework customizations will also be made in the present page DOM – again, not within an IFRAME – which eliminates the necessity, although not the power, for hosting more involved customizations in another site.

Since the customizations are made in the present page DOM and never within an IFRAME, they’re not going to have a similar baggage connected together as IFRAMES have. Among the greatest advantages to this would be that the customizations is going to be responsive and accessible naturally.

When designing customizations using the SharePoint Framework, you need to make certain you aren’t excluding your users by using them in legacy SharePoint sites.

Another part of the SharePoint Framework would be that the customizations you develop works not just in the brand new current modern pages, but they’ll work within the traditional classic web part pages in addition to publishing pages.

First Party &amp 3rd Party

Previously, such things as SharePoint add-ins were another-party only personalization tool Microsoft didn’t create add-ins for SharePoint… they simply baked their changes into the product. The down-side for this is the fact that Microsoft, the company from the host and also the development model, isn’t while using tools they provide us to increase the merchandise.

The word “first party” describes people like Microsoft – furthermore they’ve created the host extensibility model, they also use that extensibility model to increase SharePoint. When they would like to produce a new component or personalization in SharePoint, from here forward they’ll use the SharePoint Framework.

Exactly what does this suggest for SharePoint developers? Well, they’re clearly going for a strong dependency by themselves extensibility model so that they can leverage exactly the same benefits it offers that people use within our customizations but around the switch side, they may also be held back by its limitations. This really is good because when they enhance the SharePoint Framework for his or her use, we can usually benefit from it too.

How About Exterior Applications?

Since I’ve covered the 4 major choices for developing customizations with SharePoint, their list is in no way exhaustive. Fundamental essentials four possibilities to developers who wish to deploy customizations to SharePoint. However bear in mind that SharePoint offers multiple APIs enabling developers to construct applications located elsewhere for example on corporate servers or within the public clouds (Microsoft Azure, Amazon . com Web Services, Google Cloud Platform, etc.). These applications could be built using any technology, any language, using any stack and leverage the factors-based REST APIs SharePoint and Office 365 offer to integrate with SharePoint.

Within the last section I spoken concerning the different tools within the SharePoint developer’s toolbox you can use to produce and deploy customizations to SharePoint. What about custom data that the application needs or creates… where in the event you put that?

This can be a common query developers face, so allow me to offer some guidance and supply a couple of options.

The simplest choice is to help keep the information within SharePoint and Office 365. Including using SharePoint lists, libraries and OneDrive for Business. The advantage for this choice is there are well-known APIs developers may use to produce these customizations. However, the down-side to those options, particularly SharePoint lists and libraries, is they aren’t meant for highly transactional applications (i.e., plenty of rapid reads/writes) nor could they be smartly designed for holding plenty of data. Taking it towards the extreme, a SharePoint list isn’t a good target for logging data.

Another option which requires a little more jobs are to externalize the information from SharePoint. If you’re dealing with Office 365, the general public clouds, particularly Microsoft Azure, make lots of sense during these scenarios. From relational to document databases, message queues, file storage and caches, developers can combine these options using their custom applications to produce compelling SharePoint customizations and extensions!

In the following paragraphs, I detailed the various choices for creating SharePoint customizations. Developers who wish to build customizations that’ll be deployed and located within SharePoint have multiple options to select from including SharePoint solutions, SharePoint Add-ins, JavaScript Injection, and also the SharePoint Framework.

What about applications which are produced and deployed exterior to SharePoint? What options do developers have when designing custom applications that should speak with SharePoint or Office 365? What APIs and SDKs does Microsoft provide to those developers and may they be utilized within the same SharePoint located customizations? That’s the topic of my next article so stay tuned in!

SharePoint Framework Web seminar

Want much more assistance with SharePoint personalization and SharePoint Framework? Join me for any web seminar at 2pm ET on Thursday, September 7 with AvePoint’s D’arce Hess to uncover guidelines and strategies for selecting the best API and/or SDK for the custom applications.