I always try to set up entity transformers in a way I can easily re-use/re-apply them. In some scenario’s I want to write the entities I’m processing to a storage within a transformer on the incoming configuration. In this case re-using the transformer is not possible because I need to selecte the storage using a dropdown.
Example:
Incoming: Get categories
Incoming: Get products
Let’s assume these objects/entities (category & product) have a very similar data structure. This allows me to create a transformer that I can re-use.
However, right now it’s not possible if I want to save the entities in the same transformer. Unless I will use a single storage for both categories and products which is not desirable.
Of course there is the possibility to create seperate transformers for saving to storages, but this would mean I need 3 transformers instead of 1.
It would be very nice to dynamically switch storages using conditional transformers or placeholders.
Thank you for sharing your use case—this is a very thoughtful approach to building reusable transformers, and we can see how being able to dynamically select storage would enhance flexibility and maintainability in your integrations.
As you mentioned, the current behavior of the Storage transformer in Alumio requires a static selection from the dropdown, which indeed limits the reusability of a transformer across multiple entity types when different storages are required.
Your idea of being able to dynamically switch storages using conditional logic or placeholders is a strong and valuable suggestion. At the moment, a possible workaround—as you noted—would be to separate the logic by using transformers for each entity-storage combination. While this adds some overhead, it maintains clarity and avoids conflicts in data storage destinations. Alternatively, you can use our Alumio API method to dynamically create/update the storage, see Alumio API.
For example, I want to post a new entity into storage called “foo-storage” and I want to save it to a storage entity with the identifier “itemA”. Then, you can use the Alumio API URL and Request body below to achieve that. URL : https://yourEnvironmentIdentifier.Alumio.com/api/v1/storage/entities/foo-storage/itemA Method : PUT Body : Is your Json content.
Please let us know whether using Alumio API can work as a workaround for your case.
That said, we agree that supporting dynamic storage selection—perhaps by allowing expressions or placeholder values in the Storage Writer configuration—would be a great enhancement. We’ll log this as a feature request with our product team for consideration in future updates.
Same for http clients. We have an integration which needs to send to 2 different endpoints. The routes can be the same except for the domain to send too. The outgoing contains multiple transformers which use the client. Right now we need to duplicate them all just for having different clients.
HTTP subscriber, transformer, and publisher already support them. This way, you can configure different domains (base URI) or authentication to call dynamically using placeholders.
Please let us know whether this can be a workaround.
Don’t thinks so, I’d still have to duplicate the transformer for assigning different baseurl and authentication. So i have to duplicate the transformer to use a different client or to add a plugin for baseurl and authentication to use.
That seems like a good solution indeed. A colleague of yours told me via support that there was no way to make the client dynamic. So we already duplicated al the necessary routes, with the biggest being over 60 transformers and other components, too bad
Hi @tommy It is actually correct that there is no way to make the client dynamic at the moment. The dynamic one is the HTTP plugins and authentications within the HTTP subscriber, transformer, or publisher.
Really sorry to hear you had to duplicate everything, especially with over 60 transformers and components involved. That sounds like a huge effort. Hopefully, this insight can help streamline things a bit going forward!
