>> Our next guest. >> Ghost. Don't kill people. >> No. >> Okay? It's not right. >> Our next guest, April
Dunnam is going to show us how to build your
own custom connector. You can go from zero to hero. April is one of those
extraordinary people who has incredible creativity in how she
goes about designing Power Apps. She makes probably the most beautiful
Power Apps you've ever seen. She actually does this
fantastic session on beautifying your Power App, so it's Power Apps make-over. Check out her YouTube channel, April Dunnam, and you
can see how to make Power Apps look not like the traditional Power
Apps you are used to. She use this tabs and
themes and colors, and she can make them pretty quickly and they can look
incredibly impressive. She can make beautiful Power Apps, but she can also use custom connectors and be
extraordinarily impressive. >> That's really cool.
Hopefully, this session won't be as shocking- >> You're still doing it. >> -as the last one. >> He's still doing
it, wow. All right. April, we really apologize for
these horrible jokes. Over to you. >> Over the cycle. >> He's still doing it. Thank
you so much for joining us, April. Over to you. >> Thanks, [inaudible]
. Thanks for having me. I'm so happy to be here, to talk with you-all about
custom connectors today. My goal is to take you from zero
to hero in custom connectors. For those of you who don't know me, my name is April Dunnam. I'm a Partner Technical
Architect here at Microsoft. If you've been around on the
Power Platform community, you might know me from there for
being really involved in Paradox, and now there is the Power
Apps and Power Automate MVP. If you want to connect with me, you can connect with me
on Twitter @Aprildunnam, my YouTube and my LinkedIn. The agenda for today, I
want to talk about, first, give you a good understanding
of what custom connectors are, and then we'll build on that and
talk about some of the use cases, and why you might want to use custom connectors in your
applications and your flows. Then we'll actually walk through, go into some demo by creating a
new custom connector from scratch, and how to use that and implement
that in an app and a flow. Just diving right in, what is a custom connector? Well, custom connectors are really the building blocks of
the Power Platform. It's what enables Power Apps and Power
Automate, to communicate with a bunch of different
services so that it can access data and use that in
your apps and your flows. All it is, is a wrapper around
an API that you define. If you've used Power
Apps and Power Automate, you will have noticed
that there are over currently 325 different connectors that they share between the two, but you can utilize today to different pre-built
SaaS applications, all the Office 365 apps, like SharePoint and all of those
great applications, of course, and then other third-party
applications that you can access. What we're seeing here is just
the tip of the iceberg of some of the apps that you can connect to with these pre-built
connectors that you're seeing. But the problem is, even if the 325 seems like a lot of connectors
that you can access, there is always going to be a case where there is some other service, maybe it's an internal
legacy system that you need to connect with and use within
Power Apps or Power Automate, or some other publicly accessible API that you want to consume
that's not on this list. That's the gap that
we're going to bridge today with custom connectors. In my opinion, custom
connectors are really one of the easiest and most impactful ways that you can extend
the Power Platform. Before I joined Microsoft, I did a lot of consulting, I built hundreds of different
Power Apps applications. One of the most common
use cases that I saw or I need to extend the stack, was to be able to connect to
these other systems or services. Power Platform, custom connectors
are a great resource for that. It allows you to bring in that data from the public and even private APIs into the Power Platform so that your app makers and flow makers
can use to consume that. Another great use case for this
that you might not even think of, is to extend and consolidate some of those 325 different pre-built
connectors that we talked about. I've run in this to one
of my customers before. They really wanted to use
the Service Now Connector, for example, in one
of their Power Apps. But some of these
connectors they don't expose everything that the API
can do to you in the connector. That's a great use case to go
in and build a custom connector to bring in that functionality that might not be there in
a pre-built connector. Now, if you have used the
Power Platform before, specifically, if you've
used Power Automate, you might be wondering your
next logical question. What if a custom connector
is just a wrapper around an API to let me make
calls to the endpoints? Well, why can't I just use
an HTTP request for that? That's a great question that
we want to address today. The first thing that I'm going
to say about that is simplicity. When we are building solutions
and extending the platform, the end goal is to make it easier for our business users,
or app makers, and flow makers to consume the data. By building a custom connector, you're making that easier on those users, because we
really can't expect that our traditional end-users would
know all the ins and outs of calling an API without
knowing what get post and put, and all of those details means. A custom connector though, they're are very familiar
with if they're in their everyday building
apps and flows, they know how to go in and add a connector and do things with that. You're going to make their
life much more simple. Another one is re-usability. You can build these custom
connectors and you build it once, and you can use these in Power
Apps and Power Automate. Another, is unnecessary overhead. There's not a native way in
Power Apps, for example, to directly connect to an
API to make an HTTP request. You have to use Power
Automate for that. If you need to consume that in
your Power Apps application, you're going in and having to make a Power Automate call to do that
and then return the data back, which can lead to some unnecessary complexity to your business process that you could avoid with a custom connector. Finally, better
logging and analytics. If you're relying on HTTP requests to call data and get
it from your API, you don't really have a way
to monitor and track that, where it's being used
and how it's being used. But with the Power
Platform Admin Center, you can monitor and
track the usage of your connectors across Power
Apps and Power Automate. Check on how much better
logging analytics from that standpoint. Now you're probably wondering, what APIs can I create
a connector to? The beauty of this is,
these connectors for Power Apps and Power Automate
work with any Restful API. If you are using Logic Apps, those can connect to
SOAP APIs as well. This can be APIs from public
services like: Spotify, Yelp, NASA, and that's actually what I'm going to be
demoing for you-all today. This can be from public APIs that you manage or Azure
functions, web apps, APIs which we saw and we'll see some great sessions about custom
connectors, Azure functions. This can also be private APIs, and this is a thing that I know a lot of people don't
even realize that you can do in Power Platform, because
you know it is a Cloud service, so you think you can only connect
to other Cloud applications. But there's a thing called
the On-prem data gateway, which allows you to connect to your internal behind the firewall systems, so therefore, you can connect
to your private APIs that way. Now we have a good understanding
of what a connector is, and why you might want
to use it and which types of APIs that we can use. Now, let's talk about your
wanting to use custom connectors. How can we secure that API and what security authentication
methods are available to us? Custom connectors first the
support generic OAuth 2.0. They also support OAuth 2.0 from different third party services
like, Azure AD, GitHub, Dropbox. Basic Auth is supported and
API keys are also supported. Now that we have a good
foundational level understanding, let's talk about when you're
building the connector, how do you describe the API so
that the connector can consume it. Connectors support OpenAPI
2.0 aka Swagger files, so you can import those or
link to those from URL. They also support
Postman Collections. That's a great way to easily
create a custom connector, because I like to test my API calls and all that in
Postman before doing anything else, just to make sure it works
and the authentication works. Being able to just export
that to a collection and then import that into the connector,
makes it very simple. Then the other option, you
can actually just create a new connector from scratch with
the custom connector portal. Actually, that's how I'm going
to be showing you today, how to create a new connector. Last slide before we
get into the demo here. The components of a connector
when we're building our site, you'll see when we get to the demo. First, you need to give
it the information about the connector itself.
This is really important. You want to make sure you
have a really relevant name, logo, and description, so that when your app
makers and flow makers are wanting to use this
in their applications, they know what this connector
is going to do for them. Then you have your actions, this is where the bulk of the
building of a connector will be. That's where you define your
endpoints and their visibility, and the headers, and the definitions. You have the triggers which are the timed or event-driven
webhook actions. You have references which are
reusable input and output objects, and then you can also
define policies or templates for modifying
the runtime behavior. All right, so with that, we're going to switch over to a demo. Before I get started showing you how to actually build
the connector itself, I want to talk about the use case, so what's bringing us here or giving us the need to have
to build a custom connector? In our business here, we have one of our app makers in the sales department that
has created a Power App that you're seeing here
on the screen to help manage customer and
contact information. The Power App works
great and it's usable. But the problem is when they
go in to add a new contact, they really need to track
a lot of information about this user, and their employees, their sales people, really don't have a lot of time on their hands to be manually filling out
this person's name, their time zone, their location, all this, and their
company information. They came to our
developers wanting to know how can we make this easier on our end users to possibly pre-populate all of this
information for us. That's the use case that
we're trying to solve. Now, I happen to know about
an API that's publicly accessible out there
that we can use to do this called, the Clearbit API. What I'm going to be walking you
through today is how to create a custom connector to the employee
lookup functionality of this, which will allow us to just put in an e-mail address of a contact and it will automatically populate all of that information
in our app for us. All I did is went out to the Clearbit API and signed
up for their program, got our API keys and all that, looked at the documentation to get a good understanding of what
the API itself is doing. I said that I always like to start with Postman when I'm
working with this, because I like to test my API calls, make sure that I have the authorization and
everything formatted correctly. That's what I did
here. I've just made a connection to this employee Lookup API call and
I've ran a quick test, pass it in some dummy information, and I'll have to see and verify that it's returning the
information successfully, and that it has
everything that I'm going to need for our application. Now, it's time to actually
build the custom connector. There are two options that you
have for building connectors. You can either do it through
Power Automate or Power Apps. There's places where you can build custom connectors
from either one of those, in the custom connector
that you built is the same, no matter which program
you create it in. Let's look at Power Apps. I'm going to go in there and we'll see how to create a custom connector. From the Power Apps landing screen, you'll see in tab for Data
on the left-hand side, and in there you'll have an
option for Custom Connectors. You'll be taken here, and you'll see all the connectors that you already have created in your environment. If you want to create
a new connector, just select the "New
Connector" option in the upper right-hand side, and this is where you'll see all
the different options that you can use to create a new custom
connector on the Power Platform. As you can see, I
could import directly from a Postman collection
here if I wanted to, and for the OpenAPI, I can either upload a Swagger
file or a linkage from a URL. Though what we're going
to do, just so we can see the true experience of
building custom connectors, we're going to start from blank. First thing we need to
do is give it a name. I'm going to give it
the name of my API that I'm calling, click "Continue". Now, this is the information
section that we talked about. What's really important here is you want to make sure that
you're uploading an icon, because that will really help the user when they're looking
through the list of connectors. Let them know quickly offhand, what this connector is to. You just upload your icon there, you can see it on
there on the screen . You also have the ability to define custom background color for this if you would like
so it's not gray, so it's white and looks
a little bit better. Then you can of course,
give it a description. Description is very important too. When your users are looking at this, trying to decide if this is going to help them
solve their problem, the description is what's going to give them some more information. I've just populated that
with a description there. Then you define your scheme, so is this an HTTPS or HTTP call? Now, we go into the host. This is the API that
we're going to call, so we're going to put in that here. Notice that in the help text here it says you don't put in the HTTPS, so just put in that bit
of the information there. I just got that from
our Clearbit API. Now, let's go proceed to
the Security section. Now, this is where we define
our authentication type. For demo purposes,
I'm just going to use the API Key since our
Clearbit API supports that. When you do this, there's three different properties
that we need to configure for the API
Key authentication type. The first is the perimeter label. With connectors, when users log
in to create the application, they create a connector to that. When they create the connector,
it's going to prompt them to put in information
here to authenticate. What this is going to do is the perimeter label is going
to prompt them for the input, so we want to make
sure it's relevant. We're going to call this
perimeter label API Key, so that the user connecting knows that they need to put
in an API Key here. Then we give the
parameter name itself. This is what the header
parameter is in your API, which is going to be Authorization. Then the next, we just define the header for the perimeter
location, which will be the Header. We have our API key
authentication type, a clear label for our end users, the parameter name, and the location. Now, it's time to move
onto the definition. Here are the different
sections that we talked about. The one that we'll
be focusing on today that's supporting is
the action section. First thing that we need
to do is go in and create a new action to call our API. We're going to give this action
a summary and a description, just so that the user using this
knows what it's going to do, so get person info, give
it a little description. Then now, we just need our
operation ID from our API call, which for the clear view
API is just people. Visitability section down here
is important because this is what determines the
properties from our API, how they show up specifically
in Power Automate. If you're in Power Automate
you might notice when you click into a field and you
see that dynamic content, there's some properties that show up automatically
and then some that you had to click "See more" for or you you have to click "Show
advanced options" for. Those settings are defined here. If you want these properties from
your API to always show there, you'll select the "Important" option. Then you also have the option for making these properties internal, and Advance will be they'll show, but you have to click "See
more" or "Show advanced". I'm just going to switch
that to important. Now we have our general operation ID. Now we need to define the request. What I'll do is I'll click
"Import from sample". For this API call, if we recall from postman, it's just doing a GET request. So we want to switch
that property to GET and then we'll just paste in the URL
from your call and import that. You'll see when we
do, it automatically fills out all this
information from us. This is a GET request. Here is the endpoint that
we're going to call, and here are our required properties. So it automatically was able to tell where you
need to require an e-mail. We have the ability to go in and
additionally configure this. I can go into the
e-mail, click "Edit", and I can give a detailed description and then define if it's required. So it didn't pick up, for example, that I need this
property to be required. I'm going to switch that to
"Yes" and we'll go back. Notice when I do that
we have a red asterisk, letting us know that this
is a required fields. Now we have a response section. We can fill this in with
a default response. Well, what I'll do is I'll go into our postman collection and I'll just copy the default response that we have here from our test
that we ran and paste that into the body and then select Import so that we'll know the
response that's expected. Now if I click within
the default response, you see it has our body
filled out for us. Again, I can see all the properties that are going to be
returned for me from the API, and make any modifications
to this if I need to. Let's just go back, scroll down. That's honestly, all that we
need to do to get this custom connector working to
return the information about a person when we
pass an e-mail address, it's really just that
simple in this case. What we want to do
now, is we'll go back and we're going to
create this connector. As before, we can test this. We want to create the
connector itself. While that's creating,
you see it's pretty fast. So it created successfully,.I
have my Clearbit v2 connector. Now I can go in and test it. Before you start
trying to use this in your app to your flows,
test it here first. It'll save you a lot of headache. To test it, you need to first define a connection to the connector itself. So we can do that directly from a test panel by clicking
new connection, and this is where it'll ask
for that API key for the user. So that was the label
that we defined and here's the authorization
API key that will put in. So I'll click "Create" and that
will create a new connector. When you do that, it
does take you back to this connections
screen in Power Apps. In this case, where you can see
all the connections that you have. So you will need to go back
in after you initially create that to your
custom connectors tab, find your connector and click "Edit", and go back to that test panels. So I continue and
continue trying to test. So here was my input that we defined for the e-mail
which is required. What we can do is just
put in an e-mail to test, run a test operation. I can see that's great news. We got a 200, that means
it was successful. I can look at the body, makes sure that the
information is being returned as correct,
which'll looks great. Our validation succeeded. So really here in just
a couple of minutes, we have a completely ready
and usable custom connector for our app makers. Something I'll point
out before we move on to showing how to use
this in and of itself, you can always switch to
Swagger editor and edit this. It's Swagger if you'd prefer.
Okay, so that's exciting, we have our custom connector. Now let's see how we can
use this in our app. So from this point, our app makers can really take it and run with it. I have the app that our sales member created or Customer Success app
opened in Edit mode. If they want to use
our new connector, all they have to do is
go into data sources, add a data source, and search for Clearbit. So we see our Clearbit v2
connector that we just created. That's going to add
the connector into our app and now I will just go to where we need to
consume the information. So on our new contexts screen, what I wanted to have happen
is I enter in an e-mail here, I click the "Check" button, and when I click that, I want it
to go call our Clearbit API and return all of that information to
me, about that particular person. So we have an icon here. If we go to its OnSelect property, you'll see that we can just use some global variables and Power Apps. We're going to have
two different lines; one for personal info and
one for company info. That's just because the way
that the API is structured. So you can see we have the
person information that has a subset of properties and then
we have another subset of that, which is company information. So we're just to call our API. You just type the name of the
connector that we created. Then if you do a dot, let's just delete this real quick. So we'll do v2 in this case. You'll see that it has
built-in IntelliSense. So just like we're used
to in visual studio, we had that rich
IntelliSense, so I can do a dot people and it's telling me that, it's expecting
an e-mail address. So I can fill that in
right into my text box, the text value of that, and do a dot, and I can get the person object
information directly from that. It's really as simple as that. That's all that I need to do to
call this API in my application. So I've set that into
two global variables. Now if I look at the app itself, I have a bunch of labels in here to show the information to the user. So all I'm doing is I'm calling that global variable of the person
info and I can just keep doing dots so I can get the different
properties that I would want to use in this and mapping
all of those accordingly. So let's just test this out, let's see how it works. Let's see what this can
tell us about Satya. Awesome. There you go. You see that it returned
the company information and all the information that we
need to know about Satya. It's pretty cool. All right,
and we can come back in, and just to prove that it
works for anyone, I was going to do another test,
I could type correctly. That would be great. There's
the company information, the information about myself. So that's how we can
do that in Power Apps. But you can see we can also use the same connector in Power Automate. So I could have a flow, for example, that's triggered by a button click where all I do is require
an e-mail address. I can add in an action to our
Clearbit API, which I did there. Pass it in, the e-mail address from our trigger, and have it create
an item in a SharePoint lists, for example, just to show
you how that would work, we'll just run a quick test. It will put an e-mail address. Within a second there,
we have a flow that we can save a contact with only
requiring e-mail address. Pretty cool. So there's the
SharePoint list with the contacts. So I see my name, e-mail, and job title filled out. Going back to the slides real quick, I want to leave you
with some homework. So as to quote [inaudible] , now, I want you to do the thing. So first thing I want
you to do, is to go out and get a Power
Apps community plan. Now these custom connectors are premium functionality
with the power platform, so it does require some
additional licensing. But if you go out and sign
up for this community plan, which there's a link to right here, you can test out custom
connectors for free. Then, I want you to find an API
that you want to integrate within the Power Platform and just
go out, build the connector. Because as we saw, it's really intuitive and straightforward to do. I want you to use that in your
Power Apps and Power Automate. Then I want you to share
with me how it went in, what you build
@aprildunnam on Twitter. I'll be around on Dev.to after this, to answer
any questions in chat. So please join me
there. Thanks everyone.
