Albato Storage (Beta)

Albato Storage works as an action, meant to emulate capabilities of a storage unit.



The first group is "key counter". the actions allow you to add/increase/delete the counter in connection with a given key. if we consider the actions as applied to a bot, the ID of the user who wrote to us can be used as a key. before accessing AI, you can call the "get value" action, specifying the user as a key. in response, the storage will return how many times we have seen this user, or how many tokens he has spent (zero if he has not seen the user before). after AI has finished working, we can call the "add/update counter" action, giving the user's ID as a key, and as an increment - either 1 to count the number of hits from the user, or the number of used AI tokens for the token count limits. this will keep the counter in the storage for later triggers of the bindings.

Another option of using these actions in the bot is to limit not the total number of hits from the user, but daily ones. to do that you can use two fields as a key - user id + current date. In this case, each counter will not grow in terms of user, but in terms of user+date, thus zeroing out every day (no data on the key means that the counter=0).

Under the hood of this group of actions is a table with fields "key", "counter" and "lifetime". As a key can be any string up to 255 characters. as a counter - any number, which can be increased by adding any other. the lifetime is set in minutes, it removes the counter after a specified number of minutes from the last update. field is optional, if it is not specified, the counter will live forever.

The second group of actions is "storage of data by key". the credential describes the fields to be stored (similar to, for example, http-request). then, for each key in the action, you can fill all these fields and they will be stored in the storage. with other actions you can get/delete them. this is rather not for bot. case that came to my mind first - telephony, which sent a hook with details on the call, but without reference to the call record. We need to send to the CRM all call details together with the recording. You can configure in the repository the necessary fields of the call. from the first hook put into it all the call details and do nothing else. when hooking on the call record - get the call ID details, and send it to the CRM all together.

Under the hood of this group of actions - table with fields "key" and "JSON with data". as a key can be used any string up to 255 characters. as data - the fields specified in the Credential. life time was not added here, we will add later.

Both groups of actions are linked to the credentials. the credentials share different counters/stores. i.e. by specifying different credentials in different actions we can store different data for the same keys. so far no limits have been applied to the storage size - this is a matter still under consideration/development.

This documentation is a brief explanation of use cases for Albato Storage. The document will be updated in the future.

Updated on: 03/06/2023