Microsoft 365 | Specialised Training | SharePoint | Nintex | LiveTiles | Azure | Project Server
Thorough education is key to working with SharePoint 2013 productively. This course guides you through essential 2013 elements, from pre-requisites to system integration, giving you the skills to work confidently and leverage full value from new technology.
Ideally, students will already possess some hands on SharePoint end user experience, be familiar with Visual Studio, and possess some knowledge of JavaScript, the .NET programming language (like C# or VS.NET) as well as object oriented concepts. JavaScript experience using common patterns and popular frameworks (such as jQuery) and ASP.NET experience including User Controls, Server Controls, and Web Services is required.
The primary audience for this course is Web and .NET developers that need to learn how to extend and develop applications using SharePoint.
It is essential for developers to master the SharePoint vernacular that is pivotal to the successful implementation of an out of the box SharePoint Farm before setting out to alter that experience. So, this module is an attempt at level-setting the participants understanding of the SharePoint platform, essential SharePoint terminology, core SharePoint developer concepts, the SharePoint developer environment, and along the way we debunk several SharePoint myths for good measure.
It’s been said that craftsman are only as good as their tools. So, alongside the release of SharePoint 2013 is Visual Studio 2012 which includes a plethora of new tools for building SharePoint platform extensions and packaging them for deployment. This module explores the numerous new capabilities Visual Studio provides to enrich the SharePoint development experience and enhance SharePoint development productivity. Further, the labs explore how to extend Visual Studio itself to enhance the development experience to achieve even greater developer productivity.
A SharePoint Feature is a bundle of functionality that can be activated at a given scope. A SharePoint Solution is a collection of assets packaged for deployment to a given SharePoint context. These two facilities are fundamental to every SharePoint platform extension. No matter how big or small, everything deployed to SharePoint must be managed using Features and Solutions. Fortunately, Visual Studio 2010 provides significant assistance in configuring and generating both Features and Solutions.
The Share Object Model comes in two flavours. The Server Object Model is used to query and update the configuration and content databases. This provides a layer of abstraction that ensures that code created today will work tomorrow even significant underlying architectural changed are made to the SharePoint platform.
First there was LINQ to Objects, then LINQ to SQL and LINQ to XML. Now there is LINQ to SharePoint. Integrating query into the language provides many benefits not the least of which is a strongly-typed (think object properties rather than arrays with string keys) design-time validation of a SharePoint List query. No more CAML queries in managed code! This module demonstrates not only how to query SharePoint Lists using LINQ to SharePoint but also how to update that content.
The Client Object Model provides methods techniques of interacting with the Server Object Model from contexts other than the SharePoint server. The SharePoint Ribbon is dependent on the Client Object Model. The Client Object Model has been significantly extended to support the new SharePoint 2013 App model.
Representational State Transfer (REST) is such a poor name. Think query by URL to retrieve JSON object response. Also known as ADO.NET Data Services, WCF Data Services, and OData, SharePoint 2013 supports the REST protocols for querying data in SharePoint Lists. The OData API has has been significantly extended to support the new SharePoint 2013 App model.
Web Parts are the basic building blocks that fulfill SharePoint’s prime directive: Empower the end user to self-sufficiency. A self-reliant user is a happy user. Web Parts allow the end user, within some constraints, to assemble, configure, and customize their own applications. Visual Studio 2012 introduces a SharePoint Project Item that facilitates creating Web Parts with a design surface called Visual Web Parts. The labs for this module also explore the concept of Replaceable Parameters in Visual Studio 2012 SharePoint Projects.
One pivotal aspect to any Web development effort is navigation. One of the most visible changes in SharePoint 2013 is the user interface element called the Ribbon. The Ribbon along with several other the context-sensitive elements: the Dialog Framework, the Notification Area, the Status Area, and the AJAX framework make up with is known as the fluent UI. Creating Custom Actions and orchestrating these elements requires a few JavaScript programming skills. Since SharePoint leverages the ASP.NET Navigation Provider model for providing a Site Map of links to Sites and Lists in close proximity to the current Site, the labs explore creating a Custom Site Map Provider too.
Extending SharePoint imperatively can easily be done by hooking into the events surfaced by the SharePoint platform. Events are fired when users interact with List Items, Lists, Webs, and Features. This module explores what events are available, how to configure them declaratively and imperatively, and how to package them so the end user can decide what contexts they will run in. The end user in two of the four contexts is the SharePoint Farm administrator.
There are only two ways to run code: 1. someone did something (see Event Receivers and Feature Receivers) or 2. Time has passed. Timer Jobs can be scheduled to run only once or on a given schedule. They can run on a single server or every Web Front End (WFE) on the SharePoint Farm. They always initially run in a God-mode thread so they make a wonderful catch-all for anything that hasn’t been accommodated by the SharePoint platform extension framework.
Who is that trying to access to the SharePoint Farm? Evaluating the user’s ability to identify themselves by providing some predetermined evidence that they are who they claim to be is not something that SharePoint tries to do. Instead, SharePoint relies on the pluggable ASP.NET membership provider model. So, this could be as simple as collecting the users username and password or could include additional factors like the presence of a smart card, a digital certificate, a USB dongle, or even a biometric scan. This modules lab demonstrates how even SharePoint could be used as a repository of members for authenticating to SharePoint.
While many developers would be in favour of just granting everyone administrator access and be done with security. The reality is that businesses need to make sure only certain people have access to certain information. SharePoint provides four securable objects: Site, List, Folder, and Item. By default, all objects inherit their permissions from the top-level Site. Permissions can be granted on an individual by individual basis or a collection of people can be granted access (AKA role-based security). There are the traditional ways of naming collections of people like Active Directory Groups, Forms Based Authentication (FBA) Roles, and even SharePoint Groups. However, there is a new way of identifying a collection of people via some common characteristic provided as a Claim made by the identify provider. This modules lab explores how to augment claims for an existing identify.
All SharePoint Lists and Libraries consist of a collection of columns which derive their display-mode and edit-mode characteristics from one of the out of the box Field Types. The presentation of the data managed by the Field Type is governed by a Field Control. This module’s lab examines how custom Field Types can be derived from an appropriate out of the box Field Type and how a custom user interface can be presented in the context of a List Item being displayed in a list or on its own, as well as its behaviour and presentation when the screen is in edit-mode.
SharePoint 2013 introduces both a corporate and a public Marketplace (“App Store”). Finally! In short, you can now write applications for SharePoint (Apps) that extend SharePoint sites using the new SharePoint App Model. This module covers everything you will need to know about the three models for developing SharePoint Apps.
SharePoint 2013 is all about hosting external application functionality in a SharePoint context. Those external applications (Apps) will often need to interact with the SharePoint environment. This module illustrates how to leverage each of the various client object models implementations in SharePoint projects to access SharePoint data.
Traditionally, event receivers ran imperative logic on the SharePoint server. SharePoint 2013 adds remote event receivers to handle events that occur on a list item, a list, a web and now in an App. Additionally, App event receivers handle events involving the app itself, such as when it’s installed or deleted.
Information is frequently not confined entirely to SharePoint databases. This module focuses on consuming and interacting with external data sources using a custom .NET Assembly Connector. Creating BCS-enabled SharePoint Apps, the new remote callouts, the extended client-side object model are explored as well.
In SharePoint 2013, Windows Azure Workflow (WAW) Services isolates logic into a service that is independent of SharePoint. This module demonstrates how to create custom workflows using either SharePoint Designer 2013 or Visual Studio 2012.
SharePoint may maintain the fully qualified reference to imperative code in dozens of web.config files scattered across one or more Web Front End (WFE) servers, in XML files through the {SharePoint Root}, and in hundreds of rows in the configuration and content databases. Upgrading from one assembly version to another is a daunting undertaking and typically hasn’t been done. This module’s labs not only explore FeatureUpgrade, BindingRedirect and the like but also demonstrates the use of a WebConfigModification when it is required.