 Hello, I'm Jason Johnston, a senior content developer with the Outlook Ecosystems team. In this video, I'm going to show you how to connect your Node.js app to Office 365 and do a basic calendar sync. So to start with, I've got this basic Node.js app that we developed in the first video in this session to do the authentication piece. We're going to build on that work and add calendar sync. So let's go ahead and get started. In order to do all of our API calls back to the Outlook calendar API, we'll use the Node Outlook library, which is a lightweight wrapper around the REST APIs. So the first thing that we want to do there is install that library using NPM. And once that's installed, we need to require it in app.js. Okay, so if we go back to the app that we implemented earlier, we were left with this sync button that we haven't implemented yet. It's pointing to a slash sync route in our app, so let's start by implementing that. Okay, so there's a lot here, so let's go through it bit by bit. So we use the Outlook base namespace for this functionality, and the reason that we do that is that Node Outlook is, as I said earlier, very lightweight. It implements a few basic functions, but it also implements the ability to use any API call even if we haven't implemented a wrapper around it. That's what the base namespace is really for. So the first thing that I do here is use the set API endpoint function to point all of our API calls at the version 2.0 Outlook endpoint. We're going to make some use of some of the new features in version 2.0 during this, so we'll use that endpoint. The next thing that I do is set the anchor mailbox to the user's email. This is why we went through the trouble of extracting the user's email from the ID token in the first session. And then I set a preferred time zone. This is a new feature in the version 2.0 endpoint. The ability to specify a preferred time zone and have all calendar times returned in that time zone so that you don't have to do all the calculations yourself. Okay, so to start with, we're going to manually configure our API request since we don't have a wrapper around it. The first thing that we do is set up the request URL. When you're doing calendar sync, that all works off of the calendar view endpoint in the API, which is a view on a window of time. We're going to do this for a week starting from today and seven days out. So we set this to the me calendar view. Next we're going to set up that time window, as I said. The start date will be today at midnight and the end date will be seven days from that time. Then we're going to set some prefer headers, which will enable the sync functionality that we're after. There's a couple of prefer header entries that we need to add. One, we need to set odata.track changes. That tells Office 365 that we want to be able to synchronize data as changes come in. The next thing that we set is our max page size. Here we're saying five, which will limit the return results for each call to five results. Now we package up all of those things that we built before into this API options object, which gets passed to the make API call function. Now that we have that there, let's go ahead and run the app and see what happens. As you can see, we have basically a raw dump of the JSON response for our synchronization request. We get back an event entity for each item on the calendar up to the maximum of five that we specified. So great. We see that that works. But what happens if we have more than five items or changes come in after we do that initial sync? How do we continue to get changes? Well, if we take a look in the response, here at the end we have this item called odata.delta link. This is how we continue on with our sync. So the way that calendar sync works is that the request that we just made is considered the initial sync request. From that, we always get a delta link included in the response. So the next thing that we should do is issue a second call to that delta link. If there's more changes, we'll receive them. If there are no more, we'll receive an empty response. The response will include a delta link if there are no more changes. And at that point, we can save that delta link and periodically make calls to it to get any changes that come in. If there are more changes, more than the maximum that we have set in the prefer header, we'll get a next link instead. So after the initial sync, we can look if there is a next link, there are more changes. If it's a delta link, there are no more changes and we can wait however long we want to wait until we do the next sync. So with that in mind, let's modify our code a little bit to save the delta link and use that on the next call to sync. So here I'm checking our session to see if we've saved a sync URL. And we'll use that instead of the basic me calendar view. If it's not there, then we'll just use the base URL. But in order for it to be in the session, we need to save it. So let's come back down here to where we process our response and save our delta. Now we're taking a simplistic approach here for this demo. If there's a next link, we save that as our next sync URL. Otherwise, if there's a delta link, we save that. We'll use whichever one we get back. So now that we have that, let's rerun the app and see what happens. Okay, so we'll do our first initial sync and we get back five items. Now if we click sync again, we get one more item that used the delta link to get further information. Now if we click sync again with our new delta link, we get back no changes. So we've received all the changes that are there. Let's take a look at the code in pages.js that actually renders those changes that come in. So we basically take the changes that come in and loop through each one of them. We check if there is a reason property on each change that's said to deleted. If we have that, then we know that it's a deleted item rather than an added or updated item. Deleted items are a little different in that you don't get all of the properties on the item since it no longer exists. You do get back the item identifier. So if you're saving this into a back end somehow, keeping them in sync, it's a good idea to be able to find the item in your back end based on the item identifier so that you can remove it. If it's not a deleted item, then we just set the entry in the table to use the subject of the appointment and add it into our table. Now let's take a quick look at what happens if we add an item after we've completed our sync. So we'll go to the user's calendar and we'll just add an item here. Now if we switch back to the app and do another sync, we should see the new item that we just created. And we'll see the flip side of that. We'll delete the item and do another sync. And this time we get back a delete change with the ID of the item. And that's it. We've done basic synchronization functionality. Join us in the next session where we'll take a look at doing a little bit more with the calendar, viewing items, updating items, and deleting items, all from our app. Be sure to check out dev.outlook.com and dev.office.com for more information and getting started materials for Node and other platforms. Thanks for watching.