Routing rules - Payload for POST


#1

Is it possible to POST the entire content of Details (JSON string presented on the Data Logs Details tab) to a destination URL as JSON content using a routing rule?

An example of what I have for details…

{
“received”: “2016-05-12T11:34:02.909323”,
“authtype”: “otp”,
“tags”: [
SOCKETAPI”,
SIMPLESTRING”,
DEVICE_37599
],
“routingResults”: {
“matchedRules”: 1,
“errors”: []
},
“device_name”: “Unnamed Device (11111)”,
“errorcode”: 0,
“source”: “8944501006151403831”,
“timestamp”: “4277”,
“record_id”: “7446b006-1835-11e6-bd8e-bc764e208873”,
“data”: “MTY1TTJ8MTEzMzU2fC0zNy43NzgzfDE0NS4xMjQ4fDExOA==”,
“device_id”: 11111
}


Recommended Temperature Sensor Tutorials
#2

Yeah, if you do a webhook rule that payload is what gets posted by default.


#3

Thanks - but I’m still having trouble understanding the data format I should expect.
From some experimentation (and previous discussions on this board) I can get the Data content by using ?field=<< decdata >> but not the whole JSON detail. I also noticed << data >> with give non decoded data (makes sense…)
Some additional documentation in this area would be really useful - but in lieu of that is there any chance I could get a sample of a full HTTP request that Konekt would invoke from the Advanced Webhook Builder?

Hope this is OK - I’ll update with some further things I’ve found in the hope it is of use to others searching this forum (these could well be documented elsewhere - but I’ve missed it in my searching)

The variables to use in the URL post match directly with the fields from the Details tab of the Data Logs;
So additional URL parameters along the lines of ?deviceId=<< device_id >>&received=<< received >>&deviceName=<< device_name >>&recordId=<< record_id >>&data=<< data >> will post all the associated field data.
In addition there is a special variable << decdata >> which is a decode of the Base64 encoded << data >> field.

I’m yet to get an of this to work as a payload (as opposed to URL parameters) - so any advice / samples / documentation on this would be appreciated.

Another edit - Looks like << record_id >> (and << recordid >> and << record >>) aren’t valid variables.


#4

I am looking for the same information. I have a site that I created with a Web api for accepting HTTP Post. I have been testing my site/APi using fiddler. In fiddler, I enter the URL of my site like:
http://testsite/api/ControllerName,
Then in the fiddler body I paste the JSON that has been generated by my Dash. This works great, but when I enter that same URL in a Konekt custom webhook URL Routing rule. Nothing is received on my site.

Thanks.


#5

Sounds similar to me. I’ve got mine posting to a generic API controller which just dumps into Azure table store for further processing / presenting etc.
I’ve been using fiddler in the same way. It definitely does work when you use the variables and url parameters, but I’ve had no luck to date with the data coming through in the body of the post (I’ve tried using form data and just JSON)


#6

We definitely need to document this better. Also, it looks like you guys found a bug. If you leave the payload field blank in the rule, it’s supposed to send the full payload, but it looks like that’s not working.

However, you can send the full dump of cloud data by putting _ALL_ in the payload field. This will do a form encoded request where the payload field is the JSON that you’re looking for.


#7

P.S. Right now the record_id and id aren’t included in the output at all when processing a rule. If you guys would like it, we can restructure some stuff to add it. I can see there being some value in that.


#8

Excellent - the ALL does the trick.Thanks.
I didn’t have any particular plans for using record_id - but could see this being very useful for some integration models.

It looks like when using ALL the variables in the URL parameters don’t get replaced with values (except for UserId) - eg. this is what is actually recieved - ?deviceId=<< device_id >>&received=<< received >>&deviceName=<< device_name >>&data=<< decdata >>", “payload_is_json”: true, “user_id”: 1384, “hook_payload”: "ALL"
I’ve got no plans to use both URL params and Payload (now that I know about ALL - but thought I’d mention it in case this was an unexpected result.)


#9

So this is what I have in my routing rule.
I only added the ALL this morning based on this post, but it doesn’t appear to be working. Right now the only way I’m checking is I should have new records in my SQL table when something is posted.


#10

Your probably not catering for it being form encoded.
You mentioned you’re using Fiddler to test. To replicate, in the composer, in the top section add this directly under the Content-Length line
Content-Type: application/x-www-form-urlencoded
In the request body put payload=" and then copy paste in your content from the Detail Tab of the Data Content page in Konekt Dashboard.
Finish it off with a closing " and hit execute. I’m fairly sure this will replicate what you get from the Routing in Konekt.


#11

This sounds very likely. I appreciate the response. Unfortunately I won’t get a chance to test for a while, but I have a feeling you’ve put me on the right track.

Thanks.


#12

This has been a really helpful thread for us. We’ll definitely fix the issue with variable replacement not happening in the URL in _ALL_ mode. We’re also going to make the system a little more flexible and add the ability to insert the top-level elements into the payload.


#13

I had a chance to test this. If I encode the message as suggested by ajandar, using fiddler, I get all Nulls in my web api controller on my site, which I’m assuming means I’ve replicated what is happening from Konekt.
I also assume then, (confirming what ajandar suggested) that I need my site to handle form url encoded content in order to receive the payload?


#14

Yeah, if you’re using the _ALL_ payload then it sends everything as form encoded. One easy way to test this stuff is to use http://requestb.in/
It basically lets you spin up an endpoint that you can post data to and see the exact format of the data.


#15

OK, I will try that. Is the other option sending the payload as URL parameters?


#16

When you say payload, do mean the entire thing that @ajandar posted in the OP or just the exact data you’re sending?
If you only want your data, then you can stick <<decdata>> in the URL parameters or in the POST payload.
If you want the entire thing, the only way to do that right now is with _ALL_ in the POST payload, but we’ll be adding a way to do that in the URL soon.


#17

did we get any further with documentation.
sorry to hijack the thread


#18

I only know how to use SerialCloud.println() to send simple strings. What can I do to change the tag from “SIMPLESTRING” to something else? I want to use different re-route rules for different things that I send to Hologram Cloud, but right now I don’t know how to differentiate them. Thanks.


#19

@juipin tag management as you described will be coming in our 1.0 firmware update. I do not have an exact date for when it will drop but I do know we are very close. :tada:


#20

Thanks @benstr. That’s a good news, as long as the wait time is not too long. I actually want to selectively send SMS. Perhaps, you can give me some pointer as to how to make the device send SMS to several phones directly. I understand that in this mode, each SMS message will cost me $0.19, and multiplying by the number of phones to send to.But at least I can use it to solve 2 problems. This second problem I am referring to is that the SMS do not often get sent out immediately from the Hologram Cloud. Just today, several of the messages were sent only 2 to 3 hours later. My application is to detect the temperature of a battery charging station and to send SMS to alert people when it gets too hot.

Do you think this delayed transmission of SMS from the Cloud will be resolved, or anyway to workaround it? Thanks.