TO DO

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

1 Database servers

Menu path:
Database Servers / Servers
Definition of the database servers registered in the system.
wic_database_server
Label Description
Database server Unique server code
Name Free text description of server
Driver JDBC Driver used to connect to the databases.

  • Values:
    • informix: .
    • oracle: .
    • postgres: .
    • db2udb: .
    • mysql: .
    • sqlserver: .
    • derby: .
    • hive: .
    • sqlite: .
User User that will be used for administrative connections to the databases located on this server.
Such user must be previously created in the database server with the necessary permissions.
Password User password for administrative connections.

  • Default: crypt(server_password)
Mirror When a server has a replication, the secondary (mirror) can be specified in this field.
This informative field will be used by database connection groups that can access the secondary server.
In this case, the system will inherit the entire configuration from the first server to the second, so that all users who access the first server will also be able to access the second in the same conditions.
One of the advantages of the use of mirror servers in the system, one might mention reporting . The mirror server could be used to obtain reports that, due to its characteristics, consume excessive resources from the database server, thus preventing penalization of the primary exploitation server.
To provide this functionality, the database connection group is required to define the 'Pool type' field with the value 'allow secondary'.
In the event of secondary server service crash, towards redirecting accesses to secondary server, at least one of the following options should take place: a) Eliminate definition of the 'mirror' field. b) Modify 'Pool type' field with 'primary only' value for all database connection groups (only those that have some database assigned to secondary server).

The server specified herein as mirror must have been previously registered in this form.
Environment
  • A Development environment is where you configure, customize,

    and use source control to build an image of the Waveset application to be promoted to another environment.

    You also write an upgrade procedure in this environment that you follow in each target environment.

  • A Test environment is where you test your upgrade procedure against controlled data and perform

    controlled testing of the resulting Waveset application.

  • A QA environment is where you test your upgrade procedure against data, hardware, and software

    that closely simulate the Production environment and where you allow intended users to test the resulting Waveset application.

  • A Production environment is where the Waveset application is actually available for business use.

This flag is override by wic_database_object with same column

If wic_database_object.database_environment is informed prevails from server.



  • Default: NULL
  • Values:
    • NULL: .
    • DEV: Development.
    • TEST: Test.
    • QA: Upgrade test.
    • PROD: Production.
Locked Flag to enable or disable users access to databases. Generally used for maintenance of the databases.

  • Default: 0
  • Values:
    • 1: Yes.
    • 0: No.
Protocol Connection protocol used by the specified driver.
Driver Protocol
Informix jdbc:informix-sqli
db2udb jdbc:db2j:net
oracle jdbc:oracle:thin
mysql jdbc:mysql
sqlserver jdbc:sqlserver
postgres jdbc:postgresql
hive jdbc:hive2
Host Host name or IP of the server
Port Port associated to the database service.
Service Name of database service. In informix determines the Informixserver, in Oracle the TSName.
Options Additional arguments to connect to the database server, as for e.g. ENABLE_TYPE_CACHE
Information Additional description of server (free text).
Initial SQL SQL statements for initial connection. They will be executed in all server databases when establishing the first connection with each of them.

Here are some SQL statements examples:

  • IBM-IDS database agent (INFORMIX)
    • SET LOCK MODE TO WAIT 5;
    • SET ISOLATION TO COMMITTED READ;
    • SET ISOLATION TO DIRTY READ;
  • ORACLE database agent:
    • ALTER SESSION SET NLS_SORT='ASCII7'
Physical configuration This field allows to program rules in code xml to specify the data disposition in the logical areas (dbspaces) of server, indicating where must be saved the table data, data corresponding to indexes and the columns CLOB/BLOB type.
The rules are evaluated in the order in which they are introduced and the first one that meets the condition is taken. The condition consists of:
  • starts: indicates a start pattern of the table name. For example, if 'gdwh' is indicated, the tables that have this prefix, it is to say, that they begin with 'gdwh', will fulfill the condition and will use this instruction.
  • database (optional): name of the database. This parameter is optional. Indicates the name of the database to which the instruction applies. If not indicated, it applies to all databases.
If any definition that meets the condition is found, the table or index will be created in the dbspace indicated in the body of the xml tag.

There are four tags to indicate where they are located:
  • Data:
            <tablelayout starts='TABLE_NAME_PREFIX' [database='DATABASE_NAME']>
  • Indexes:
                <indexlayout starts='TABLE_NAME_OF_INDEX_PREFIX' [database='DATABASE_NAME']>
  • Blobs:
                <bloblayout starts='TABLE_NAME_PREFIX' [database='DATABASE_NAME']>
  • Clobs:
                <cloblayout starts='TABLE_NAME_PREFIX' [database='DATABASE_NAME']>

An example of syntax would be as follows:
<databaselayout>

    <!-- Layout for application dictionary tables : -->
    <tablelayout starts='wic'>d_wics</tablelayout>
    <bloblayout starts='wic'>s_wics</bloblayout>
    <cloblayout starts='wic'>s_wics</cloblayout>
    
    <!-- Layout for finance tables : -->   
    <tablelayout starts='c'>d_icon</tablelayout>
    <indexlayout starts='c'>i_icon</indexlayout>
    <cloblayout starts='c'>s_icon</cloblayout>
    <bloblayout starts='c'>s_icon</bloblayout>
    
    <!-- Layout for treasury tables : -->
    <tablelayout starts='t'>d_icon</tablelayout>
    <indexlayout starts='t'>i_icon</indexlayout>
    <cloblayout  starts='t'>s_icon</cloblayout>
    <bloblayout  starts='t'>s_icon</bloblayout>
    
    <!-- Layout for Datawarehouse tables : -->
    <tablelayout starts='gdwh'>d_gdwh</tablelayout>
    <indexlayout starts='gdwh'>i_gdwh</indexlayout>
    <cloblayout  starts='gdwh'>s_gdwh</cloblayout>
    <bloblayout  starts='gdwh'>s_gdwh</bloblayout>
    
    <!-- The demo_test tables that start with g will be installed in the following dbspaces -->
    <tablelayout starts='g' database='demo_test'>d_test</tablelayout>
    <indexlayout starts='g' database='demo_test'>i_test</indexlayout>
    <cloblayout  starts='g' database='demo_test'>s_test</cloblayout>
    <bloblayout  starts='g' database='demo_test'>s_test</bloblayout>
    
    <!-- The tables that start with g from the rest of the databases will be installed in the following dbspaces -->
    <tablelayout starts='g'>d_iges</tablelayout>
    <indexlayout starts='g'>i_iges</indexlayout>
    <cloblayout  starts='g'>s_iges</cloblayout>
    <bloblayout  starts='g'>s_iges</bloblayout>
    
    <!-- The remaining tables of all the databases will be installed in the following dbspaces -->
    <tablelayout >d_data</tablelayout>
    <indexlayout >i_data</indexlayout>
    <cloblayout  >s_data</cloblayout>
    <bloblayout  >s_datas</bloblayout>
    
</databaselayout>

1.1 Database connection passwords

Using this option, access the register passwords or passwords of groups of users of electronic connection in the system. It can even record different passwords for each database server existing in the system.

wic_database_server_users
Label Description
Database server
User User code
Password

  • Default: crypt(server_password)
Info Information
Date updated Updated date

  • Default: CURRENT

2 Elastic node

Menu path:
Databases / Elastic node / Node

Parametrization a set of ordered and trained servers.

An automated database crawling system will use this parameterization to determine on wich server to perform the creation of the database.