cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
AndyBradford
Regular Visitor

Cloud Flow: HTTP Request trigger yielding blank dynamic content variables

I am using this flow to take a JSON input from a form website, parse it into variables, feed variables into a Sharepoint list, and some other things.

 

I used a sample request to generate a JSON schema. This generates a large number of Dynamic Content variables. When I put these variables into an email, then every single one turns up blank. I created a string variable to hold the entire "body" variable (Initialize Variable) and fed it to the email action alongside individual variables, and it comes up with a full JSON entry. Somehow, "body" has content, but none of its components have content.

 

AndyBradford_0-1668722783905.png

 

Here's the schema:

 

 

{
  "type": "object",
  "properties": {
    "headers": {
      "type": "object",
      "properties": {
        "Expect": {
          "type": "string"
        },
        "Host": {
          "type": "string"
        },
        "User-Agent": {
          "type": "string"
        },
        "X-Requested-With": {
          "type": "string"
        },
        "Content-Length": {
          "type": "string"
        },
        "Content-Type": {
          "type": "string"
        }
      }
    },
    "body": {
      "type": "object",
      "properties": {
        "Form": {
          "type": "object",
          "properties": {
            "Id": {
              "type": "string"
            },
            "InternalName": {
              "type": "string"
            },
            "Name": {
              "type": "string"
            }
          }
        },
        "$version": {
          "type": "integer"
        },
        "$etag": {
          "type": "string"
        },
        "Submitted": {
          "type": "string"
        },
        "DateWorkBegins": {
          "type": "string"
        },
        "DateWorkEnds": {
          "type": "string"
        },
        "RoadName": {
          "type": "string"
        },
        "RoadDistrict": {
          "type": "string"
        },
        "RoadStatus": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "Parameters": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "Location": {
          "type": "string"
        },
        "Reason": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "Impact": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "CommentsNotesOrOtherInformation": {},
        "DispatchInformation": {},
        "SubmittedBy": {
          "type": "object",
          "properties": {
            "First": {
              "type": "string"
            },
            "FirstAndLast": {
              "type": "string"
            },
            "Last": {
              "type": "string"
            },
            "Middle": {},
            "MiddleInitial": {},
            "Prefix": {},
            "Suffix": {}
          }
        },
        "PhoneIfReporterIsNotACountyEmployee": {},
        "Latitude": {},
        "Longitude": {},
        "SubmittersEmailAddress": {
          "type": "string"
        },
        "Entry": {
          "type": "object",
          "properties": {
            "AdminLink": {
              "type": "string"
            },
            "DateCreated": {
              "type": "string"
            },
            "DateSubmitted": {
              "type": "string"
            },
            "DateUpdated": {
              "type": "string"
            },
            "IsBeta": {
              "type": "boolean"
            },
            "LastPageViewed": {},
            "Number": {
              "type": "integer"
            },
            "Order": {},
            "Origin": {
              "type": "object",
              "properties": {
                "City": {},
                "CountryCode": {},
                "IpAddress": {
                  "type": "string"
                },
                "IsImported": {
                  "type": "boolean"
                },
                "Region": {},
                "Timezone": {},
                "UserAgent": {
                  "type": "string"
                }
              }
            },
            "Timestamp": {
              "type": "string"
            },
            "Version": {
              "type": "integer"
            },
            "Action": {
              "type": "string"
            },
            "Role": {
              "type": "string"
            },
            "Status": {
              "type": "string"
            },
            "PublicLink": {
              "type": "string"
            },
            "InternalLink": {
              "type": "string"
            },
            "ReviewerLink": {
              "type": "string"
            },
            "Document1": {
              "type": "string"
            },
            "Document2": {
              "type": "string"
            }
          }
        },
        "Id": {
          "type": "string"
        },
        "Latitude_IncrementBy": {
          "type": "integer"
        },
        "Longitude_IncrementBy": {
          "type": "integer"
        }
      }
    }
  }
}

 

 

Here's a redacted version of a HTTP request that experienced this behavior.

 

{
    "headers": {
        "Connection": "Keep-Alive",
        "Expect": "100-continue",
        "Host": "hostname",
        "User-Agent": "CognitoForms",
        "X-Requested-With": "XMLHttpRequest",
        "Content-Length": "2963",
        "Content-Type": "application/json"
    },
    "body": {
        "Form": {
            "Id": "992",
            "InternalName": "entry",
            "Name": "entry"
        },
        "$version": 8,
        "$etag": "W/\"datetime'2022-11-17T18%3A38%3A33.7459312Z'\"",
        "Submitted": "2022-11-17",
        "DateWorkBegins": "2022-11-18",
        "DateWorkEnds": "2022-11-18",
        "RoadName": "testing ln",
        "RoadDistrict": "North",
        "RoadStatus": [
            "Closed"
        ],
        "Parameters": [
            "near"
        ],
        "Location": "welp st",
        "Reason": [
            "Tree down, no wires involved (not IW)"
        ],
        "Impact": [
            "Road closed - Use detour or other alternate routes"
        ],
        "CommentsNotesOrOtherInformation": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.",
        "DispatchInformation": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.",
        "SubmittedBy": {
            "First": null,
            "FirstAndLast": " ",
            "Last": null,
            "Middle": null,
            "MiddleInitial": null,
            "Prefix": null,
            "Suffix": null
        },
        "PhoneIfReporterIsNotACountyEmployee": null,
        "Latitude": null,
        "Longitude": null,
        "SubmittersEmailAddress": null,
        "Entry": {
            "AdminLink": "url",
            "DateCreated": "2022-11-17T18:38:33.512Z",
            "DateSubmitted": "2022-11-17T18:38:33.512Z",
            "DateUpdated": "2022-11-17T18:38:33.512Z",
            "IsBeta": false,
            "LastPageViewed": null,
            "Number": 3,
            "Order": null,
            "Origin": {
                "City": null,
                "CountryCode": null,
                "IpAddress": "dot.dot.dot.dot",
                "IsImported": false,
                "Region": null,
                "Timezone": null,
                "UserAgent": "agent"
            },
            "Timestamp": "2022-11-17T18:38:33.512Z",
            "Version": 1,
            "Action": "Submit",
            "Role": "Public",
            "Status": "Submitted",
            "PublicLink": "url",
            "InternalLink": "url",
            "ReviewerLink": "url",
            "Document1": "url",
            "Document2": "url"
        },
        "Id": "992-3",
        "Latitude_IncrementBy": 1,
        "Longitude_IncrementBy": 1
    }
}

 

 

When I've used HTTP Requests from other websites to trigger flows, they've been fine and the variables haven't been null. The Parse JSON action, given either the blank schema or the full request as a sample to generate a schema from, gives the same results - "body" is full, but any component is empty and null.

 

What can be happening? What am I doing wrong to produce this result? How do I get actual variables out of the HTTP Requests? 

1 ACCEPTED SOLUTION

Accepted Solutions
Nic-AF
Frequent Visitor

OK I managed to solve my problem which was the same as OP's: the variables generated by the "When a HTTP request is received" action are all blank, the body variable is not.

 

I had to add a "Parse JSON" action after the "When a HTTP.." action.  The content to parse would be the "body" from the "When a HTTP.." action.  So basically I'm parsing the body twice.  Like this:

NicAF_0-1669243479401.png

The Schema in the Parse JSON is generated using a sample body.

Then the "Parse JSON" action also generates variables, but these variables are not blank.

 

 

Ranting: It was 3 hours of frustration.  Power Automate is powerful, but I find that I often come across problems that are confusing and very time consuming to resolve.  I may not be a JSON expert, but I don't understand why I have to do the above to make it work.  The flow used to work without the Parse JSON, but once I generated a schema from a new version sample, the problem began.  Not sure if there's something in the JSON that the flow doesn't like.  Besides, when I was trying different things in the flow in attempt to fix this, doing one thing suddenly made it work, but then doing the same thing again no longer worked.  The Undo button broke my flow once and somehow made actions parallel.  I had never made parallel actions in this flow.  And, shouldn't it be "When an HTTP" instead of "When a HTTP"?  Sorry for the rant.

View solution in original post

6 REPLIES 6
ChristianAbata
Super User
Super User

@AndyBradford  mmmm, I'll suggest use compose and add the body response propertie inside. Then use that compose output to pass it to parse json.



Did I answer your question? Please consider to Mark
my post as a solution! to guide others :winking_face:

Proud to be a Flownaut!


If you want you can follow me at www.christianabata.com Quieres contenido en español? Síguenos en Power Automate LA

Tried putting Compose in, and same behavior. The Compose input and output are identical.

Nic-AF
Frequent Visitor

I'm facing the exact same issue and I have no clue so far.  If you managed to solve this, please let me know.  Thanks.

Nic-AF
Frequent Visitor

OK I managed to solve my problem which was the same as OP's: the variables generated by the "When a HTTP request is received" action are all blank, the body variable is not.

 

I had to add a "Parse JSON" action after the "When a HTTP.." action.  The content to parse would be the "body" from the "When a HTTP.." action.  So basically I'm parsing the body twice.  Like this:

NicAF_0-1669243479401.png

The Schema in the Parse JSON is generated using a sample body.

Then the "Parse JSON" action also generates variables, but these variables are not blank.

 

 

Ranting: It was 3 hours of frustration.  Power Automate is powerful, but I find that I often come across problems that are confusing and very time consuming to resolve.  I may not be a JSON expert, but I don't understand why I have to do the above to make it work.  The flow used to work without the Parse JSON, but once I generated a schema from a new version sample, the problem began.  Not sure if there's something in the JSON that the flow doesn't like.  Besides, when I was trying different things in the flow in attempt to fix this, doing one thing suddenly made it work, but then doing the same thing again no longer worked.  The Undo button broke my flow once and somehow made actions parallel.  I had never made parallel actions in this flow.  And, shouldn't it be "When an HTTP" instead of "When a HTTP"?  Sorry for the rant.

This worked. I share your annoyance. I've built other HTTP-Request-ingesting flows and this is the first time I've needed to use a Parse JSON box to make a flow work. 

goetz
Frequent Visitor

I was excited when I found this post, already started to think it is me... unfortunately, in my case the body is empty. I can put the headers in the parse json, if I add the body it fails. If I add the body to a compose function it is empty.

 

Is there something I am missing? I have other flows that are setup the same that work fine.

 

goetz_0-1673453293119.png

goetz_1-1673453321649.png

 

Helpful resources

Announcements
Power Automate News & Announcements

Power Automate News & Announcements

Keep up to date with current events and community announcements in the Power Automate community.

Community Calls Conversations

Community Calls Conversations

A great place where you can stay up to date with community calls and interact with the speakers.

Power Automate Community Blog

Power Automate Community Blog

Check out the latest Community Blog from the community!

Top Solution Authors
Users online (2,301)