Powerapps This Operation Is Being Provisioned. Please Try Again in a Few Minutes.
Recently I've built a custom connector for Microsoft Menstruation. Here are a few things I wish the documentation was clearer almost.
Procedure automation for the masses
Microsoft Flow is one of the latest additions to the Office 365 suite. It allows users to build powerful automation scenarios for their work processes. Using Microsoft Flow, they can for example easily manage their e-mail attachments, go notifications when a sure event occurs or share information with their colleagues with a single printing of a button. There are tens of connectors and hundreds of templates for users to choose from. And the best part of information technology all is, that using Microsoft Flow doesn't crave programming skills, which makes information technology a very appealing tool for not-developer audiences. Just there is more.
The existent value of Microsoft Menses
When yous start using Microsoft Flow, y'all tin choose of tens of first and tertiary party connectors and templates Microsoft made available for yous to build your flows. Using what's available out of the box, y'all will be able to automate mundane tasks in your every twenty-four hours's piece of work and spend your free energy on what truly matters. Only using the standard connectors will take you but that far. To truly benefit of the value that Microsoft Flow offers, you should consider building connectors for the applications your system uses.
Microsoft Flow custom connectors
Microsoft Flow connectors allow you to use applications bachelor in your organization in your flows. Some connectors give y'all admission to applications provided by Microsoft, such as SharePoint or Outlook. There are likewise connectors that permit y'all to integrate third party applications such as Slack or Twitter. But you lot tin can as well build custom connectors for line of business organisation applications managed by your organization.
Microsoft Flow connectors are not code. While they are a chip more circuitous to build than flows, they still don't crave programming skills. All you need to know, is how the APIs of the application that y'all want to integrate in Microsoft Flow await like, which you should be able to go from the application'south documentation. To put it differently: Microsoft Flow connectors tell Microsoft Flow what APIs are there, and which requests and responses they support. Connectors are cipher but metadata for your applications. The actual logic and data processing remains in your application.
What yous should know most building connectors for Microsoft Flow
Recently, I've congenital a Microsoft Flow connector that allows you to analyze the quality of your SharePoint applications. And while there is some documentation on how to build Flow connectors, information technology didn't quite reply all my questions.
Getting started
When you lot get-go building a connector, y'all have three options. You can either import an existing Swagger definition of your API, import a Postman collection or start from scratch and define the deportment and triggers manually.
In fact, in that location are 4 options:
- Import Postman drove (and add missing information manually)
- Import existing Swagger definition (and add together missing information manually)
- Build Swagger definition including Microsoft Flow metadata and import it in Microsoft Flow
- Build the connector directly in Microsoft Period
If you happen to have an existing Swagger definition for your API, it will give you a head start for creating a Flow connector, but near likely, you volition demand to add some information manually afterwards importing it to Flow. Flow uses custom API properties, such as x-ms-visibility which controls the visibility of your properties in the Microsoft Flow editor, and which most likely your existing Swagger definition won't have. You can either add these properties to your existing Swagger definition or you can configure them in Microsoft Flow after importing your Swagger definition. Having the custom properties in your Swagger definition gives you the benefit of having all information in 1 place, but depending how you create the Swagger definition, it might or might non be possible.
Building Swagger isn't always picayune. While in that location are some editors that give you feedback whenever something isn't correct, information technology's all based on the JSON schema of a Swagger file, which isn't always clear about what is incorrect exactly. The skilful news is, that you can create the connector in Microsoft Flow, and once it'south working, yous can export it to a Swagger file with everything you configured. If you don't accept Swagger definition for your API, yous should definitely export your connector and store it somewhere safety in case something changes and you lot need to restore it to its previous state.
Can't rename the connector
When creating a Microsoft Catamenia connector, one thing you lot should exist certain of, is its proper name. Once you lot create a connector, you can't rename information technology. The simply way to modify its proper name, is to remove it and recreate it from scratch with the new proper noun, breaking all existing flows in consequence. The good news is, that y'all can recreate the connector either using the existing Swagger definition or by exporting the connector to a Swagger file, but still you volition need to reconfigure all flows using that connector.
When choosing a proper name for your connector, keep in heed, that at any time you tin add new deportment and triggers and the connector'south name should be generic enough to arrange them. Typically it will be the name of your application for which you're building the connector.
More info...
When I started building my connector, one thing that I totally missed, was the fact, that each of my request parameters was actually a push allowing me to edit its details.
When you click the push button, a context menu appears, allowing you to edit properties of the particular property, which is necessary in case you lot want to change its data type or visibility in the Flow editor.
Processing binary file contents
Ane of the most ambiguous things I've come across, was how to become the contents of a binary file correctly in my API. When you build a flow using for example Outlook and OneDrive and clarify its execution, y'all'll find the contents of the binary file passed between the deportment as every bit a base64-encoded string. But when your API specifies 1 of its request parameters as a string, y'all will get the raw binary data instead, resulting in a cleaved payload.
It turns out, that in society to go the contents of a binary file encoded as a base64 string in your connector, the asking parameter which will hold the data has to be marked as Type: string, Format: binary.
In Swagger information technology looks like this:
{ // ... "properties" : { "file" : { "title" : "File contents" , "type" : "string" , "format" : "binary" } } } Your API will then receive a payload with a file property (following the example higher up, but you lot are gratis to choose any name for the property) which by itself will be a JSON object that looks as follows:
{ "file" : { "$content-type" : "awarding/octet-stream" , "$content" : "UEsDBAoAAAAAAEthx0wAAAAAAAAAAAAAAAAG..." } } The $content-type property specifies the mime-type of the file. The $content property contains the base64-encoded contents of the binary file. This is how Microsoft Flow will deliver the contents of a binary file to your API. If your API expects annihilation else, you will need to adjust it to support a request in this format.
Asynchronous connectors
When your API gets chosen from Microsoft Period, it should return a response instantaneously or at least equally quickly as possible. Just what if your application needs to perform a long-running operation?
Microsoft Flow supports the notion of an async functioning. If your API requires some time to complete the activeness, when called, it should render a 202 Accepted response. Along with the response, it should return two headers: location and retry-later on. The retry-after header specifies the number of seconds that Microsoft Menses should wait before checking if the long-running performance completed. The location header, specifies the URL that Microsoft Flow should call to check if the long-running performance completed or non. If it did, that URL should return a 200 OK response. If the operation is still in progress, once over again the API should return a 202 Accepted response with the location and retry-subsequently headers.
Permit's take a await at a sample sequence of requests to an API that performs a long-running operation. At outset, y'all issue a POST asking to trigger the operation:
Mail https://api.contoso.com/v1/long-running-performance content-type: application/json { "property1": "value1", "property2": "value2" } The API accepts the request and starts the long-running operation in the background:
202 Accepted location: https://api.contoso.com/v1/status?id=ABC retry-subsequently: 10 Subsequently waiting for ten seconds, as specified in the retry-later on response header, your API is called again to cheque if the job completed:
GET https://api.contoso.com/v1/status?id=ABC As the job is still in progress, the API once again responds with a 202 Accepted response:
202 Accepted location: https://api.contoso.com/v1/condition?id=ABC retry-after: 10 Afterward waiting for some other 10 seconds, your API is called again.
Get https://api.contoso.com/v1/status?id=ABC This time, the job is completed, and then the API returns a 200 OK response along with the job consequence.
200 OK content-blazon: application/json { "resultProperty": "resultValue" } What'due south impressive about this approach is, that it allows y'all to easily implement long-running operations in your API without troubling the user edifice a menses with your connector. As long every bit your API returns a 202 Accustomed response, the flow volition exist stopped on your connector. Equally soon as your API returns a 200 OK response, the flow volition proceed. And Microsoft Flow will handle all of that past itself, without the user having to exercise anything.
When async connectors piece of work, they're nothing curt of magic. But they tin become pretty inconvenient when they don't. It's hard to debug them in case they don't work as expected. After your flow failed, only the commencement asking and the concluding response are visible in the debug information. The calls in-between, responsible for checking if the long-running operation completed, are not visible in Microsoft Flow and tin can be traced only through your API'south logs.
It's calling something, but not your API
When y'all're edifice a Microsoft Period connector, at some point you volition want to examination it. When you lot practice, you lot might notice, that Microsoft Flow isn't calling your API directly. Instead it calls a proxy, which then calls your API. In the network tools of your spider web browser you will observe a URL similar to following:
https://europe-001.azure-apim.net/apim/contoso.5f0d59cdcc07448e52.5fb0d954e02c19715b/shared-contoso.5f0d5-7dad6eca-cb38-412e-9790-4811a2225196/api/operation The proxy is registered when you relieve the connector for the outset time. Typically, things work as expected, and y'all don't demand to worry about it. But sometimes, when you update the connector to reflect some changes in your API, it might have a moment for the changes to be propagated to the proxy. As a outcome, fifty-fifty though you have just updated the connector, for a while Microsoft Flow will proceed using its previous version which volition likely crusade errors when calling the updated API. Unfortunately, there isn't much yous tin can do near it, other than wait a few minutes.
Sharing the connector in your arrangement
When y'all build a custom connector, information technology tin can be used only by yourself at start. When yous're fix, yous tin can easily share it with others in your system. Y'all can either choose specific individuals, groups or the whole organization. Sharing a custom connector with others is straight-forward and doesn't require any formal procedure to be followed.
If you lot're using Microsoft Menstruum on a gratis program, each user can create merely one custom connector. So if your organisation needs multiple connectors, you either have to switch to a paid plan or distribute the custom connectors over multiple users.
Summary
Through custom connectors for Microsoft Flow yous tin can empower your users to automate using applications in your organization. The process of edifice a connector isn't circuitous. Except for a few details, the Flow documentation is good enough to get you lot started, assuming you have a documentation of your application's API. With custom connectors y'all will be able to truly benefit of using Microsoft Flow in your system.
Source: https://blog.mastykarz.nl/what-know-building-microsoft-flow-custom-connectors/
Postar um comentário for "Powerapps This Operation Is Being Provisioned. Please Try Again in a Few Minutes."