Skip to main content
Funcțiile logice rulează în sandbox în procese Node.js de scurtă durată — odată ce o rulare se termină, nimic din ce a fost păstrat în memorie nu supraviețuiește. Când ai nevoie să îți amintești ceva între rulări (să pui în cache un răspuns API costisitor, să stochezi un cursor pentru sincronizări incrementale, să aplici debounce sau să transmiți starea de la o funcție la alta), salvează-l în spațiul de stocare cheie-valoare integrat. Fiecare aplicație primește propriul spațiu de nume izolat: intrările sunt asociate cu aplicația autentificată, astfel încât cheile tale nu pot intra niciodată în coliziune cu — sau fi citite de — o altă aplicație.

Get, set, delete

Importați kv din twenty-sdk/logic-function. Valorile pot fi orice payload serializabil JSON.
src/logic-functions/sync-linear-issues.ts

Domenii de aplicare

Fiecare intrare are un domeniu de aplicare, transmis ca opțiune la fiecare apel. Valoarea implicită este WORKSPACE.
  • WORKSPACE (implicit) — intrarea este privată pentru instalarea curentă a workspace-ului aplicației tale. Fiecare workspace care instalează aplicația primește propriul set independent de chei. Aceasta este opțiunea potrivită pentru cache-uri, cursoare și stare specifică fiecărui workspace.
  • SERVER — intrarea este partajată între fiecare instalare a aplicației tale de pe server. Intrările de tip server se comportă ca niște claim-uri: valoarea stocată este întotdeauna workspaceId-ul care a revendicat cheia (omite value la set pentru a revendica cheia pentru workspace-ul curent), iar doar acel workspace o poate suprascrie sau șterge. Orice instalare poate citi intrarea.
Revendicările de server există pentru rutare între workspace-uri. Un server-route resolver rulează în workspace-ul proprietar al înregistrării aplicației, dar un webhook de intrare, de obicei, conține doar un id de cont extern — nu un Twenty workspaceId. Configurați fiecare workspace să își revendice ID-ul extern la momentul conectării, apoi rezolvați-l în rută:
Deoarece o cheie de tip server poate fi revendicată doar pentru propriul workspace al apelantului și nu poate fi niciodată suprascrisă de un altul, un workspace nu poate deturna o mapare care aparține altcuiva. kv.set aruncă o eroare atunci când cheia este deja revendicată de un alt workspace.

Folosește-l: păstrează în cache un apel costisitor

O utilizare tipică este păstrarea în cache a unui răspuns lent sau cu limitare de rată de la un terț, astfel încât rulările repetate să îl refolosească în loc să plătească costul de fiecare dată.
src/logic-functions/getExchangeRate.logic-function.ts

Tipare și sfaturi

  • Spații de nume. Prefixează cheile pentru a păstra domeniile diferite separate — sync-cursor:linear, cache:exchange-rate:USD:EUR, lock:nightly-report.
  • Expiry (TTL). Store-ul nu are expirare integrată. Stochează un timestamp în interiorul valorii (ca în exemplul de cache) și verifică-l la citire sau curăță cheile învechite dintr-o funcție declanșată de cron.
  • Ce să stochezi. Orice valoare serializabilă JSON — numere, stringuri, array-uri, obiecte. Păstrează intrările mici; acesta este pentru coordonare și caching, nu pentru blob-uri mari sau fișiere. Pentru fișiere, folosește un câmp FILES și uploadFile.
  • Vizibilitate. Intrările există în baza de date a instanței, nu ca înregistrări ale workspace-ului — nu apar niciodată în interfața workspace-ului, nu fac parte din modelul de date al aplicației tale și nu necesită permisiuni de rol sau de obiect.

Alternativă: un obiect de stocare interogabil

Spațiul de stocare integrat este, în mod deliberat, opac: intrările nu sunt înregistrări, astfel că nu le poți răsfoi în UI, nu le poți corela cu alte obiecte și nu le poți filtra cu interogări de înregistrări. Când ai nevoie de oricare dintre acestea — de exemplu un jurnal de sincronizare vizibil sau o stare per-înregistrare — definește în schimb un mic obiect tehnic cu un câmp key unic și un câmp RAW_JSON value, și interoghează-l prin clientul API tipizat. Vezi Objects pentru referința defineObject și Data → Unique indexes pentru aplicarea unicității cheilor.
  • Limitarea la o înregistrare. Adaugă o relație de la obiectul de stocare la obiectul țintă, în loc să codifici id-ul în cheie.
  • Vizibilitate și permisiuni. Rândurile trăiesc în baza de date a workspace-ului ca orice altă înregistrare, astfel încât pot fi interogate prin API și respectă rolul aplicației tale. Pentru a ține store-ul în afara UI-ului principal, nu îl include în navigation menu.
Spre deosebire de spațiul de stocare integrat, un obiect personalizat este întotdeauna limitat la un singur workspace — nu poate partaja intrări între instalări, așa cum fac cheile SERVER.