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.

Postgres Performance Comparison from versions 7.4 to 9.4. One of the reasons why Sclable uses PostgreSQL is because of its continuous performance improvement. With the new Sclable Core 2.0 we are getting more out of the PostgreSQL community’s endeavours. Image: "PostgreSQL Addict"

Postgres Performance Comparison from versions 7.4 to 9.4. One of the reasons why Sclable uses PostgreSQL is because of its continuous performance improvement. With the new Sclable Core 2.0 we are getting more out of the PostgreSQL community’s endeavours.
Image: PostgreSQL Addict

Higher Performance

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.

Higher Security

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.

Onion Architecture

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.

Sclable Core Entities. This Graph shows the dependencies of the entities of the Sclable core domain grouped by modules. An interactive version "can be found here". Image: "Sclable"

Sclable Core Entities. This Graph shows the dependencies of the entities of the Sclable core domain grouped by modules. An interactive version can be found here. Image: Sclable

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’.

Reference Types

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.

Sclable Selection use case example. This image shows a simple use case for Sclables concept of “Selections”: For the display of chosen manufacturers from a business domain only the name of the company along with the latitude and the longitude of that company’s city is needed. It is a simple task of click-selecting attributes along a chosen relational path. The Sclable Core Engine automatically writes the appropriate SQL join statements for the auto-generated database view which ultimately is filtered by the user’s scope. Image: "Sclable"

Sclable Selection use case example.
This image shows a simple use case for Sclables concept of “Selections”: For the display of chosen manufacturers from a business domain only the name of the company along with the latitude and the longitude of that company’s city is needed. It is a simple task of click-selecting attributes along a chosen relational path. The Sclable Core Engine automatically writes the appropriate SQL join statements for the auto-generated database view which ultimately is filtered by the user’s scope. Image: Sclable

 

Selections

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.

Internationalization

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!