 Even though Microsoft retired the MS600 exam and the associated MS600 developer certification in March 2023, you can still use the free, self-paced resources that Microsoft provided to learn how to use things like the SharePoint framework to customize and extend SharePoint and Viva connections. In this video, I'm giving you my entire guide that walks you through these free resources, including lectures, hands-on labs, and videos. Hi, I'm Andrew Kyle, and if you're new here, be sure to hit that subscribe button to stay up to date on all my videos for web and cloud developers on Microsoft 365 and related topics. And while you're at it, make sure you subscribe to my newsletter to get insights and the latest news in the world of Microsoft 365 for web and cloud developers. I've got a link to it here and the one in the description below. Before we get started with this, I want to set some context on what this video is going to cover. And while this only takes a moment if you're familiar with the history of my MS600 exam prep course, feel free to use the chapter links in the description below to jump ahead to the start of this guide for self-paced learning about customizing and extending SharePoint with the SharePoint framework. I created an exam prep course for the MS600 exam building applications and solutions with Microsoft 365 core services that hundreds of developers had used to prepare for and pass the exam. Microsoft used the exam to measure a developer's knowledge around a few Microsoft 365 workflows, things like SharePoint, Microsoft Teams, Azure AD, Microsoft Graph, and Office add-ins. But when Microsoft retired the exam in March 2023, I was left with this course that served as a guide for all those free self-paced study resources that developers could use to prepare for the exam. I can't sell that. No one could buy it would buy that course or more importantly, I can in good conscience sell it because the exam doesn't exist anymore. But here's the thing, the course content is all still valid. It's a self-paced guide on how to learn various things like what you need to know to be a qualified developer to be customizing and extending SharePoint with the SharePoint framework. So I've decided to release the chapters for each of the different workloads here on my channel. That's what you're about to watch. Note that there are parts of the video where I refer to the exam. Just know that the exam I'm referring to the MS600 exam. That's retired at this point and it's no longer available to take. Also throughout this video I'm going to reference a lot of online resources like documentation, training modules, videos, hands-on labs. The links are all in the video, but I've also compiled them in a single downloadable PDF and you can get this from the link in the description below the video. It's all on my site. Okay, enough with the explanation out of the way, let's dive into learning about the free self-paced resources for learning about customizing and extending SharePoint with the SharePoint framework. Now Microsoft SharePoint is a customizable platform that developers can extend with custom components and the SharePoint framework is the recommended development model to extend the modern SharePoint experience. This workload accounts for 15 to 20 percent of the questions in the question pool that could show up when you take the exam. In the first iteration of the MS600 exam, SharePoint had a much stronger focus than it does today. It originally was responsible for 20 to 25 percent of the questions on the exam, but in the November 2020 refresh of the exam, Microsoft realigned the waiting to put more emphasis on Microsoft Teams than on SharePoint, hence the reduction of SharePoint question pool down to about 15 to 20 percent. Now that you know what SharePoint is and how much of the exam the questions are going to account for devoted to SharePoint, let's look at the depth of knowledge that you're going to need to have in these various areas. Recall Bloom's taxonomy from the overview chapter in the course? Let's use that again to provide some context around what you need to know because it helps to understand how deep you need to know something before you embark studying for that topic. This helps you grasp the level of questions that you'll see on the exam. Now when you look at the skills checklist that Microsoft provides for the MS600 exam, you'll notice most of the skills include the following words, describe, identify, create, and implement. These phrases fall across the entire spectrum of the taxonomy, and that means for SharePoint, we're going to focus on the entire pyramid of the taxonomy, all the way from the lower order thinking skills like remember and understand, all the way up to the higher order thinking skills like evaluate and create. Now let's take a minute to explore what lessons you're going to find in this chapter so that you know what to expect as you proceed through this SharePoint chapter. In this first lesson on the overview, you've learned what to extend the SharePoint workload is all about. And on the next slide, I'm going to wrap up this lesson with some additional learning resources. So be sure that you check the notes under the lesson video for a collection of all the external references that I use throughout this chapter. The SharePoint workload is quite large and so many products at Microsoft not only come from the SharePoint but also integrate with it. And it has a long history of various ways to extend this product. It also has the added complication that SharePoint roots come from an on-premise installable product. While the focus today is the cloud service SharePoint online. So in addition to all of that, we're also on the fourth customization extensibility model for SharePoint. Sounds like a lot. Yeah, it is. But just like the other chapters, you don't need to know everything about this topic in order to pass the exam. So in the next lesson, I'm going to call out specific things that you need to focus on as well as things you can ignore as they aren't relevant to the exam. Then we'll begin with a look at an overview of what the SharePoint framework is. The SharePoint framework is commonly referred to as SPFX. So that's how you're probably going to hear me refer to it most of the time throughout this chapter. This lesson is going to look at some of the more global things that you need to be familiar with when it comes to SPFX. And this includes the tools that developers are going to use and also cover elements of SPFX that are not specific to particular types of components or topics that warrant their own discussion or lesson, like deployment or working with additional APIs. And the next lesson, I'll cover web parts and the basic building blocks for creating SPFX based customizations. And we're also going to look at how developers can add support for users either to edit public properties on the web part using property panes and some alternative usage scenarios for web parts, such as implementing single page applications and tabs in custom Microsoft Teams apps. And then we're going to look at the other popular type of component that you can build with SharePoint framework, extensions. These are also referred to as UI extensions and they enable developers to customize modern SharePoint pages and lists in one component. And this lesson will look at the different types of extensions that you could be tested on in the MS600 exam. Now, after covering the different components that you can create with SPFX, I'll then cover how to consume different types of APIs that are external to the SharePoint framework. And then finally, I'm going to cover the aspects of packaging and deploying SPFX solutions into your production environments. But there are plenty of resources that are available to you that you can leverage if you aren't familiar with the topic. So if I cover something in the course that you may think, I got it, I'm comfortable with my knowledge on this topic, then you're probably good. But if you think to yourself, I don't think I get it. Or if you aren't familiar with the process or a particular API that I cover, then you should go read the official documentation or study one of the multiple resources that I'm referencing throughout the course to make sure that you are adequately familiar with the topic prior to taking the exam. Now, I'll reference specific resources throughout the course. But like I said before, be sure to check the notes for this lesson under the video below for a collection of all the external references that I use throughout this chapter. But on this slide, I want to quickly run through the Microsoft Learning resources that I'm providing and explain what's in each one of these. The first group of links is around Microsoft Learning. They have learning paths and modules, and a learning path is just a collection of a bunch of modules that have been strung together. The learning path for SharePoint is called Extend Microsoft SharePoint Associate, and it contains the modules used for self-paced study to study for the exam. We then have five modules that cover various topics that I'll reference throughout this chapter, and all contain hands-on labs if you want to practice some of the topics you need to be familiar with prior to taking the exam. Now, these modules are as follows. Getting started with the SharePoint framework, developing web parts of the SharePoint framework, enable SharePoint framework web property, web part configuration with property panes, work with the SharePoint content using the SharePoint framework, extending the SharePoint framework user interface with SPFX extensions, leverage Microsoft Graph, and third-party APIs, deploy SharePoint framework components to production, and build teams' customizations using the SharePoint framework. You'll notice a lot more modules in this learning path than others that I've referenced in other chapters throughout the course, and that's because the SharePoint modules were originally written prior to the MS600 exam and the Microsoft Learning content site. So all the modules that support the content covered in the MS600 exam, but they're just broken down into much smaller topics. For example, there are two modules on dealing with web parts, one on web parts and one with web part properties, but in this chapter I'm covering both of those as a single topic and a lesson rather than breaking it up. SharePoint also contains a ton of documentation as well on their site, and I'll reference a bunch of individual links in the lesson notes, but you can always start at their Docs homepage and, again, found in the notes that accompany this lesson under the video. In this lesson, we're going to take a look at an overview of SPFX and look at some of the topics that don't necessarily belong and some of the other lessons throughout this chapter. Let's start with an overview of SPFX. And as I said in the introductory lesson in this chapter, SPFX is the entire focus of the MS600 exam's SharePoint section. To prepare for the MS600 exam, you should be very familiar with two aspects of SPFX, the core components and what's important to Microsoft. When I refer to the core components of SPFX, I'm talking about the fundamental aspects of the product as well as all the technical aspects that every SPFX developer should be aware of. High-level points that you need to be aware of are things such as that SPFX is the recommended way to customize and extend SharePoint. And this includes not just SharePoint online, but it actually includes every on-premise release of SharePoint going back to SharePoint Server 2016. Although SharePoint Server 2016 is a bit unique in the sense that it is supportive for SPFX, it's very limited. But regardless, you don't need to know much about the on-premise story of SPFX when it comes to the exam, just that it's possible. You should also be very familiar with the fact that SPFX is a client-side customization option for extending SharePoint. And this means there is zero server side component or options when it comes to the core part of SharePoint framework, which differs from other extensibility options. Furthermore, SPFX is primarily only a customization option for the modern user experience. While SPFX web parts are supported in the classic experience, SPFX is intended to be the customization experience for the modern experience. Now, let's start to look at some of the specifics with SPFX. The MS600 exam actually contains a question or two about the development experience. So you should be aware of what tools are required in order to build SPFX components. The official documentation that I've linked to walks you through all the requirements for setting up an environment for SPFX development. And you should be very familiar with this process. Specifically, all the tools that you'll use to work with SPFX are built on top of the Node.js framework. This is just a JavaScript engine wrapped in an API that enables it to run outside of the browser on a device like a laptop. One of the most significant differences in tooling from SPFX development compared to previous SharePoint developer models is that the Visual Studio is no longer required or recommended. The recommended tool for Microsoft is the lightweight text editor called Visual Studio Code. But really, you're free to use any editor that you like, including WebStorm, Atom, Sublime, or even Notepad. And by removing the dependency on Visual Studio, unfortunately, SharePoint loses that whole new project template wizard experience. Instead, Microsoft has adopted Yeoman and Yeoman generators to create the new project scaffolding. So make sure that you're familiar with how this works and that Yeoman is the engine or tool that runs a generator. Microsoft has created a Yeoman generator for SPFX projects. So when you execute the generator with Yeoman, you're presented with a series of questions that drive the creation of the project folders and the files for your project. So two more tools that are involved in creating SPFX projects are Webpack and Gulp. And you need to install Gulp on your development machine just like Yeoman, the Yeoman Generator, and Node.js. It serves as the same role that MSBuild fills with .NET projects as a task runner that handles jobs like compiling, bundling, and packaging these different solutions. And if you're familiar with Gulp, you know that it executes tasks that are defined with JavaScript. This is Microsoft's build tool chain that's included with each project, includes all the tasks that you're going to need to create, build, and manage your SPFX projects. The MS600 exam is not going to test you on creating custom tasks or anything other than the fact that Gulp is used as part of the tool chain. Furthermore, Webpack is used to combine multiple JavaScript and CSS files into a module or a bundle. You don't need to install it this as it's installed as part of the dependency tree in every single project. If you're familiar with Webpack, you know you need to provide configuration settings either in the form of a command line inputs or as a configuration file. Microsoft's build tool chain that's included with each project does this for you with each build, so you just need to be aware that it's used, but no specifics on how to customize Webpack when it comes to the MS600 exam. The last thing you need to be familiar with is language that's used to develop SPFX solutions, and as I've already stated, SPFX solutions are entirely client-side projects, which means they are ultimately comprised of JavaScript, HTML, and CSS. However, all the APIs and projects are based on TypeScript. That's a super set of JavaScript, so you should be familiar with that. Now with the core development topics covered that you need to be familiar with, let's take a moment and talk about the different types of things that you can create with the SharePoint framework. From a high level, SPFX can be thought of as two things. First of all, it's an API that developers can use to interact with the page, SharePoint, and other hosts, such as Microsoft Teams and other services, such as Microsoft Graph. The other aspect of SPFX is that you can build a few different types of components with it. SPFX supports creating three different types of components. The two types of components that you need to be familiar with are web parts and UI extensions. Now I'm going to go into more detail on both of these in the next couple of lessons. The third type of component that developers can create with SPFX are library components. Library components are used to contain code and logic shared across multiple SPFX web parts, extensions, or other library components. And while an important capability for developers, there aren't any questions in the SharePoint pool of questions about library components on the MS600 exam. Another topic that the MS600 exam may test you on are the different rendering options available to developers in SPFX solutions. Rendering options refer to the different web frameworks that can be used to implement SharePoint applications inside a SharePoint. Now the SharePoint framework has no limitations or restrictions on which web frameworks are or not supported for use in custom solutions. Developers can use whatever they want, including popular frameworks such as React, Angular, Vue.js, and many others. However, the Omen Generator for SharePoint does include project templates for web parts and select UI extensions for React. There is nothing special about the support for React in SPFX solutions though. SharePoint leverages React and therefore developers don't need to worry about getting it on the page. And then last but not least, you should be familiar with what the Office UI fabric is and how it's used within SPFX solutions. The Office UI fabric is the official front-end framework for building experiences in Office 365 and Microsoft 365 in SharePoint. SharePoint provides seamless integration with fabric that enables Microsoft to deliver a consistent and robust design language across various SharePoint experiences such as modern team sites, modern pages, and modern sites. You should be aware of the differences between the two different flavors of the Office UI fabric. There's fabric React and there's the React versions. There's core and React. The core packages contain the core style sheets, typography, colors, icons, and other building blocks that are used in the overall language. The React package contains a set of reusable components that are built using React on top of the fabric design language. Now, experienced SharePoint developers may be asking, but what about Fluent UI? Fluent UI is supposed to be the successor to Office UI fabric design language. However, it's not covered or addressed by the MS600 exam so you can ignore it for preparation but it's basically the same thing. It's just a different name for the Office UI fabric and you may also ask yourself, but wait, what about the PMP reusable controls? These are popular controls that are by the community that are community driven that are React controls that are built on top of the Office UI fabric. I don't deny these things are incredibly useful but these are not covered at all on the MS600 exam so you can also ignore these for your preparation. Okay, that wraps up my SPFX overview lesson and the next lesson we're going to look at the different types of components that developers can create and we're going to start off with web parts, property panes, and then how we can use web parts. In this lesson we're going to cover SharePoint framework web parts, the different types, and the various aspects that you need to be familiar with for the MS600 exam. With web parts, we also need to discuss other things, not just web parts but property panes and another unique case for web parts which is called full page apps. These full page apps are also called single page app pages but are most commonly known as SPAS or single page apps. We'll also cover using web parts as the implementation for custom tabs inside of Microsoft Teams although they can be used for a lot more stuff in teams but really only just interested for the exam about how they can use as custom tabs. Now let's start this lesson by looking at web parts. These are the most common type of component used in SPFX solutions. You should be very familiar with building SPFX web parts including the core SPFX API. The SPFX web part API is implemented by extending the base client side web part class and this contains a handful of methods that you need to be familiar with for the exam. You should know how to initialize your web part using the on and knit method and how that differs from using the web parts constructor class. In the nutshell, the constructor class is going to run or a constructor on your class is going to execute potentially before the SharePoint framework has initialized. So if you try to access the page context, you're going to get an exception or you have a good chance of getting an exception. On a knit method though, that is only going to run once SharePoint framework has been initialized and then it's going to be initializing your web part. You should also know that regardless if you are using the web part framework or a web part framework such as React or pure JavaScript, the render method is where you implement the logic that will create the visual aspects of your web part. And then finally you should also know how to work with the get property paying configuration property. That's going to define the property paying configuration for the web part. All web parts can also have setable public properties used to customize web part instances and you should be familiar with how to define and access these properties via the SharePoint framework API. Every SPFX component contains a code file where you'll define the logic as well as a manifest file and the manifest is a JSON file that describes the component including things like the name, the unique ID and other things that are unique to the component. For web parts, this includes things like the title, the description and the icon that are shown in the toolbox when adding a web part to a page. Then you also have these things called pre-configured web part properties and these are values that are all set in a section of the manifest called pre-configured entries. Now within that object there is a collection of name, value, pair properties that developers can use to pre-define your own custom public web part properties that are set when the web part is initially added to the page. Now you also need to be familiar with how to debug and test SPFX components. Web parts and extensions are tested different ways. Web parts can be tested using the workbench and this is a special page with a canvas that you can add the web part to the page. The hosted workbench is available in every SharePoint site collection. The hosted workbench is a real SharePoint page and that allows you to run your locally hosted web part alongside all other deployed web parts and even access real SharePoint data and lists. Now when discussing the API I mentioned the get property pane configuration property. This property enables developers to define the property pane in order to create a custom experience for your end users. You should be familiar with how to create custom property panes. You can do that by using the existing property controls that we have like textbox toggle controls, drop down lists, many others. You should also be familiar with how to implement data validation and the difference of reactive and non-reactive property panes and how to switch between these two modes and why you would want to do it. And then finally what's also involved in creating a custom property control that's something you need to know. Now the MS600 exam doesn't contain a lot of question on creating custom property controls but you should be familiar with the process and what's involved in creating them. If you're not familiar with this process refer to the Microsoft learning module in the lesson notes below the video as there's a hands-on lab exercise that walks you through this process. Now let me talk a little bit about full page apps. Web parts are special in the sense that they are the basis for a few different extensibility options that are based on SBFX. One of these are full page apps and you'll see and hear Microsoft also refer to these as single page app pages but we more commonly refer to these as spas or single page apps. Now what makes them unique from traditional web parts is the idea that the component takes up the entire page or most of it and is implemented using a web framework typically like React to create an application experience. They are added to SharePoint by creating a new page and selecting it from the list of page options. Now from the end user's perspective it's just a page because they can't modify the web part or add additional web parts to the page and developers can specify a web part can be added to a site as a spa by using this thing called the supported host property in the web parts manifest. By default this property contains the SharePoint web part string indicating that it can be added as a site to the site as a web part but if you use the string SharePoint full page it tells SharePoint that this web part can also be added as a spa and should be included in the list of template options when creating a new page on a site. Now as we'll cover in another chapter in this course Microsoft Teams is a huge area of focus for the MS600 exam because Microsoft 365 has a very big focus on teams and one area they're investing a lot of energy in is using SPFX to create custom Microsoft Teams apps. Now for the MS600 exam the only thing you'll be tested on is how to use SPFX web parts to create and implement a custom Microsoft Teams tab. So developers should be able to know how to specify a web part can be used as a tab in Microsoft Teams and you do that using the supported host property that I just used a minute ago. This is done in the web parts manifest and you simply add the string Teams tab to the array. Now the other thing you need to know about is that SharePoint's web parts as I've already covered use property panes to allow users to modify the public properties. Microsoft Teams tabs work differently and that settings are displayed as a pop-up and you should know how the initial configuration experience differs between hosting web parts in SharePoint or as a tab in Microsoft Teams for the MS600 exam. If you aren't familiar refer to the MS, the Microsoft learning module that I've included in the notes that is associated with this lesson for a hands-on lab exercise that walks you through this topic. And then finally you should also be familiar with the deployment and the hosting aspects of using SPFX web parts as Microsoft Teams tabs for the MS600 exam. Okay so that wraps up the lesson on SPFX web parts. In this lesson we're going to cover SharePoint framework extensions and the various aspects that you need to be familiar with for the MS600 exam. Now let's start with a high-level overview of extensions and some topics that you should be familiar with across all different types of extensions. There are three types of extensions that you can create as a SharePoint framework developer that you need to be aware of for the MS600 exam. These are application customizers, command sets, and field customizers. For each of these you should know how to test and debug them as the experience is very different from web parts because you can't use post-it workbench. Rather you need to use real SharePoint pages and lists to test each one of these different extension types. In addition each type of extension is different in how it's tested so make sure that you're aware of each one. And how to test each different type of extension. You also need to understand the deployment considerations for each type of extension and this includes setting predefined properties and unique configurations that each extension may require. And then you also need to make sure that you're familiar with the concept of tenant-wide deployment as well as the fact that only app customizers and command sets support this option. Now with all that being said let's look at what you need to be aware of with each type of extension. When it comes to an application customizer these are going to enable developers to do two different things. You can add client-side script to all pages within a site where the application customizer has been installed or when combined with the tenant-wide deployment option you can also add client-side script to all pages across all sites throughout your tenant. And this is done using the extensions on a net method. Make sure you also understand how placeholders work with application customizers. There are two placeholders on every single page the top placeholder and the bottom placeholder. Make sure that you understand how to get a reference to the placeholders the correct and safe way in your code. You should also be familiar with some common scenarios when application customizers are going to make the most sense. Think about when you'd want to add script to all pages throughout your site like a cookie or privacy dialogue notice or adding some telemetry and analytics application to your tenant. These are just two or three examples. Another type of extension is the command set and these enable developers to add buttons to the interface specifically on list toolbars as well as to the context menu on items inside of a SharePoint list. You control where the buttons appear when you register the button in the components manifest file. You should be familiar with the API event on list view updated that's raised every single time the state of the list view changes. So for example when a user selects an item this method is raised which can then enable the developer to change the visibility of a command set button. And then finally you should also know how to run your custom logic when a button is clicked as indicated by the on execute event that you can implement. And then last but not least is the field customizer. This extension allows developers to use JavaScript to implement the rendering of a cell and the display view of a SharePoint list. You should understand that how to use the on render cell method to implement the custom UX for a cell inside of the grid list of all items in a SharePoint list. The deployment of a field customizer is very different from the other two types of extensions that you're going to be tested on. For instance a field customizer is deployed as a new site column to a SharePoint site. So you should make sure you understand how this works and how it's very different from the testing and debugging process of creating custom field at customizers. Okay so that wraps up the lesson on SharePoint framework extensions. In this lesson we're going to cover adaptive card extensions and customization options for Viva connections. Let's start with a high level view of adaptive card extensions also known as ACEs and some topics that you should be familiar with when preparing for the MS600 exam. ACEs are a type of component added to the SharePoint framework in their release 1.13 and they enable developers to build rich native extensions for dashboards and Viva connections and SharePoint pages. ACEs use adaptive cards to generate UI that are supported across Viva connections, web, desktop, and mobile clients. And the skills worksheet is not very descriptive and detailing what exactly you need to know about ACEs so you're best off having a solid understanding of the various types of cards that are made available. There are two ways that you can render an ACE, the card view and the quick view. The card view is the ACE rendering when it's rendered in a dashboard or a page. ACEs when used on dashboards and pages are always rendered as a card, at least to start. Now there are three different options for rendering a card view. There are two similar options that are called basic card view and primary text card view. The basic card view is simply going to display some text with an optional button that can be used to launch the quick view while the primary text card view can be used to display some additional text with a card view. The other option is to display an image with text using the image card view option. The other way to render an ACE is with a quick view. When you interact with an ACE it can display a much larger customized experience which is what we call the quick view. So what kinds of things should you know about with respect to ACEs? You should know how to create both the card and the quick view of an ACE as well as how to add buttons to the card and handle actions like launching a browser window or opening the quick view. Similar to web parts, ACEs can have configurable properties that are set by users with the appropriate permissions and these enable you to customize each implementation of your ACE and this is done using the property pane. The standard property pane we're used to using with web parts. ACEs can be configured just like web parts. You should also know how to work with a state of an ACE and how the state differs from the properties on the card as well and you should also be familiar with action handlers and what they're used for. These allow you to perform actions when a user selects buttons in your cards. Another thing you should be familiar with are the different types of action handlers that are supported by ACEs. These include things like geolocation capabilities like getting and showing locations as well as uploading media like image files in your cards. Now the links that I've referenced in this lesson as well as those that are included in the notes below the lesson, they include a lot of really good tutorials, hands-on labs and samples of different things that you can do in creating ACEs to customize SharePoint pages and Viva Connections. In addition to ACEs, developers have additional options for extending and customizing Viva Connections and for the exam you should be aware of what options these are. These are covered in other lessons throughout this chapter. Now Viva Connections is just an app version of your SharePoint Internet site in Microsoft Teams. At least that's how you can think of it from a developer's point of view. And the reason I say this is because the way that you customize specific pages in Viva Connections, which are really just SharePoint pages, is to use web parts and we've already covered web parts in other lessons. Another option is to use application customizers, which is one of the types of extensions that we've covered in another lesson. You can use these application customizers to make customizations globally across all the pages inside of your SharePoint site and thus Viva Connections pages. All right that wraps up our discussion on adaptive card extension. Now in this lesson we're going to cover one of the more complicated topics with SPFX, which is how to consume external services including third-party APIs secured with Azure AD in your components. And it's a fairly complicated topic that you need to ensure you're well familiar with when preparing for the exam, just like I've mentioned throughout other lessons though in this course. Use the links that I've included in the notes under the lesson for preparing for the exam for some hands-on experience if you need that. So what exactly are we going to cover in this chapter? That's probably a pretty good place to start. The one thing I find quite interesting of the skills checklist for this exam is that Microsoft only included mentions of consuming third-party APIs secured with Azure AD as well as consuming the Microsoft Graph endpoints. The reason I find this interesting is that I know for a fact from my experience there were questions about calling two other types of endpoints. These other two types of endpoints are consuming third-party APIs that are not secured with Azure AD. These APIs are either anonymous or they are secured with a much more simplistic approach such as using a token or a key in the header value or in the URL. And the other endpoint which I can't believe was missed in the skills checklist is how to consume the SharePoint REST APIs. How can they miss mentioning that you need to know how to get data from a SharePoint REST API using the SharePoint Framework API and SharePoint Framework components? I don't get it but hey that's why you signed up for this course. In addition to the links that are relevant to the documentation on these topics I've included links to two Microsoft learning modules that cover all four types of these different options of endpoints you can call. So if you want some hands-on practice check the exercises in these two modules to get more experience prior to taking the MS600 exam. Okay so let's get started with the content. We're going to start by talking about the easiest option and move our way through to the more complex options. The first thing you need to know is how to consume services in a remote API that are not secured with Azure AD. This includes endpoints that could be either anonymous APIs that require no form of authentication or those that have some sort of security that's a lot simpler to handle than an endpoint secured with OAuth2 tokens such as Azure AD which we'll look at in a later in this lesson. For these endpoints you need to know how to use the HTTP client API that's included with the SharePoint Framework API. While you're not going to be tested on it it helps to know that this API is just a wrapper to the native support browsers have for something called the Fetch API and then it also includes a polyfill for browsers that don't implement the Fetch API like that pesky internet 11, internet explorer 11. This API as you can see from the following code snippet supports making a simple get or post request to a remote endpoint. The optional third argument in the get or post method enables us and developers to override the default HTTP header values and the body if you need to have more control over the request. The next and maybe more common endpoint that you're going to consume within your custom SPFX components that's the SharePoint REST API. The SharePoint Framework includes the SP HTTP client API which is used to call the SharePoint REST APIs in the same site where the component is running and as you can see from the following code snippet it looks identical to the previous sample for the HTTP client. The nice thing about this API is that it handles all the authentication and configuration of the request that are required to call the SharePoint REST API and just like the HTTP client an optional third argument on the get and post method enables developers more control over the request headers and body and in fact under the covers the SP HTTP client object is just reconfiguring the HTTP client object to call the SharePoint REST API. Now we move into the more complicated parts. You need to be familiar with the support SPFX has for calling third-party APIs that are secured with Azure AD. Let me explain from a high level what Microsoft did and how it works using my own UML sequence diagram. Now Microsoft has provisioned an Azure AD app for every SharePoint online tenant and this app is found in the Azure AD tenant for your Microsoft 365 tenant. Administrators can grant this app permissions to another endpoint secured with Azure AD and then using the AAD HP client API in the SPFX API. A component can request an access token for the target endpoint. What the API does is request an access token from SharePoint online which in turn is going to authenticate and request the access token for the previously approved permission request and then SharePoint online if everything has been set up correctly returns the access token to the SPFX component. The SPFX component then uses this access token to submit the request to the endpoint like normal. The entire process that I just explained while complicated is entirely transparent to the developer and thankfully other than granting the request and granting of the permissions the entire process I just explained is handled by the AAD HTTP client factory as shown in the following code sample. Now the call to get client is what triggers the request to SharePoint online for the access token. When SPFX receives the access token it uses it to configure the client that you then use like any other HTTP client that I've already gone over so far in this lesson. The one thing that's unique about this API is the permission request and you should be familiar with the different ways that you can request permissions as well as how to manage these different requests and while the Microsoft official documentation does cover these options it's a bit sparse and it leaves a bit to be desired. So I've included a link to a blog post in the lesson notes that I wrote that has some guidance on this topic and includes an additional detail on how it works so that you may find that useful in terms of better understanding this entire process. Now it's very important that you also understand that a permission request is not tied to a specific SPFX solution or components. Once a permission is granted within SharePoint online to another API any client side script within the tenant can access or request an access token SharePoint online has no way to determine which script the request came from. Now also Microsoft does provide a way to secure a request to a specific SPFX solution. This is done using something called domain isolated web parts but I'm going to cover that when I talk about packaging and deployment of SPFX solutions in another lesson. This last endpoint to cover is calling the Microsoft Graph. Now this one is unique in that other than the SharePoint API it's the only one that other than it's the only other endpoint that has its own API in the SharePoint framework API. Now on the last slide remember that code snippet that I used that used the AAD HTTP client factory to call the Microsoft Graph. Now that works when you want to call the Microsoft Graph REST API but there's another option that's supported by SPFX. The Graph team has created a JavaScript SDK that developers can use to work with the REST API for Microsoft Graph. This SDK abstracts away the REST nuts and bolts and provides a fluent UI that some developers are going to prefer. Now what the SharePoint team did is they created a special API that uses their support for calling Azure AD secured endpoints like Microsoft Graph to automatically configure the Microsoft Graph JavaScript API for you. So as you can see from this code sample it looks very similar to the AAD HTTP client factory API except you don't have to specify the endpoint when you call get client because it already knows what the Microsoft Graph client is or endpoint is. The other difference is the client that you get back as is the Graph JavaScript SDK that provides the fluent API. Now the support for Microsoft Graph also has all of the same requirements and considerations when it comes to requesting and managing permissions that we went over when I talked about Azure AD secured API so make sure you're familiar with all of those as well. Okay that wraps up the lesson about working with third-party services and SPFX solutions. In this lesson I'm going to cover what you need to know about packaging and deploying custom SharePoint framework solutions for production for production use in order to be prepared to pass the MS600 SharePoint workload portion of the exam. So let's get started. This let's quickly look at what this includes as well as what it doesn't include and we're going to look at the different options that developers have at their disposal when they are preparing an SPFX solution for deployment including all the tools that are involved. Now the process of packaging an SPFX solution for SharePoint development or deployment to SharePoint framework environments we're also going to look at what's involved in upgrading SPFX solutions and then we'll cover two specific deployment topics one of them is tenant scope deployment of SPFX extensions and we're going to also look at domain isolated web parts as well. Now there's one topic that we're not going to cover in this lesson or anywhere in this chapter and that's the process of publishing apps to app source. In mid 2020 Microsoft added support for publishing SPFX solutions to app source that's Microsoft's app store or public marketplace and this capability pre-dated the MS600 exam and therefore isn't covered in the course as you don't really need to be familiar with it for the exam but I've included a link to it in the lesson notes if you're interested in learning more about this process. Okay so let's go ahead and get started. We're going to start by looking at the process of preparing your SPFX package for deployment and I've already covered some of this topic in previous lessons. The topics that I covered in previous lesson are the tools used in packaging your solution these are tools such as gulp and webpack gulp is used for to run tasks while the SPFX tool chain uses webpack to create a JavaScript bundle that'll be included in the generated package you should be familiar with the role that webpack serves but you don't really need to know how much more than that for the MS600 exam so for example while you can customize webpack you don't need to know how to do this for the MS600 exam and the same story is true about gulp you don't need to know how to create custom tasks for the MS600 exam however you should be familiar with the tasks and what they're used for that are included in a new project and you can get a list of all the tasks by executing gulp within the context of a project with the dash dash tasks flag on it. Another topic that you need to be familiar with for the exam is the nuances around leveraging external JavaScript libraries and your SharePoint framework project now referencing external libraries such as jQuery this is a common practice when creating custom client-side solutions but without knowing how this works you can inadvertently bloat the deployment files and adversely impact the performance for your users and you should know for the MS600 exam how to use the config.json file in an spfx project to manipulate the bundling process you need to know how this works and what the implications are if you don't or if you do or don't elect to include this in the project so now let's look at the actual process of packaging your spfx solutions for deployment there are a few topics that you there are a few topics that you should be familiar with in your preparation for the exam you need to know the difference between the two different packaging modes and these two different modes are the debug mode and the production or the ship mode you control the mode by including or omitting an argument when you run the gulp task bundle and package solution commands using gulp now when you include the dash dash ship argument you're running in the production mode otherwise it's just the debug mode so what's the difference well the production mode creates bundles intended for deployment and it expects these these it expects these files are not going to be served up locally from your developer workstation rather they're going to be deployed to their final hosting location we're going to come back to that in a minute the production mode will also minify the generator bundles removing all white space and comments to make the files as small as possible however the debug mode will leave the files unminified that simplifies debugging and the files will be served up from a local web server on your local development machine another topic you need to be familiar with is the Microsoft 365 CDN and how you can leverage it as part of your deployment now when you create an spfx solution package there are two groups of files that are used to implement your solution one set of files are deployed to SharePoint to make it aware of your custom solution and this also includes details on where the SharePoint framework can load the executable files from the other group of files are those used to implement the logic of your customization this includes the component manifest json file and the components in the javascript bundle now how does this fit into the cvn well spfx solutions by default they have a property called include client assets in the package solution dot json file and that's within the project and it's all it's by default set to true and this tells the build pipeline to include the second group of files in the SharePoint package when you run the packaging process if you deploy the package to a SharePoint online site and the tenant has the Microsoft 365 cvn enabled SharePoint will extract the SharePoint framework solutions javascript bundle and manifest file and deploy them to the Microsoft 365 managed cvn and this greatly simplifies deployment for customers however this might not work for all scenarios so you should also be aware of the deployment options when Microsoft 365 cvn is not available and in that case customers can deploy spfx solutions job the javascript bundle and the manifest file to another publicly available areas or even another cvn and in this case you should know how to configure a solution to deploy these files to a cvn or a location that they control you should also know some common scenarios when customers may want to use their own cvn for example maybe they want more control over the cvn settings than the one that managed by Microsoft 365 maybe uh maybe you wanted to leverage the ip or geolocation filtering of content and because cvns aren't used to secure files rather they're used to distribute them maybe a customer situation maybe they want to ensure the files are not publicly accessible so that's another option they may want or maybe the deployment target isn't SharePoint online maybe it's SharePoint server 2019 which is an on-premise installation and thus it doesn't have access to the Microsoft 365 or the Microsoft 365 cvn these are just a few of the scenarios the point is though in that preparing for the exam you should be familiar with on how to configure a project to both use the Microsoft 365 cvn or another location that you control to host the packages manifest and javascript bundles now at this point we've covered everything you need to know up to actually deploying your custom solutions so let's tackle that topic right now when you deploy your spfx solutions you upload and publish them to a special library called an app catalog the SharePoint has two different types of app catalogs that support deployment of solutions at different scopes every SharePoint tenant has a single tenant app catalog created and managed typically during the initial setup and creation of a tenant all spfx components included in solutions uploaded and deployed to the tenant app catalog are available for installation and used within any SharePoint site across the entire tenant the other option are site collection app catalogs and these act the same way as a tenant scoped app catalog except that the spfx components within these app catalogs are only available for installation and used within the site collection where they were deployed and this gives SharePoint administrators the ability to limit the scope of who has access to select site collections now site collection app catalogs must be created in each site collection by an administrator as they weren't created by default when the sites were created and furthermore these must be created via the console usually either via the SharePoint online power shell commandlets or using the cli for microsoft 365 that was formerly known as the office 365 cli you should be aware of how to create the site collection app catalog for the ms600 exam specifically you really only need to know the SharePoint online power shell options because the cli is a community-based project that is not going to be uh you're not going to be tested on now once you've deployed and installed your spfx solution you know one of your users or customers is going to eventually request a change maybe it's a bug or a new feature or maybe that button need to be a little more blue in these cases you should be familiar with the aspects of updating and upgrading spfx solutions and this falls into multiple different topics some you should be familiar with for the ms600 exam questions but also in understanding just how everything works and while you're not likely to get a question about about this you should also be familiar with the process of checking to see if your project contains references to outdated dependencies as well as how to upgrade these different dependencies again you're not going to be tested on how to do that though you should also be familiar with the process of adding additional components to existing packages so for example say you've deployed a package it's got a single web part but later you want to add two more web parts to the same package how do you handle this or how is this being handled by spfx well in a nutshell because components are provisioned using SharePoint features under the covers you need to get a you need to get SharePoint to reactivate the feature the way you do this is by incrementing the solutions version which is going to be set in the package solution json file and then you're going to upgrade the previously installed app instances to get that feature to get activated or upgraded the upgrade action will then trigger SharePoint to activate the new features in the solution package which will provision the new site components in the site but you also need to know how to SharePoint handles code changes when packages are upgraded many SharePoint developers are surprised that simply changing the code and uploading a new package without making any changes to a version number or actively upgrading installing the app actually upgrade the existing code so in other words regardless of anything else when you update and install spfx package the code the new code files overwrite any previously deployed files and this happens the moment the package has been uploaded and trusted and then finally you need to be familiar with the version numbers SharePoint framework solutions contain multiple version numbers and I've mentioned before there's the version for the entire package that's deployed to SharePoint that's defining the package solution json file then there's also the version number of the individual component found in each of the components manifest files that are set right beside the actual code file for that component a web part an extension etc and then there's the component version that's defined in the package json file this number is only used when the components version number is set to an asterisk think of this as an easy way to set the version for all components within the package to be the exact same version another topic that you must be familiar with and preparing for the ms600 exam is the tenant scope deployment and this is an optional deployment option for spfx solutions when a solution that is this capability has been enabled the administrator is given the option to make the solution available to all sites within the organization when the solution in is deployed in this manner all components are immediately available in all sites across the tenant once the package has been uploaded and deployed to the tenant's app catalog the way that you're going to configure this in a solution to support this deployment option is by setting the skip feature deployment property equal to true in the package solution json file and this is actually set when you create a new project and answer the question do you want to allow the tenant admin the choice of being able to deploy the solution to all sites immediately without running any feature deployment or adding apps and sites it's a lot answer yes that's that's the value of true now then you also need to understand the impact of web parts because when a solution that contains web parts is deployed to the entire tenant this way they're immediately available in the uh in the sharepoint or in the web part picker tool uh tool pane uh in all sharepoint sites and then when a solution that contains extensions is deployed to the entire tenant this way they are immediately available and added to all sharepoint sites this time that they're installed or deployed to the tenant app catalog now the last topic I need to cover that you should be familiar with in your exam prep are domain isolated web parts now in a previous lesson I covered how the SharePoint framework and SharePoint online addresses the OAuth2 access token acquisition process for an SPFX component to call an Azure AD secured endpoint now one aspect is that any script in the tenant can use this same process to obtain an access token not just an SPFX solution so domain isolated web parts introduce a way to isolate access to Azure AD secured APIs so that only specific SPFX web parts can obtain access tokens for the API now this is done by enabling a setting called the is domain isolated property to true in the packages package solution JSON file now what this does is it renders the web part not in a div on the page but rather in an iframe and that iframe is hosted on a domain that is unique to this particular component in addition when the solution is provisioned SharePoint provisions a unique uh Azure AD application for the SPFX solution and then when the SPFX component requests the access token SharePoint online can ensure the call is coming from the unique domain for the specified Azure AD application which has been granted permissions to the secured API you should be familiar with how domain isolated web parts work the scenarios where they're suitable and how they're different from non-domain isolated web parts that call the Azure AD secured APIs if you have any questions about what I've covered here please drop a comment or let me know if you want to see more videos about SharePoint framework development or something else by dropping a comment below if you like this video please give me a thumbs up and subscribe by smashing that big red subscribe button below the video so you'll see when I publish more videos for web and cloud developers on Microsoft 365 and Microsoft Azure topics I'm Andrew Connell again thanks for watching I hope to see you next time