How to use mustache code to parse event value into Response Template

Cloud Integrations
1

I now know that hook-response events may undergo several retries to get to my device and if I have two webhook calls within 20 seconds it is possible for the hook-responses to arrive at my device in any order. When my handler on the device receives hook-response data I’d like it to be able to determine which webhook invocation it corresponds to. (This is a simplified example and the idea of creating two identical webhooks with different names will not work in production for me.)

My thought on how to do this is to include a different random string in each webhook call I make. I have not found a good way to include just that random string in my webhook response. (I have no control over the remote system in production so I can’t pass this value through that service.)

My simple example below is asking a remote system if a particular personNumber is authorized. The service returns an allow/disallow in JSON.

Example published event data to webhook:

{
"personNumber":123,
"txdID":454678,
}

The server might return

{
"result":"allow"
}

My webhook response Template would be:

{{PARTICLE_EVENT_VALUE}} 
result: {{result}}

With this I could find the txnID and know that a response was for a specific webhook invocation. However, I have to return all of the event data in the response. I was hoping to use mustache code to trim this down. This is what I tried but it does not work.

{{#PARTICLE_EVENT_VALUE}} 
   txnID: {{txnID}}
{{/PARTICLE_EVENT_VALUE}}
result: {{result}}

I think this fails because PARTICLE_EVENT_VALUE is not a JSON list. But perhaps there is some subtlety here that I don’t understand? Or another way to parse the event value JSON in the response template? I am not a master of mustache code.

(The actual response templates that I use generate formatted data that is more easily parsable on the device, but this example is pared down to just show the issue I’m trying to address. So thanks for thinking about ways to format the response better, but that isn’t the issue here.)

2

Talking about this more, we thought that one way may be to append a one-up value to the end of each event we publish to fire off a web hook. If our webhook is getAuth, then we would publish getAuth_1 the first time; getAuth_2 the second time, etc. In our cloud callback routine we’d parse this value from the Event Name and correlate the response with the appropriate request.

3

Not quite. Even if PARTICLE_EVENT_VALUE is a JSON string, the main issue is that nothing of the incoming event data is passed to the response side unless its relayed by the remote server (publish -> webhook request -> remote server -> webhook response -> subscription) there are no short-cuts from one stage to another bypassing any in between stages (apart from "self-subscribing" to the event).
Data that gets dropped between two stages will be gone for good.

Although such a feature was requested a long time ago, Particle hasn't picked up on it so far :wink:

BTW, pity that your remote side doesn't offer a feature like "nonce exchange".

4

I don’t think that’s true anymore. If I add {{PARTICLE_EVENT_VALUE}} to the Response Template then I do get back the data that was in the published event. My event data is JSON so I was hoping I could parse it with the mustache code.

5

Hmm, I’d have to double check.
I had performed some tests before posting and in these tests the behaviour was as it was expected from past experience - maybe confirmation bias :blush:

6

I think you’re both right, sort of.

The initial event variables like {{PARTICLE_EVENT_VALUE}} are available to the hook-response template.

However, only the response body from the server handling the webhook body is JSON parsed and available is separate variables to the hook-response template.

Thus, even though the initial request body is sort of visible, it’s not available as mustache variables in the response template, because the assumption is that you’re interested in parsing the response from the web server, not the original request.

7

Thanks for the clarification. That helps a lot.