Low-code projection databases
Introduction: What is a Low-Code projection database?
Low-code projection database (Eximee Registry) is an internal mechanism of the Eximee platform that allows storing and transferring data between different instances of the same application or between multiple separate low-code applications. It works like a shared information clipboard, which a low-coder can independently manage from Eximee Designer using simple scripts (ScriptCode).
What is this mechanism used for?
This tool was created so that applications built in low-code can easily share knowledge about current matters without the need to create heavy, developer-oriented backend integrations. Thanks to this, the low-code layer gains full independence in managing the state of its processes.
In practice, a low-coder uses the projection database to:
Aggregating context split across many cases: Storing relationships between different low-code applications, for example a list of loans currently being applied for under the client's PESEL number
Addressing incoming data: Storing pairs external identifier:internal identifier that allow you to optimally find the case to which an event from Kafka or MQ should be passed
What do projection databases give Low-Coders?
The most important benefits that projection databases give Low-Coders:
No need to involve programmers: As a Low-Coder, you can independently save data outside the context of a single application, fully managing the data structure.
Fast access to data: From Low-Code, you can quickly find the data set you need. You have full control over the search key.
Isolation and dedicated scope: Thanks to dividing projection databases into namespaces (namespace) you can work comfortably without affecting other teams. You can share namespaces to exchange information with other applications, but you do not have to.
How to use the Projection Database in ScriptCode?
Access to the projection database (Eximee Registry) is provided directly from each ScriptCode script run in the context of a form (e.g. in validators, page services, EntryService or ExitService), at the level of handling automatic process tasks or Kafka/MQ event consumers. You perform all operations using the built-in interface api.registry
Last updated
Was this helpful?
