Suppress Workflow Header Information while sending back HTTP Response in a Flow | Power Automate

May 16, 2021 priyeshwagh777 Power Automate http request in flow, http request power automate, http response, http response in flow, http response power automate, Power Automate, suppress header information

Let’s see how we can suppress critical information about the Flow to the caller HTTP Application while sending back a response.

Scenario

The Flow will send Header information back while sending a HTTP Response to the caller HTTP Request.

Here’s how the Flow will look –

Note, that we are sending a Custom Header along as well.
And along with this info, the follow Header information will also be visible in the calling application. We’ll use Postman to check this scenario.

You’ll see that a lot of Headers have been sent back along with our Custom Header.

And you’ll see whole lot of Headers that expose the Flow details in these Headers.

Let’s see how we can cut this information short and not send back any unnecessary information to the HTTP Request we’ve received.

Suppress Workflow Headers in HTTP Request

Let’s see how with a simple tweat, we can avoid sending the Workflow Header information back as HTTP Response.

We go to the Settings of the HTTP Request Trigger itself as shown below –
Now, you see the option, Suppress Workflow Headers, it will be OFF by default.

Your turn it ON,
Now, let’s try to make a call again and see the difference. Going back to the Postman, we Send another request post you’ve saved the workflow changes above.

We see that only 10 Headers are sent as opposed to 24 as seen without suppressing the info.
And if we see what Headers are sent back, we see along with our Custom Header, only the ones which are required will be sent suppressing all the critical information.

This is a good practice to suppress Workflows that don’t give out information in production scenarios which are not required by end application.

I’ve also made a quick YouTube video of the same. Check it out as well –

Hope this was useful!

Here are some more Power Automate / Flow posts you might want to check –

Asynchronous HTTP Response from a Flow | Power Automate

March 22, 2021March 23, 2021 priyeshwagh777 Power Automate asynchronous http request, asynchronous http response, asynchronous http response in a flow, http request, http request in flow, http response

By default, whenever yo submit an HTTP Request to a Flow, your application will wait till the request is completed. Meaning, the HTTP Response by default in a Cloud Flow is Synchronous.

So, let’s see how you can make it Asynchronous and how you can later retrieve the status of the HTTP Request itself from the Flow. If you make a HTTP Response as Asynchronous, the calling HTTP Request application will receive a 202 Accepted in response.

HTTP Request by Default

Let us see how the HTTP Request and Response is structured by default.

Here’ s the HTTP Request which will receive the request and process the data further.
And let’s assume you some lengthy process involved in your Flow which is making an average execution time span to a significant time. To mimic that, I’ve simply introduced a delay of 3 minutes to demonstrate the Async example.

In case you want to review how to pause a Workflow using Delay and Delay Until, you can check this post – Pause a Flow using Delay and Delay Until | Power Automate
And finally, assuming my execution of the Flow has completed and I’m supposed to send the Response back to the HTTP Request calling application, I’ll use the Response Action from the Request connector
}
And my Response will look something like this letting the caller application know that the processing has been successfully completed.

Now let’s see how this calling application will behave in this case. Assuming, we haven’t manipulated any settings as yet.

The Flow looks like this just to give you a visual perspective of the implementation.
Now, Once I send a Request from Postman, the Postman itself will be waiting for a response till the execution of the Flow is completed.
This is because the Flow itself is waiting to be processed and yet to reach the Response block in the Flow.

Asynchronous Response

We will now turn on the Asynchronous Response of the HTTP Response Action –

Go to Settings on the Response action step.
In Settings, turn on Asynchronous Response On and save it.
As mentioned in the description of the Asynchronous Response setting, the caller Application will immediately get a 202 Accepted code upon sending the HTTP Request.
Notice the Headers, you’ll see a Location header item
Capture this URL in your calling application as you can use it to check the status of the Request later on once the operation is completed on the Flow.

Checking Request Status

Since we have the Location information which was passed on from to the Response Header previously, we can use the URL to check the Response Status separately by making another call to the URL itself.

If the Status is still Running, you’ll get this response. It will imply that the Flow is still Running and the Response is not available yet.
Else, you’ll get the actual Response which was supposed to be received had the Flow’s HTTP Response was set to Synchronous by default (Asynchronous Response = OFF)

Hope this was helpful!

I’ve added a YouTube Video for the same. You can alternatively, check the same as well –

Here are some more Power Automate / Flow posts you might want to check –

Thank you!!

Validate JSON Schema for HTTP Request trigger in a Flow and send Response | Power Automate

March 20, 2021March 20, 2021 priyeshwagh777 Power Automate cloud flows, http request in flow, http response, http trigger in a flow, Power Automate

In a Cloud Flow, if you are using an HTTP Request Trigger that accepts HTTP Requests – you have the option to validate the Incoming data based on the Schema of the JSON.

Scenario

Let’s assume this is the data which will be passed to the HTTP Request Flow –

HTTP Request & Schema

Let’s look at the HTTP Request Trigger itself in a Cloud Flow –

First, let’s initiate the HTTP Request Trigger here and make sure we generate the Schema from the same data we will be passing. I also have a separate post on the HTTP Request itself which you can check here – Accept HTTP Requests in a Flow and send Response back | Power Automate
Here, we can paste the sample data which we saw in the scenario above.
Once you click Done, the Schema will be generated from the sample data you’ve just entered. Additionally, if needed you can also specify the method you are looking to implement. POST in this case
Further on, I’m doing some operations internally and finally, I’ll be sending a response to the caller using the HTTP Response Action in HTTP connector in a Cloud Flow
And here is what I’m sending back in Response if my Flow happens to work as expected.
So, the end of my Flow looks something like this. (Depending on what you are trying to do in your Flow)

Turning Validation On

Now, coming back to the HTTP Request trigger itself –

Go to Settings on the HTTP Trigger itself –
Now, look for Schema Validation option and turn it on.

Now, let’s consider the scenario and test the Postman.

Testing with Postman – Validation On

Let’s try to send incorrect data to the Flow using Postman which doesn’t comply with the Schema and see how we receive the 400 Error message in Postman

Now, when I try to send the correct data as expected by the Schema once the validation is turned on, I’ll get a success message once the Flow has finished running and return with a 200 code
Now, if we try to send incorrect data, it will not be accepted. So first, I’ll add a new attribute which I’ve not added in the schema already in order for the validation to fail and give us an expected validation error.
See the data which I’m sending. To which, I get the 400 Bad Request error
If you get back a 400 Bad Request, the Flow will not register it as a Flow Run. Hence, you won’t know if the Flow was hit or not.
And in case the validation is turned OFF, you’ll get the Response as expected from the Flow in the event that Flow has completed successful execution.