This is a nice solution to the problem of dynamic schema, but I encountered interesting obstacles on this endeavor of implementing x-ms-dynamic-schema into the Swagger… The first problem was the fact that there is currently a small bug where the Flow Designer will only recognize a dynamic schema call if the referenced function is a GET method (this actively being fixed). This allows Flow to get the schema during editing a flow instead of running a flow and allows the reference boxes to be populated in later condition or action cards. Now while editing a Flow if this custom API is used, the Flow Designer should recognize that there is dynamic schema definition and call the function attached to the definition. This extension allows a definition in the Swagger to have the property “x-ms-dynamic-schema” which also entails referencing a function that will dynamically populate the schema. The team developed a Swagger Extension: “x-ms-dynamic-schema”. Luckily, the team had encountered this issue while integrating services like SQL Server, Excel, Sharepoint. It was to inconvenient to use, which defeats the objective of Flow when we want people to “Work less, do more”. My first implementation although functional was completely useless to an end-user unless they have clairvoyance and l33t webdev skills. This means the Table is dynamic in nature. The response object is a “table” derived from a specific query It’s impossible to know the number and names of the columns that will be in the table, or the type of information each column is represented by until the query is actually executed. The main problem is the response from the query. This looked great and returned the correct results…īut unfortunately the Flow designer could not inherently create the reference boxes that make it extremely simple for an end user to reference data from a previous card like so: The Swagger contained all the necessary information including the security definitions (AAD in this case), a single well-defined “POST” call, and explicit definitions for the request object to the backend as well as the response object (JSON Objects in this case). The first iteration was trivial to produce: That is, a flow should just be able to query given a cluster name, database name, and query string and receive tabular results. The objective of adding this API is deceivingly simple: we just wanted to allow users to be able to include a Query to the backend in one of their flows. This originally detailed writing a Swagger for it and grabbing an icon off of a Power Point. I was tasked with creating a “connector” for it (Adding a Custom API, and Integrating it with PowerApps and Flow). It is a “Disruptive Technology for Log Search and Analytics”.
#Swagger editor edit save location how to#
Some modifications using Microsoft specific Swagger extensions may be necessary to fully integrate a Custom API with Flow.Ī more in-depth guide to creating and registering a custom API with PowerApps can be found in this Custom API Tutorial, as well as more specifics about how to Customize your Swagger definition for PowerApps and Flow Creating a Custom API for Application analyticsĪpplication analytics is a relatively new service that Microsoft publicized, although it’s been used for a while internally at Microsoft.
#Swagger editor edit save location download#
Personally, it was much easier for me to use YAML and download it as JSON.Ī section labeled securityDefinitions needs to be included in the Swagger. Conveniently, the Swagger Web Editor allows you to download a Swagger as YAML or JSON. The main things to note regarding integration with Microsoft Flow: The Swagger can be written in JSON or YAML, but Microsoft Flow and PowerApps requires a JSON file. More information, a Web Editor, and examples of Swaggers from companies like Spotify, Uber, Slack, and Rackspace can be found at Swagger.io.
0 kommentar(er)
