CUSTOM CONNECTORS: No multiple GET's using same URL?

[ericonline]

So... this one kind of hurts. I hope I'm doing something wrong. 

Scenario:

• I have a GET web service (AKA: REST API) which is queried using a parameterized URL
  • Example: https://mycompany.com/api?param1=yadda&param2=yah&param3=yougetit
• Each parameter sends back a different JSON schema (<--very important)
• Example:
  • https://mycompany.com/api sends back a simple JSON list of objects
  • https://mycompany.com/api?param1=yadda&param2=yah sends back a nested JSON blob
  • https://mycompany.com/api?param1=yadda&param2=yah&param3=yougetit sends back a  nested JSON nightmare
• When I tried to create a SINGLE Custom Connector with multiple GET actions, one for each schema type, I'm presented with an error that says:
  • "The combination of PATH and METHOD must be unique to each operation..."
  • 

I hope I'm just doing something incorrectly because, the result of this, is that I need a Custom Connector FOR EACH GET REQUEST! Even though its the same URL just additional parameters tacked on. 

The result is that my Users must authenticate to 4 (yep, one for POST too) Custom Connectors the first time they use the app. NOT FUN. 

Does anyone else have a solution for this? Maybe something to do with base URL ?

Thank you!

[v-xida-msft]

HI @ericonline ,

Why do you add one operation for each of your three Requests (that you mentioned) within your custom connector?

Based on the needs that you mentioned, I think it is not necessary to add one operation for each of your three Requests (that you mentioned) within your custom connector.

On your side, you just need to add single one operation for your third Request (https://mycompany.com/api?param1=yadda&param2=yah&param3=yougetit) within your custom connector, then eidt these Query parameters and set the Visibility property of theses Query Parameters (param1, param2 and param3) as advanced:

then when you call your custom connector actions within your app, you could specify these query parameters optionally rather than mandatory.

Best regards,

[timl]

Hi @v-xida-msft 

The reason why @ericonline needs 3 Get operations is because depending on the arguments that he passes to his API, the schema that the API returns will be different. Unless I misunderstand you, how would you configure the 'response' part of a single operation to support multiple schemas?

[ericonline]

@v-xida-msft , Thank you for the advice. 

At first, I did try adding a single custom connector with all three parameters at first. I did not try setting the parameters to "advanced". (Thats a cool tip to know!)

The question is, which of the 3 schemas do I paste into the Response example? Each is different based on the parameters sent.

[timl]

Hi @ericonline 

I've just been watching Mark Wood's Zapier talk at the 'PowerApps Virtual Summit' (it was a great talk!).

https://zapier.com/

Although I've not used this, it seems that it might be possible to 'proxy' your 3 calls via a single custom connectiont to Zapier. Perhaps this might be worth investigating?

[ericonline]

Thanks for the idea @timl .
My org is pretty "3rd party averse". Its challenging as is to get PowerPlatform sanctioning!

I'm wondering if there is a way to architect JSON responses to make them more "Custom Connector/PowerApps friendly".

Some ideas you, I and others have already learned:

• Flatten the JSON Response (hierarchy) as much as possible (2 levels deep, 3 at the most)
• Keep schemas the same for multiple GET requests (unfortunately, you'd have to have different URL's for each GET request to use a single CC)

I'd REALLY LOVE to hear from someone on the PowerApps team on that.
PS: Zapier has a killer remote working blog too. 

[joshbooker]

@ericonline

I think what you need to try is using the x-ms-dynamic-schema vendor extension in your swagger.

It's not fun or easy and there are zero samples of using this in PowerApps but I believe the only way to get PA to fetch the schema dynamically.

https://docs.microsoft.com/en-us/connectors/custom-connectors/openapi-extensions

Also, good luck getting a team member to chime in on custom connectors.

https://docs.microsoft.com/en-us/connectors/custom-connectors/openapi-extensions

Lastly, FWIW, There is supposted to be new and improved guidance docs on Custom Connectors being resleased in the the 'April 19 release' timeframe, but I haven't found anything yet - prolly still forthcoming.

https://docs.microsoft.com/en-us/business-applications-release-notes/April19/cdm-data-integration/co...

HTH,

Josh 

[PowerPat]

hi, have you solved it? i have the same problem

[UnhappyUser]

Hi There Kris,

Do you work for Microsoft?

You understand how incredible dumb your answer sounds right? Why on earth would you go through the process of building a solid Postman collection from your API (which by definition will have the same base url) only to be able to import one action for the API? Answer that riddle please.

I have spent several hours building the Postman collection, only to be the told by the vendor my work is useless, so I'm wondering who at Microsoft needs an extremely stern talking to about documentation and good design and coding practices! Because if your answer is correct it is the poster child for why people hate to use Microsoft products.

[Brendan1]

Hi Community!,

I had to tackle this problem myself today, and came up with a workaround that worked for me:

I'm working with the Xero payroll API, the base URL is https://api.xero.com/payroll.xro/1.0/

If I want to retrieve all timesheets in a tenant, the URL is https://api.xero.com/payroll.xro/1.0/Timesheets

If I want to retrieve a single timesheets, the URL is https://api.xero.com/payroll.xro/1.0/Timesheets/{TimesheetID}

As we're aware from the above posts, this does not work, the editor will not let it save.

Instead, I used the following for all timesheets: https://api.xero.com/payroll.xro/1.0/Timesheets

And I used the following to retrieve a single timesheet: https://api.xero.com/payroll.xro/1.0/{Timesheets}/{TimesheetID}

In the parameters for the second get, I defined {Timesheets} with a default value of 'Timesheets'

This allows the definition to be saved and tests OK.  I haven't tested it in production yet, but don't forsee it being a problem.

I hope this helps!

Brendan