Last week I discussed what the new Microsoft Trusted Application API for Skype for Business is and a talked a little bit about some of the things it could be used for. This week I show you the 3 important pieces as a developer you will need to create in order to make your first TAP application. As I did last week I will shorten some of the terms used to save some time, here is a recap of those;
TAP - Trusted Application API
SE - Service Endpoint
SFB - Skype for Business
There are 3 essential things you will need in order to create a TAP application. They are an Azure AD application, a registration of that application in your SFB tenant in o365, and an endpoint in your SFB tenant for the SE to use.
1. The Azure AD Application
You can create your application in Azure using the Active Directory section if you choose. However in step 2, I will show you a new portal for registration that can actually automate both step 1 and 2 if you like.
From this page you can create your application, make a new Web app / API application, as Native apps aren't really allowed to have the permissions you will need for the feature set of a TAP application.
Setting the permission is important in the required permissions page, and they can look something like this.
Again, this will depend on what you want to use your app for, and you can always change them, up to the point of admin consent, which we will discuss later.
2. Tenant Registration of Your App
Until the TAP program hit public preview the only way to do this was with an email to special team at Microsoft, but now with this portal developers and automate this process which is great.
You can see once you sign into the portal, you have the option to use an existing Azure AD app like we created in step one, or have it do step 1 and 2 at the same time. I will caution you if you do both at the same time you wind up with a couple of things that aren't awesome in my experience.
1. Your site name instead of being something lik emytapapp.azurewebsites.com, will likely be a guid instead, which is fine if you have 1 app, but trying to find your app in a sea of guids if you multiple later, is not optimal. You can still find it by name, but it's just ugly to look at.
2. The second issue with doing it all at once is you will wind up with if you use the portal for both steps, is the client secret password will have a 2 year lifetime. If you doing a demo app that is probably fine, and you can go and delete it, and create one that lasts forever later, but it's something to think about if this is production app. The last thing you want is one more cert expiration to track.
3. The SFB endpoint for your app
It's very important to do the steps in order, because you will need things from 1 and 2 before you can create 3. Before you can do step 3 you will need a couple of things. First go ahead and do the admin tenant consent. Once you have that done, make sure you have the ability to use powershell against your SFB tenant. If you don't refer to these articles.
When you are ready the command you will use will look something like this.
New-CsOnlineApplicationEndpoint -Uri -ApplicationId -Name -PhoneNumber
You don't have to add the phone number right away, or at all if you doing say an IM only type app. If you want voice, right now the only way to get it to your SE is with a purchased PSTN number from your SFB cloud portal. You should pick a number of type service number to accommodate your application.
Next week we will take a look at how we use all this information to begin creating our application.