Forum Discussion
Implement TestConnection with both Uri.Type plus optional parameter
Hello, I'm trying to create a custom connector for our company Microsoft Purview. We basically use two urls, one to query, which has mandatory json parameter, and another which will receive an entity id directly on url's relative path (executing once per table row). In Power BI Desktop, this connector works wonderfully, however I'm struggling to implement TestConnection. I would like to keep the Uri.Type parameter because of the relative url invocations, however it seems like datasourcepath has a really weird behaviour when trying to set up TestConnection when I need to use both parameters at once.
Thank you for reaching out to the Microsoft Fabric Forum Community.
Akash_Varuna thank you for your inputs.
f_daniel_souza -I have attached some official documents below for your reference. They may be helpful, so please take a look.
Gateway Support for Power Query connectors - Power Query | Microsoft Learn
Solved: Custom Connectors - API url + body - Microsoft Fabric Community
Custom API Connector - Data Source Path - Microsoft Fabric Community
Thanks.Hi v-priyankata , unfortunately I couldn't solve this current problem, however I managed to create a dynamic navigation table that let me to call specific entities APIs with some engineering. You can close this thread nonetheless.
Thanks!
8 Replies
- Akash_VarunaSuper User
Hi f_daniel_souza To do the TestConnection with Uri.Type and an optional parameter, ensure the DatasourcePath combines the base URL and parameters logically. Structure TestConnection to match the arguments of your DatasourcePath. Use Record.ToTable to include optional parameters effectively. Test thoroughly with both URL types to ensure compatibility.
- f_daniel_souzaRegular Visitor
Hi Akash_Varuna, thank you so much for the reply. Do you have any code example representing this scenario? I have already tried several different things, such as parsing the dataSourcePath with Json.Document, or using static values, some of them actually pass the VSCode TestConnection but fail on Power BI Service. I think I've read all Github examples, but none of them covers a Uri.Type + second parameter, so I assumed Microsoft "special handling" of Uri.Type might be causing the problem.
- v-priyankataCommunity Support
Thank you for reaching out to the Microsoft Fabric Forum Community.
Akash_Varuna thank you for your inputs.
f_daniel_souza -I have attached some official documents below for your reference. They may be helpful, so please take a look.
Gateway Support for Power Query connectors - Power Query | Microsoft Learn
Solved: Custom Connectors - API url + body - Microsoft Fabric Community
Custom API Connector - Data Source Path - Microsoft Fabric Community
Thanks.
- Poojara_D12Super User
You're building a custom Power BI connector for Microsoft Purview that interacts with two types of endpoints—one that requires a JSON body for querying data, and another that targets a specific entity using an ID embedded in the URL path. While this setup works perfectly in Power BI Desktop, you're running into issues implementing the TestConnection function, which is required for publishing certified connectors and for validating credentials in the Power BI Service. The challenge arises because Power BI expects the dataSourcePath used in TestConnection to be a stable, base URL (like the hostname or a consistent API root) that doesn't contain dynamic elements such as JSON bodies or path parameters. However, your connector uses Uri.Type to handle relative URLs for entity-specific lookups, and combining this with TestConnection causes inconsistencies or validation errors. The recommended approach is to isolate your connector's base URL and use it as the dataSourcePath—ensuring it's static and predictable—while keeping the dynamic parts (like JSON payloads or entity IDs) within individual function logic using RelativePath and Query in Web.Contents. Structuring your connector this way satisfies Power BI’s validation requirements for TestConnection while preserving the flexibility needed for your relative URL invocations.