Axional Studio is a multi-tenant Model–view–controller development framework specifically designed to build large scale enterprise applications.

Multi-tenancy means that a single instance of the software and the entire supporting infrastructure serves multiple customers. Each customer shares the software application and also shares a single database (or database infrastructure). The data is tagged in the database as belonging to one customer or another, and the software is smart enough to know to whom the data belongs to.qwre

In contrast, classical applications are Single tenancy, which means managing a single instance of the software and the entire supporting infrastructure serves only a single customer. With single tenancy, each customer has its own independent database and instance of the software. With this option, there’s essentially no sharing going on. Everyone has his own perimeter, separated from anyone else.

Model–view–controller (MVC) is a software architectural pattern for implementing user interfaces on computers. It divides a given application into three interconnected parts in order to separate internal representations of information from the ways that information is presented to and accepted from the user.

Multi-tenancy is mainly hidden from developers and should only be considered for database design. In contrasts Model–view–controller approach is open to programmers so they can interact with the MVC application framework.

The following sections will provide a step-by-step guide to the process of Axional Studio development.

1 Metadata

Axional Studio relies on metadata to describe an application. A database dictionary is a group of tables that stores the metadata of an application. Every logical database object that Axional exposes is internally managed using metadata. Objects, (tables in traditional relational database parlance), fields, stored procedures, and database triggers are all abstract constructs that exist as metadata.

This metadata will be used to create database structures and database business logic at least once for each target database for a given application dictionary.
During runtime, the application description metadata will be used to materialize application views, forms or reports.

Every server looks for configuration description in it's configuration database. This database holds the links between users, applications, databases and dictionaries.

User is validated to users list.
User options and available databases are loaded.
As user selects to run an application on a target database (from it's available list of db resources), associated metadata it's loaded and application is materialized.

For historical reasons database dictionaries names are prefixed by wic_. You should be familiar with the following database names.

Database	Description
wic	It's the development dictionary that includes data structure definitions and application forms to build and application.
wic_conf	Stores the configuration of a cluster of servers, users, databases, dictionaries, etc..
wic_admin	It's an application dictionary of `wic` nature. Describes wic_conf application.

2 Database modeling

According to the MVC paradigm we need first to have a model. So we can use the database dictionary to define the application model. As application has at least a database side and a server side, metadata can be split in two parts:

Database metadata, that defines all database tables and objects including database side business logic (Functions, Stored Procedures or Triggers).
Server metadata, that defines application objects like menus, forms, reports and server side business logic (Transaction handlers and Scripts).

2.1 Database metadata

Before starting an application you require a database model. It may be an existing one or a new one. In any case, Axional Studio provides tools for modeling the database, to keep track of changes and more important: to ensure proper deployment of database schema and business logic on any target database running the specified application.

Database schema definition (DDL) including tables, indexes, foreign keys.
Database business logic including stored procedures, functions and triggers.
Database logical aspects like field names, default values, field validation rules, include lists, data helpers.

A large enterprise application can have thousands of objects including tables, procedures, triggers, foreign keys, etc. Handling it manually it's impossible. Axional Studio provides tools to check database status against it's model definition an automatic reconditioning procedures. To make this option available you must use Axional Studio database modeling features.

2.2 Server side metadata

A set of database dictionary tables store server side application definition including:

Menus, to allow user navigation across application options.
Forms, to allow data entry and data visualization.
Reports of different types including business operational reports, page perfect reports and pixel perfect reports.
Business logic process like sending and e-mail or perform complex calculations.
Dashboards, to group complex data visualization.

Notice you will write application by parts and will not have a compilation unit. Application code is materialized on demand and will run on any Axional Studio server in the application cluster.

2.3 Target database

Using the database model, stored in a dictionary you can create one or many target databases. A target database can be used for development, test or production environments but if they run the same application, then they have the same application dictionary associated.

To setup a target database you need to connect as manager and setup it inside the wic_conf:

Register the database object in wic_dbms_objects.
Register at least an administrator user to access it, in the wic_dbms_users table.
TO DO
This section is incomplete and will be concluded as soon as possible.

Next lines provide a sample configuration to run an application called app1 on two databases named test_db1 and prod_db1. The server will at least need the following databases.

Database	Type	Dictionary	Description
wic_conf	CONFIG	wic_admin	This is the configuration database. It does not hold any program. It holds descriptions of users, databases, dictionaries, etc. So it holds a table like this.
wic_admin	CONFIG	wic	It's a metadata dictionary that describes configuration application. So it's dictionary it's `wic`.
wic	DEV	wic	`wic` is the database that stores development tools. It's self referenced
wic_app1	DEV	wic	This is the database dictionary where application will be stored. As it's an application dictionary, its programs are defined in `wic` dictionary.
test_db1	DATA	wic_app1	This is a test database using metadata from `wic_app1`
prod_db1	DATA	wic_app1	This is a production database using metadata from `wic_app1`

3 Views and controllers

As seen before, the development of a web application will be guided through a database named dictionary. This database will give programmers a multiuser structured repository for all application code.

After having defined a model, we can start the development of its views.

3.1 DDL Data Definition Language

All database applications relay on SQL language to perform queries or transactions. Axional includes an XSQL/DDL language that allows users to write database independent SQL operation. Writing SQL operations using XSQL/DDL has great advantages like those described for database modeling but also adds the possibility to use security injection.

3.2 Security

Axional Studio provides a feature named security injection that allows isolating application logic from security. The security injection defines entities with selected table access restrictions. Then, these entities are applied to users.

During application runtime and when any query is materialized, each XSQL/DDL statement used will be injected with the appropriate security restrictions.

Development guide