Troubleshooting Rule HTTP Action Responses

When using the HTTP Action within SharpTools Rules, you might encounter a situation where you try to retrieve data from the response and things don't work as you expect. In this article, we'll cover some general troubleshooting you can do to better understand what’s happening with your HTTP Action.

For this example, we'll use an HTTP Request to get data from the Open Weather API which is a popular action we've seen commonly in the community. In this example, our rule makes an HTTP GET request to a URL and we want to store the daily[0].summary  value into a variable like the following:

Try URL in Browser

Since this is a simple HTTP GET request and doesn’t have any special headers, we can easily test it directly in our browser. Assuming your configured URL is the raw URL and doesn’t inject any SharpTools variables to complete the URL structure, take the URL you have listed as an HTTP GET and enter it directly into your browser.

In my example, I’m using FAKE  for the appid, so the query fails as expected with the following value:

The value of the value  attribute indicated by the arrow in my screenshot above is equivalent to $context.response.data . You can review the content of that value to better understand the structure of your response and adjust your variable property selection as needed.

Checking Logs

If my HTTP Request was a bit more complex, for example injecting variables or using headers, I could also check the SharpTools Rule Logs.

Sending Request

For example, if I was using variables in my URL, the first thing I would check is the “Sending HTTP Request…” log entry.

Keep in mind that you can tap the ‘view’ link on the right side of any log entry to view the details. In my case, the URL looks like I would expect it to. If you had injected variables to create your URL, this would be a good chance for you to be able to take the ‘final’ calculated URL and copy it into your browser for testing as noted above.

Request Response

For checking the request response, there’s a few different approaches we can take.

Existing Response

Since we're already trying to use a property like $context.response.data.xxx somewhere within our rule, we can find the relevant log entry that's using that variable, tap the ‘view’ link, then verify the content in the Runtime Data section.

In this particular case, the Runtime Data would likely not have a valid value set for the response (we'll see why later):

If you are using an expression and it is explicitly showing «expression evaluation error»  in the message, double check your expression. Feel free to post in the community if you need help with your expression syntax.

Temporary Variables

A good approach for testing HTTP responses is to temporarily add actions to your rule to save the raw response data and response status.

For example, I’m snapshotting the raw $context.response.data and separately snapshotting the $context.response.status (the numeric HTTP status code).

Then when I run the rule again, I can see the raw response body and code in my logs.

In my example, I can see that the HTTP Response code is a 401 which means the request is not properly authenticated.

Valid Execution

And if I ran the rule again with a valid Open Weather appid (token), I would see the raw response along with a 200 “OK” status code:

I could then drill into the ‘view’ next to the log-line which uses the raw $context.response.data  and scroll down to the Runtime Data section to better understand the structure of data being returned.

The value of the value  attribute indicated by the arrow in my screenshot above is equivalent to $context.response.data . You can review the content of that value to better understand the structure of your response and adjust your variable property selection as needed.