Axional Frontend allows you to program a Frontend application

1 Overview

Applications are defined in the table wic_frontend_app. The column (app_code) defines the code of the application and is used to configure a frontend instance in the config.xml file.

For each application multiple endpoints or paths can be defined in the table wic_frontend_endpoints. T he routes defined in this table determine the contents of the application menu. Endpoints can be of distincts types and the system provides views for all the types with the exception of the custom type views.

2 wic_frontend_app

Menu path:
Web Services / SQL catalog (Deprecated) / Applications
wic_frontend_app
Label Description
Code Application code
Session data Code of the SQL catalogue providing user session data
Dark mode

  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
Default view Path of the default view

3 wic_frontend_endpoint

Menu path:
Web Services / SQL catalog (Deprecated) / Endpoints
wic_frontend_endpoint
Label Description
Application code Application code
endpoint_id Endpoint identifier
Parent menu ID
Label Label
Path Path
Hide in menu

  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
Type Type

  • Values:
    • L: List. List
    • M: Map. Map
    • C: Chart. Chart
    • P: PDF. Chart
    • U: Menu. Menu
    • F: Form. Form
    • T: Custom. Custom
    • R: Custom row view. Custom row view
Path Path
Label Label
Catalogued SQL SQL Statement
Catalogued transaction SQL Transaction
Role
Updatable row condition
Custom view
Attributes

Created by

  • Default: USER
Date created

  • Default: CURRENT
Modified by

  • Default: USER
Date updated

  • Default: CURRENT

4 wic_sqlc_object

Menu path:
Web Services / SQL catalog (Deprecated) / SQL Statement
The system allows to perform queries to the Axional backend via SOAP calls.
The query request must exists registered in the catalogue of a backend database dictionary, or within the master Wic.
Each query consists of two parts: a code naming the quey itself and a statement.
The Frontend always invokes the query by its code, and the underlying statement is executed, at the backend side.
As results, the dataflow prevents the transaction against the execution of arbitrary code, delivered from the client side.

Queries can have filtering parameters and variables. The filtering and output columns of the query are defined in the object wic_sqlc_object_out while variables are stored in wic_sqlc_object_colvar .

The filtering condition is constructer upon the column marked are filterable and the data sent by the client and is automatically added to the query. If the WHERE clause already contains conditions the system will look for the string $0 and will replace with the condition: 

...
<where>    
    geanmovh.refter ='A' AND $0    
</where>

Variable conditions allow more control over the conditions of the query. Variables are replaced using the ${VARNAME} notation. Each of the declared variables will be replaced using the value sent from the client, for instance:

...
<where>    
    geanmovh.refter = ${codlab}   AND geanmovh.fecmov between ${fecini} AND ${fecfin}
</where>

When a query has filtering columns or variabled defined, then in the client side an form will appear to allow to input of the filtering values

wic_sqlc_object
Label Description
Code Record identifier code
Information Information of the object

SQL query SQL query to execute

Cache indicates if the select can be cached

  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
Created by

  • Default: USER
Date created

  • Default: CURRENT
Modified by

  • Default: USER
Date updated

  • Default: CURRENT