Folders

This function is used to create and update a folder. A folder is a complete reference, identified by a code, in which is found all the setups and management rules and all the data used. A folder is characterized by:

  • a root directory and a group of sub-directories on the application server. The SAFE X3 objects originating from the setups can be found there.
  • an Oracle user (or a user combination, login with SQL server) defined for the database server. All the database tables are attached to it.

The creation of a folder is necessary before starting the setup and/or the entry of data. This operation is relatively long. As much as it is normal to revalidate the folder in the process of setup when the configuration setups are changed, it is best to create the folder(s) directly with the good setups that will be used in production. Indeed, this phase will determine the correct initial sizing for the database and will avoid the later requirement to use the production tools of the database to resize it. In addition, in the production folder, a revalidation can be a relatively long operation and requires that no one be connected to the folder being processed.

A reference folder is always the starting point for the creation of a folder. The benefit in using a reference folder is to be able to start with a basic setup. The supervisor folder, which can serve as the reference folder, and which contains all the setups relative to the current language/country, is delivered with the software, but any other folder can act as the reference.

Prerequisites

See also Refer to documentation Implementation

Screen management

The setups of a folder are defined in the folder table. As soon as the folder is not created (i.e. validated by the corresponding button), these setups can still be modified with limits.

After creation, only some setups can still be modified. In order for a modification to be taken into account, the folder must be re-validated. This operation may be rather long since it may involve a change in the structure of heavy tables and a regeneration of the software screens and windows.

A folder is defined by an alphanumeric code of over 10 characters, to which a set of setups defined on tabs is linked.

Folder (field DOSSIER)

The name of the folder can take a maximum of 10 alphanumeric characters. The first letter must be alphanumeric.

Name (field NOMDOS)

Enter the description of the relevant record.

This long description is used as a title in screens and reports.

Tab General

This tab contains the main organizational Information for folder definition.

Basis

Database type (field TYPDBA)

Define the database used to create the folder. This database can be SQL SERVER or ORACLE. As a function of the license that is used, this choice may be possible or imposed.
Volume (field VOLUME)

This "SAFE X3" volume number corresponds to the directory from where the physical files (not in the database) describing the folder objects are placed on the process server. The SAFE X3 volumes are defined in the "adxvolumes" file in the installation directory (contained in the ADXDIR environment variable). The default volume is A, but others can be defined on installing the software.

It is possible to select the volume using the key.

Please refer to the technical appendix on Volumes at the end of the Folder management documentation.

SQL server

Containment type (field TYPCNM)
Use file groups (field GRPFIL)

This question is asked in the case of a SQL database server is used to define if separate files are created or not to store the indexes and the data (for the important databases this is the normal case).

Base sizing

Data size (field SIZDAT)

These values are used to size the data files and the index in the database. The size is expressed in Mega-bytes.

These values are only interesting from the point of view of folder creation, and they are generally entered at the end of the definition of the folder parameters, just before the actual folder creation. In fact, to have available a correct estimate for the value, it is important to have previously sized the database tables by means of the sizing values ( Tables tab), and to have more importantly defined the table structure of the database by means of the activity codes (Options, Screens, Specifics).
Index size (field SIZIDX)
Format (field CODDBA)

Defines the set of characters used to store the character fields in the database. It can take the values ASCII or UNICODE.

  • The ASCII format is used for managing European languages: each character is stored on one byte and the accented characters on values higher than 128.

  • The UNICODE format is only useful when managing languages having sets of characters requiring over 256 combinations. This is the case for Chinese, for example.
    The SAFE X3 client is native UNICODE: it inherently ‘knows’ how to manage texts of this type. It can elect to choose one of the two following formats at the level of the database: UCS2 or UTF8.

    The UCS2 format is a format originating with Microsoft™ in which all characters are stocked in 2 bytes; the normal ASCII characters have the same code (but one of the two bytes in which they are coded is null). This is the only UNICODE format type that is supported by SQLServer. On the other hand Oracle accepts other formats, and in particular the UTF8 format, which is the most common. It features a format in which the characters are stored over a variable number of bytes (from 1 to 5 depending on the cases, the standard ASCII characters are stored over one byte, the accented characters use two and the Asian languages start beyond). It should be noted that Oracle supports other coding standards (UCS3, UCS4, UTF16...) and these standards can be used (on the condition that they are created manually in the database).

Internally and independently of the database format (for its temporary variables), the SAFE X3 engine uses the UTF8 format (the process sources are coded in UTF8), and the Windows client uses the UCS2 standard.

Folder type

Reference folder (field DOSREF)

The "reference " folder must be an existing folder, where the data dictionary will be used during the intialization of the folder. A link is made between a folder and the reference folder. Thus, by default, if a resource (process, table, report) is not found in the current folder, it is looked for in the reference folder, by an inheritance mechanism.

This value is taken by default in the copy folder, the folder from which, during the creation of the folder, it is possible to copy certain data (parameters, accounting plan...) as well as indicated in the Init tab.
Copy folder (field DOSCOP)

The copy folder, which must have been created previously, is the folder from which the data defined by the Init tab will be copied. This folder can be the reference folder, but equally another folder with an identical structure (for example, a parameterization folder in which the parameterization has been refined during the analysis phase, in which certain data can be introduced or recovered by import). It is important that the structure of the copy folder is identical (even if no control can be made, errors could be produced during the copy if this is not the case).
Purge folder (field DOSHIS)

This folder cannot be entered directly in the management of the folder. It is entered when an archiving folder is created after the creation of the live folder, by the corresponding function.

The archiving folder is used to store the data considered as not changing, so that they can be consulted off-line.
Start date (field STRDAT)

This date is used to define the date of the first financial year for a newly created folder.

This date is fundamental, because it cannot be changes at a later date. It corresponds to the start date of the first financial year from which the enterprise data will be managed with the software. Warning, it is advisable (for balances) to start from the previous financial year to the one that the installation will actually start with.

By default, the value of two supervisor parameters STRDAT and ENDDAT, which define the possible connection period, will be defined by :

  • STRDAT = Entry date
  • ENDDAT = max(STRDAT+ 12 months, Current date)

These parameters, which can be modified later, are used on the connection to the folder. It is controlled so that the entry date is contained between the dates defined by these 2 parameters.

Folder currency (field RPTCUR)

Makes it possible to update the parameter SYSCUR in the folder. This parameter cannot be further modified by the folder management after the generation of the folder.
Test folder (field TSTFLG)

The Test folder signifies that this folder is designed to receive a copy of the standard processes present in a patch, if this must be installed in the folder. If this flag is not set, the patch processes will only be integrated at the supervisor folder level. The fact of having this flag set makes it possible to carryout integration tests for patches in a folder. Once the patches in question have been fully integrated in this environment, it is advisable to "clean up" by deleting previously installed processes (if not, the next patch or version installation will not be taken into account by these processes, which risks the appearance of malfunctioning). A production folder must not have this flag set.
Specific folder (field SPEFLG)

This check box signifies that the specific/custom processes present in a patch will be installed in the folder even if they did not previously exist. The specific processes are identified by their name : They start either by X, Y or Z, or else by SPE, else they start with CNS and finish with SPE. If this flag is not set, only the previously existing specific/custom processes will be replaced in the folder by the new version present in the patch.

Grid Installed modules

Description (field LIBMOD)
Active (field MODULE)

This grid contains the modules retained for the folder to be generated. Only the functions and the tables associated with the activated modules will be usable in the folder once it has been created.

It is recommended to only enter the modules that are actually useful. In effect, this makes it possible to create only the tables and objects actually used and keep to a minimum the creation time and disk space taken. It is always possible to add modules at a later date. The list of modules and any constraints are given in an appendix at the end of the documentation describing the management of the folder.

Sizing

Image size (field BLBLNG)

This field determines the maximum size taken by default in the blob files (binary large objects) stored in the database. These fields correspond notably to the images stored in the database.

This field is defined as having the power 2 : 1 equivalent to 2 Kb, 2 to 4 Kb, 3 to 8 Kb and so on (the corresponding value is displayed up to 20, which corresponds to 1Gb).

It should be noted that each field of the type blob can be sized differently in the database (if the database type carries an explicit length, this default length is not used).
field BLBTXT
Text size (field CLBLNG)

This field determines the maximum size by default in the clob fields (character large objects) stored in the database. These fields corresponds notably to the texts stored in the database.

This field is defined to the power 2 : 1 equivalent to 2 Kb, 2 to 4 Kb, 3 to 8 Kb etc (the corresponding value is displayed, it can go up to 20, which corresponds to 1 Gb).

It should be noted that each field of the type clob can be sized differently in the database (if the data type carries the length explicitly, this default length is not used).

field CLBTXT

Tab Options

In this tab, two tables are found containing the activity codes relative to the data structure that is required. These codes can be set up as Yes or No:

  • the first table, named Options, contains the general interest activity codes.
  • the second contains the codes starting with K, which define the management options used for the localizations.

The activity codes linked to the legislations follow a specific rule for names: the second letter corresponds to the country for which the management option was developed.

The grid below details this rule:

Activity code

Legislation concerned

KF*

French

KG*

English

KI*

Italian

KP*

Portuguese

KS*

Spanish

KU*

American

KC*

Chinese

KA*

Argentina

In version 150, setting up the activity codes of this type to Yes does not mean that the legislation concerned is going to be used for all companies. However, they have to be activated for a given legislation to be used at least on one of the companies of the folder.

Note that all the possible codes do not necessarily appear in this grid; only the active codes taking into account in the retained modules are presented.

It is important to note that when a folder is created from a reference folder other than the supervisor folder, only the activity codes that have been set to Yes in the reference folder can be set to Yes in the created folder. In this way, if another folder is created later from the folder where options are defined, it is necessary that all the required options in the final folder are present in the reference folder at creation time.

Grid Options

Code (field CODACT1)

An activity code is used to:

  • Make an element optional in the dictionary if the value associated with the activity code is null
  • Identify the specific/custom elements if they are marked with a code starting with X, Y, or Z
  • Size a maximum number of lines when the activity code marks elements from a grid

If the activity code is disabled:

  • The marked element will not be useable
  • The associated code will not be generated nor activated
Description (field LIBACT1)

Title associated with the previous code.
Module (field MODULE1)

Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid.
Active (field FLACT1)

For development, setting this field to Yes activates the tables and screens or those fields in the tables and screens that depend on the activity code. Conversely, if the field is set to No, the screens and the tables, or the dependent fields, are no longer accessible and do not appear.

Caution: On operation, any activity code status change requires:

  • Modifying the activity code in the folder record from the parent folder.
  • Validating the child folder.

Grid Localizations

Code (field CODACT2)

An activity code is used to:

  • Make an element optional in the dictionary if the value associated with the activity code is null
  • Identify the specific/custom elements if they are marked with a code starting with X, Y, or Z
  • Size a maximum number of lines when the activity code marks elements from a grid

If the activity code is disabled:

  • The marked element will not be useable
  • The associated code will not be generated nor activated
Description (field LIBACT2)

Title associated with the previous code.
Module (field MODULE2)

Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid.
Active (field FLACT2)

For development, setting this field to Yes activates the tables and screens or those fields in the tables and screens that depend on the activity code. Conversely, if the field is set to No, the screens and the tables, or the dependent fields, are no longer accessible and do not appear.

Caution: On operation, any activity code status change requires:

  • Modifying the activity code in the folder record from the parent folder.
  • Validating the child folder.
Help

Is used to access the help defining the aim of the activity code, the values it can have and the impacted functions. This function can be access in all the grids where the values associated with the activity codes are entered (standard activity codes, localizations, specifics, screen sizing).

Tab Screens

In this tab, a single table appears. It contains the activity codes of two types, which are related to:

  • the sizing of grids in the screens of the software (indeed, the screens which are used to enter multi-line documents are sized statically upon entry of a function).
  • the sizing of some values that are stored randomly in the database. In this case, there are normally few values (less than a hundred).

A positive value must thus be entered with respect to these activity codes.

The activity codes of the first type are only used to define a quantity of memory used for the screen, their modification involves only the revalidation of the concerned screens and windows. It is however important to note that seriously over-sizing certain values for this table will incur the need to have available increased amounts of allocated memory for each workstation. If the memory sizing is insufficient, the No more memory available error message is likely to be displayed on the screen during the use of the software, the function concerned being stopped. It should be noted that it is possible to define additional memory quotas for the given menu profiles (if certain functions that are particularly heavy memory consumers are reserved to certain users only, this can be set up in this way).

With respect to each activity code of second type, a dimension is entered to define the number of values that can be entered in the associated screens, but also the structure of the corresponding tables in the database. Modifying these values thus results upon re-validation of the folder in a structure change of the concerned tables.

A maximum value for the database is displayed for this type of activity code. This value cannot be exceeded because it would result in a table with a number of columns or with a line size different from the allowed values.

In some cases, a minimum value for the database can be displayed. If the value entered is inferior to this value, it will be possible to enter less occurrences in the screens than what the database can store. If the entered value is superior, both sizing will be identical. This minimum value exists because if some fields were not in the database, there is a risk that the standard Crystal Reports might not work anymore.

Grid Functional sizing

Code (field CODACT3)

An activity code is used to:

  • Make an element optional in the dictionary if the value associated with the activity code is null
  • Identify the specific/custom elements if they are marked with a code starting with X, Y, or Z
  • Size a maximum number of lines when the activity code marks elements from a grid

If the activity code is disabled:

  • The marked element will not be useable
  • The associated code will not be generated nor activated
Description (field LIBACT3)

Title associated with the previous code.
Module (field MODULE3)

Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid.
Screen size (field DIME3)

Define the number of occurrences used in the screens and also in the tables involved, remembering that for a table, a minimum number (and a maximum number) can exist, all of which will lead to the use of the following formula to size the tables

min(max(MIN,SCREEN),MAX).

Min extension (field DIMIN3)

Define the minimum number of columns stored in the database (independently of the number displayed in the screen, which can be lower). This is used to avoid the standard reports making reference to columns not likely to exist according to the parameterization.
Max extension? (field DIMAX3)

Define the maximum possible dimension taken into account in the table structures in the database.

Help

Is used to access the help defining the aim of the activity code, the values it can have and the impacted functions. This function can be access in all the grids where the values associated with the activity codes are entered (standard activity codes, localizations, specifics, screen sizing).
Help

Tab Tables

This tab makes it possible to give information for a certain number of values making it possible to then calculate a sizing algorithm:

for each database table, a physical storage size is estimated. This physical size is used during the definition of the table characteristics (planned size, extents management in Oracle, for example).

by cumulative, the global size of the database

It is important to enter these setups correctly by taking into account the requested history (if for example, there is a database with 500,000 records per year and 5 years of history is requested, it is necessary to allocate 250,000 to the corresponding VOUCHER setup). Indeed, if this is not done correctly, a reorganization of the database and its setups will be necessary at a later date to avoid fragmentation of the data and to obtain an optimal response time.

Grid Table sizing

Code (field DIMCOD)

The sizing elements are used in the sizing formulas calculations to estimate the number of lines planned for each table and from this are used to calculate the planned size of the tables.
Description (field ZDIMCOD)

Title associated with the previous code.
Module (field MODULE5)

[object Object]

Value (field NBR)

This number corresponds to the value linked to the sizing element of the line.

Help

Is used to access the help defining the aim of the sizing variable, the values it can have and the impacted functions.

Tab Init.

In this tab there are default values used upon actual folder creation and setups influencing the way a folder is to be re-validated:

  • The copy options are used to enter the data of some tables from the table content of another folder (the copy folder declared in the first tab, the default reference folder). This is made upon folder creation or upon revalidation if a module addition activates the table that were not used yet.
  • The grid Validation of transactions is used to prevent all screens that can be set up to be revalidated from the base screen (in the setups menu in all modules) upon revalidation of a folder. Since the revalidation may take time and is not necessary if the structure of the base screens has not changed, it can be avoided by answering No to the question. When answering No by mistake or avoiding the folder revalidation time on purpose, it is still possible to relaunch the validation via the dedicated function.
  • The checkboxes Update are used to avoid the code regeneration associated with the revalidation of a certain number of elements in the dictionary upon folder revalidation. This is done in order to shorten the revalidation time. For security reasons, these boxes can only be unchecked in a development folder, and it must be done with caution. This can also be done later on via a dedicated function.
  • The language table makes it possible to define a list of languages that can be used by users connected to the folder. It is advised to only select those that are actually useful, because this slows down the folder creation (part of the files linked to the windows are generated for each language retained).

Grid Transaction validation

Module (field MODTR)

[object Object]

Y/N (field TRVAL)

A positive response to the question leads to the validation of the transactions associated with the module.

Grid Languages

Languages (field LAN)

Grid used to enter the languages that may be used in a connection to the folder. The validation of the folder causes the entry screen generation in all these languages : this operation consumes a lot of system resources.
Translation ref (field LANREF)

This check box can only be checked if the following two connections are met :

  • the language is a language not shipped as standard by the editor.
  • this language is not already checked for another folder in the current environment (also known as the solution).

It is used to specify that the current folder is the reference folder for the translation of the language in question, that is to say it is the folder that carries the most up to date translations for the language concerned.

By default for the languages shipped as standard, it is of course the root directory, which is explain that the box can no longer be checked in a standard folder; but for the "non standard" languages the user is free to define a translation reference folder.

A control verifies the uniqueness of the translation reference folder for a language, in order to change it, it is first necessary to un-check the folder previously set as the reference.

If for a language, there is no reference folder is checked, it is selected in the following order :

  • the root folder (if the language concerned is defined in it)
  • the first folder (in alphabetical order) that contains this language.

Grid Legislation

Legislation (field LEGDOS)

Grid Copy data

Copy options (field LIBCOP)

Each group corresponds to a coherent group of tables in the copy folder, tables where the contents can be copied in the folder currently being parameterized during its creation.

By right click on the field access is obtained to the list of tables where the contents can be copied if the response is Yes.
Y/N (field OPTINI)

As a function of the response, the data is copied or not from the folder copy. This copy is only carried out during the creation of the folder or in the case of the creation of the tables following the activation of a new module.

Default values

Default language (field LANDEF)

Makes it possible to update the parameter LANGAGE (main language) in the folder. This parameter is used to define a connection language when it is not specified for instance in the case of batch processes.
Default country (field CRYDEF)

Used to update the CRYDEF parameter during the creation of the folder This parameter corresponds to the country proposed by default on entry of the addresses.
Recoding list (field CHGCOD)

This field is used to give a screen that defines a list of recodification codes. If this screen is entered, at the end of the creation, the setups copied from the reference folder are renamed according to the renaming rules defined by the considered codes (taken in the order).

This is particularly useful when, for example, the user wants to create a single-legislation folder: some setup codes, prefixed by a legislation code, are particularly heavy to use in that specific case, and the recodification can simplify the use of setups afterwards.

Update

Screen update (field CREMSK)

These fields are always checked in a normal delivery environment. They are used by the editor, in a development context, to re-validate a folder for testing avoiding the generation of the code corresponding to the options presented (screens, objects, windows, inquiries).
Windows (field CREWIN)
Object update (field CREOBJ)
Inquiries (field CRECNS)
Help

Tab Modifications

This tab defines the connection characteristics of the folder, notably information in the connection box of the workstation when connecting to the folder. Entering the information here is used to update a configuration file located on the server, in the root directory of the supervisor folder, and named X3APPLI.ini. This file can be remotely loaded on the client workstations with the aid of a suitable button, from the connection setups definition box.

Grid Transaction validation

Module (field MODTR)

[object Object]

Y/N (field TRVAL)

A positive response to the question leads to the validation of the transactions associated with the module.

Grid Languages

Languages (field LAN)

Grid used to enter the languages that may be used in a connection to the folder. The validation of the folder causes the entry screen generation in all these languages : this operation consumes a lot of system resources.
Translation ref (field LANREF)

This check box can only be checked if the following two connections are met :

  • the language is a language not shipped as standard by the editor.
  • this language is not already checked for another folder in the current environment (also known as the solution).

It is used to specify that the current folder is the reference folder for the translation of the language in question, that is to say it is the folder that carries the most up to date translations for the language concerned.

By default for the languages shipped as standard, it is of course the root directory, which is explain that the box can no longer be checked in a standard folder; but for the "non standard" languages the user is free to define a translation reference folder.

A control verifies the uniqueness of the translation reference folder for a language, in order to change it, it is first necessary to un-check the folder previously set as the reference.

If for a language, there is no reference folder is checked, it is selected in the following order :

  • the root folder (if the language concerned is defined in it)
  • the first folder (in alphabetical order) that contains this language.

Grid Legislation

Legislation (field LEGDOS)

Grid Copy data

Copy options (field LIBCOP)

Each group corresponds to a coherent group of tables in the copy folder, tables where the contents can be copied in the folder currently being parameterized during its creation.

By right click on the field access is obtained to the list of tables where the contents can be copied if the response is Yes.
Y/N (field OPTINI)

As a function of the response, the data is copied or not from the folder copy. This copy is only carried out during the creation of the folder or in the case of the creation of the tables following the activation of a new module.

Default values

Default language (field LANDEF)

Makes it possible to update the parameter LANGAGE (main language) in the folder. This parameter is used to define a connection language when it is not specified for instance in the case of batch processes.
Default country (field CRYDEF)

Used to update the CRYDEF parameter during the creation of the folder This parameter corresponds to the country proposed by default on entry of the addresses.
Recoding list (field CHGCOD)

This field is used to give a screen that defines a list of recodification codes. If this screen is entered, at the end of the creation, the setups copied from the reference folder are renamed according to the renaming rules defined by the considered codes (taken in the order).

This is particularly useful when, for example, the user wants to create a single-legislation folder: some setup codes, prefixed by a legislation code, are particularly heavy to use in that specific case, and the recodification can simplify the use of setups afterwards.

Update

Screen update (field CREMSK)

These fields are always checked in a normal delivery environment. They are used by the editor, in a development context, to re-validate a folder for testing avoiding the generation of the code corresponding to the options presented (screens, objects, windows, inquiries).
Windows (field CREWIN)
Object update (field CREOBJ)
Inquiries (field CRECNS)
Help

Tab Miscellaneous

In this tab is found a grid containing the values and characteristics associated with the activity codes starting with X, Y, or Z, which makes it possible to mark all specific/custom developments.

Grid

Code (field CODACT4)

Defines the custom/specific activity codes (i.e. starting with X, Y, or Z), which can be activated in the folder.
Description (field LIBACT4)

Title associated with the previous code.
Module (field MODULE4)

[object Object]

Active (field FLACT4)

If this field is set to Yes, the fields marked by the activity code in the dictionary are activated.
Dimension (field DIME4)

This dimension associated with a specific/custom activity code is used to size the grids and multi-occurrence fields marked by the activity code in question.
Vertical (field COP)

This indicator must be set to Yes in the case where :

  • a three level folder architecture is being used (reference folder, development folder, live folder).
  • the associated specifics are expected to be defined at the intermediate level and will be automatically transferred to the lowest level folder in the case of revalidation or of the patch, including in the case of update.

If the indicator is set to No, the specific/customizations will not be updated when a revalidation is carried out if they exist already.

This flag is used to distinguish the vertical developments that are likely to be installed in a group of folders and updated by revalidation at three levels, and the developments made in the folder at the lowest level (developments carried out by the customer for example).

For more information, it is advisable to refer to the corresponding technical annex.

This tab is used to define the sizing elements useful to the execution environment of server processings associated with each of the open software sessions. The entered data is stored in a configuration file named APL.ini, located on the server, in the folder root directory, once it is created. These setups have a minimum value that will be used if the set up values in this screen are not sufficient.

System

Engine process memory (MB) (field MEM)

This parameter corresponds to the memory size used for the local data during the execution of the server process. By default, 16 Mb is proposed, this is a reasonable value even if the minimum value possible is 4 Mb. It is possible to increase it as a function of the maximum number of lines used for the large tables in memory (orders, invoices, postings). The higher the given values in the Screens tab, the greater the need to increase the necessary memory size. The system variable maxmem is used to identify the current value during a session.
field MEM1
Database process memory (MB) (field MSA)

This field is used to define the memory size allocated to the process accessing the database (it is named sadora or sadoss according to the database).

The default value is set to 20Mb, which only needs changing on rare occasions. The system variable sadmem is used to identify the current value in a session in execution.
field MSA1
Programs (field MPR)

This parameter is used to define the maximum number of processes open simultaneously in a software session. The default value is 200, the minimum value being 100. A higher number will improve the performances by limiting the reloading of processes. The system variable adxmpr is used to identify the current value during a session.
field MPR1
Open tables (field MTO)

This parameter is used to define the maximum number of tables in the database simultaneously on line in a software session. The default value is 150 and it is appropriate in most cases. The system variable adxmto is used to know the current value during a session.
field MTO1
Sequential files (field MSO)

This field is used to define the maximum number of sequential files open simultaneously in a software session (by the instructions Openi, Openo, Openio). The default value is 10, the minimum value being 10. Except to very specific cases linked to these instructions, this value has no reason to be modified. The system variable adxmso is used to identify the current value during a session.
field MSO1
Class memory (field MST)
field MST1
Link activation
Link test

Tab Links

This tab is used to define the folder links to folders situated on other solutions (i.e. on another server or another connection service, or both).

It has the advantage of making easier the use of connection between software in SAFE X3 technology when they have to share or update common data. A typical example of this kind of cooperation is when a software must update financials situated on a remote folder.

From a technical point of view, a program situated in a folder DOSSIER1 is likely to open tables from a remote folder named DOSSIER2 via a syntax of type:

File ="serveur:[email protected]"

When this happens, a process for data access is opened on the remote folder (it is called sadora or sadoss depending on the concerned database) and tries to connect to the database with a default user name (in the database context) equal to the DOSSIER1 code from the folder where the request was launched.

If it exists, it is not a problem but the access rights to the tables from folder DOSSIER2 have to be sufficient.

If no folder with name DOSSIER1 exists on the remote folder, no access will be possible, except if a directory DOSSIER1 was defined on the remote folder, containing a minimum number of strategic files used when starting this type of process (files .users, .password, APL.ini, adxora).

The adxora file stores notably the user code in the form of a code with which the process for data access will connect, and the corresponding password.

In this tab a link grid is to be entered with setups sufficient to all the creation of files authorizing the remote connection. This creation is not performed upon line entry but it is launched when the link is activated (function accessible via right click on the line).

Note that the links may be characterized by functionality: an accounting link, for instance, corresponds to a link making it possible for a software to access a remote accounting. Only one characterized link of each type is available by folder, and in this case the exhaustive characteristics of the remote folder to be connected to are to be specified. These characterized links have following advantage: they are managed by software which support them (an accounting operation is a software without accounting will explicitly look for an accounting link in order to know whether it should access a remote accounting).

There are also links of type Miscellaneous: there can be several of this type in a given folder (knowing that the total number of links, all types together, is limited to 5). They are supposed to be managed in custom/specific processings. A link of this type does not identify compulsorily a specific folder: it can also correspond to a given environment. If this is the case, the connection occur with a database user code to be specified.

Upon entry of the link lines, the processing looks for the version of the SAFE X3 software installed in the target environment. It detects notably the presence of a file solution.xml, which makes it possible to deduce a certain number of values by default upon entry of a line. If no such file exists, the processing supposes that the remote folder is in version 13X.

Connection

Folder (field CDOSSIER)

This field, display only, corresponds to the code for the folder being worked on.

Application server (field CSERVEUR)

Corresponds to the name or the network address of the application server, that is to say the server one which is stored the reference for the folder (notably the directories for the different folders in the solution).
Port (field CPORT)

Defines the TCP/IP port in which the connection server expects the connection requests from the folder.
Access path (field CPATH)

Display only, this field corresponds to the root directory of the folder as it is defined on the application server. It is defined as a function of the volume entered in the first tab of the folder record.

When connected to the folder itself, this information can be found by entering the instruction :

filpath("","","")
Process server (field CSERVTRT)

Corresponds to the name or the network address of the process proposed by default (there may be more than one and by default it can be the application server). A process server is a server on which the application code transmitted by the application server is executed.
Publication directory (field CPUB)

Corresponds to the applications server directory from which the XML elements defining the user interface are created. This field is not displayed, its value being defined as a function of the installation.

Grid Access rights to the folder

Solution folder (field SOLDOS)
Authorization granted for the current folder (field SOLAUZ)

Grid Folder links outside of solution

Link type (field LTYPLIEN)

Define the type of link :

  • either it is a Miscellaneous link, which must be managed as specific/custom in the processes.
  • or it is a characterized link (To Accounting, To Fixed Assets, To Pay, To Logistics...). This type of link is manage by the software when required. A single link for each type may exist for a given folder.
Active link (field LLIENACT)

Field only displayed if the link is identified as active. This field is stored in the table of folders, but an existence control on the remote directory is made on the active when the tab is displayed.
Machine (field LMAC)

Network path defining the remote server to be connected to.
Service (field LSERV)

Number of the remote server to which a connection is made.
Directory (field LREP)

Installation disk address for the remote solution. It is this location that the directory that is used in the remote connection will be created if a folder of the same code as the current folder does not exist.

This address corresponds to a database directory (volume 0 in adxvolumes) on the application server.
Type of OS (field LTYPOS)

Defines the operating system of the server to which the link is made.
Linked folder (field LDOSTARG)

Define the linked folder to be connected to. This information is mandatory when the link is characterized, but not for a miscellaneous link.
Solution (field LSOL)

This field, only displayed, gives the name of the solution (in the SAFE X3 sense of the term), if the latter can be found in the xml configuration file (i.e. subject to a connection to an environment greater than or equal to Version 140).
Database type (field LTYPDBA)

Define the database type to which the user is to be connected.
Name of the database (field LDBA)

Corresponds to the name of the remote database. This information is recovered in the solutions.xml file if the link points to an environment for a version greater than or equal to 140.
Data source (field LSRC)

This field (display only) gives the name of the ODBC data source if this can be found in the configuration.xml file (i.e. if connecting to an environment where the version is greater than or equal to 140).
DBMS user (field LUSR)

Defines the user code (in the database sense) used for the connection.
Password (field LPWD1)

Defines the password (in the database sense) for the user to be used to connect to the remote database.
System user (field LUSRJAV)

This is the platform used by the Bridge Java to open a remote session.
Password (field LPWDJAV)

This is the password of the User platform used by the Bridge Java to open a remote session.
Link activation

Triggers an update of the link, that is the creation of the directory corresponding to the code of the folder being set up on the remote folder with the necessary configuration files.

If the directory exists already and corresponds to a directory of a "true" remote folder (a check is carried out to verify if there is a sub-directory TRT), nothing is changed in order to avoid perturbations in the connections to the folder on the origin folder. But in this case there is nothing to do since the connection is achieved remotely (with the privileges of the user BDD corresponding to the folder code).
Link test

Once the link is activated, it is used to verify that a connection is possible (the attempt is made to open one of the supervisor tables).

SEEWARNING This function is only available if the folder code whose links are being set up is the current folder.

Link deactivation

This function deactivates the link, that is:

  • the flag Active is updated in the folder setups.
  • proposes to delete the directory and the files created upon link activation, if this link does not correspond to a "true" remote folder. Caution: deleting this directory triggers the deactivation of the connection possibilities for folders with the same name located on other servers. The answer to the proposition is thus not compulsorily Yes.

Reports

By default, the following reports are associated with this function :

  ADOSSIER : Folder parameters

This can be changed using a different setup.

Specific Buttons

Validation

This button launches the function to validate the folder.

In the dedicated technical appendix the detail of the operations carried out in validating the folder can be found.

This function is particularly useful at the time of the transfer of a complete folder from one folder to another. It is necessary on one hand to transfer the file directory structure of a folder and on the other, to transfer the data (this can be done using the database tools or by safe x3 table import/export if the target folder already exists). But it is also necessary to recover the structure information contained in the Folder record (in effect, the information in this record are stored in the ADOSPAR, ADOSIM, ADOSACT tables, which are the supervisor tables attached to the supervisor folder, and therefore not automatically transferred. Import option allow the creation of a correct Folder record, in reading the configuration record called PARAM.ini, located in the root directory of the transferred folder. The PARAM.ini record, created at the time of the creation of a folder, is updated at each revalidation.

This function is used to view the log file concerning the last validation carried out on a folder. It is important to review this log file when the validation is finished, in order to verify that there have been no errors. The errors are in red for identification in the log file.

This function starts the size calculation taking into account the sizing setups defined in the corresponding tab. When the function has been executed, a window allows the appearance in a grid, for each table, the number of lines calculated and the size in Mega-bytes necessary for the data and for the indexes. At the bottom of the window, the cumulated size for the data and for the indexes is displayed, as well as the total size necessary. This size can be passed (with a possible increase to keep a maneuver) to the first tab in folder management.

The format of the database is of course taken into account when determining the proposed size in mega-bytes. The algorithm is the following:

  • in an ASCII database type, one character accounts for one byte.

  • for a UNICODE database type (UTF8 or UCS2), the character accounts for 2 bytes, except if the environment variable named STUSIZE (it can be read by the SAFE X3 function getenv$) exists, to give a different multiplication coefficient. In the case of a database managed with Chinese characters, for example, it is advised that the value is set to 3 rather than 2, but it can be an intermediate number such as 2.5.

This function is used to create a setup file for the BATCH server in order to reuse them in another folder and another version.

Following elements are exported:

  • Batch tasks (ABATTAC table)
  • Task group (ABATGRP table)
  • Recurring tasks (ABATABT table ) Except for the recurring task setups
  • Calendars (ABATCAL table)
  • Time constraints (ABATHOR table)

This function creates a file named « BATCH.tmp » in the basis directory of the GDOSX3 folder. All records superior to "X" are also reused.

This function can only be accessed from the root folder GDOSX3.

This function is used to import the file "BATCH.tmp" present in the basis directory of the GDOSX3 folder.

This import overwrites all records present in this file. For the recurring tasks the setups are not reused and all recurring tasks are deactivated during import.

At the end of the import, the file "BATCH.tmp" is deleted.

This function can only be accessed from the root folder GDOSX3.

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

Non existent volume

The name of the volume (A by default) is not known.

Code already exists in line i

In the language table, a language code has been entered that is already referenced in a previous line.

N users in the folders

An attempt is being made to start folder revalidation, but users are still connected to the folder.

Error messages on folder validation

When the folder validation is started, a log file is created. A series of errors can occur. They appear in the form of an error line (in red) in the log file, followed by additional information. Certain errors are generic, but most are linked to the complex phase of screen revalidation. The two series of errors are listed below.

Caution:

The folder validation log file is accessible via the button from the folder management. If the folder validation is started by the batch server, the log file of the request only gives the validation start time: It will be necessary to pass by the folder management to view the detailed log of the operation.

Other errors not listed are likely to occur, in particularly at version change. These errors are defined in the release notes accompanying the version updates.

Generic errors

Folder in use

Folder in process of being generated

N users in the folder

These errors can arrive in the preliminary phase of blocking a folder in the process of revalidation, blocking not being possible at this time.

Read error / Write error / Deletion error

A problem with access rights exists in a table whose name is given in the following message. These errors can arrive in any of the generation phases (screen creation, menus....) if an access problem exists in one of the corresponding dictionary tables.

Errors linked to the screen revalidation

Not enough width available( Necessary width / Maximum width )

Not enough height available(Necessary height / Maximum height)

When validating a screen, there is not sufficient space to position all the fields in a screen (this does not prevent the validation of the screen, but it is necessary to manually verify the screen).

Data type non existent

Non existent action

Non existent object

Non existent table

Non assigned setup

These non blocking errors can occur at the time of screen validation: they do not happen in the entered screens, but can occur after inter-folder element transfer by copy, followed by a revalidation of the folder: here also it is necessary to manually verify the screen.

Too many lines in a block (max 30)

Too many columns in a block (max 15)

Too many fields in a block (max 150)

Too many setups in a block (max 20)

Too many actions in a screen (max 500)

These blocking errors can occur at the time of screen validation: they do not happen in the entered screens, but can occur after inter-folder element transfer by copy, followed by a revalidation of the folder: here also it is necessary to manually verify the screen.

Variable not defined in block i

The variable from the bottom of the block has not been correctly declared in the tab structure.

Appendix: additional technical information

Volume definition

The volumes are used to define the directories where the software installation files and the files concerning the created folders (excluding the database) are located.

These directories are defined in a configuration file named adxvolumes, installed in the engine installation root directory (this directory being itself identified by the volume 0 (zero), which is reserved for the installation of the run-time engine).

The database path of a volume can be found by using the following function in the SAFE X3 calculator:

filpath("!","","","","x")

where x is the volume code (0, A,B,C...)

In assigning the second setup of the filpath function, it is possible to find the exact access path to the adxvolumes file itself:

filpath("!","adxvolumes","","","0")

In the standard installation, the adxvolumes file contains at least two lines (one of the lines for the 0 volume, the other for the A volume, possible others for the B, C, D.... volumes) in the following format (on a NT server, on a UNIX server, the paths are in the format /home/SAFEX3/runtime, for example):

0 :D:\SAFEX3\Runtime
A :D\SAFEX3\Dossiers
B :E:\VolumeB

It should be noted that using volumes other than the first two offers relatively little interest as such in version 140, because the folder structure, if it contains lots of files, takes up a space that does not change much; a problematic optimization of the entries/exits by distribution over different disks is not really useful in this case, the data being stored in the database. The only case where this could be interesting is the one where the text and image files are stored in the TXT directory as it was done in version 130 (in version 140, there is the possibility, to store them in the database which is much more preferable). In addition, when using the Web interface, the XML files generated and used by the http server are always stored in a directory defined in the volume where the supervisor folder is installed (this is normally A).

Modules usable in the folder definition

The usable modules can be defined for several types:

  • The functional modules described in an annex documentation.
  • Technical modules (Supervisor, Common data, Development, Internal X3). The Internal X3 module can not be activated (it is reserved for the SAFE X3 development teams). It is advised to activate the Development module, even if no specific development is planned, in order to have access to certain maintenance functions directly in the folder.
  • There are additional module (Specific modules 1 to 4) open to the partner development.

Interdependence constraints exist between the modules. These constraints are directly tested in the entry of active modules and are described in the annex documentation. For the technical modules, the Supervisor and Common data are compulsorily equal to Yes.

Tables used

See also Refer to documentation Implementation