Although the reports share common elements with other objects, they are an independent entity since it fulfills a highly specific aim.

The common elements are:

• Identification and additional info
• Input query, variables and SQL conditions.
• Object help documentation.
• Control data

1. Identification:
   • Report code*: It must be a unique identifier. Use conventional syntax, with lowercase letters and underscore between separate words. Preferably, give a meaningful name to the object.
   • Tag name: it corresponds to the name that will be displayed in the report tab. Capitalize the first letter of the tag name.
   • Title*: it is the text that appears in the report header. Use capital letters.
   • Group*: this field corresponds to the functional groups of objects and panels and serves two major functions. On the one hand, to assign role permissions through the wic_conf. On the other, to control some aspects related to the appearance and color of the report.
   • Locked: if the locked box is disabled, then the report can be selected and executed. Enable it if the report is being designed or under revision.
2. Settings:
   • Cache: this flag enabled indicates to save on the cache to avoid executing it again. When the flag is disabled, the report will always force its execution, that is, it will not use the system cache.
   • Full output: indicates whether the report is fully issued without considering the limits of its database connection group (wic_conf: wic_dbms_users). These limits are the maximum number of readable records (usr_maxqrows) and the maximum number of records in printing processes through XSK Formatting Objects (usr_maxfrows).
   • Autorefresh (seconds)*: seconds for data autorefresh within the navigator (default value 0). Use it when working with critical data to frequently execute the object. When automatically executed, it retrieves data from DB, never the browser cache.
3. Order by criteria:
   • Sort: the output order will be considered as the ORDER BY clause of the SQL statement of the object, hence it is not necessary to indicate it in the SQL syntax.
4. Report tabs:
   • SQL Statement: the SQL statements of the object consist of the syntax of the query that the system will perform to the database, in the object execution time.
   • Input: defines the fields on the query form.
   • Variables: defines complex query fields.
   • Filter: defines quick access query fields.
   • Output: this chart maintains the association and the attributes among the fields of the SQL sentence that generates an output report and its correspondences with columns of the metadata dictionary. For further information see Output tab on the following sections.
     
   • Color: the color tab allows modifying the text and the background color of the columns. It uses expressions to change colors when the defined column matches the expression.
   • Font: the font tab allows modifying the text style to be displayed when columns match defined expressions. It includes options like font family, weight, style, size, transformations, decorations, and alignment.
   • Links: hyperlinks to other objects (target) defined in repository databases, which provide information related to some concept of the source object.
   • Page links: create links to move easily between reports.
   • PDF Confing: configure the PDF of the report with a different look than the same report on screen.
5. Project and notes: it is recommended to use these fields to document this function.
6. Help tabs:
   • Object info: help text description to be reported when the user clicks on the object instance help icon. Use PARSEXML format.
   • Snapshot: picture of an object instance example.
   • Language: allows the name and title of the object to be translated into other languages.
7. Control data
   • ID: instance identification number.
   • Created by and data created: user who has created the report and when
   • Modified by and data updated: user who has updated the report and when
   • CRC: or checksum is an error detection code.
   • Rows: number of rows in the code.
   • Size: file size.
8. RCS Delta changes: all changes in the Report definition will be registered. Use the opportunity to properly document each modification.
9. Report buttons:
   • Copy: it copies the entiry report definition with a different name.
   • Buffer edition: Axional Studio has the option to edit reports in Buffer mode, just by pressing the Buffer edition button. During the buffer mode, the report 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.

     WARNING

     During the buffer mode edition, user will execute all changes saved when executing the object.

The data displayed in the report is configured via the SQL Statement text area box. The statement may consist of a SQL query or an XSQL-Script returning a result set.

The syntax of the statement can be expressed in XML or in standard SQL language, without limitation of lines of text or fragments of instructions.

Each SQL statement may include the following injections:

1. $0: this injection allows the user to configure and filter the report by selecting values.

   The list of values will be injected in the $0 clause. Therefore, when value filters are enabled, the WHERE clause must follow this format: [name_of_column] IN $0.

2. $METAQCOND: this injection allows the user to filter the report. Permitted filters will be defined in the Filter tab.

3. $GROUP: this injection allows the management of dynamic groups, so the user can reorder columns, by the drag and drop mode and instantly, if they are defined as break groups. For further information see Dynamic groups in the next chapter.

When we talk about databases, a query is a request for data stored in that DB. Queries are a way of searching for and compiling data from one or more tables.

The QBE (Query By Example) provides a simple interface for a user to enter queries. Instead of writing an entire SQL command, the user can just fill in blanks or select items to define the desired query. Each query field represents a field in a table that you want to consult. Usually, entries are only made in query fields for which you want to specify search criteria.

The query fields must be defined through the object instance form wic_obj_base:

Query fields are only applicable to the following object types:

• Reports
• Transactional

The components that define a query field are:

• Order: the order in which the input fields will appear.
• Group: allows grouping query fields to be used separately in a statement. The default value 0 is equivalent to $set. Review pending Use $QRY1, $QRY2, ..., instead of the unique $0. Different groups of input fields can be implemented, for example, so that some selects only affect a subset of fields.
• Table: table where to consult the query.
• Column: name of the column you want to provide the user with the possibility of introducing a selection criterion.
• Query: defines a different field to the column field so that it takes a logical dictionary with an alias, but when applying it to the SQL cond it makes a specific query.
• Required: determines whether a query field is required and if it will be displayed in the main query screen or the secondary one. All required fields will display an *asterisk to let the user know that it is a mandatory field.
• Default: allows assigning default values to a query field.

When the user enters some selection criteria in the input fields of an object, the system will translate it into SQL language, and will add it to the end of the SQL statement built for the query to the database.

When the object consists of a simple SQL statement, that is, a single SELECT statement intervenes, the object will be executed without any problem.

When the object consists of a complex SQL statement, in which several SELECT instructions are involved, or it consists of a GROUP BY clause, then it will have to be indicated, using the AND $ 0 operator, the appropriate place in the SQL statement where we want the system to add the syntax of the selection criteria entered by the user.

The input order will be the one corresponding to the order in which the system will present the input fields to the user, when entering the selection criterion.

If the object had query variables associated, the input fields are displayed first, and afterward, the variables are displayed.

The Group defines to which functional group it belongs. Functional groups in combination with functional roles will allow the application to dynamically adapt user menus.

Functional groups are pre-defined in the wic_jrep_roles object.

Name of the table and column you want to provide the user with the possibility of introducing a selection criterion.

The column reported here, for the indicated table, should be registered in the wic_jdic_coldata column dictionary on the system.

By default, fields tabname and colname act as a driver to retrieve logical data like labels, attributes, soft-references or the possible list of input values. All of them relay upon the logical dictionary definitions.

Besides, the query field allows us to apply another condition in the execution of the SQL statement.

The text, code, column or table.column filled here do overtake the default values stored as tabname and colname. Moreover, the content applies without any kind of transformation as a "left-side" of the row condition.

In this case, the virtualstudio table has no physical schema. The input query shows the virtualstudio.state label, but the report will show the results of employees in an "A"ctive state of the studio_employees.state field.

Examples of allowed data:

Query fields allow specifying a default value by specifying one value on the Default attribute at Query Fields entity (wic_obj_inputqry.qry_defvalue). Although the user can modify this default value before executing the query, its use is recommended in those cases where it is the most common query value.

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

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

This field can take three possible values:

• Important: the field will appear on the main query screen (in contrast with unusual). If present, click on the See more field in order to see the secondary screen.
• Unusual: the field only appears if user displays the secondary screen of the query.
  
  
• Required: the query is not executed until this field is filled. Note that required fields will be marked with an asterisk * in the query screen.
  
  

  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 there are missing values on the 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.

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 introduced QBE params into the mentioned SQL clause.

The tables below contain 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)

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, applying the QBE params:

• Firt Name: John
• Last Name: Smith

The resulting SQL clause is:

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

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

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:

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

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

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:

<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 , then the executing statement will be:

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 .

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

SELECT * 
  FROM customers
 WHERE customers.cust_id = 2
 INTO TEMP tmp_customer_001;
SELECT * 
  FROM tmp_customer_001;

This functionality allows having specific attributes on an QBE field and keep SQL statement simple.

The attributes determine how columns behave in a form or report, with a variety of options determining display, input, etc. For further information, see Attributes in Data Modeling section.

To select all the columns of the table without having to specify one by one, it is only necessary to create an input with the table name and an asterisk * in the column. This will include in the query input all the columns defined in the table.

The variables are another mechanism for data filtering. They should be created when the inputs fields cannot be used due to the query complexity.

The variables allow defining input fields to be used in expressions that conform the SQL sentence of an object. Each variable can define their own type and its way of being incorporated to the SQL sentence during the construction phase.

The variable input form has the following options:

• Order: order in which the system presents the input variables to the user.
• Group: the group name corresponds to the variable name, which will be used in the statement. Syntax: VARNAME (alphanumerical characters).
• Table and column: table and column to take the logical dictionary.
• Query: only for construct type. It defines a different field to the column field so that it takes a logical dictionary with an alias, but when applying it to the SQL cond it makes a specific query.
• Type: select one among the existing options.

Two main causes that force you to create input variables:

• Selection criteria.

  As we mentioned when explaining the registration of input fields, there are occasions when in order to make selections by certain fields, it is not possible through that registration.

  The reason is that the name of the table in an input field is implicit in the field in the SQL syntax that the system constructs when querying the database. As the SQL statement of the object consists of several FROM clauses, for some it will be fine and for others, it will lead to errors because the table does not belong to the list of tables of that clause.

  In this situation, the most viable and advisable is, for these conflicting fields, to define query variables, since this way we avoid the mentioned errors and the same query can be made as through input fields.

• Processes. When the SQL statement of an object consists solely of activating a process to which certain parameters reported by the user are passed, the only way to request said parameters from the user is through input or query variables.

When the possible values of a variable correspond to fixed values or to records in a table, it will have to be assigned an include.

This include will be the one that returns the possible values from its definition; hence it must be defined in the wic_jdic_colincl dictionary of includes.

There would be no point in assigning in a construct class variable a list of possible values, since a normal variable would be enough. In any case, the system would still work if the integration of the variable in the SQL statement is done taking into account that it is of this class.

The include type will define how the user can select the values provided by the include that the variable has assigned.

Order in which the system presents the input variables to the user. This command is subject to the input fields that the object has defined. The variables are placed behind the input fields.

Name that is assigned to the variable, which will be the one used when including it in the SQL statement of the object, preceded by the $ character, regardless of the class and type it is.

If a variable has been defined without having integrated it in the SQL statement of the object, it will be equivalent to not having defined it; that is, the system will ignore it.

Suppose that we define a variable to request an exercise. If we define the variable with the code EXERCISE, to integrate it into the SQL statement it would indicate: $EXERCISE.

Table name, if you want the label defined for any column in a table to appear as a description of the request of the variable, having to match the name of the column of this table with one of the variable. In the case that there is a description and a table, if it is found, the table is the one that prevails.

The query column of the input fields of an object allows to take, from the logical dictionary, the attributes defined by tabname and colname but at the same time to apply another condition in the execution of the SQL statement.

Using this method you can avoid having to define the table and column before the variable in the STATEMENT of the object.

You can inform this query field in several different ways:

• column: if you only inform the name of a column, the select will take the table defined in the previous field Table. This is the case of the VAR_DATE_CONSTRUCT variable example, that will take the field_date column of the studio_field_types table.
• table.column:the select will take the table and column here informed. This is the case of the VAR_INT_CONSTRUCT variable example, that will take the studio_field_types.field_int table and column instead of the virtual studio table.

The type of variable is very important, since it must be in accordance with the type of values that the variable can accept. Taking this into account, the type of variable affects in case of assigning an include to the variable, the possible values that that include can provide.

Besides, the type of values that the variable supports must also be consistent with the type of field to which it will refer in the SQL statement of the object.

The types of variables that the system supports are the following:

• Char (character): this will be the type of variable to assign when the values to be entered in the variable are alphanumeric. When the system builds the query's SQL statement, the values of the variable will be enclosed in quotes: '' . An example of such a variable could be the code of an accounting account, a supplier, a customer, a warehouse, etc.
• Date: this will be the type of variable to assign when the values to be entered in the variable are dates. When the system constructs the SQL statement of the query, the values of the variable will be transferred in the form: MM-dd-yyyy (month, day, year).

  An example of such a variable could be any date to request.

• DateTime: this will be the type of variable to assign when the values to be entered in the variable are date and time, increasing the accuracy. When the system constructs the SQL statement of the query, the values of the variable will be transferred in the form: MM-dd-yyyy HH:mm:ss (month, day, year, hour, minutes, secons)
• Integer: this will be the type of variable to assign when the values to be entered in the variable are numeric without decimals. When the system builds the SQL statement in the query, the values of the variable will be passed as they are. An example of such a variable could be an exercise, a period, etc.
• Decimal : this will be the type of variable to assign when the values to be entered in the variable are numeric with decimals. When the system builds the SQL statement in the query, the values of the variable will be passed as they are.
  An example of such a variable could be any number that must include decimals: amounts, quantities, weights, measures, etc.
• Expression: this will be the type of variable to assign when the values to be introduced to the variable consist of expressions based on SQL language that will be transferred to the SQL statement of the object as they are expressed. These types of variables are not usually reported by the user, but belong to objects that are run from some "wic_jrep_collnk" hyperlink. In that case, these types of variables are already reported with the corresponding expression.

When you want the variable to have a default value at the time of the execution of the object, it will be reported here. By default, the system also supports SQL expressions and functions of the type: TODAY .

Mark this field to make this value required on the query screen.

Through this indicator, the system is informed if the variable is going to have, in the construction of the SQL statement, a behavior equivalent to a construct field or input field.

Whether or not this indicator is activated will influence the integration of the variable into the syntax of the object's SQL statement.

When a variable is defined as class construct; that is, this indicator is activated, it will always be included in the syntax of the object's SQL statement as follows: AND table.field $VARIABLE , regardless of whether the variable is assigned an include, as mentioned in the include type field.

When the system constructs the SQL statement of the query for a variable of this class, depending on the information supplied by the variable, the system will intelligently use the necessary logical operators based on it.

The most usual examples are the following:

• = . When the variable supplies a single value, for example an fiscal year, the system will create the statement of the form: table.field = 2000 .
• IN () . If instead of supplying a single fiscal year, you get two values separated by a | , then the sentences would be: table.field IN (1999,2000) .
• MATCHES . If the value supplied by the variable is linked with a * , in this case, the statement would be: table.field MATCHES '* value *' (depending on whether the * has been reported to the left, right of the entered value, or both sides.)
• BETWEEN . If the values supplied by the variable arrive separated by : , then the statement would be: table.field BETWEEN value1 AND value2 .
• etc.

1. For a user executing an object to distinguish a construct variable from a normal one, the system presents them in different colors, so that the class construct is will show purple and normal green.
2. The content of this type of variables, in the context of an xsql-script program, must be defined as the unquoted attribute according to the following example: <p_empcode mode='unquoted' />

The query input field inherits the soft reference from table and column definition. It is possible to inform a different soft reference that will work only on the query screen. This can be useful to avoid dependencies soft reference of the table and column.

• If no soft reference is informed here, the query input field inherits the soft reference from table and column definition.
• If a new soft reference is informed here, the query input field will use this new one instead of the one related to the table.column.

Soft Reference implementation is detailed in chapter Advanced features, section Soft References.

When the system constructs the SQL statement of the query for a normal variable, the system will integrate the variable value literally, with not possible logical operators.

When the system constructs the SQL statement of the query for a construct variable, the system will intelligently use the necessary logical operators based on it.

When the system constructs the SQL statement of the query for a construct variable, the system will intelligently use the necessary logical operators based on it. If, in addition, the variable has a column.field defined in the variable query field, the system will automatically integrate these into the construction.

For further information of variable Query name, see previous section Query Input Variables: Query.

The SQL conditions or Filter consist of establishing selection criteria with fixed conditions associated with an object, in such a way that, when executing that object, the system will enable the SQL conditions of the object in question. This way the user, in addition to the indicated dynamic selection criteria, can (optionally) select one of the SQL conditions to set conditions for selecting it.

They are also known as meta query.

The input order will be the one corresponding to the order in which the system will present the SQL conditions drop list to the user, when displaying the SQL condition field in the QBE.

This code must be a unique identifier, preferably using capital letters.

The title field corresponds to the label code from the wic_jdic_lbldata that the application will show the user in the QBE screen when selecting the SQL condition option. This way it must be possible the SQL condition to have language descriptions from that label defined in the wic_jdic_lbldata.

The SQL condition indicated here will be the one that the system will add and concatenate to the original condition of the object to which the SQL conditions is assigned, at the time it is executed.

There are several considerations to keep in mind:

• When the system adds the SQL condition established here to the object, it does it in the following way: AND SQL condition, so that the operator AND is automatically preceded by the system itself, hence its inclusion in this condition is not necessary.
• If the object to which the SQL conditions belongs has query variables these are also susceptible to use and include in the SQL statement of the SQL conditions.
• The system includes by default a series of standard variables that can be very helpful and can also be used in the SQL condition. These are:
  • $USER. The content of this variable refers to the code of this user.
  • $DBMS. The content of this variable refers to the code of this database.
  • $LANG. The content of this variable refers to the language code of this user.

The system supports the inclusion of some XML tags for the correct transformation of some SQL functions that depend on the database agent where it runs. For example, the function NVL is valid in Informix and Oracle, but in DB2 it is called COALESCE and in MySQL IFNULL, and using the XML tag <nvl> it is transformed to the corresponding one. To concentrate all the possibilities, you can write these supported functions in XML, including the entire condition between the tags <xsql-text> and </xsql-text>, to indicate that it must be transformed previously.

EXISTS(
  SELECT gcomalbl.cabid
    FROM gcomalbl, gcommovl_datc
   WHERE gcomalbl.linid = gcommovl_datc.linid
     AND gcomalbl.cabid = gcomalbh.cabid
     AND LENGTH(NVL(gcommovl_datc.codpre, gcomalbh.codpre)) > 0
)
                

                    <xsql-text>
EXISTS(
  SELECT gcomalbl.cabid
    FROM gcomalbl, gcommovl_datc
   WHERE gcomalbl.linid = gcommovl_datc.linid
     AND gcomalbl.cabid = gcomalbh.cabid
     AND <length><nvl>gcommovl_datc.codpre, gcomalbh.codpre</nvl></length> > 0
)
</xsql-text>

                

Through this option, we access the definition of the report output fields. If the user has the required authorizations, it is possible to create, modify and delete such definitions.

In this chart, in addition to recording the output fields corresponding to the columns of the SQL statement of an object, a whole series of properties and their characteristics are also defined, both from a presentation and functional point of view.

The system performs a permanent synchronization between the columns involved in the last SELECT clause of an object and the values reported in the output fields of the same each time it is executed, so when developing objects, if the output fields are not reported, the first execution of the same will be filled in automatically.

It should be noted that an essential condition for this synchronization to take place is that the main table in the last SELECT clause of the object is not a temporary table.

Even with this system characteristic, it is recommended when creating an object to review the output columns after the first execution, since this mechanism may not be able to define hidden columns, break groups, columns that add ... subjects that are under the responsibility of the object's programmer.

Because of the possibilities provided by the definition and registration of the output fields of an object, it would be very important to pay close attention to each of the utilities previously exposed.

The system performs a permanent synchronization between the columns involved in the last SELECT clause of an object and the values reported in the fields of output every time it is executed, taking into account the following considerations:

• No column is registered: all output columns are registered in the same order in which the last SELECT clause of the object is expressed. The table name for the output columns is the name of the main table of the mentioned SELECT clause.
• The number of columns registered is DIFFERENT than the number of columns in the SELECT clause: the system will carry out the verification process.
• The number of columns registered is EQUAL to the number of columns in the SELECT clause: for each column registered in the output, it is checked if it matches the position in the SELECT clause.
  
  If everything matches, the system considers it good.
  
  If any does not coincide, it can be for two reasons:
  
  1. They are poorly ordered. The system will carry out the verification process.
  2. Some of them do not coincide. The system will carry out the verification process.

Order of presentation (from left to right) of the columns in the report. The order indicated here must coincide with the order that the columns follow within the SQL statement, since in reports in which there are groups of breaks, if they did not coincide, it would give rise to irregularities in the output format of the resulting information.

Name of the table to which the column to be registered as the output field belongs. When the column has an alias, this has to be reported in this field.

The table reported here should be defined in the wic_jdic_tabdata table dictionary, and in combination with the column to register, in the wic_jdic_coldata column dictionary. The fact that they are registered in this last dictionary is important because it will depend on the system showing the descriptions abbreviated from the dictionary, such as column titles.

Three colored circles appear next to the table name. Each circle is a link to an option of the table or column. If this circle is shown in gray, that option does not exist and the link is not available.

• ⬤ Red: link to the physical schema of the table.
• ⬤ Magenta: link to the attributes of the column.
• ⬤ Purple: link to the column dictionary of the table.
• ⬤ Grey: no link is available.

The real column corresponds to the real name of a column when it uses an alias in the output column field.

For example, when the select obtains columns from several tables, there is a possibility that some of the columns share the same name. Because they are primary keys, in these cases it is mandatory to define an alias for them, which is the one that we will insert in the output column field. Then the real name of the column must be put in the Real column field.

A tooltip is a message that appears when the cursor is positioned over a row. To define it, it is necessary to indicate the name of the column in the tooltip field.

Break groups for an object are used and defined when you want to make breaks within a report. The order of the breaks should be consistent with the order of presentation of the fields; otherwise, there may be poorly readable formats in the reports.

Break groups are most often used when you want to obtain subtotals for certain items in the report. The fields through which you want to make a break must be assigned the same group number.

For a better view of the report, for each break group that appears in the object, the system will show it with colors of different shades, based on the palette assigned to the functional group of the object.

Important aspects to consider when defining break groups in an object:

• Both the number of groups to establish per object, as well as the output fields that can be part of each one, are unlimited.
• The groups of breaks to be defined must start with the value 1, and if there is more than one group in the object, they must be correlative in their numbering; that is, jumps will not be accepted. Otherwise, the system will take notice of this circumstance and stop the execution of the object.
• The reason for this verification is so that the color tones of the different breaks follow a predefined scale and are not disproportionate to each other.
  
  

This functionality allows the user to reorder, through the simple use of drag and drop, how columns or columns groups, do construct break groups and subtotal lines. This enables the user to retrieve different report approaches from a single object, and consequently, to reduce to one the number of reports necessary to obtain all the combinations that this new report provides itself.

The functionality also allows us to hide each group of columns individually. If disabled, the set of columns will not appear in the report. Moreover, reordering the groups of columns or hiding any of them, will rebuild dynamically how to sort data by these groups.

The dynamic groups do not appear in the Column concealment option or the Sort option of the Report setting menu.

The user interaction with the dynamic groups is allowed through the QBE screen or, after getting the results, in the Group menu (hiding and moving). This last menu also allows data sorting by a dynamic group.

<select>
	<columns>$GROUPS emp_no, first_name, last_name</columns>
	<from table='studio_employees' />
</select>

The break groups turn into dynamic groups when they are activated using the $GROUPS injection in the report statement.

Procedure:

• Define the main statement of the report with all the required fields.
• At the output form, define the break groups filling them in the group field as explained in the previous chapter Group.
• Within the main SQL Statement, replace all fields defined as 'output groups' with the expression $GROUPS, with no ending comma.
• Within the main SQL Statement, replace de 'group by' fields defined as 'output groups' with $GROUPS. No ending comma is required afterwards.

Using columns affected by dynamic groups in the link SQL condition might be some tricky, because depending on which columns are being used as grouping or not, the link condition wether take them into account or not.

For example, having the following expression:

cefectos.empcode = '${empcode}' AND cefectos.proyec = '${proyec}'

In case of the column empcode is a dynamic column group, and is visible, the column can be replaced normally and produces an SQL condition such as:

cefectos.empcode = 'DEISTER' AND cefectos.proyec = 'ID'

But, in case of the column is hidden, the displayed data is groupped by empcode; so it has no sense to include this column in the link condition. In that situation, it is desired to not take the column empcode into account when building the SQL condition.

In order to do so, there is the JUEL function getGroupExpr(colname, exprIfHidden). In this case, this function must be used in this way:

cefectos.empcode = ${getGroupExpr('empcode', 'cefectos.empcode')} AND cefectos.proyec = '${proyec}'

So, in case of the column empcode is visible, the resultant SQL condition would be:

cefectos.empcode = 'DEISTER' AND cefectos.proyec = 'ID'

While, in case of the column is hidden, the resultant SQL condition would be:

cefectos.empcode = cefectos.empcode AND cefectos.proyec = 'ID'

The groups of headers in an object allow making groupings of columns under the same title. The utility in the use of this type of group is to provide the user with a more didactic and intelligible presentation of a report.

The grouping criteria of the columns respond to the existence of a common link between them, which can be of a very different nature: administrative area (purchasing, sales, logistics, etc.), type of documents (orders, delivery notes, invoices, etc.), temporary periods, etc. The output fields that are going to belong to the same grouping must be assigned the same header group.

Insert in the headers field the label code from the wic_jdic_lbldata, so that it will use the idiomatic descriptions of the label in the header group.

For those cases in which you are interested, you can indicate to the system by which output fields you want to make totals and subtotals, as well as accumulated carried forward.

The possible indicator values are as follows:

• N. No aggregate: this value would be the one used for those columns in which you do not want to obtain or make any total or summation. This is the default value displayed by the system.
• Sum. This value is the one that will be indicated for those numeric columns, for which you want to obtain a total of the column, as well as subtotals in the cases in which the object has break groups.
  If the object had no break groups, it would simply present a Grand Total at the end of the report.
  If the output field consists of a column type percentage, the system will also calculate the percentage of totals and subtotals, as long as the columns involved in the calculation of the same (dividend and divisor), also get totals.
• Accumulated. This value will be reported in those cases in which you want to drag an accumulated value for each record that is displayed. If the object had breaks, in the columns in which this value was reported, the total of the break will coincide with the amount accumulated until the break.
  
• AVG. Takes arithmetic mean of the values.
• Count. Counts the number of values in that field that aren't blank.
• Count (Distinct). Counts the number of different values in that field.

The reports allows to write expression in the UEL format. These expressions can be configurated writing a formula in the column Formula into the Output section.

In this example, the column Store sales/Unit sales (UEL) has been parameterized to divide the columns Store sales and Unit sales. This column has a background style.

Using this parameter, we indicate to the system the number of decimal places of precision that we want to show us in a numerical field.

When you want the system to display the same number of decimals as that of the field's own physical definition within the table to which it belongs, then we will indicate the value Auto here. This value is the one presented by the default system. In fact, for those fields that are alphanumeric, it will be the value used, regardless of the one that has been reported.

If the physical definition of the field does not support decimals, the system will not display decimals even if it is prompted to do so. For this, it would be necessary to vary the physical definition of the field itself.

The report outputs can colorize data cells depending on its content, generally to emphasize the importance of a cell among a group of cells or to classify the dataset when it contains numeric values.

Just by indicating the color rule definition rule_code in the out_palette field is enough. Use the Table Colorizer tool and you will make it easier to analyze reports at a glance.

It is possible to define different expressions that will determine the style of the cells in the report. The expressions are applied to columns. The Color and the Fonts definition have been separated into two tabs.

In this tab, it is possible to define the color of the text (foreground) and the background of the cells. To do this, expressions are assigned to columns: the foreground or background of the cells defined by the field column will change color when the conditions of the expression field are met. It should be noted that:

• The column of the field column and the column of the field expression can be different or the same.
• If the field column is not defined (null) and the expression is defined (not null), the color definition will affect all columns.
• If the field column is defined (not null) and the expression is defined (not null), the color definition will affect only that column.
• If the field column is defined (not null) and the expression is not (null), the color definition will be always applied to that column.
• It is possible to define the column by using the metacharacter *. For example, the expression on a column defined as sql_* will affect all columns that start with the letters sql_, for example, sql_store and sql_grocery. When the field column has a metacharacter *, the column on the expression has to be getCurrentColumnValue(); this way all the columns that meet the definition will apply the expression.
• If two expressions apply to the same cell and there is no order, the system will apply the color of the first expression established.
• If two expressions apply to the same cell and it has been established order in the corresponding field, the system will apply the colors depending on the order established.

In this tab, it is possible to define the font of the cell text. To do this, expressions are assigned to columns: the cells defined by the field column will change text font when the conditions of the expression field are met.

The definition of font works the same as the definition of color, so all the notes that apply to color should be taken into account for the font application.

• Font family: this field specifies a list of preferred fonts that a browser should use to write the content. Font names should be capitalized. The most common are: Activa, Arial, Arial Narrow, Brush Script MT, Candara, Calibri, Cambria, Comic Sans MS, Courier, Courier New, Copperplate, Cursive, Fantasy, Garamond, Geneva, Helvetica, Liberation Sans, Lucida Bright, Monaco, Optima, Perpetua, Symbol, Times, Times New Roman, Verdana ...
• Weight: the weight of a font is how bold it is. The font-weight property affects how heavily the text is drawn on a page. Choose between normal, bold or define a numerical value: 100, 200, 300, 400, 500, 600, 700, 800, 900. Each value is one degree bolder than the previous one. Normal is equivalent to 400. Bold is equivalent to 700.
• Style: this property, provides control over several different effects on text. They can be Normal, Italic, Oblique or Backslash.
• Size: it specifies how large text appearance in pt. The point size refers to the height of a character.
• Transform: it allows you to specify the capitalization of text. There are various types of capitalization: uppercase, where every letter is in uppercase; capitalize, where every word is capitalized; lowercase, where every letter is in lowercase; initial, where every initial letter of every word is capitalized; and inherit.
• Decoration: this property provides control over several different effects on text. They can be None, Underline, Overline or Line through.
• Align: the alignment possibilities are none, left, right, center, justified, initial or inherit.

A hyperlink represents a way or resource to connect a certain report with the universe of possible queries related to any of the existing concepts in the report.

The definition of hyperlinks in objects will be what allows us to deepen into the information of a database both horizontally ( drill across) as vertically ( drill down).

Any hyperlink that is defined in an object must be assigned to one of the output fields of the object itself, regardless of the field in question.

Generally, the object behind the hyperlink will provide related information with the output field in which it has been defined. In principle, there is no limitation on the number of hyperlinks that can be defined for an output field.

When the system detects that an object has associated hyperlinks, when displaying the result in HTML format, they will appear reflected in the field in which they have been defined.

It is possible to place more than one hyperlink to a field, so with the order, we define the system the position in which we want to place this hyperlink.

This will be the order in which the hyperlinks will be presented in a certain output field; hence, for each field, it is a new numbering.

Name of the column where you want to define the hyperlink. The column indicated here must correspond to one of the output fields of the object; otherwise, it could not carry out the definition of the hyperlink.

This field only allows two options:

• Cell: applies the link to the indicated cell.
• Cell (stars with): applies the link to those cells that start with expression indicated here. This is used when the cells to apply the link are dynamic and we cannot know specifically in which they will have to be applied.

When a hyperlink is defined in a certain field, by default, this hyperlink will always be active and capable of being executed.

Now, the system allows the possibility of activating hyperlinks based on certain pre-established conditions.

This option is very useful since on many occasions it will be interesting to activate a hyperlink when certain conditions exist, since in any other case its execution is not interesting, or even make no sense.

When this happens, in this field you can establish the conditions that must be met for the hyperlink to be active; that is, available for execution. The syntax of these conditions must be expressed in Javascript language.

When the hyperlink is of type alarm, in addition to activating the hyperlink, this will appear reflected on the screen in a blinking manner.

As mentioned previously, the conditions established must refer to the information of the object itself; that is, to the values of the fields included in the object.

Suppose that in a sales report broken down by months we define a hyperlink in each of the periods to obtain the detail of sales by clients.

In this case, it could happen that in a certain period the sales were 0, therefore the execution of the hyperlink would not make sense since it would not provide any information.

For this case we could establish the following condition in the hyperlink of each of the objects: #month!=0; where month would be the name of the field that would correspond to the sales of each one of the periods.

Another example could be a report that obtained a summary of invoices issued and received from a third party. (person external to the company serving as customer and supplier at the same time).

Assuming that there is a record of invoices issued and another of invoices received, if you want to establish a detailed query of each invoice by accessing the registry of each one, it would be necessary to define two hyperlinks for the invoice number field, so that one would go to obtain the detail of the received invoices (accessing the received invoices register) and another for those issued (accessing the register of issued invoices).

In this case, in each hyperlink a condition would have to be established, so that only one of them would appear active, depending on whether the invoice is issued or received.

Assuming that the source object has a field (tipfac) that indicates if the invoice is issued or received, For the hyperlink to access the register of issued invoices, the following condition should be established: '#tipfac'=='E' and for the hyperlink to access the invoice register received: '#tipfac'=='R'.

With these conditions, when it was an invoice issued, the hyperlink to access the issued invoices would appear active and that of the received invoices deactivated. If it were a received invoice the same would happen but in reverse.

There are four different possibilities of opening links:

• Default: opens the report link on the same window.
• New window: opens the report link on a new window.
• Modal window: opens the report link on a modal window, but does not refresh data after closing it.
  A modal window creates a mode that disables the main window but keeps it visible, with the modal window as a child window in front of it. Users must interact with the modal window before they can return to the parent application. This avoids interrupting the workflow on the main window.
• Modal and refresh: opens the report link on a modal window and refreshes data after the modal window closes.

The object to link or target consists of an object that will provide information related to the source or with any of the concepts involved in it.

The name of the object to be linked must be an object that has the physical name of a table in the database as code.

This object can be one of the existing ones in the object definitions of the repository database that we are defining, or it could also be an object contained in the object definitions of another repository database. For the latter to be viable, it is necessary that, in the system configuration database ( wic_conf ), the operating database is assigned as a repository database, all those that contain object definitions that may be involved in the hyperlink definitions.

Otherwise, the system would not be able to locate the definition of the hyperlink destination object, which would prevent its execution.

The ultimate goal of defining a hyperlink is to obtain, it directly and instantly, information related to the source object thereof; that is, with concepts contemplated in the source object.

For the information obtained to be related to the information of the source object, the destination object of the hyperlink must be aware of some data corresponding to the source object.

Precisely, using the condition that is established here, it will transmit to the target object the information that is desired to obtain concerning the source object. If this condition is not established, executing the hyperlink would be equivalent to execute the target object of the hyperlink individually and independently.

The link condition of a hyperlink consists of an SQL statement. Compared to previous versions and to improve security, the URL does not show the link condition, instead, it will show a reference to the link that will be executed by the server on the object.

This link condition, that will be executed with the hyperlink, would be equivalent to executing the target object of the hyperlink independently, but informing you of a selection criterion equivalent to the established hyperlink condition.

The definition of this SQL statement will largely depend on the definition of the source and destination object of the hyperlink, concerning input fields and variables query.

Based on this, the cases that can occur will be the following:

• A. Both the source and destination object of the hyperlink, they only have input fields.
  This case would be the simplest. In it, it is normal for the SQL statement of the link condition to refer to one or more fields in the source report, preceded by the term # and enclosed in quotation marks '' if alphanumeric, and include all source object selection criteria using the AND $0 operator.
  To include the source selection criteria, the tables in the FROM clause of the target object must include the tables in the input fields of the source object, otherwise, it will give SQL errors.
• B. The source object contains input fields and variables, while the destination only contains input fields.
  Here, as in the previous case, the SQL statement will include some or some fields of the source report and as far as possible the selection criteria. What it should always include would be the variables of the source object, as long as it has not already been considered as a field.
  If the variables are not included, the information resulting from the hyperlink may not be consistent with the source information.
• C. If the source and destination object contain input fields and query variables.
  First of all, the first thing to achieve is to be able to transfer to the variables of the target object the necessary and coherent value for the hyperlink, that in some cases will be a field of the own report origin and in others will have to be some of the variables of the object origin.
  This is accomplished through the variable assignment associated with a hyperlink. In case of not being able to transfer some data to any of the variables, it would not be any problem, because when executing the hyperlink, the system would request it automatically.
• D. There are only input fields in the source object and there are input fields and variables in the destination.
  As in the previous case, the first thing to do is define the variable assignments, so that as far as possible none are left unreported.
  Subsequently, it will be possible to define the SQL statement so that those particularities that the variables do not cover are contemplated. If it were not necessary to define it, it would be left blank or reported (1 = 1) in case the SQL statement of the target object contained the operator AND $0 .
• E. Both the source object and the destination have only query variables.
  In this case, the only thing that can be done is to define variable assignments, and those that could not be reported will be requested by the system in the execution of the hyperlink.
  Nothing will be reported as an SQL statement or (1 = 1) if the target object is contained in your SQL statement the AND $ 0 operator.

A link can reference an object which requires input variables for its execution. Those variables can be parameterized, so the variables will be filled with the information of the report execution or even the information of each row of the report.

It is very easy to define the link to variables of a target object. It will only be necessary to define two fields:

• Variable name: which corresponds with the name of the variable in the target object, without further symbols (neither #, nor $, nor anything). It is case insensitive.
• Value: which can be defined using several expressions as it is shown bellow.

Depending on the source of the value and the complexity of the expression it can be used serveral syntaxes.

The most common and powerfull syntax to define the value of variables is by using JUEL expressions. JUEL expressions syntax is like:

${ expr }

In the link context, UEL expressions have access to the values of each row of report directly by the name of the column ${ colname }. Variables can be referenced via the variable method (${ variable('varname') }).

Some samples of UEL expressions are:

${ empcode }
${ cantid*precio }
${ empcode != null ? empcode : delega }
${ variable('DATEINI') }
${ date:today() }
${ date:current() }
${ date:firstDayOfWeek(date:today()) }

Variables can also be referenced via the common syntax:

$VARNAME

It exists some special words which returns specific values:

• $DBMS: Obtains the name of the current database.
• $USER: Obtains the name of the session user.
• TODAY: Obtains the current date, it does not include the time.
• CURRENT: Obtains the current date, including the time.

If the expression is not preceeded by '$' and is not a System util clause it will be parsed as a text constant. Notice that the constant will be always evaluated as text.

A1      -> 'A1'
17      -> '17'
17.14   -> '17.14'

The page links allow easily changing the view between various reports. The developer only has to define the linked reports in the Page links section.

Besides, the developer can determine the SQL conditions of the reports and the variables.

Procedure:

• Define each report as an independent object.
• Access the Link page of one of them.
• Object code*: add all reports to be linked (included this one).
• Send query: check this indicator to propagate the parameters of a query from one report to another. This way, the target object will show the result with the same query condition used in the first report.
• Condition: optionally, define a SQL condition to execute each report.
• Variable: you can access the definition of input variables, which are propagated from the main report to the linked report.

In this example, the user can toggle between the Annual report, Monthly report and Daily report by just selecting one of them in the drop-down menu.

Axional Studio provides a wide range of printing modes depending on the purpose and the data to be printed. The different tools allow printing from a simple report as a list of records to printings of advanced design and high quality.

This is the default layout used to retrieve data without DML. These reports can deliver simple grid designs but also more complex representations. The printing will take into account the styles defined for report.

Report Printing

It is possible to generate a PDF of the report with a different look than the same report on screen. This allows the developer to bring a professional and modern style to the reports generated in PDF, without losing efficiency during on-screen display.

Access the PFD configuration through the PDF CONFIG tab. Here the configuration code must contain a Javascript function called config, which receives the parameters rs and config.

function config(rs, config) {

	// configuration parameters

}

The printing parameters for this example are:

For further infomation, see Axional JS Script Library/ResulSet/Report.

The execution of the new reports allows showing the log generated using Javascript code and the function console.log. This process is highly useful for identifying and removing errors from the report definition. Have in mind that it is only possible to perform logs when a Server Javascript is executed.

Once the report has been executed, the logs can be displayed on the Query information screen of the report. The execution of this example report shows the logs on the Query information screen. This screen will also show possible errors during execution.

This is the example code that generates these logs:

<script>
	for(let i = 0; i < 10; i++)  {
		console.log('Execution [' + i + ']');
		Ax.lang.System.sleep(500);
	}


    return 'Execution complete';
</script>

Progress elements are used in the program to graphically show the progress of a process. Generally, they serve to inform users about their evolution when processes last more than a few seconds. For this reason, they are intended to give certainty to the person who waits that a process is still running, giving an idea of the elapsed time and the time remaining for its completion.

The Progress notification is the feature that allows you to notify the progress of the execution of a process through the report loading window. Notification of progress can be made using three indicators:

1. The phase or task of the running process
2. The subtask of the running process
3. The percentage bar of the process completion

Indeterminate progress
	When console.get.Progress value is 0, the Progres notification will display no task nor subtask, and the percentage bar will remain undetermined with a random movement.
Copy Javascript Function <script> let totalTime = 4000.0; let numSteps = 300; let sleepTime = totalTime/numSteps; let progress = console.getProgress(0, 'Preparing data...'); for (var row = 0; row < numSteps; row++) { Ax.lang.System.sleep(sleepTime) } return 'Execution complete'; </script>

Phase/task description progress
	To notify only the task or phase of the process, a progress instance must be created using the function console.getProgress. The phase/task can be updated with the function setTaskName function.
Copy Javascript Function <script> let totalTime = 4000.0; let numSteps = 300; let sleepTime = totalTime/numSteps; // Initialize process progress with // an indeterminate percentatge and an initial task description let progress = console.getProgress(0, 'Preparing data...'); for (var row = 0; row < numSteps; row++) { Ax.lang.System.sleep(sleepTime) } // Update process task description progress.setTaskName('Executing process...'); for (var row = 0; row < numSteps; row++) { Ax.lang.System.sleep(sleepTime) } return 'Execution complete'; </script>

Subtask progress
	Process subtasks can also be notified, using the function setSubTaskName.
Copy Javascript Function <script> let totalTime = 8000.0; let numSteps = 300; let sleepTime = totalTime/numSteps; // Initialize process progress with //an indeterminate percentatge and an initial task description let progress = console.getProgress(0, 'Executing process...'); for (var row = 0; row < numSteps; row++) { // Update process subtask progress.setSubTaskName('Task ' + (row+1) + '/' + numSteps) Ax.lang.System.sleep(sleepTime) } return 'Execution complete'; </script>

<script>
  let totalTime  = 8000.0;
  let numSteps  = 300;
  let sleepTime  = totalTime/numSteps;
  // Initialize process progress with
  // an indeterminate percentatge and an initial task description
  let progress = console.getProgress(numSteps, 'Executing process...');
  for (var row = 0; row < numSteps; row++) {
    // Update process subtask
    progress.setSubTaskName('Task ' + (row+1) + '/' + numSteps);
    // Increase process completion in 1, from the initital defined steps (300)
    progress.worked(1);
    Ax.lang.System.sleep(sleepTime)
  }
  return 'Execution complete';
</script>

<script>
    let totalTime   = 8000.0;
    let numSteps    = 300;
    let sleepTime   = totalTime/numSteps;
    let progress =  console.getProgress(numSteps, 'Executing process...');
    for (var row = 0; row < numSteps; row++) {
    progress.setSubTaskName('Task ' + (row+1) + '/' + numSteps)
        progress.worked(1);
        Ax.lang.System.sleep(sleepTime)
    }
    return 'Execution complete';
</script>

Structs is an option to represent the data in different graphic models. The obtained data of the query must have a specific structure to create the graphics.

The types of graphic are:

• Line
• Area
• Vbar
• Percentage
• Double percentage
• Max - Min
• Balls

In this case, the columns show multiples examples of graphics:

• Unit sales: Balls
• Monthly sales: Vbar
• % : Percentage
• Monthly cost: Line
• Diff. prev : Max-Min

<select first='15'>
    <columns>
        store.store_id,
        store.store_name || ' (' || store.store_city || ')' store_name, 
        
        <!--g.unit_sales,-->
       row('ball', 'Units', g.unit_sales, (select Min(abs(a.unit_sales)) from agg_c_special_sales_fact_g a),(select Max(abs(a.unit_sales)) from agg_c_special_sales_fact_g a)) Bunit_sales,
       
       g.sales,
       row('vbar colored', 'Jan', sales_jan, 'Feb', sales_feb, 'Mar', sales_mar, 'Apr', sales_apr, 'May', sales_may, 'Jun', sales_jun, 'Jul', sales_jul , 'Aug', sales_ago, 'Sep', sales_sep, 'Oct', sales_oct, 'Nov', sales_nov, 'Dec', sales_dec) sales_m,
       row('percent', '%', g.sales_pct, 0,(select Max(abs(a.sales_pct)) from agg_c_special_sales_fact_g a)) sales_perc,
       
       row('line', 'Jan', cost_jan, 'Feb', cost_feb, 'Mar', cost_mar, 'Apr', cost_apr, 'May', cost_may, 'Jun', cost_jun, 'Jul', cost_jul , 'Aug', cost_ago, 'Sep', cost_sep, 'Oct', cost_oct, 'Nov', cost_nov, 'Dec', cost_dec) cost_m,
       
       row('mm', 'cost', (g.cost_prev - g.cost), (select Min(a.cost_prev - a.cost) from agg_c_special_sales_fact_g a),(select Max(a.cost_prev - a.cost) from agg_c_special_sales_fact_g a)) cost_dif
       
    </columns>
    <from table='agg_c_special_sales_fact_g' alias='g'>
        <join table='store'>
            <on>g.store_id = store.store_id</on>
        </join>
    </from>
    <order>1</order>
</select>