The applications are developed on a multitier architecture, which physically separates the functions on three tiers:

• Presentation tier
• Middle tier: business logic processing
• Data tier: data management

Loading...

digraph E { node [fontsize=12 fontname="Verdana"]; rankdir=LR; graph [fontsize=14, fontname="Verdana", compound=true]; edge [color=black dir=both]; UI [shape=box, style="filled", color="#673AB7", label=" Client Side JS ", fontcolor="white"; width=1.3; height=0.5]; DataM [shape=box, style="filled", color="#00BCD4", label=" XSQL ", fontcolor="white"]; Axional [shape=box, style="filled", color="#FF4081", label=" XSQLScript - ServerSide JS ", fontcolor="white"]; Pres [shape=none, label=" PRESENTATION TIER "]; Midd [shape=none, label=" MIDDLE TIER "]; Data [shape=none, label=" DATA TIER "]; Pres -> Midd -> Data subgraph cluster_1 { Midd Axional; } subgraph cluster_2{ Pres; UI; } subgraph cluster_3{ DataM; Data; } }

This is the tier that the user sees, presents the system to the user, communicates the information and captures the user's information. This layer communicates only with the middle tier.

In Axional Studio, the presentation tier is mostly made based on parameterization via objects. However, the system allows minor modifications through Client Side Java Script programming.

• For further information on Objects definition, see section JRepObjects.
• For further information on Client Side Java Script, see Client Side JS section in Languages references.

This is the tier where the programs that are running reside, the user's requests are received and the responses are sent after the process. This is where all the rules that must be followed are established. This tier communicates with the presentation layer, to receive the requests and present the results, and with the data tier, to request the database manager to store or retrieve data from it. Application programs are also considered here.

When application needs to write code in the middle tier (neither the database backend, nor the user agent front-end), a procedural language can be used. Axional Studio provides a full featured scripting language called XSQL Script.

The XSQL Script:

• It is a XML based interpreted language.
• It includes a full set of control instructions and more than 200 built-in functions.

Axional Studio application server can also execute scripts in Server Side Java Script language. Those scripts are stored in the wic_dbscripts_js entity, and can be invoked from any statement within the Axional Studio framework...such as Form Buttons, SQL-Tables, etc.

For further information, see XSQL-Scripts and Server Side Java Script.

Because it is not necessary to compile these codes, Axional Studio has the option to edit them in Buffer mode pressing the Buffer mode button. During buffer mode, the program can be modified and saved several times without the need to document the delta. Use Buffer revert button to discard changes or Buffer commit button to accept them. After commit is performed, it is mandatory to document delta.

It defines a function or routine in xsql-script syntax. The xsql-script developing executable database-independent procedural code both in the back-end, in a Java UDR or in the middle-tier (webStudio applicaciton servers). The implementation is originally based on concepts detailed in XEXPR ( A Scripting Language For XML ).

Most of the business logic implemented in Axional Studio is executed on the Database Server (BD). Webstudio XSQL-Script runs on the application server, and can interact with:

• BD Servers : Running SQL statements.
• Email servers: sending emails.
• Print Servers : submitting documents for printing.
• Web Servers: using web pages.
• FTP Servers: transferring files.
• SOAP Servers: Call functions.

Webstudio XSQL-Script lets you interact with databases (via JDBC), by including it in the code, from SQL in XML grammar ( XSQL ). The labels corresponding to this type of statements are exceptionally transformed into the native database management system syntax. This transformation is performed using the XSL (eXtended Stylesheet Language). For more information on the syntax see XSQL-Scripts

From a function or routine xsql-script you can include code programmed in the repository of XSQL Script includes, normally used to particularize part of the program and also for conditional code. For further information on includes, see XSQL Script includes.

• Code*: XSQL-Script name.
• Description: explanatory text of the function functionality. For example from where it is called, parameters, etc...
• Locked indicator: only the user who has locked the record has permission to edit. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record.
• Script*: XSQL-Script code.
• Project and Notes: it is recommended to use these fields to document this function.
• Call flow tab: it is a graphical representation of the function's workflow. It is based on the use of various symbols to represent specific operations. Use Call Flow button to create it.
• Imported tab: a graphic representation of the calls to functions or procedures that are called from the current routine is displayed. This representation is recursive, that is, it begins with a red rhombus on the first level that represents the current function. In the second level, as many nodes appear as routines are invoked from the function itself, being presented as red rhombuses if they are functions or yellow ellipses if they consist of procedures. And so forth, until terminal nodes that represent routines that do not contain calls are reached. Use Graph imported button to create it.
• Graph exported tab: graphic representation of routines that call to this script. Use Graph exported button to create it.
• Generate delta button: creates a new delta record that allows documenting changes.
• Buffer edition/revert/commit buttons: initiates, reverts changes or performs changes of buffer edition mode.

In addition to scripts in xsql, Axional studio allows the creation of scripts using java script, through the JS Code and JS lib forms. The main purposes of executing JavaScript syntax for business logic are:

• Powerful dynamic language
• Incredibly fast engines
• Consistent language for Client/Server applications
• Popularity (Many Libraries and Documentation)
• Unit testing

This form allows you to define a function or routine in JS Code syntax. JS Code allows developing database-independent procedural code, which runs on the middle-tier (webStudio servers).

• Code*: JS script name.

  IMPORTANT

  The code of the register must match the JS function name.

• Description: recommended explanatory text of the script functionality. For example from where it is called, parameters, etc...
• Locked indicator: only the user who has locked the record has permission to edit. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record.
• Script*: JS script code.

  IMPORTANT

  It is possible to define several local functions within a single register, but these local functions must always be defined within the global function.
• Project and Comments: it is recommended to use these fields to document this function.
• Call flow tab: it is a graphical representation of the function's workflow. It is based on the use of various symbols to represent specific operations. Use Call Flow button to create it.
• Imported tab: a graphic representation of the calls to functions or procedures that are called from the current routine is displayed. This representation is recursive, that is, it begins with a red rhombus on the first level that represents the current function. In the second level, as many nodes appear as routines are invoked from the function itself, being presented as red rhombuses if they are functions or yellow ellipses if they consist of procedures. And so forth, until terminal nodes that represent routines that do not contain calls are reached. Use Graph imported button to create it.
• Graph exported tab: graphic representation of routines that call to this script. Use Graph exported button to create it.
• Generate delta button: creates a new delta record that allows documenting changes.
• Buffer edition/revert/commit buttons: initiates, reverts changes or performs changes of buffer edition mode.

When invoking a catalogued JavaScript function, the system will use the script resolver function to determine the location of the requested resource. When executing a script from Axional Studio using the following function calls will be resolved in the following way:

A JS lib is a JavaScript file that contains a bunch of functions, whose functionalities are closely related. This forms allows you to define function packs that can be imported.

• Code*: JS script name.
• Description: recommended explanatory text of the script functionality. For example from where it is called, parameters, etc...
• Locked indicator: only the user who has locked the record has permission to edit. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record.
• Script*: JS script code.
• Project and Comments: it is recommended to use these fields to document this function.
• Generate delta button: creates a new delta record that allows documenting changes.
• Buffer edition/revert/commit buttons: initiates, reverts changes or performs changes of buffer edition mode.

When invoking a catalogued a javascript library, the system will use the script resolver function to determine the location of the requested resource. When executing a script from Axional Studio using the following function calls will be resolved in the following way:

 

It allows defining part of a function or routine in syntax xsql-script. From a function or routine xsql-script you can incorporate programmed code from the include repository, normally used to particularize part of the program and also for conditional code.

A xsql-script can incorporate from 0 to n xsql-script includes.

From the include you have access to all the variables visible from the xsql-script program that contains the include at the point at which it is invoked. If a non defined include in the repository is included in a xsql-script, the interpreter will continue with the following instruction. If the include exists, the include begins to run and once finished, the execution of the main code is resumed in the following line to that of the include.

• Code*: name of the code that incorporates this include.
• Name*: name of the xsql-scrpit include.
• Locked indicator: only the user who has locked the record has permission to edit. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record.
• Description: explanatory text of the include functionality.
• Include data: XML code of the XSQL-Script include.

This tier is where the data resides and is responsible for accessing it. It is made up of one or more database managers that perform all data storage, receive requests for storage or retrieval of information from the middle tier.

Stored procedures, functions and triggers can be written using XSQL language extensions. Although these codes are defined in the dictionary, they must be compiled in the database. The appropriate code for the target database agent will be produced during model deployment (compilation time).

Inserting "business logic" into the database using these options eliminates the need to duplicate the same logic in each of the programs that access the data.

For further information, see XSQL language.

A database trigger is a special stored procedure that is run when specific actions occur within a database. This form allows you to define a trigger associated with a dictionary.

The trigger is fired automatically whenever an event such as INSERT, DELETE, or UPDATE occurs against a table. They are mostly used for maintaining the integrity of the information on the database, without the need for the user executing the SQL statement.

Some examples of the use of triggers may be:

• Before registering a new sales order for a customer, it checks if he has a pending debt; in this case it cancels the registration of that order stating the reason.
• Removing a provider from our database involves deleting all data related to that provider.
• Updating the total amount of an invoice each time a detail line is inserted, deleted or updated.

Triggers are written in XSQL and compiled into the database. For further information about trigger grammar, see Languages reference/XSQL/SPL/Triggers.

From a trigger you can include code programmed in the repository of trigger includes, normally used to particularize part of the programm.

• Code*: trigger Code.

  IMPORTANT

  This code must correspond to the name within the trigger body.

• Database: it limits the function update to the indicated database. If left blank, it indicates that it is a general function to be updated on all databases.
• Locked indicator: only the user who has locked the record has permission to edit. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record.
• XSQL code*: code of the function. Functions before use must be loaded into the database through the compile code button. For this purpose, the system transforms the function written in XML grammar into the native syntax of the database agent.
• Project and Comments: it is recommended to use these field to document this function.
• Generate delta button: creates a new delta record that allows documenting changes.
• Compile code button: although the functions are defined in the dictionary, they must be compiled in the database through this button.

It allows defining part of a trigger in syntax xsql. From a trigger you can incorporate programmed code from the trigger include repository, normally used to particularize part of the program.

A trigger can incorporate from 0 to n trigger includes.

• Code*: name of the code that incorporates this include.
• Name*: name of the trigger include.
• Locked indicator: only the user who has locked the record has permission to edit. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record.
• Description: explanatory text of the include functionality.
• Include data: SQL code of the trigger include.

A function is a group or set of statements that perform a specific task. Unlike procedures, functions return only one value. This form allows you to define a user function or a routine associated with a dictionary. A function is a prepared SQL code that you can save, so the code can be reused over and over again just by calling it.

This object, wic_xudf_object, allows defining the functions associated with a dictionary.

The programming of a XUDF is based on the grammar XSQL-UDF. To do this, webstudio has an utility called ws-dbschema . To get information about this command, see documentation ws-dbschema . For further information about grammar XSQL-UDF, see Languages reference/XSQL/SPL/Function.

• Code*: XUDF Function Name.
• Database: it limits the function update to the indicated database. If left blank, it indicates that it is a general function to be updated on all databases.
• Order*: order of function creation to satisfy dependencies.
• Locked indicator: only the user who has locked the record has permission to edit. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record.
• Description: explanatory text of the function functionality. For example, from where it is called, parameters, etc...
• Function statement*: XML code of the function. Functions before use must be loaded into the database. For this purpose, the system transforms the function written in XML grammar into the native syntax of the database agent.
• Project and Notes: it is recommended to use these field to document this function.
• Call flow: it is a graphical representation of the function's workflow. It is based on the use of various symbols to represent specific operations.
• Imported: a graphic representation of the calls to functions or procedures that are called from the current routine is displayed. This representation is recursive, that is, it begins with a red rhombus on the first level that represents the current function. In the second level, as many nodes appear as routines are invoked from the function itself, being presented as red rhombuses if they are functions or yellow ellipses if they consist of procedures. And so forth, until terminal nodes that represent routines that do not contain calls are reached.
• Generate delta button: creates a new delta record that allows documenting changes
• Compile code button: although the functions are defined in the dictionary, they must be compiled in the database through this button.

It allows defining part of a function in syntax xsql. From a function you can incorporate programmed code from the function include repository, normally used to particularize part of the program.

• Code*: name of the function code that incorporates this include.
• Name*: name of the function include.
• Locked indicator: only the user who has locked the record has permission to edit. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record.
• Description: explanatory text of the include functionality.
• Include data: SQL code of the function include.

A procedure is a group or set of statements that perform a specific task. Unlike functions, stored procedures can return between 0 to n values. This form allows us to define the procedures associated with a dictionary. A stored procedure is a prepared SQL code that you can save, so the code can be reused over and over again just by calling it.

This object, wic_xudp_object, allows defining the procedures associated with a dictionary. The programming of a XUDP is based on the grammar XSQL-UDP. For further information about this language, see Languages reference/XSQL/SPL/Procedure.

Each application database that is assigned to this dictionary will potentially have to include these procedures in their structure. The procedures, before being used, must be uploaded to the operating database. To load them into the database, they must be transformed into the database agent syntax. To this end, webstudio has a ws-dbschema utility on it.

• Code*: XUDP procedure name.
• Database: it limits the procedure update to the indicated database. If left blank, it indicates that it is a general procedure to be updated on all databases.
• Order*: order of procedure creation to satisfy dependencies.
• Locked indicator: only the user who has locked the record has permission to edit. Until the user who has locked the record unlock it, no other user can make changes or delete the selected record.
• Description: explanatory text of the procedure functionality. For example, from where it is called, parameters, etc...
• Procedure statement*: XML code of the procedure. Procedures before use must be loaded into the database. For this purpose, the system transforms the procedure written in XML grammar into the native syntax of the database agent.
• Project and Notes: it is recommended to use these field to document this procedure.
• Call flow: it is a graphical representation of the procedure's workflow. It is based on the use of various symbols to represent specific operations.
• Imported: a graphic representation of the calls to functions or procedures that are called from the current routine is displayed. This representation is recursive, that is, it begins with a red rhombus on the first level that represents the current procedure. In the second level, as many nodes appear as routines are invoked from the procedure itself, being presented as red rhombuses if they are functions or yellow ellipses if they consist of procedures. And so forth, until terminal nodes that represent routines that do not contain calls are reached.
• Generate delta button: creates a new delta record that allows documenting changes
• Compile code button: although the procedures are defined in the dictionary, they must be compiled in the database through this button.

It allows defining part of a procedure in syntax xsql. From a procedure you can incorporate programmed code from the procedure include repository, normally used to particularize part of the program.

A stored procedure can incorporate from 0 to n procedure includes.

• Code*: name of the procedure code that incorporates this include.
• Name*: name of the procedure include.
• Locked indicator: only the user who has locked the record has permission to edit. Until the user who has locked the record does not unlock it, no other user can make changes or delete the selected record.
• Description: explanatory text of the include functionality.
• Include data: SQL code of the procedure include.

They are stored procedures written in native language.