Custom Connectors in Power Platform
Background
I recently worked on a project where I was requested to build an integration with an API, and the custom connectors was a great help to achieve it. Before the release of power platform and custom connectors, to integrate with an external service, we must usually build the integration using plugin or custom workflow activity in order to connect to the API, which require C#, .Net skills.
Developers have to spend substantial amount of time to get it up and running, and carry out some integration tests and apply some solid security around the integration. Now with the release of custom connector, special skills are no longer required to implement integration between Power Apps and an external service or source. Power Platform abstracts all these complexities via custom connectors and handles most of the securities for us as well.
A connector is a wrapper or a proxy around an API that interact between power automate or Power Apps and the back-end service or data source. It allows a bi-directional communication between the two. Connector can access data from both cloud and on-premise sources, but we need to make sure the source that we would like to connect to is exposed via a RESTful service as we can see on Fig.1 below.
As we all know, Cloud hold a huge variety of data, we can also connect to data in local systems through the common on-premise data gateway which also supported for custom connectors as well.
The connector allows the user to access the underlying data source but the permission to it is also taken into consideration. The connection needs to be shared to give permission to others user to access it, and we have over more than 200 connectors available today from wide range of sources.
Custom connectors come in place when we have a service or a source that we would like it to be available in Power Automate or Canvas App. There are two types of connectors, public and custom connector. Public connectors are the ones that are out-of-the box and are publicly available, however custom connectors are not always available publicly, they are the ones built by a developer in an organisation, it can be made available to a user, group of users or the entire organisation or tenant.
Why build a connector?
Sometimes, we might need to access a source or service that is not part of the out-of-the-box sources or services provided by Microsoft and sometimes even though the services might be publicly available and we might not have the features that we are looking for, or we might also need to connect to a custom or internal service, usually, these connectors are not publicly exposed.
Custom Connector Architecture
The custom connector sits in a hosting environment, where there are some interactions happening when Power Apps makes a call to execute some operations. The data are exchanged between each building blocks, from Power Apps through the custom connector and then to the RESTful API. The communication requires three main parts, the connector ID, the operation to run, and the connection ID. the connection ID represents the reference to the credentials that will be used to run the operation, under the hood, these three parts are translated by the custom connector and the hosting environment into respectively Host, Path and Credentials and then sent to the API as illustrated on the Fig. 2 below
The connector ID provide the information about the Host, Operation provide information about the path to use, connection ID provide information about the credentials to use, we might have connector that is anonymously authenticated, so we don’t need to provide any credentials to be authenticated, but we still need to have a connection.
The communication between the custom connector and the RESTful API is bi-directional, so the RESTful API receives a request from the custom connector, and it will respond back, and then the custom connector relay the information back to Power Apps or Power Automate. Custom connectors are very secure, to let other users access the custom connectors, the custom connector owner just needs to share it with other users to allow them to use it. Your credentials will never be exposed. Also, as we can see on Fig. 2, Power Apps doesn’t call the RESTful API directly.
Building a Custom Connector
1. You’ll need a Power Apps License to create a Custom Connector
2. Click the solution where you would like to package the custom connector and then on the top of navigation bar, click on New, Other, and then the Custom Connector, see Fig.3 below, and we should land on the custom connector editor on Fig. 4
We need the custom connector to be created to be able to import the Postman collection JSON file by updating the custom connector, so we just enter a value in the host field and it will allows us to create it, see Fig.4, then we can proceed later and import the Postman collection JSON file.
3. Import the Postman Collection into Power Apps.
We just need to click on (…), then It will prompt us to select an artefact, such as Import an OpenAPI file, Import an OpenAPI from URL or Import a Postman collection, you can also create it from scratch, the quickest way to create a connector is to import an artefact, in this case, we will import the Postman collection JSON File. See Fig.5
Importing Postman collection will pre-populate the custom connector General Tab, Definition tab but will need to manually configure the Security tab for authentication, see Fig. 6 below.
Create the Connection for the custom connector
The connection is required to request users’ credentials to allow us to run the custom connector, these credentials are required when the custom connectors are added in the Power Apps or flow, and we’ll be prompted to enter our credentials to authenticate at the organisation level. As we can see on Fig.7 below, the Test operation is disabled because we haven’t created a connection yet for the custom connector, the reason a custom connector is not fully operational until we create its connection, so, at this point of time, It can’t be tested without a connection associated to it.
Testing the Custom Connector
It’s best practice to test the custom connector before using it from the Power Apps or flow, so that we can fix any issues before exposing it to other power platform components, as we can see on the screenshot below(Fig.8), it has successfully validated the API calls.
Security
In case, we need a certain level of security, there are couple of authentication options to choose from such as Basic Authentication, OAuth 2.0 or API key.
Sharing
Allow other users within the organisation to use your connector, we can give permission to user. (edit or use)
Make Custom Connector publicly available
Very often, Partner and ISV (Independent Services Providers) might want to expose their services to their external customers, so they have to make their connectors certified by Microsoft in order to make them publicly available.
Integrate custom connector with other Power Platform components
There are a couple of ways available to integrate the connector with others Power Apps components such as canvas App or power automate so, by leveraging power automate or canvas App. In case of using it with Power Automate, we need to add an action by selecting the connection that is configured with the custom connector and select the operation, and some mapping might also be required for the custom connector. (see screenshot on Fig.9 and Fig.10).
How to deploy Custom connectors into other environments
There’s two possible options available to move custom connector from one environment to another, the most recommended is via the automated Build tools, the Microsoft Build tools will be used to move custom connectors from one environment to another, in addition, we can also use others options available such as manually exporting and importing solutions across environments, however, I don’t recommend to use the import/export feature that I demonstrated in my previous post Export/Import Feature, as at the time of writing it was not possible to export and import custom connectors across environment using the export and import feature.
Deploying the custom connector into another environment
As we all know that to move components from one environment to another, we just need to package all the components in one solution then export and import it in the target environment, we will use the Microsoft Power Platform Builds Tools, it will generate a build artefact and then deploy it onto the target environment, so we’ll initiate, export from Dev, build and release. Below are some screenshots of a simple build and release pipeline I have set up to deploy the custom connectors from Dev to the target environment.
Initiate Phase
We need to run a couple PowerShell scripts on the Dev. environment, in my case, I have used visual code to run these scripts to export the solution zip file from Dev. environment, see Fig.11 below and extract it by leveraging solution packager in the PowerShell Script and the resulted XML files are stored in source control
As shown below on Fig.12, the custom connector files XML files on my Dev. environment that will be committed in source control in DevOps and should be picked by the build and release pipeline.
Build Pipeline
Release Pipeline
Fix Connections
We need to fix all the connections into the target environment after the deployment is completed. As shown on Fig. 15 below, the warning sign on the connection require the connection to be re-authenticated in the target environment.
Conclusion
Custom connectors are highly productive, low-code development components that enables a simple and easy way to integrate with external services and sources and with just some few clicks; we can get an integration up and running within couple minutes.
Build, Explore and Innovate with the Power Platform — Join the Capgemini Microsoft Team.
