Transactional API endpoint for creating multiple Tulip table records in different tables as a single unit operation

Product Suggestions
1

Are there any intentions to implement a transactional API endpoint for creating multiple Tulip table records in multiple different tables as a single operation that can either succeed or fail? On failure the expectation would be to immediate rollback any of the changes that were made up to the point of where the record creation process failed.

2

This seems oddly specific… although I have definitely had to write scripts to do similar things in the past. Maybe we should start by asking for the ability to even do batch api processing?

Still no way to do more than 1 record at a time for create, update, or delete.

These building blocks would make it easier to achieve what you are describing.

3

I don’t think so at all :wink:

Let me explain why: I am requesting this to have a reliable way how to push data into the Tulip platform that spans over multiple tables, where each of those entries represents a critical input describing a single order. At present it is impossible to achieve a reliable handover of such data. And this is really a shame because it creates a lot of issues.

At present you are left with two options:

  1. Interpreting the order “on-platform” which essentially means handling the record creation inside an app that first pulls data from the foreign system (e.g. the ERP) and then creates the necessary records one by one. If the interpretation on the client goes south - which essentially is what happens under the hood - , so does the order interpretation and the data that is stored. This can easily happen if the network is not 100% stable. Furthermore, if there is more than a single record that needs to be created in a table you have to use a custom widget to do the looping. On top of that it needs a manual intervention by running the app first.

  2. You send individual requests via some form of middleware to the Table API. They all get filled - or not filled - individually. There is no guaranteed data integrity at this point. If you need this because your apps require the full set of data to be available to function properly, you have to somehow build logic in an app to do that pre-testing. We are working around this at the moment, by creating a final “all-is-good” record in a helper table to signal that the communication was successful. This record will only be created IF all other parts were receiving OK messages from the Tulip API when creating those records.

Neither solution is particular pretty because in the event of a failure somewhere in the chain, you end up with rubbish in the platform that is difficult if not impossible to weed out later down the road.