Identify use cases for custom connectors – Identify the core components of Power Platform

Identify use cases for custom connectors

As mentioned earlier, a connector is a wrapper that surrounds a REST API supplied by the application or service that will be the data source. Power Platform provides connectors for a great many applications or services, but certainly not for every one. For developers that require access to data sources for which there are no public connectors available, it is possible for them to create their own custom connectors.

When a developer creates a custom connector, it is part of the current working environment and is usable only by the apps and flows operating in that same environment. It is also necessary for consumers running apps or flows that use custom connectors to have their own credentials for authentication to the data source, if the data source requires them. Unlike with public connectors, there is no way for consumers of a shared app or flow using custom connectors to inherit credentials supplied by the developer.

Depending on the application or service for which the developer will create a custom connector, there might or might not be an existing API with which the connector can communicate. A third-party application or service might already have an API in place. If not, the developer might have to discuss with the third party the possibility of their creating one. For an internally developed application or service without an API, the developer might have to create one using a tool such as Azure Functions, Azure Web Apps, or Azure API Apps.

There are several ways in which a custom connector can communicate with the API. When a developer runs the Custom Connector Wizard, the following options are provided:

■ Create from blank

■ Create from Azure service

■ Import an OpenAPI file

■ Import an OpenAPI from URL

■ Import a Postman collection

OpenAPI (formerly known as Swagger) and Postman are definition file formats that provide the communication information the custom connector needs. When creating a custom connector from scratch (using the Create from blank option), the developer is led by the wizard through four stages:

General—Prompts for an icon and color for the connector tile and the host name for the API, as shown in Figure 2-22

FIGURE 2-22 The General tab of the Custom Connector Wizard

Security—Prompts for the authentication method the connector should use to access the API: Basic authentication (as shown in Figure 2-23), API Key, or OAuth 2.0

FIGURE 2-23 The Security tab of the Custom Connector Wizard

Definition—Provides the interface for creating the connector’s actions, triggers, and policies, as shown in Figure 2-24

FIGURE 2-24 The Definition tab of the Custom Connector Wizard

Test—Provides a platform for testing specific operations in the custom connector, as shown in Figure 2-25

FIGURE 2-25 The Test tab of the Custom Connector Wizard

After developers have created custom connectors, they can share them with users inside their organization. Sharing an app or flow that uses a custom connector makes it accessible to the recipients of the share. Developers can also share their custom connectors with other users by selecting Invite other user from the Custom connectors page to display the interface shown in Figure 2-26.

FIGURE 2-26 The Share tab of a custom connector

To share custom connectors with users outside of the organization, developers must submit it for certification by Microsoft, which validates the connector’s functionality and content. The connector then undergoes a testing phase in a preview area, and when testing is complete, it is deployed for public access. Connectors that are certified and published by Microsoft must be released as open source software.

Leave a Reply

Your email address will not be published. Required fields are marked *