SOLUTIONS FOR POWER PLATFORM

Building a Power Platform Independent Publisher Connector for the Ethereum Blockchain (Part 2)

This article is the second of a three-part series on building and submitting a custom connector through the official certification process.

Sebastian Zolg 🤝
7 min readMar 28, 2022
Photo by Nikola Johnny Mirkovic on Unsplash

TL;DR — Part 2 shows the overall certification process for your connector. While focusing on independent publisher connectors, you also learn about the other types of connectors. Furthermore, we look at the Github process and learn about the necessary CLI tooling.

In Part 1 of this series on building and publishing an independent publisher connector for the Power Platform, we learned how we could use various techniques to connect from the Power Platform to any external system, such as the Ethereum Blockchain.

In this second part, we’ll look into submitting a custom connector to the official repository in the form of an independent publisher connector. We take my Infura Ethereum connector as a real-world example. Before we get into details, let’s do a quick recap on what makes a custom connector.

What makes a custom connector?

A custom connector consists of three mandatory and two optional files. We have an icon for the connector, an Open API swagger definition, and an API properties file that defines the connector’s metadata, such as authentication, template policies, UX parameters, etc.

Optionally, the custom connector may include a settings.json, which simplifies the work with the connector CLI tooling.

In addition to that, the connector can include a C# script file to transform requests and responses, as shown in Part 1 of this series.

However, in the case of an independent publisher connector, you can’t submit a custom icon, and you have to provide a README.md file during the process. The settings.json doesn’t belong there either.

Custom Connector vs. Independent Publisher Connector

Connector Types

There are three types of connectors you can submit. Although there isn’t a significant difference in how they got built, there are differences in how you submit them and get certified. Each type of certification comes with its pros and cons.

Certified connectors are built by partners who own the end service of their connector. These connectors are deployed and available out-of-box within the Power Platform. One requirement of the connector certification program is that newly certified connectors must be open-sourced for community contributions.

Independent publisher connectors are submitted by publishers such as MVPs, developers, and companies, that do not own the underlying service behind their connector. Anyone can submit a new connector, add functionality to existing connectors, and resolve issues related to the connectors.

Custom connectors are fully functional connector samples that can be deployed to any Power Platform environment for extension and use.

So, the major question you need to ask is if you own the underlying service of your connector, meaning you’re the sole provider of that service, or if you just connect to that service independently.

Suppose you’re indeed the owner, e.g., connecting to a SaaS application you or your company build. In that case, you need to submit the connector through the certified connector process.

You can either submit a custom connector sample or an independent publisher connector if you don’t own the service.

Benefits

There are many benefits to building and certifying a connector for Power Automate, Power Apps, and Logic Apps. These include the ability to expand the reach of your API to users of Microsoft Power Platform to interact with it. However, since every connector type has its own benefits, we focus on the benefits of an independent publisher connector, which are as follows:

  • Certify for free. There’s no cost to register, go through the certification process, or update your connector after certification.
  • Unlock marketing benefits. In addition to being featured in the new connectors blog post, you’ll be featured in YouTube videos, monthly demos, and social media platforms.
  • Obtain thorough review and technical feedback. Microsoft engineers will help unblock you through technical support and perform a technical review before the connector goes public.
  • Gain visibility through having your name across Power Platform products and documentation. You or your company will be listed as the official publisher of the connectors you submit. Your connector will belong to the official list of Microsoft connectors and the public connector documentation. Each connector will receive a dedicated page on Microsoft docs with your name.

High-Level process and requirements

The process for certifying your connector as an independent publisher is relatively simple.

First, you must create, document, test, and validate the connector. After that, you submit your connector to the official GitHub repository through a pull request.

Overview of the connector certification process

After submitting the pull request, the connector will be certified by Microsoft. Usually, you should hear back from Microsoft within a few business days.

Finally, Microsoft will deploy to all production regions after your connector is validated and prepared for deployment. On average, it takes 3 to 4 weeks to deploy the connector, independent of the size or complexity of your connector or whether it’s new or an update.

Once your certification ends and your connector is published, you can add new operations and functionalities to your connector in the GitHub repository anytime. Microsoft will recertify your connector as needed.

GitHub Fork

Let’s look at a few steps of that process as described in the official documentation. As a first action, you fork the official Custom Connector repository.

After that, you clone your fork locally and link it to the upstream repository to keep the repositories in sync while you work on your connector.

However, I recommend having a dedicated repository for your connector. This way, you can add all your stuff under source control. For example, you could write tests to test your connector locally or put additional documentation in place.

After that, you copy the required files to a dedicated connector folder of the forked repository.

Finally, you create a pull request to the original connector repository from your fork. Once you’ve done that, Microsoft will look at your submission and starts the review and certification process.

If you want to get an idea of what the discussion will look like after submitting the connector, check my PR. We discussed different implementation details, patterns, and limitations, so I did update my connector a few times during the certification process.

CLI tooling

Last but not least, you need to use the paconn CLI tool to work with your connector during development. Although you could model the connector right inside the Power Platform UI, there are certain things like additional UI parameters which can only be added through the connector files.

Since we should have everything under source control, the CLI helps you login, create, update, delete or download a connector from or to your dev environment. It also allows you to validate the swagger file of the connector before submission, so your PR isn’t rejected, and you follow best practices.

Here’s a shortlist of the essential commands:

  • paconn login | Connect the CLI tooling to your Power Platform development environment using your Azure AD credentials.
  • paconn create -s settings.json | Create your connector from a single settings.json file. This simplifies your development workflow quite a bit.
  • paconn update -s settings.json | Update your connector from a single settings.json file. This can also be used in CI/CD pipelines across environments.
  • paconn validate -d apiDefinition.swagger.json | Validate your Swagger OpenAPI file before submission.

Please see the official documentation for a complete list.

Summary

So, that’s it. That was my certification journey, and here are my four key takeaways:

  1. The documentation can be a bit overwhelming at first. Don’t get lost.
  2. The overall process is fairly simple after you understand it. So don’t worry too much about it, and focus on developing your custom connector.
  3. You gain a lot of visibility. People will ask you about how you did it. You get invited by the power platform product team to blog post or speak at Microsoft events. Block some time to present your work.
  4. Most importantly: It is a lot of fun! I encourage everyone to write a connector for the service you like the most. It is a great learning opportunity.

In the last part of my blog post series, we take a quick look at how certified custom connectors show up in the platform and how you can use them inside Power Automate, Power Apps, or Power Virtual Agents.

Make it so 👉
— Sebastian

--

--

Sebastian Zolg 🤝

I’m an IT professional with experience in enterprise mobility, workplace, cloud technologies, and software development. sebastianzolg.de