Native ERP translation service

Tulip does not yet seem to offer any automated data import capability which would allow it to receive data, manipulate/interpret this data and write it into its known tables following some logic.

Example: Legacy SAP systems which send IDOC XMLs.

More concrete example: Receiving a Process Order via IDOC from SAP which then needs to be translated into multiple Tulip Tables, e.g. Order, Operation, Input Materials table.

This necessitates another middleware service in between, either on SAP side or as part of some 3rd party custom middleware which takes care of the translation.

SAP → Middleware → Tulip Table API calls.

This creates quite a few challenges, also in terms of data integrity. In the example mentioned above, the middleware layer would right now need to send independent Tulip Table API requests to write/edit data in the Tulip tables as needed. If there is a need to split the data between multiple tables, there is no guarantee that the operation finishes as expected.

Having an internal translation service would allow to ensure that the incoming message has been received in full and that the necessary translation actions have been performed on the platform as required.

May I ask, how are other customers dealing with this challenge right now? Maybe it is a particular problem of legacy ERP installation as you are unable to fetch ERP data on-demand. But there are surely still a lot of these system out there.

In my compagny, we have build a layer of REST API on top of SAP with SAP Gateway

Hey @sebme -

There is a bunch of work going on right now to extend how triggers work, and how they can be leveraged more extensively throughout the product. One of the gaps we hope to fill with this work is precisely what you are talking about, enabling the ability to create a shim between external data sources (like a connector) and apps/tables/etc.

This work will start landing towards the end of the year but will continue into the first half of 2023 as we expand the scope of possible.

Pete.