The Sclable Core Engine as of platform version 2.0 has been re-written from scratch. For two main reasons: first, to have a less monolithic architecture and second, to allow developers to extend the Sclable core.
At the same time we added some new features we’d like to introduce. Read on to learn how Sclable 2.0 adds more performance and security to your applications and lets you utilize events and triggers.
This one must go to the beginning of this post: The main challenge before the rewrite was the varying performance for agenda filtered views of an entity. Even though we aimed one step further to filter on an attribute level, we wanted to increase performance. We solved that issue by tying the Sclable user management to the PostgreSQL user management. Instead of primarily operating with filter functions, Sclable uses real views, thus allowing PostgreSQL to plan the execution of the query more efficiently and increase the performance.
With tying the user management to the PostgreSQL roles, the Sclable Core Engine is secured down to the data level. The users are not only logged into the application, but into the database as well with the very same privileges. Hence the users have the same level of access on every architectural level of the Sclable Business Application Development Platform.
Event and Trigger System
The event and trigger system introduced with version 2.0 allows you to extend the Sclable SQL core with additional functionality by simply hooking SQL functions into events and triggers. This reveals a world of great possibilities from process automation to arbitrary business rules.
Sclables Core Engine architecture has been redesigned to collect features in modules. Every module is stacked on top of the modules it depends on, just like layers of an onion. From the domain modelling point of view, the Sclable Core Engine modules belong to the domain «Sclable» and can be read and understood just like any business domain modelled with Sclable, thus being a good example of how to structure a domain.
System, Event and Builder
The minimal core consists of the system module containing domain, module, entity and attribute information and logic. Followed by the event module, needed to execute the appropriate actions upon changes to the instances of entities in the system module. Those actions reside within the builder module.
Data Integrity Modules
‘rule’, ‘restriction’ and ‘path’ are the next Sclable core modules in the hierarchy. It’s all about data integrity. ‘rules’ are regular expressions and operators applied to attributes. The ‘restriction’ module describes uniqueness and requiredness of attributes and handles references between entities. The module ‘paths’ chains references to more complex relations such as ‘customer’ → ‘city’ → ‘country’.
To give a better description and control to the behaviour of references, we introduce reference types. In a relation of ‘order line’ → ‘order’, the type would be ‘cascade’ (which is the default), allowing to remove all order lines of an order when the order is deleted. While this is a good thing to keep the order lines entity clean, it would be catastrophic removing all customers for a city when it gets deleted. By describing such a relation as ‘restricted’, a city can’t be deleted as long as there are customers pointing to that city. ‘decouple’ will leave instances with the former reference set to NULL and ‘delegate’ will force users to point to an instance to be referenced, replacing the former reference.
Workflows with Action Triggers
Workflows became a system module of it’s own to describe the lifecycle of an instance of an entity. One of the most important new features with workflows are action triggers. action triggers allow you to execute functions on the database before and after a specific action has been executed on an entity. They present the ability of a more fine grained hooking than a trigger on the entity itself which is executed on every change.
Delegation with data filters on attribute level
One of the top onion layers of the Sclable Core Engine is the delegation module, responsible for authentication and authorization. Sclable 2.0 implements an authorization down to the attribute level: Users have access only to the attributes of an entity they are allowed to read by the actions they are allowed to perform.
A new Action Binding Concept
In Addition to this, Sclable has a new action binding concept as of 2.0. Take a Sclable based CRM for example: A user is responsible for customers in Germany and Austria. The entity customer has a relation to the entity city, which is related to the country. The agenda ‘key-account-manager’ allows to execute the edit action on customers bound via the city to a country. When assigning the user to this agenda, we select the countries Germany and Austria to grant access to all customers in these countries.
Selections were introduced in version 1.0 as an extension to the core. Selections represent a set of values from attributes or calculated/aggregated attributes throughout a defined relational path. In version 2.0 we decided to give them more importance by adding them as a core module. They now integrate well with the authorization concepts of the delegation module.
Last but not least, we refactored (and simplified) Sclable’s built in data dictionaries. Translations can be activated for attributes since 2.0. Translations then are stored by entity, language and instance, thus reducing the amount of queries to translate an entire instance dramatically.
Recap and upcoming features
With its rewrite, the Sclable core is ready for our proposed roadmap. The onion architecture allows developing and releasing of feature packs every quarter as well as the maintenance of legacy versions. Amongst things we already queued for the upcoming version 2.1 are re-written calculated attributes along with a concept for aggregated attributes, both available within your selections. Keep an eye on our roadmap to stay up to date!