Main advantages

// Application development

Application development for different business areas, tasks and projects

// Data Consolidation

Data from different IT-systems consolidated, aggregated and demonstrated on Dashboard Screen

// API and Integration hub

Conversion of different data into a single format and integration with any IT-systems

// Businesses process automation

Business process automation and adaptation, functional extension of internal IT-systems (master-systems)

// Development and Support

Development and maintenance performed by customer

Web interface

Web interface for each module consists of a number of screens. Every screen is a set of Parts, where Part is a widget - table, form, graph, tab control, tree control, picture gallery, rich text editor, etc. Parts layout based on screen grid is defined in the screen.

Each Part has to be referenced to a data source, where data source is a set of data obtained from Dolmen server. Usually data source is a table having been defined previously, though, sometimes it may be an API function, e.g. for graph Parts. Several Parts my be linked to one data source and show the same data differently

Demonstration of the platform interface

Chart and Task List Example on Screen

Task List Example on Screen

Tables Example on Dark Mode Screen

User access is defined for screens, data editing, screen buttons, etc.

Each screen item may be localized to the specific language using auto generated localization files

Coding examples

For example file test_main.json contains table description, where we can see several types of fields

f_string – string field, usage “name” means this field value will be a label for the record
fjnteger – integer field with default value = 1
f_enum – status field with two values “v1” (label “Label 1”, default value) and “v2” (label “Label 2”)
f_datetime, f_datetimemillis, f_plaindate – different date fields
f_ref_main – reference to test_main table (to the same table). All references by id, refDelete option (constraint) instructs Dolmen system what to do with source record when linked (target) record is going to be deleted
f_text – text field
f bool – boolean field
 "code": "test.reain",
 "fields": [
         "code": "f.string",
         "label": "String field",
         "usage": "name"
         "code": "f.integer",
         "label": "Integer field",
         "type": "integer",
         "value": "!"
         "code": "f.enure",
         "enura": [
                 "default": true,
                 "label": "Label 1",
                 "value": "vl"
                 "label": "Label 2",
                 "value": "v2"
         "code": "f_datetiree",
         "label": "Oatetiree field",
         "typ€": "datetiree"
         "code": "f_date"
         "code": "f_plaindate"
         "code": "f_ref_«ain",
         "ref": "vtest.reain",
         "refDelete": "erepty"
         "code": "f_text",
         "type": "text"
         "code": "f_bool",
         "type": "bool"
 "indexes": [
         "fields": [

These are sample language constructions which allow you to describe your own logic - java/kotlin code for

  • Buttons in the Ul
  • External communications
  • Abstract tables
  • Other needs


All functions declared in a Dolmen module class are API functions. After module installation they may be called from web interface, using standard API or from test web console.

// new object
var o1 = Test_Main()
ol.f_String = "new Object"

// edit object
var o2 = select(Test_Main(), RowID.get(101))
o2.f_Bool = false

// interate objects
for (i in tterote(Test_Main::class, filter: "f_string = 'ABC'")) {
   // interate subordinate objects
   for (j in iterete(Test_Main::class, filter: "f.ref.main = ${i .id}")) {
       // do something

// find first object by 'where' condition
var o3 = selectFirst(Test_Main::class, filter: "f.string = 'ABC'")