HTTP POST Connector Function Input Datetime data type not available in JSON Request Body

1

I’m trying to use an HTTP POST to push some data to a Highbyte webhook including the time stamp.

In the Input area you can select Datetime as the data type (to be passed from the app completion data), but when I go to create the Request body in JSON, there’s not a compatible data type.

My recommendation would be to autoconvert to two possible scenarios, for Text, keep the time stamp in RFC 3999 or if Integer is chosen, convert to milliseconds from Epoch.

2

Have you same issue with plain text option (instead of JSON output UI)?

We also connected Tulip to HB. Can you share your use case? What kind of actions you want to trigger from Tulip apps?

3

No, would prefer to keep it as JSON but I can test plain text.

Right now I’m only testing as we’re only trialing HB, my current use case is to capture manual day by hour data that operators log using a simple Tulip app.

4

:joy:

So I changed to plain text and now I see what you mean, it’s still really JSON without all the manual mapping.

1 Like
5

So I’m trying plain text but it’s not clear to me how to substitute the variables. It doesn’t appear to be well documented so at random I tried @ and noticed it gave me a quick pick for the variables, but when I tried to test I got 500 Internal Server Error instead of 200.

{
    "timeStamp": "@timeStamp",
    "operator": "@operator",
    "stationName": "@stationName",
    "partCount": @partCount,
    "productionOrder": @productionOrder,
    "rejectCount": @rejectCount,
    "shiftID": "@shiftID",
    "redStamp": @redStamp
}
6

Hey @Richard-SNN -

You’re super close here. I will make a note to get the documentation improved around this:

{
    "timeStamp": "$timeStamp$",
    "operator": "$operator$",
    "stationName": "$stationName$",
    "partCount": $partCount$,
    "productionOrder": $productionOrder$,
    "rejectCount": $rejectCount$,
    "shiftID": "$shiftID$",
    "redStamp": $redStamp$
}

In regards to your original question, the underlying reason the json formatter doesn’t allow datetimes as a variable type, is because the json format inherently doesn’t have a datatime type:

What this means in practice is each API takes datetime on text fields, and it is up to the users on both end to agree on a format for that date information. ISO8601 is the most common standard I have run across, but there are others. Tulip enabling this as a json datatype would mean either we would need to build a mechanism for you to choose the date format, or we would need to just pick a single standard, which would limit compatibility.

Pete

1 Like
7

That got it. Thanks Pete!

Looks like I got my wires a little crossed, but there are a lot of standards out there. Looks like RFC3999 is a subset of ISO8601 so we were mostly talking the same thing.

I still think my idea has merit.

Allow use of either Text or Integer in the JSON mapping where Text would keep the Tulip style date time and just convert to text (which is what happens with Plain Text) and for Integer, convert to Unix style milliseconds from epoch.

8

Use expression editor function in output mapping can help. We always need messaging mapping and it is better to make it in an connector rather than apps

9

The concept of centralized converting into whatever protocol the other system uses on the connector level, not on the app level is a meaningful architecture difference.

It strikes me that one solution to this problem would just be to allow expressions to be used in the json builder, as long as their output matches a datatype that json does support. So you could pass the connector a datetime object (be that app info.current date and time or something else) and the conversion would be happening on the connector level, not the app level.

I will write up a feature request for this gap and work with the engineering side to see what their thoughts on approaches to this are.

Pete

1 Like