The following document try to introduce the reader to the Object instance. After reading this article the reader will know what is an Object instance, how to create and configure it, and what functionallities does it implements.

1 Introduction

Every view on WebApp application (Reports, Transactional forms, Rest APIs, etc.) is an instance of this Object entity. This implementation gives a centralized configuration for views, such us the tree menu configuration and views functional grouping.

Furthermore, when definining references to an Object throught the application, such as links, automated executions, etc. Those reference point to an unique entity, the Object Instance, whatever the type of Object is.

Finally, most of the Objects requires a process of query in order to narrow the data to be displayed on the view. This is what we call QBE (Query By Example); which consists on a set of parameters that provide the user an user friendly form with a set of input fields for specifying what data wants to manage. So, the Object instance provides the entities: Query fields, Query variables and Meta queries to implement the mentioned QBE.

For sumarizing, the Object instance is intended for providing:

  • Simplified application menu configuration.
  • Simplified Object references within application.
  • Centralized description and localization.
  • Centralized query.

2 Definition

TO DO

This section is incomplete and will be concluded as soon as possible.

Object types:

  • Report
  • Transactional
  • REST application

The table bellow shows a detailed stucture of the Object definition entity wic_obj_base:

Menu path:
Objects / Definition / Objects (New)
wic_obj_base
Label Description
Id Object Id
Object Object code

  • Case: Downshift
Group Application area
Title Object description
Tag name Short description for tabs in the jsp pages
Type Object type

  • Default: 0
  • Values:
    • 0: Report. Report
    • 1: Transactional.
    • 2: Rest application.
Locked Object locked/unlocked

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

  • Format: PARSEXML
Imagen Result snapshot
User created User that has created the object

  • Default: USER
Data creació Date of creation

  • Default: CURRENT
User updated User that has updated the object

  • Default: USER
Date updated Last update date

  • Default: CURRENT

3 Query fields

TO DO

This section is incomplete and will be concluded as soon as possible.

Query fields are only applicable to the following object types:

  • Reports
  • Transactional

3.1 Default value

Query fields allow specifing a default value by specifing one value on the Default attribute at Query Fields entity (wic_obj_inputqry.qry_defvalue).

When defined, the QBE page will initially display the input field with the corresponding value.

3.1.1 Syntax

TO DO

This section is incomplete and will be concluded as soon as possible.

3.2 Required value

Query fields can be mark as required via the Required attribute at Query Fields entity (wic_obj_inputqry.qry_isrequired).

Setting a query field as required has two affectations in Axional Studio application:

  • Invalidating the form at QBE page until all required query fields are filled. So, the query cannot be executed from QBE page if the are missing values on required query fields.
  • All URLs executing an object with missing required query fields will be redirected to the QBE Page. That is, by no means an object will be executed without specifying a value for a required query field.

3.3 Use in statement

The final goal of QBE page is to generate an SQL clause that will be used in a server side statement as a filter condition to limit the number of rows to be displayed in a view. The following section explains the process of conversion from the introdued QBE params into the mentioned SQL clause.

3.3.1 QBE to SQL conversion

The tables bellow contains the translation between QBE expressions into the corresponding SQL clause.

Common clauses
Type QBE Param QBE Value SQL clause
Equal Firts Name John
Copy
user.first_name = 'John'
Not equal Firts Name !=John
Copy
user.first_name != 'John'
Is in List Firts Name John|Mary
Copy
user.first_name IN ('John', 'Mary')
Not is in List Firts Name !John|Mary
Copy
user.first_name NOT IN ('John', 'Mary')
Empty Firts Name =
Copy
user.first_name IS NULL
Not Empty Firts Name !=
Copy
user.first_name IS NOT NULL
Character fields
Type QBE Param QBE Value SQL clause
Starts with Firts Name J%
Copy
user.first_name LIKE 'J%'
Not starts with Firts Name !J%
Copy
user.first_name NOT LIKE 'J%'
Ends with Firts Name %J
Copy
user.first_name LIKE '%J'
Not ends with Firts Name !J%
Copy
user.first_name NOT LIKE '%J'
Contains Firts Name %o%
Copy
user.first_name LIKE '%o%'
Not contains Firts Name !%o%
Copy
user.first_name NOT LIKE '%o%'
Numbers and date fields
Type QBE Param QBE Value SQL clause
Greater than Birth Date >21-05-2019
Copy
user.birth_date > MDY(5, 21, 2019)
Greater or equal then Birth Date >=21-05-2019
Copy
user.birth_date >= MDY(5, 21, 2019)
Lower than Birth Date <21-05-2019
Copy
user.birth_date < MDY(5, 21, 2019)
Lower or equal than Birth Date <=21-05-2019
Copy
user.birth_date <= MDY(5, 21, 2019)
Between Birth Date 01-01-2019:31-12-2019
Copy
user.birth_date BETWEEN MDY(1, 1, 2019) AND MDY(12, 31, 2019)
Not between Birth Date !01-01-2019:31-12-2019
Copy
user.birth_date NOT BETWEEN MDY(1, 1, 2019) AND MDY(12, 31, 2019)

Multiple fields

In case of specifying more than one QBE param they are applied to narrow the filter, so they are joined by the AND operator. For example appying the QBE params:

  • Firts Name: John
  • Last Name: Smith

The resulting SQL clause is:

Copy
user.first_name = 'John' AND user.last_name = 'Smith'

Dates handling

Notice that dates are introduced in the user format and timezone, and they are translated into the database format and timezone when applied.

Basic Text Search (BTS)

TO DO

This section is incomplete and will be concluded as soon as possible.

3.3.2 QBE statement application in SQL

By default the SQL clause generated by the QBE is automatically applied to the main SQL statement of the object instance. For example in case of having the following statement:

Copy
<select>
    <columns>*</columns>
    <from table='customers'/>
</select>

And receiving a QBE clause where the query field customers.cust_id is equal to 2. The executing statement wil be:

Copy
SELECT * 
  FROM customers
 WHERE customers.cust_id = 2;

It works fine with single SQL fragments, which are the most common, but in cases of having more complex statements, with multiple fragments or script execution, it could be necessary to specify where to put the QBE clause. For example when having the following statement:

Copy
<select intotemp='@tmp_customer'>
    <columns>*</columns>
    <from table='customers'/>
</select>

<select>
    <columns>*</columns>
    <from table='@tmp_customer'/>
</select>

And receiving a QBE clause where the query field customers.cust_id is equal to 2. The executing statement wil be:

TO DO

Explain what happen with the where clause when exists more than one fragment and it is not specify where to put the where clause.

So in that case when can specify where to put the QBE clause with the expression $[grpname], where group name is the code defined. By default, all Query fields has the same group name, with the code 0.

Copy
<select intotemp='@tmp_customer'>
    <columns>*</columns>
    <from table='customers'/>
    <where>
        $0
    </where>
</select>

<select>
    <columns>*</columns>
    <from table='@tmp_customer'/>
</select>
Copy
SELECT * 
  FROM customers
 WHERE customers.cust_id = 2
 INTO TEMP tmp_customer_001;
SELECT * 
  FROM tmp_customer_001;

TO DO

This section is incomplete and will be concluded as soon as possible.

Use of variables

TO DO

This section is incomplete and will be concluded as soon as possible.

3.3.3 Specific SQL clause

TO DO

This section is incomplete and will be concluded as soon as possible.

This functionalloty allow having specific attributes on an QBE field and keep SQL statement simple.

3.4 Dictionary attributes

TO DO

This section is incomplete and will be concluded as soon as possible.

3.5 Select all columns

TO DO

This section is incomplete and will be concluded as soon as possible.

4 Query variables

TO DO

This section is incomplete and will be concluded as soon as possible.

Query variables are only applicable to the following object types:

  • Reports

4.1 Type of variable

TO DO

This section is incomplete and will be concluded as soon as possible.

4.2 Required value

TO DO

This section is incomplete and will be concluded as soon as possible.

4.3 Default value

TO DO

This section is incomplete and will be concluded as soon as possible.

4.4 Use in statement

TO DO

This section is incomplete and will be concluded as soon as possible.

4.4.1 Normal variables

TO DO

This section is incomplete and will be concluded as soon as possible.

4.4.2 Construct variables

TO DO

This section is incomplete and will be concluded as soon as possible.

QBE to SQL conversion

TO DO

This section is incomplete and will be concluded as soon as possible.

QBE statement application in SQL

TO DO

This section is incomplete and will be concluded as soon as possible.

Specific SQL clause

TO DO

This section is incomplete and will be concluded as soon as possible.

4.5 Dictionary attributes

TO DO

This section is incomplete and will be concluded as soon as possible.

4.5.1 Alternative columns

TO DO

This section is incomplete and will be concluded as soon as possible.

5 Meta query

TO DO

This section is incomplete and will be concluded as soon as possible.

Meta queries are only applicable to the following object types:

  • Reports
  • Transactional