Custom request
(released with 2.1.17)
Last updated
Was this helpful?
(released with 2.1.17)
Last updated
Was this helpful?
Typically an operation is bound to a projection (endpoint) and often also to a particular entity set in that projection.
Custom request is different in that it is not bound to any projection, meaning it can be used without first activating the projection/endpoint it eventually will communicate with. It will, however, communicate with a projection, but the way it does it is much more manual. You won't get much help from the connector setting up the machine step that uses the operation, but you also get more freedom to setup the operation how you want it to work. It can be a quicker way to setup an operation, but it is more advanced and does require a more experienced workflow designer.
The operation can be found under 'Global' at the top of the operation tree.
When selecting the operation you are presented with a rather empty UI. First thing you typically do is select what kind of operation you want to do.
Next you need a url, you can click on "Get base url" to get you started, but you will need to provide the rest of the url yourself. Chances are that you already got an url from some other source.
In the parameters section you can provide query parameters, such as $select, $top. You can also define path parameters by replacing parts of the url with for instance {parameterName}. Click on 'Refresh variables' to update variables.
There are two modes, either 'Query and path' where you can use both query and path parameters, but do not put path parameters inside of a query parameter. Or you can select 'Only path' where no query parameters are parsed, all parts (or the whole) url can be a path parameter.
You can also add any http header you want to send along with the request. Since 'If-Match' is common header in OData context, there is a designated button you can use to add that header.
In the body section you provide the data to send as body to url (if applicable depending on operation). Only JSON data is supported. To use Flow variables you use mustache syntax, example {{flowVariable}}. The double '{' and '}' is to not confuse with JSON data.
The body will be sent as provided, with Flow variables replaced, string replacements - meaning that if you want to send a string either the variable must contain quotation marks, or let them be part of the JSON (as in image above).
In the response section you can define what you are interested in from the response of the call. Only JSON data is supported, if you need to download binary data you must enable that projection and use the operation that downloads the binary data instead.
The structure of the result of the operation matches the corresponding regular operation if it can be determined (output of actions and functions might be hard to predict).
Status code and error messages are always provided, but you can decide whether to include headers and an entity descriptor (if applicable, i.e. Create operation).
You can specify what level of metadata you want from OData provider. With 'Full' being the most verbose and required if you do want an 'Entity descriptor'. 'Minimal' will provide an '@odata.etag' - which you might be interested in. If you just want 'raw' data - you can select 'None', which is the fastest option.
The response JSON data does not need to exactly match the response from the OData endpoint. If you are not interested in property 'X' - simply remove that row from the JSON data. It will still be provided by OData endpoint, but will not be sent by connector to Flow Server (and by extension not to the client either). The structure better match though.
