PowerApps is quite nice and very useful. But we (and I imagine others) have needs to use custom APIs to pull in functinality from several sources within our organization. Currently there is no option to update a custom API Swagger....the only way is to delete it and start over. This does not work for us as we probbaly will have the custom API in several Apps and Flows. Deleting the cutom API requires that we go around and re-do all the connections in all the apps and the flows that we used it!!! A little frustrating to say the least. Please provide a way to update the Swagger definotion for an existing connection. Regards, Khaled Hikmat
... View more
Submitted on08-27-201809:02 AMSubmitted bymheberton08-27-201809:02 AM
OpenApi v2.0 supports message polymorphism using the discriminator property (search “discriminator” in the specification : https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md). This allows to correctly define REST operation where the schema of the message (request and/or reply) varies based on the value of a specified attribute. In the specification example, the message contains a “petType” attribute that can either be “cat” or “dog”. In each case, the content of the message is adjusted for attributes needed for one or the other type, in addition to shared attributes. Our company used many REST services leveraging discriminator to limit the number of operations. However, PowerApps does not currently support this. As a workaround, we must create OpenApi specification files for each variations of the operation content and create a separate connector for each of them. Some operations have as many as 20 variations. Using the same example as in the specification, we could have a single “save” REST operation that can save either cat or dog records, but we need to create two OpenApi files and the corresponding connectors: SaveCat and SaveDog. The correct OpenApi definition for this service should have a single “save” operation and use discriminator on the petType attribute to describe the message schema for each type. In PowerApps, each operation of a service is exposed as a method of the connection, I understand that the validation of the request content in PowerApps as well as the type definition of the reply are based on this method (operation). I suggest that when discriminator is used, then the operation id (eg “save” in our example) be suffixed by the discriminator value to create a series of methods (“save_cat” and “save_dog” in our example) thus allowing correct validation and type definition. This change will reduce (by a factor of about fifteen for our company) the numbers of connectors we need.
... View more