Couldn’t find anything on this in the docs… might have missed it… but are there plans to enable this in the near future?
Something like this would require to be able to define a Tulip endpoint to receive some data from a foreign source which would then trigger a workflow to parse the incoming data and e.g. create some table record based on this.
This could be a great way to interface with legacy ERP systems.
you can parse XML data through a connector host using Xpath syntax. So if you use that connector in an automation, the answer to your question is yes.
No, this would require me to actively trigger the request from some endpoint.
In the case I explained, I am not fetching from a remote endpoint but instead offer an endpoint from Tulip perspective to which some other software would then send the POST request. And finally, receiving this incoming POST request, would trigger an automation workflow to parse the incoming data and make sense of it.
You could post the data to a Tulip table using the table API. Then the creation of that record could begin an automation.
Also an option if there is a function in the automation trigger toolbox to parse the incoming JSON or XML… is there already?
Tulip has never been able to natively parse JSON. It always requires using a Connector function, a Custom Widget, or some extremely precise string parsing if your structure is consistent. I am sure that Pete and Pete from the product team are well aware of this and I would expect JSON parsing to be possible in Automations at some point. It might look something like the new UI when you map MQTT attributes. XML less likely.
Alternatively, if Custom Expressions ever become a thing… there are infinite possibilities. JSON, XML, SOAP, YAML, etc. And the Tulip ecosystem can grow exponentially instead of waiting for feature requests. Just my 2 cents.
Parsing, message mediation, message mapping is a key function in all automation solutions. Webhook also
In case someone is wondering about this as well… as of 13.11.2023 there is no such functionality.
Super interesting thread -
@sebme hit the nail on the head, right now we don’t support triggering an automation off an endpoint that customer can hit with a payload that is then handled downstream in the automation.
Calling an automation from some external system is something we are thinking about, but the current focus of the team is continuing to build out the core automations offering.
I see this as two primary asks:
- Allow the shape matching to happen within the automation, not on this endpoint - so I can pass it any payload and it will dynamically adjust to support its shape. This is not a pattern we support outside of connectors (and their parse interface). This is probably the bigger mental model shift that we need to seriously consider before implementing.
- Allow automations to be called from an api endpoint. The use case is clear here, its just a matter of having the capacity to get this to the top of the priority list.