When using the same call from inside the app, the resulting collection only contains the "properties" object, but is missing id, name, type and location
Hi @ffcloud-bskies ,
Could you please share a bit more about the Response JSON Schema you defined for this action within your custom connector?
Based on the issue that you mentioned, I have made a test on my side, and don't have the issue that you mentioned. Please make sure you have defined proper Response JSON Schema for this action within your custom connector:
Then you could edit these properties under the Response Body, please make sure you do not set Visibility property of the id, name, type and location property to "internal", instead, you could set the Visibility property of these missed properties to "important":
If the issue still exists, please consider create a new custom connector from scratch based on your REST API. Then specify proper action within this custom connector, and define proper Response JSON Schema for this action, then check if the issue is fixed.
More details about creating custom connector in PowerApps, please check the following article:
Thank you very much for your reply. This helped a lot.
I basically need a connector for Azure Lab Services. So as I didn't find an existing connector supporting Lab Services, I took the API definition from GitHub (https://github.com/Azure/azure-rest-api-specs/tree/master/specification/labservices/resource-manager...) and used it to create a custom connector.
What I found out is, that "Lab" definition amongst some others references "Resource" definition, which defines the properties I'm missing in the resulting PowerApps collection when executing the query.
This seems not being resolved by PowerApps. Replacing the reference with the actual properties from Resource definition solved the issue.
So for now I will get it to work as intended, hence modifying the schema and replacing nested references that cannot be resolved.
Do you know if this is known and might be changed in the future? In general it seems to be a supported scenario in OpenAPI (swagger seems to successfully resolve all references)
Thanks & Regards
Hi @ffcloud-bskies ,
Do you want to define the Response Body within your custom connector OpenAPI definition file via $ref?
Based on what I have known, I think you could define reference for the specific action in your OpenAPI definition file via $ref key. But based on the "Lab" definition structure that you mentioned, I think there is something wrong with it.
If you want to defined a Response Body for a specific action in your custom connector via $ref key, the standard OpenAPI definition structure should be as below:
responses: 200: description: A User object schema: $ref: '#/definitions/User' definitions: User: type: object properties: id: type: integer description: The user ID. username: type: string description: The user name.
You should specify the Schema inline the Operation, and then use $ref key to reference the Response definition. Please check the following article for more details:
Please make sure you have defined proper Schema keyword to describe Response Body for your operation. As an fixed solution, I agree with your solution, you could replace the reference with the actual properties from Resource definition.
In addition, you could also consider take a try to create your custom connector from scratch based on your REST API, then you could get rid of this OpenAPI definition structure issue.
Hi @v-xida-msft ,
the definition I'm using is not describing a custom API I created. It is describing the Microsoft Azure API for working with Azure Lab Services and is being maintained by Microsoft. That of course doesn't mean, that it must be fitting the specification, but
as Azure APIs are quite extensive, creating the connector from scratch would be very time consuming and also a bit unreliable compared to just taking the published definition (that has probably been generated from the actual API) and using it here. I would also like to avoid doing bigger changes to make it fit to PowerApps.
I had a look at the OpenAPI spec and found, that the constellation used for referencing the Resources schema seems to be valid as per https://swagger.io/docs/specification/data-models/oneof-anyof-allof-not/ so from what I see there, there is nothing wrong with the definition I used.
As mentioned above, for now I have a workaround. But it would be a very nice thing just being able to take definitions from the Microsoft Azure Repos and directly create connectors from it. That would save a lot of time. Or even better, just having a Built-In connector for all of the Azure APIs 🙂
Edit: If it turns out, that there is something wrong with the definition, I will head over to GitHub and ask for a fix. But from what I found out until now, that doesn't seem to be the case.
Check out the on demand sessions that are available now!
ISV Studio is designed to become the go-to Power Platform destination for ISV’s to monitor & manage published applications.
Features releasing from October 2020 through March 2021
Una semana de contenido con +100 sesiones educativas, consultorios, +10 workshops Premium, Hackaton, EXPO, Networking Hall y mucho más!