 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 things like Microsoft Teams app development. 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 Cottle, 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 of Microsoft Teams app development. 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 Addends. 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 building Microsoft Teams apps. 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. Know 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 Microsoft Teams app development. Microsoft Teams is an extensible platform that you can create custom apps on. Apps for Microsoft Teams can be as simple or as complex as you need from sending notifications to channels or users to complex multi-surface apps, incorporating conversational bots, natural language processing, and embedded web experiences. You can build apps for an individual, your team, your organization, or for all Microsoft Teams users everywhere. And just like all the other chapters in this course, I'm keeping the depth of explanation to the level of what you need to know in order to pass the exam. I'm trying not to go too deep with my explanations because this is an exam prep course. It's not intended to teach you everything about the topic. There are plenty of other resources available that you can leverage if you aren't familiar with a particular topic. When I cover something in the course, you may think, okay, I got it. I'm comfortable with my knowledge on this topic. But if you think to yourself, I don't get it, or you aren't familiar with a process or an API that I'm covering, you should go read the official docs 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'm going to reference specific resources throughout the course. But like I said, be sure to check the notes for this lesson under the video for a collection of all the external resources that I'm going to use throughout this chapter. But on this slide, I quickly want to 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 Microsoft Learning paths and modules. A learning path is just a collection of modules that are all strung together. The learning path for Microsoft Teams is called Develop Apps for Microsoft Teams Associate. It contains the modules used for self-paced study to study for the exam. And then we have some modules that cover various topics that I'll reference throughout the chapter. They all contain hands-on labs. If you want to practice some of the topics that you need to be familiar with prior to taking the exam. These modules are things like introduction to building apps for Microsoft Teams, task-oriented interactions in Microsoft Teams with messaging extensions, create abetted web experiences with tabs for Microsoft Teams, create interactive conversational bots for Microsoft Teams, collect input in Microsoft Teams with task modules, connect web services to Microsoft Teams with web hooks and Office 365 connectors, create interactive meeting apps for Microsoft Teams as well. Microsoft Teams contains a ton of documentation as well on their site. Now I'm going to reference a bunch of individual links in the lesson notes. But you can always start at their docs homepage. Okay, that wraps up the overview lesson. And in the next lesson, I'm going to cover the common topics, custom Microsoft Teams apps that you need to be familiar with before taking the MS600 exam. In this lesson, we're going to look at an overview at custom Microsoft Teams apps and look at some of the topics that don't necessarily belong in other lessons throughout this chapter. Let's start by understanding from a high level what Microsoft Teams apps are. A Microsoft Teams app that consists of one or more services that are registered with Microsoft Teams. And when I use the term services, I'm being pretty loose here because it's really just one of the things that Microsoft Teams supports. None of these things live within Microsoft Teams. Rather, Teams is going to load or interact with these things wherever they're hosted by the providers of these things. These things are surfaced within Teams, either within web frames, such as in the case with tabs or task modules or with web services, such as in the case with bots and meeting extensions. Speaking of customizations, what kinds of things can you build? Various lessons in this chapter will go into the many of these in more depth. Things like tabs, task modules, webhooks, bots, meeting extensions and meeting apps. Things that are not covered in this chapter because they aren't a focus of the MS600 exam include things like the activity fee, which is used to personally notify users of events. Another thing that's not covered by the MS600 exam are personal apps. These can be bots like private workspaces with its own tabs. And the only point of these is that they're only personalized for individual users, not a shared experience like a team. A custom Microsoft Teams app describes different customizations to the client when it's installed. Some customizations can be scoped for the different experiences for your users. There are two scopes, team and personal. The team scope makes your customization experience exist in the team context. So in the case of bots or messaging extensions, they are available in all channels within a team, while tabs are added and customized on a per channel basis. In a personal scope, your customization experience exists within the context of an individual. So in the case of a bot or messaging extension, they're only available in one-to-one chats. While tabs are available to end users via the left-hand app bar or alongside one-on-one bots. Now let's talk about hosting your custom apps. This is a topic that's closely related to testing these same apps. Remember when I said earlier that a Teams app doesn't contain the actual customizations? Well, that's because everything that you create, well, that's because everything that you create is your service that you're responsible for hosting on your own infrastructure or your own cloud services. And this is true for web apps that serve up pages used in tabs or web services that implement your bots and messaging extensions. And this means you're responsible for the entire build test deployment process. These are things that you need to manage yourself. And it's also true for hosting the services as well as testing them. But to test them, you likely wanna test them within Microsoft Teams clients as you'll wanna validate your custom components before publishing them to customers. And to do this, you wanna side load your custom app in the Microsoft Teams client. I'm gonna talk more about this deployment option in a moment. You need to be familiar with the manifest file that's used to define a custom Microsoft Teams app. In order to be prepared for the exam, you should be familiar with different ways to create a manifest. This includes using the Microsoft Teams app called App Studio, and you install this in your local instance of the Microsoft Teams from the Teams app store. While the skills worksheet was updated to remove any app studio references, as this tool has since reached its end of life and is no longer supported, when I took the exam in September of 2022, it was still some questions on the exam about it. You should also be familiar with the developer portal for Teams. This is the preferred way to manage your Microsoft Teams apps, including customizing the app manifest. You should also be familiar with how to create the manifest.json file manually because the MS600 exam is gonna have some questions in the question pool for teams that does include questions about parts of the JSON schema, so you should be familiar with it. Okay, that wraps up the overview lesson on custom Microsoft Teams apps. In the next lesson, we're gonna start looking at specific customizations that developers can add to their Microsoft Teams apps. The first one that we'll look at are task modules. Task modules is the fancy name for dialogues in Microsoft Teams. Now, task modules are used in Microsoft Teams when you need to create a modal pop-up experience, and you can use these in one of two ways. You can use these to collect input from your users by prompting them with a form to complete, as you can see here, from this screenshot. This task module, the YouTube video selector, is prompting the user for the YouTube ID of the video that you wanna display. So the information is collected from this task module. It's gonna be passed back to the initiator of this task module. And in this case, it was just a simple tab. When the form is submitted. Now, the other use case for a task module is as a modal dialogue to display something. As you can see here, from this screenshot. In this task module, the YouTube player includes the embedded YouTube player so that the user can view the selected video from YouTube. Now, like a task module is used to collect information from the user, developers can send this information to the task module, such as the cases where the YouTube video ID is passed to the task module. And by the way, from both the screenshots on this slide, they were both taken from the Microsoft learning module on task modules, specifically the hands-on lab exercise. So you can check the notes for this lesson if you'd like some hands-on experience and working with task modules. So now that we've covered what task modules are, we need to cover a few different use cases that you'll need to be familiar with in your preparation for the MS-600 exam. So we're gonna start with the options for creating task modules. Developers are offered two different ways to do this when it comes to creating task modules. You can use HTML pages to create your task modules or you can use an adaptive card to render your task modules and it's just express it as JSON. So let's look at each of these different options at a little more depth. The first option when creating task modules is to use the standard web technologies. In this option, you simply point the URL of an HTML page that is publicly accessible to the user when you launch the task module. Microsoft Teams will load the specified URL in a task module using the specified dimensions that you can see here from the code snippet that I have here on the slide. And this makes it easy to integrate it with an existing web app that you may have. To launch the task module, you simply call the method start task and you pass the task object that contains all the details including the URL of the page that Microsoft Teams should load. Now developers are free to use simple HTML, CSS and JavaScript to implement the task module or they can use a web framework such as React, Angular, Vue, JS or really whatever they prefer to implement the task modules interface. The point is developers have full control over the implementation of your task module using just standard web technologies. Now the second option available to developers to implement task modules are adaptive cards. And adaptive cards are widely supported in Microsoft Teams in multiple areas including task modules. So an adaptive card is represented as a JSON object. The JSON string defines all the controls, the text, the actions that the hosting application will use in order to render and react to the card. And this JSON can be authored in any text editor and Microsoft Teams app studio, you can use that to author adaptive cards starting with a template and a preview of the rendering of the card. One advantage to using the adaptive cards over the iframe option is that the developer doesn't have to deal with the rendering of the actual task module. Microsoft Teams is going to take the JSON provided and use the rendering using and implement the rendering using the standard UX styles defined in Microsoft Teams. As you can see from this code snippet that I have here on the slide, launching the task module that's implemented using an adaptive card is as straightforward as using an HTML page. The only difference is that you're going to swap out the URL property on the task info object with a card property. Now the Microsoft learning module referenced in the notes for this lesson contains hands on lab exercises when implementing task modules for either HTML pages or adaptive cards. But I've also included another Microsoft learning module in the lesson notes that's dedicated to adaptive cards if you aren't familiar with them. They're important, but just not for task modules but for lots of other places in Microsoft Teams as well as an office extensibility such as outlook actionable messages. Now the next thing you need to be familiar with is how to invoke task modules. Task modules can be launched in the Microsoft Teams client in two different ways. They can be invoked either using a tab or they can be invoked using a bot or conversational bot. So let's look at these two different options. Invoking a task module from a tab is something that you've already seen in the code for on the previous slides that I've shown. And this is done using the Microsoft Teams JavaScript SDK. Now what you're going to do is you're going to load the JavaScript SDK within your tabs HTML page that you created and that you host. To invoke the tab, you're going to create the task info object that defines the title, the dimensions and the source for the task modules you see here. And then you're going to launch the task module by calling the start task method and pass in that task info object. You can see that on the slide. This method, as you can see from the snippet is on the tasks property that's found on the Microsoft Teams JavaScript SDK main reference. Now you're also going to need to know how to handle situations when a task module is submitted as in the case when you're collecting input from a user. And this is done by passing a handler as the second argument to the start task method as you can see here on this updated code. I've created a submit handler function that takes in a couple parameters, an error string and the result string. And then I've taken that handler and passed that in as the second option on the start task method. Now task modules can also be invoked from bots. And this process is a lot more complex to explain as we haven't really covered bots just yet in this chapter. Kind of have a bit of a chicken and egg problem here. So you may want to jump back to this after you studied up on bots lesson and kind of understand how this works in a minute. But I'm going to go ahead and keep the bot specific discussion as topical or as simple as I can for the moment at least for now. So for now, what you need to understand is that bots are implemented as APIs or web services that you as the developer are going to end up having to host. Once you've implemented the bot as a web service, you're then going to have to register it with the Azure Bot framework and Microsoft Teams is going to communicate with your bot or the API via the Azure Bot framework. So to invoke a bot, to invoke a task module from a bot, your bot web service has to submit a specific type of a message to Microsoft Teams via Microsoft Azure Bot framework. And while the bot framework provides SDKs for .NET as well as Node.js, or you can implement the bot API with raw JSON responses if you like. But as I mentioned multiple times in this course, the MS600 exam is going to focus mostly on JavaScript or TypeScript when it comes to coding type questions that come up. That's what I'm going to demonstrate here. Now there are two handlers for your Node.js based API that you can implement to invoke and handle task modules. Now the method handleTeamsTaskModule fetch is called when a bot is called when the bot receives a message with the type set to task slash fetch. And this is going to serve as the trigger that's going to tell the bot that I want to load a task module. So the bot's going to respond to say which one should you load? As you can see there from the code sample. Now the method handleTeamsTaskModule submit is called when a bot is called when the bot receives the message with the type set to task slash submit. And this is going to serve as the handler to tell the bot that the user submitted the task module. So for instance, from my previous example I used, submitting the ID of a YouTube video. So how are these used? Well, let's look at an example of the submit action. Here you can see that the handler within the bots, the bots web service implementation that's handling the submission from another task module. Think back to our example at the start of the lesson. This is when a bot, this would be like when a bot is receiving the submission from the task module form, prompting the user for an ID from a YouTube video to display. Here you can see it's creating and returning a task module response object that is going to contain a task object. And this task object is the same task info object that we've looked previously at. Now, when this method executes, it's going to send the message from the API back to the Azure Bot framework and ultimately to the Microsoft Teams client that says invoke this task module in the client for this user's interaction with the bot. Now, the last thing that you need to be familiar with for the MS600 exam, when it comes to task modules in Microsoft Teams is a concept of chaining task module invocations. Now, this is the process of combining two or more task modules together and surfacing them within a chain. Our YouTube example that I've referenced a few times is a really good, is a good example of this. The first task module collected the ID of the YouTube video to either save it or to display it for you somewhere. The second task module display the YouTube embedded player loading the video specified from the first task module. Now, there's nothing special in Microsoft Teams or in their APIs that you need to be familiar with to create these chain task module invocations. Rather, this is more of an implementation pattern that you should be familiar with. And this pattern is demonstrated in the hands-on labs in the Microsoft Learning module that's associated with this lesson that's found in the lesson notes. Now, you should be familiar with some of the common scenarios when this approach should be used or could be used. It's something that Microsoft pushes pretty hard when it comes to bots, because it provides a more guided data collection or task-oriented approach when multiple steps are invoked rather than relying on the more free-form text-based option of bots. The two most common scenarios are collecting data from users, and then the other option that we see a lot is like a wizard-based experience that invokes tasks or prompting the user for input. Okay, that wraps up the lesson on task modules for Microsoft Teams. And in the next lesson, we're gonna look at creating personal and channel tabs for custom Microsoft Teams apps. Now tabs are a cornerstone of custom Microsoft Teams apps, and while not every app is gonna have to have them, they might be the most popular type of customization that you'll see, and they get quite a bit of attention in the pool of questions that you're gonna encounter on the exam. So make sure you're familiar with the concepts that I'm covering in this lesson. So what exactly are tabs? They're actually pretty simple. They're just tabs within the main area of the Microsoft Teams interface. Now under the covers, tabs are just web pages that are served up in an iframe control within Microsoft Teams. So as a developer, you're gonna create these web pages and then define the tabs in the Microsoft Teams app manifest file, which is just gonna point to the URL of these different pages. So let's look at some of the things that we'll cover in this lesson. There are actually a few different kinds of pages that you can create or URLs that may make up a tab. Now, not all of them are required and some of them are only available in specific contexts. You've got the contact page. You've also got a configuration page that you may use to configure the settings on the tab itself, and then you may also have a removal page. We'll look at all of these as we get to that part of the lesson, as I'm gonna talk about each one of these different things. Now, in addition to the different types of pages that are used within a tab, Microsoft Teams supports two different kinds or types of tabs. These are personal tabs that are used by an individual and channel tabs, which are used by multiple people within a channel. These tabs can also be used in a group chat as well. The next thing that we're gonna discuss is authentication. Now, this is a very complicated and tricky subject, but I'm gonna cover everything that you need to be aware of and that you should study up for on the MS-600 exam. And then finally, I'm gonna cover something called deep links and how you can use them to quickly create a quick way to jump users into your tabs from within and outside of the Microsoft Teams client. So let's get started with our first look at the different components that you're gonna use inside of tabs. We're gonna start with the different types of pages that you can use in Microsoft Teams tabs. You need to be familiar with all three different types of pages for the MS-600 exam. And as I mentioned previously, tabs are just web pages that you host that are loaded in a Microsoft Teams within an iframe. The content page is the most important one as it is the primary page that's displayed within a tab. This is what your users will see when they select a tab. The configuration page is used when a tab is added to a channel. If the tab contains settings or if the tabs manifest property specify a configuration URL property, this is gonna be shown when the tab is added to the channel. And furthermore, if a tab supports it, the configuration page is also gonna be shown when the user selects the settings menu on the tab once it's already been added to the channel. And then finally, the last page is the removal page. And this option, this is optional and it's displayed when the tab is deleted or when it's removed from Microsoft Teams. Now let's look at two different types of pages. You should be familiar with the two different types of tabs in Microsoft Teams in preparation for the MS-600 exam as well as the differences between the two. The type of tab is actually referring to the scope of a tab and the scope is set in the app manifest and it can be one of these three different values. It can be either a personal, a group or a team. The two types of tabs are personal tabs and channel tabs. Now let's start by looking at personal tabs. By using personal tabs, users can interact with your experience privately. The content of a personal tab is only relevant to one individual, the individual that's looking at the tab at that time. And these are a set of tabs that can be pinned by default without the user adding them manually. Personal tabs declared in the personal scope are always pinned to the app's personal experience. Now this type of tab was previously known as a static tab and this is important to note as you're gonna see the word static used in various places throughout the APIs and in the configuration files. Now a personal tab is defined within the static tabs collection within the Microsoft Teams app manifest as you can see from the snippet on the slide. You can define multiple personal tabs within a custom Microsoft Teams app as well. And each tab has got a series of properties that you must define as follows. The entity ID property is a unique identifier for the entity that displays that the tab is gonna display and this property is required. Think of it as unique ID. The name property is the display name of the tab in the channel interface. This property is also required and the content URL property is the HTTPS URL that points to the entity URL to be displayed in the Microsoft Teams canvas. This property is also required. The website URL property is the HTTPS URL used if the user opts to view this tab within a browser. So this is not required. So in the case of like if they wanna jump out of Teams and go to the browser, this is an option that's usually shown in the upper corner of the tab experienced to view in a web browser. The scopes property, this is an array of scopes that are supported by the tab and this is required and supports only the personal scope. And in addition, there's a valid domains property. That's gotta contain a list of all the domains that your tab might access. For example, it should contain the URL where the pages for your tabs are hosted as well as any other domains access from the page. Microsoft Teams will block access to any domains that are not listed in the valid domains array. Now the HTML pages that you host and use as the implementation for your tabs can contain some context details from Microsoft Teams when the page is actually gonna load. And Microsoft Teams replaces these placeholders with relevant values when it determines the actual configuration or content URL that you need to go to or the user's gonna be redirected to. The available placeholders include all the fields in Microsoft Teams context object that are available within the SDK. Some of the values available as URL placeholders are set when the tab is configured. For instance, like the entity ID and the sub entity ID. So how would you use these things? Well, consider the theme property. You can use this to determine if the user's team's client is in the light or the dark mode and change your CSS in your tab in your HTML page to match it. So that way the tab experience feels like it's part of the user's team's client. The properties listed here are many of the manifest same properties I went over in just a moment ago. Some additional ones include the theme that I just mentioned as well as the user's Microsoft 365 tenant ID, their ID or UPN and the custom locale setting which is useful for tabs that support multilingual experiences. Now another way to retrieve this same contextual information is using the JavaScript SDK from Microsoft Teams. And this option can be used from within your HTML page that is implementing the tab itself. To get the context, you ensure that the JavaScript library has been loaded on the page and then you call microsoftteams.getContext. And that's gonna return a context object with many of the same properties that I've already covered as you can see from the code snippet that I have here on the slide. Okay, so that's personal tabs. Now let's look at channel tabs. A channel tab has one characteristic that differs from a personal tab. A channel tab is gonna display a configuration experience to the user when the tab is added to the channel as you can see here. You can use the configuration page defined in the manifest to collect any configuration information that the web app might need to customize the information shown in the tab itself. Now this type of tab was previously known as a configurable tab. And this is important to note as you'll see the word configurable used in various places throughout the APIs and in configuration files. A channel tab is defined within the configurable tabs collection of the Microsoft Teams app manifest as you can see from the code snippet here. You can define multiple channel tabs within a custom Microsoft Teams app as well. Each tab has a series of properties to define such as the following properties. The configuration URL property is the HTTPS URL to use when you configure the tab. This is required. The can update configuration property is the value that indicates whether an instance of the tabs configuration can be updated or changed by the user after creation. So this is by default, this is set to true. The scopes property is an array of the scopes the tab can support. And channel tabs can be either a team or group chat for scopes. This property is also required. The SharePoint preview image and the supported SharePoint host property are optional. They are used to make the tab available as a web part or as a full page app within a SharePoint site. Now aside from these differences, everything else that I just covered with personal tabs applies to channel tabs. So make sure that you're familiar with these two types of tabs in preparation for the MS600 exam. Now I only want to say a brief thing about the authentication aspect in this lesson, which might surprise you because it's a big topic, but it's not really part of Teams. Prior to the August 2022 update of the MS600 exam, the tab authentication was part of the Teams workload, but it has since been moved to the Microsoft Identity workload. So refer to that lesson in that chapter about Microsoft Identity, where I'm gonna go into more depth about authentication options for tabs. Now modern devices such as desktops, laptops, and tablets and phones all have built-in capabilities that you can leverage in Microsoft Teams. And this includes things like cameras, microphones, galleries, QR codes, barcode scanners, as well as location. Using the Microsoft Teams JavaScript client SDK, your app can be granted access to these different capabilities. And for the exam, you should be familiar how to get access to these devices by configuring your app's manifest file. And I know how to integrate some of these capabilities in your application. Now originally developers could create tabs using web pages that Microsoft Teams loaded within an iframe. And while that's still true, Microsoft has added the ability to create tabs using adaptive cars. And it's covered on the exam. When you choose to build a tab using an adaptive card, you're somewhat blurring the lines because while the front end of the implementation is rendered with an adaptive card, the backend is really powered by a bot. A bot is responsible for accepting requests and responding with adaptive cards that's being rendered. Now finally, you also need to be familiar with something called deep linking to a tab. So what are these? These are just hyperlinks that take you directly to something within Microsoft Teams. And you're gonna need to be familiar with deep links in Microsoft Teams in preparation for the MS600 exam. Think of them as sort of an anchor link to part of a website or a web page. The domain is gonna take you to the site. The path portion of the URL takes you to the page. And the last part after the hash or number, the number sign jumps to a part on that page. In Microsoft Teams, we call these things deep links. And what they're gonna do is they're gonna enable users to jump from one tab to another tab or from a message within a one-on-one chat to a team chat and a team chat to another message or to a tab or an item within a tab. They're also gonna allow you, they're also powerful because they're just regular hyperlinks. So you can use these to also jump directly to content within Microsoft Teams but do so from outside of Microsoft Teams. So like for example, deep links can be used in a notification email, corporate intranets or even inside of text messages. You can create also a deep link that will take a user directly to your tab. And this is done by creating the URL with specific parameters inside of it. So let's look at some of these parameters here. The app ID, that's the ID of the custom Microsoft Teams app that's defined in the app's manifest file while the entity ID is the ID for the tab which was defined when the tab was created or configured. The entity web URL is the optional fallback URL if the user's Microsoft Teams client doesn't support rendering the tab. The label or the entity label is for the item in the tab that you want to use when displaying the deep link. And the context is a JSON object that contains a sub entity ID of the item within the tab that you want to display in the channel ID that the tab is in. So this is really only applicable if you're inside of a channel tab. It doesn't apply to personal tabs. To create a deep link to an item within a tab use the share deep link method from Microsoft Teams, the JavaScript SDK. This method takes three arguments. The tabs unique ID, the label of the item and optionally a fallback URL if the user's Microsoft Teams client doesn't support rendering the tab. Okay, so that wraps up the lesson on tabs and in the next lesson we're gonna look at webhooks both incoming webhooks and outgoing webhooks and what you need to know about them to be prepared for the MS600 exam. In this lesson we're gonna look at how Microsoft Teams supports developers using webhooks to both send and receive notifications to and from Microsoft Teams. But before we dive into this topic I wanna call one thing out and the documentation you're gonna see in this section on webhooks there's also something that they mentioned called connectors or Office 365 connectors. For your MS600 exam preparation you can ignore connectors. This topic is not gonna be tested on. Okay, so with that being said let's get started. So what are webhooks? Now put it quite simply they're just URL endpoints that accept an HTTP post request that's been submitted by another service. They're commonly used by one system to notify another system of an event. So in Microsoft Teams, webhooks are gonna provide a simple way to connect your web services to channels and teams inside of Microsoft Teams. Now this extensibility option enables you to either respond to a channel message sent to your web service from Microsoft Teams or to send a proactive message to a channel. Now Microsoft Teams supports two different types of webhooks. They support outgoing webhooks where Microsoft Teams is gonna notify your app of an event that it could respond to and it also supports incoming webhooks where your app is gonna notify Microsoft Teams of something like proactively. Now let's look at each of these different things in a little more detail. An outgoing webhook is gonna allow your users to send messages from a channel to your web service. And once it's configured, your users can at mention your outgoing webhook to have Microsoft Teams send the message to your service and your service has then has five seconds to respond to the message and optionally include a text-based message or a card. Now outgoing webhooks are manually configured on a per team basis. They're not included in custom Microsoft Teams apps. Some of the key features of outgoing webhooks include some of the following things. Now webhooks are scoped at the team levels I just mentioned. So you're gonna need to go through the setup process for each team that you wanna add your outgoing webhook to. Users must also use the at mention for the webhook to receive messages. So to be able to tell the webhook or to tell the outgoing webhook of the notification, you have to at mention them and that's what's gonna trigger teams to send the notification to your web service. Responses are also gonna appear in the same chain as the original request from the message and can include any bot framework message content like rich text, images, cards, even emojis. Now the Microsoft, the outgoing webhooks send an HP post to a web service and process the web services response. They can't access any other APIs like retrieving the roster or a list of channels inside of Microsoft Teams. And keep in mind that outgoing webhooks are scoped to the entire team. So they're visible to all the members on that team. So like a bot, users are required to at mention the name of the outgoing webhook in order to invoke it inside of a channel. So now let's look at what's involved with registering an outgoing webhook, how to process it and then how to respond to a submission from Microsoft Teams. So from a team, you're gonna add an app by selecting the create outgoing webhook link on the channel's installed apps page. Microsoft Teams is gonna display a security token after you register the outgoing webhook that your web service will use to validate the messages it receives that are sent from Microsoft Teams. Now messages that are sent from Microsoft Teams to outgoing webhooks include a hash-based message authentication code. It's called an HMAC or an HMAC in the HTTP request authorization header. This is generated by hashing the message with a secret key. Your web service should use the HMAC from the received request to authenticate and verify that the message was sent from Microsoft Teams. Your web service should use the body of the message to generate the HMAC token using the provided security key that's unique to your outgoing webhook registration. Compare your generated HMAC token with the one that's included with the request header authorization header value. If they match, you're validated that the message has been sent from Microsoft Teams so you're not getting spoofed or fished. The last step in your web service is to respond to the Microsoft Teams request message with a success or a failure and this must happen within five seconds. Outgoing webhook messages sent from Microsoft Teams are sent synchronously and your web service must respond within five seconds. The response from your web service will be added to the same reply chain as the original message. The reply text can be a text string or a rich message that includes an image or a card as you can see from this image here on the slide that's returning back a card. Now an incoming webhook, this is the simplest of the two but it requires a lot more work to configure. You manually configure an incoming webhook on a per channel basis and like outgoing webhooks, they can't be included in a custom Microsoft Teams app. After creating an incoming webhook, Microsoft Teams is gonna display a webhook end point that your web service can submit the age to be post to. Some of the key features of incoming webhooks include some of the following things. So one of the first ones is that incoming webhooks are scoped and can be configured at a channel level unlike outgoing webhooks that are scoped and configured at a team level. Messages are also formatted as JSON payloads. This declarative messaging structure prevents the injection of malicious code as there's no code that's being executed on the client itself. And if you choose to send messages via cards, you must use the actual message card format. Actual message cards are supported in all the Office 365 groups, including Microsoft Teams. Now cards are a great way to present information in a clear and consistent way. Any tool or framework that can send a post, HP post requests can send a message to Microsoft Teams via an incoming webhook. Now all text fields and actionable message cards support basic markdown. Don't use HTML markup in your cards. HTML is ignored and is treated as just plain text. Now let's look at what's involved with registering an incoming webhook and sending a notification to Microsoft Teams. So the first step is to create a web service or an application that can send an HP post request that include a JSON payload to an HPS endpoint. Your incoming webhook is gonna submit its HP post request to a unique endpoint that Microsoft Teams is gonna give you. Now the endpoint is generated when you register the incoming webhook inside of a channel. So the next few configuration screens are gonna prompt you which channel you want to register the webhook to. Ultimately, Microsoft Teams is gonna register the incoming webhook and display a unique endpoint for your web service that you will submit the HP post message to. The last step is to simply submit an HP post message to the endpoint that Microsoft Teams provided in the registration step. This image shows submitting the request using the popular tool called Postman. It submits a card to the incoming endpoint. And when Microsoft Teams receives this request, it'll add the message to the specified channel that was defined when you registered the webhook. Okay, so that wraps up the lesson on Microsoft Teams webhooks. And in the next lesson, we're gonna dive into the conversation bots for Microsoft Teams. Now bots are an important part of many custom Microsoft Teams apps and something that you should be very familiar with in preparation for the MS-600 exam. Bots are also the backbone of messaging extensions, another extensibility option that I'm gonna cover in another lesson in this chapter. Now, before we get started, I wanna say one thing about this topic. In creating this course, I define the scope to focus not on teaching you the technologies that you need to know, rather I wanted to focus on explaining what you need to know and providing resources to learn those topics if you weren't familiar with them. In many parts of this course, I've gone a bit further than just saying you need to know about this widget and instead of actually going through and explained it in a bit more depth. So you benefit from this and it's kind of beyond the scope of what I wanted to do. But bots are a topic that I can't go into on that because I can easily create a whole course dedicated to bots, but that's not why you enrolled in this course. So in this lesson, I'm gonna stick to the guide rails that I defined in the scope for this course and I'm just gonna cover the elements that you need to know, but like all lessons in this course, in this lesson especially, please refer to the links in the lesson notes under this video for additional learning if you aren't familiar with them. These have also got Microsoft learning modules as well on working and creating bots. Okay, with that out of the way, let's go ahead and get started. I'm gonna start with a brief overview of bots and how they can be used inside of Microsoft Teams. Now bots and Microsoft Teams can be part of a one-on-one conversation in a group chat or in a channel and a team. Each scope is gonna provide unique opportunities and challenges for your conversational bot. So where can they be used? Bots can be used in channels that contain threaded conversations between multiple individuals. Your bot only has access to messages where it is at mentioned directly in this scenario. You can retrieve additional messages from the conversation using the Microsoft Graph APIs. Now some examples of uses for a bot in this scenario are notifications and collecting feedback like surveys or polls. These type of interactions can be resolved in a simple request response cycle where the results are useful for multiple members inside of a conversation. Group chats are non-threaded conversations between three or more people and scenarios that work well in a channel will usually work as well in a group chat. In a one-on-one chat, bots interact with an individual user. And some examples of uses include questions and answer bots, bots that start a process in other systems or they're gonna collect input from users. Now bots created from Microsoft Teams can be used to interact with calls and meetings using real-time voice, video, and screen sharing. And this is implemented using the Microsoft Graph APIs for calls and online meetings. Now with a calling bot, developers can create voice responses, call control, and access real-time audio and video streams, including those that are coming from a desktop and app sharing. Similar to conversational bots, calling bots can interact with multiple party calls where the bot is just another participant in the call or they can interact with a user. And for the MS600 exam, you need to know how to handle and transfer incoming calls with your calling bot. Finally, you can also create online media bots for Microsoft Teams. And these are closely aligned with the calling bots that I just covered. This type of a bot has different requirements from the calling and conversational bots that you should be aware of. Now, when it's participating in a call or an online meeting, the bot must deal with audio and video streams and bots can respond with something as simple as, quote, push zero to reach an operator in the interactive voice response scenario or it can process media streams in real-time. Now dealing with media streams, specifically real-time media streams, that's a really complex topic. For example, you should be aware that these bots must use the .NET library, Microsoft.graph.communications.calls.media and that they must be deployed to a Windows server on premises or in Microsoft Azure. You should also be sure to spend some time focusing on this topic when preparing for the exam and have provided a few resources for you to be able to explore this with this lesson. So how the conversational bots work? These things are gonna consist of three different things. You're gonna first have a publicly accessible web service that you as the developer and the provider are responsible for deploying and hosting. The second thing you're gonna have is a bot registration that registers the bot or the web service with the Microsoft Bot framework. And then finally, you're gonna have a Microsoft Teams app package that contains your app manifest and this is what users will install and connect to the Microsoft Teams client to your web service, which is routed through the bot service. So what's involved with creating a conversational bot for Microsoft Teams? Bots for Microsoft Teams are built on the Microsoft Bot framework and while you can use SDKs provided by the bot framework, Microsoft Teams is gonna provide SDKs for building bots with .NET or Node and these SDKs make creating bots for Microsoft Teams a little bit easier in that they have methods and classes for using adaptive cards, sending Microsoft Teams channel-specific data on activities and processing messaging extension requests. They essentially these SDKs, what they're doing is they've gone ahead and they have overloaded methods that you can implement that are looking for specific types of messages coming from Microsoft Teams. So you can just implement the methods and just know that they've been hooked into these different specific methods coming in for things like messaging extensions. So when creating a bot for Microsoft Teams, there are four things that you're gonna need to do. You need to create the web service. This is usually using one of the Microsoft Teams bot SDKs that are provided for us and you then are gonna need to register your bot with the bot framework, Microsoft Bot framework. That's gonna give your bot a unique ID and it's gonna associate it with your web service. Next, you're gonna add your bot to custom a custom Microsoft Teams app manifest and create the app package. And then finally, it's kind of obvious, but you're then just like all the other Microsoft Teams apps, you're gonna upload the app package to Microsoft Teams where the bot can then be installed, which configures it to work with your channel. So let's dig into some of these different steps. First, let's talk about creating the bot's web service. This defines a single HTTPS endpoint that's gonna receive and respond to all the requests that it receives. Requests are sent from Microsoft Teams through the Microsoft Bot framework to your web service. Responses are gonna go in the reverse direction. All the requests are sent as an activity object and each activity has a type that's gonna define what it is. For example, some different types of activities are gonna include things like a message. A message type is just a simple string from a conversation. The task fetch and the task submit types, these are used when working with task modules and we covered those in that lesson on working with task modules. The compose extension fetch task, compose extension submit action and compose extension query types, these are all used in messaging extensions. And we're gonna learn about that when we cover that lesson. The next step is to register the bot with the Microsoft Bot framework. This is gonna create a secure channel between the Microsoft Teams client and your web service. And as I mentioned earlier, this provides your bot with a unique ID and associates it with your web service. And this ID is actually the ID of an Azure AD application and this can be a new or an existing Azure AD app that you create. But what this does is it's gonna provide your bot with the client ID and a secret that both Microsoft Teams and your web service are gonna use to authenticate with the bot framework. We're just creating that secure communication channel. Now that you've seen how to create a bot, let's talk about some of the aspects that you should be familiar with for Microsoft Teams. First, there are events specific to Microsoft Teams that your bot can be notified about. For instance, when someone is added or removed to or from one of the channels in your events in your team, or when a channel is created, renamed or deleted, and if a team has been renamed, you can also be notified of that. And furthermore, your bot can also receive notifications when a user reacts to a message that a bot posted to a channel or a chat. In this case here, you can see that when a user has reacted to one of my messages, I can check to see what's the reaction I liked or I can even respond back with, thank you, a thank you message. You should also be familiar with how to update and delete existing messages that were previously sent to Microsoft Teams by your bot. If you need an example, check the Microsoft Learning module associated with this topic as it contains a hands-on lab exercise for you to practice this. I want to only say a brief thing about authentication in this lesson, which might surprise you because it's a big topic but not part of Teams. Prior to the August 2022 update, tab authentication was part of the Teams workload but it's since been moved to the Microsoft Identity workload. So you refer to the lesson in the chapter about Microsoft Identity where I'm going to go into more depth about authentication options for bots. Okay, that wraps up our conversation on conversational bots. Now the next lesson, we're going to look at messaging extensions which also implement bots and their implementation. Now I'm going to start by explaining what these things are. What are our messaging extensions and how would they use them? Messing extensions allow your users to interact with your web service through buttons and forms within the Microsoft Teams client. They can search or start external actions in an external system from the compose message box area, the command box, or directly from a message. So the command box is the thing at the top, the compose message area is at the box at the bottom where you can actually draft a new message or directly inside of a message using the context menu that pops up. You can then send the results of that interaction back to the Microsoft Teams client, typically in the form of a richly formatted card. And in this picture, you can see where the messaging extension can be invoked from the Microsoft Teams client. So like I said earlier, you can trigger it from the command box at the top of the Microsoft Teams client from within the message itself from the more actions menu on the context menu of an item or from the buttons below the compose message box at the bottom of the client. That's applicable to channels, group chats, and one-on-one chats. Now messaging extensions are implemented as a web service and they're also registered as a bot using the Microsoft Bot framework. And when a messaging extension is invoked, Microsoft Teams is gonna call the web service via the bot framework's messaging schema and the secure communication protocol. Many of the topics that we covered in the lesson on bots applies to the messaging extension. So I'm just gonna focus on the topics that are unique to messaging extensions in this lesson. There are two types of messaging extensions that you can create. These are the action commands and these are search commands. So let's look at each one of these in a little bit more depth. I'm gonna start with an action command. Action commands allow you to present your users with a modal pop-up dialogue to collect or to display information. And when a user submits the form, your web service can respond by inserting a message directly into a conversation or insert a message into the compose message area by allowing the user to submit the message. Action commands can be triggered from all three of the different experiences within the Microsoft Teams client and this includes the command box, compose message area, or from within a message. When it's invoked from a message, the initial JSON payload that's sent to your web service will include the entire message that it was invoked from. When your service responds to the request from Microsoft Teams, the modal dialogue presented is implemented as a task module. And this task module can be implemented using either as a embedded web view, which is just like an HTML page like tabs and task modules. This enables developers to have complete control over the user interface and controls in the task module. You can also implement it as an adaptive card, which can simplify the UI work for developers as it hands off the rendering to Microsoft Teams, but that also means that developer loses control over the formatting options and available controls. And the final option is to use something called static parameters. Messaging extensions have parameters defined in the app manifest where they've been defined. Your service can specify these values, but you lose all the control over the user experience and the formatting. So let's look at some implementation details for action commands and some things that you should consider. First, you're gonna need to know how to register your action command within your app manifest file. This is done by adding an entry to the compose extensions collection in the manifest file. There are a few properties that I wanna call out in this code snippet that you're looking at here. The type property is gonna define the type of the extension. So in this case, it's an action command. The context property defines where this extension can be invoked. So in this example, it's the compose message box as well as in a specific message. And the third option here would have been the command bar. The parameters array is the list of all the static parameters that you can define for the extension that I've already covered as one of the UX implementation examples. If you elect to use parameters, you should set the fetch task property to false. Otherwise, if you're using the embedded web view or adaptive card for the dialogue, you should set fetch task to true. Now, how are you gonna set the message? Well, you then need to decide how you're gonna set the message within Microsoft Teams client. Your options are to either respond to an existing message in a conversation or insert the message into the compose message box. If a message extension responds to a message, you're gonna need to register a bot so that it has access to the conversation. Responding to the implication of a messaging extension is gonna happen in the web service. And there are two different scenarios that you're gonna need to address. Microsoft Teams can invoke your messaging extension as a request for the task module when your web service is gonna respond with the task module that it needs to render. The other option is your messaging extension could receive a submission from a task module as well. And so for both of these scenarios, the bot framework is gonna send an activity object to your web service of a specific type, depending on the two scenarios, either a fetch task or submit action. Your web service is gonna need to respond with a task object in either case. To handle the request for a task module, use the bot frameworks Node.js SDK to implement the handle teams messaging extension fetch task handler that's gonna return back an object. You'll notice this code looks very similar to how a bot responds to a request for a task module. And when a user submits the messaging extensions task module, your web service has a few different ways of how it can respond to it. From not responding at all or responding with a task module or responding with an adaptive card. This code demonstrates responding with a card that's added to a message as a reply. And notice this one implements the submit action method from the bot frameworks SDK. You also need to be familiar with how to respond to an action command extensions using parameters instead of the embedded web view or adaptive cards as it relates to questions that may show up on the MS600 exam. Now let's look at search commands on the other type of messaging extension. Search commands allow your users to search an external system for information either manually through a search box or by pasting a link to a monitored domain into the compose message area. And then insert the results of the search into a message. In the most basic search command flow, the initial invoke message is gonna include a search string that users submitted. You'll respond with a list of cards and card previews that the Microsoft Teams client will render the previews in a list for the end user to select from, as you can see here. Once the user selects a card, the full size card will be inserted into the compose message area. Now unlike action commands, search commands can't be triggered from a message. They can only be invoked from the command bar at the top of the Microsoft Teams client or from the compose message area. Now let's look at some implementation details for search commands and some things that you should consider as well. First, like action commands, you need to register your search command within your app's manifest file. And like action commands, there are a few properties to pay attention to. The type property should be set to query to define that it's a search command and the context property should include the locations where the extension can be used. Again, the options are compose and command. The last property called initial run, when this is set to true, it's gonna invoke the web service as soon as the command is invoked. Otherwise, when this property is omitted or it's set to false, it's only gonna invoke the web service when the search is executed. To handle the request for the messaging extension, use the bot frameworks Node.js SDK to implement the handle teams messaging extension query method that's gonna return back a messaging extension response object, just like the action command that we saw earlier. Now we have a couple of different kinds of response types. This type of an activity is that sent to your web service can have multiple uses that are all defined in the type property in the responses compose extension return object. The result type is gonna display a list of search results from your query that the user can select from. The message type will simply display a plain text message. The auth type is gonna prompt the user to authenticate and the config type is gonna prompt the user to set up the messaging extension. Now while I've provided an overview of action and search commands, you should make sure that you're familiar with them and your MS-600 exam preparation. My goal in this lesson was to simply make sure that you were familiar with how they work. You need to make sure that you have a solid grasp on them for your preparation. And for practice, I would refer you to the lesson notes that include a reference to the Microsoft learning module on messaging extensions. It includes a hands-on lab exercise and creating an action command messaging extension as well as a search command messaging extension as well. If you need some hands-on practice with this capability. Okay, so that wraps up my lesson on messaging extensions. In this lesson, we're going to explore the meeting extensions also referred to as meeting apps in Microsoft Teams. So let's get started. Meetings enable collaboration, partnership and informed communication and shared feedback. And the meeting app can develop a user experience for each stage in the meeting lifecycle. Developers creating custom Microsoft Teams meeting apps can implement different experiences for meeting participants. Depending on the participant's role in the meeting and the lifecycle of the meeting. Microsoft Teams meeting extensions enable developers to create a customized and interactive experience with their end users. And this type of custom app in Microsoft Teams is actually going to heavily leverage and lean on many of the other extensibility options that we've already learned about in this chapter. What do I mean by that? Well, meeting apps utilize tabs in the various meeting lifecycle stages. And Microsoft Teams can notify your app of events that occur during the meeting using bots. And you can prompt users for information in your meeting apps using messaging extensions. And furthermore, your app can even access the audio and video streams during the meeting using the support they have for calling an online media bots. What you need to know for the MS-600 exam is how these capabilities are uniquely integrated into your custom Microsoft Teams meeting app meeting extension. Now the meeting lifecycle that includes a pre-meeting an in-meeting and a post-meeting app experience depending on the attendee status, depending on when the meeting is. Is it, are we currently viewing the app before the meeting, during the meeting or after the meeting? With the pre-meeting experience, you can find and add meeting apps. And you can also do pre-meeting tasks such as developing a poll to survey the meeting participants. Add meeting apps to your meetings using the same process, you can add tabs to channels. You're gonna use the plus icon from the meeting details tab to open the gallery. And then once in the gallery, you can select the meeting app that you wanna add. The same interface is used to implement the post-meeting experience. As the only difference between the two is the context of the meeting start date and time. With the in-meeting app experience, you can engage participants during the meeting by using apps and the in-meeting dialogue box. Meeting apps are hosted on the toolbar of the meeting window as an in-meeting tab. And you can use the in-meeting dialogue box to showcase actionable content for meeting participants. In addition to dialogues, meeting apps can also be surfaced within the side panel of an active meeting. This is a great way for developers to implement a user-specific interface for the meeting app as each meeting attendee can see individual content during the meeting in the side panel. Developers can also create unique experiences in their meeting app that can be used as the presentation during the meeting. This experience is launched from the universal share icon that appears in the toolbar of the meeting extension sidebar. Developers can conditionally show different content and custom meeting apps based on the current context of where the tab is loaded. Meeting apps can be rendered in the following locations. The content area is the main area of a meeting where the details and files tabs are found on a meeting. This is commonly used for the pre and the post meeting experiences. The side panel is available when the current user has joined an in-process meeting and enables developers to implement an experience that is targeted to the currently signed in user. The side panel occupies the same location where the meeting chat and participant list are displayed. The meeting stage is the main presentation area of the meeting. And this is where the presentation and screen sharing are displayed during a meeting. Using the stage, the meeting app developer can create an experience that is presented to all attendees of the meeting. The current meeting context is available to developers using the Microsoft Teams context object. And that's passed into all custom apps. This context object contains a property frame context that is set to one of the three values for meeting apps. And developers can conditionally show different content and custom meeting apps based on the role of the current user. Your app could show one experience and provide some capabilities to meeting organizers while all other meeting attendees receive a very different experience. You should be familiar with the different roles and APIs available to determine the role of the current user in the meeting. To enable your app to be available within Microsoft Teams meetings, you need to make a few changes to your app's manifest JSON file. And these settings are all defined in the manifest JSON's configurable tabs array. The tabs content array property is gonna determine what must be shown when a user invokes an app in a meeting depending on where the user invokes the app. This property along with the scopes property enable you to determine where the app must appear. The following content options are gonna apply to your meeting apps. Your meeting app can support one or more of the following context. The meeting chat tab is a tab in the header of a group chat between a set of users for a specified meeting. And then the meeting details tab is the tab in the header of the meeting details view in the calendar. Now you have to have one of those two things or both of them specified in order for your app to work in a mobile experience. The meeting side panel is an in meeting side panel that's opened through the unified bar and it's the same location where you're gonna access the meeting chat and meeting participants list. Now an app from the meeting side panel can be shared to the meeting stage and you can't use this app in either mobile or teams rooms clients. That's the property of meeting stage. Now the tabs meeting services arrays is a set of scopes where the app is gonna be shown. So the following meeting surfaces options can apply to meeting apps and can support one or both surfaces. The side panel, that's the panel that's opened through the unified bar that's gonna be in the same location where you access the meeting chat and the participant list. And the stage is can be shared from the side panel and you can't but you can't use that one in a mobile experience or like a teams room client. Now you should also be familiar with how to obtain details about the current meeting using Microsoft Graph. The Microsoft Teams context object contains a meeting ID property of the current meeting and this ID contains the ID of the chat for that meeting surrounded by a zero and a hash symbol. Developers can take that meeting ID, remove the prefix and the suffix and use it to get more details from Microsoft Graph by querying for the chat by that ID. The response that you get back is gonna contain some information about the current meeting including a property called the join web URL of the meeting. You can then use this property to query the Microsoft Graph for all the details about the meeting. The response from the online meetings endpoint contains all the information about the meeting including the meeting participants, their roles and other details related to the meeting. Okay, so that wraps up everything that you need to know to be prepared for the extend Microsoft Teams workload portion of the MS-600 exam. If you have any questions about what I've covered here, please drop a comment below or let me know if you wanna see more videos about Microsoft Teams app 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.