Skip to content

Storages

A storage in Alumio is a component that allows you to store and manage data within the platform. It serves as a repository for data that can be utilized in various integration processes.

Under the hood, a storage in Alumio is in fact a filesystem. The storage itself is the directory, and the entities within the storage are its files. This means that an entity saved into a storage can only have one identifier. Let's say you want to store a product, then the SKU or Product ID would be a logical identifier for the entity you'd store. Note that it is - in practice, although in limited use-cases it can be done - not possible to 'search' within a storage. You can only retrieve the Storage Entity by utilizing the exact identifier.

The Storage itself has limited configuration options:

  • Automatic Pruning: by specifying a TTL (Time-To-Live), storage entities can be automatically 'cleaned'. This can be very useful when you only need to 'cache' data to optimize performance of an integration.
  • Log Actions: you can decide to log any changes to storage entities. This will impact performance, so use wisely. Mostly this should be off, unless debugging or when the entities are incredibly important.

Storages can be utilized in routes in several ways:

  • Get By ID: this Entity Transformer takes the specific Storage, the Identifier, and the requested path to place the data as arguments. It will return the storage entity if it can find it, and return nothing (not null, nothing) when it has no data to return.
  • Save By ID: this Entity Transformer takes the specific Storage, the Identifier, and the path to retrieve the data as arguments.
  • Storage Subscriber: utilizing this, you can create an Incoming which reads through all (foreach) entities within a storage. This allows creation of for example queues.
  • All From Storage Subscriber: this does not foreach through all storage entities, but retrieves it in one full list. Do not use for very large datasets.

Storages allow Alumio to create much more complex integrations. For example, you can create 'reminder' or time-based processes, just by saving the entity the last time it came through and then reading it from storage at a later moment (and checking the timestamp). This also allows 'caching' to optimize the performance of integrations.