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
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.
Header
Presentation
A folder is defined by an alphanumeric code of over 10 characters, to which a set of setups defined on tabs is linked.
Close
Fields
The following fields are present on this tab :
| The name of the folder can take a maximum of 10 alphanumeric characters. The first letter must be alphanumeric. |
| Enter the description of the relevant record. This long description is used as a title in screens and reports. |
Close
Tab General
Presentation
This tab contains the main organizational Information for folder definition.
Close
Fields
The following fields are present on this tab :
Basis
| 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. |
| 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
| 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
| 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). |
|
|
| Defines the set of characters used to store the character fields in the database. It can take the values ASCIIor UNICODE.
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
| 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. |
| 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). |
| 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. |
| 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 :
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. |
| 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. |
| 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. |
| 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
|
|
| 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
| 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). |
|
|
| 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). |
|
|
Close
Tab Options
Presentation
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.
Close
Fields
The following fields are present on this tab :
Grid Options
| An activity code is used to:
In this way, if the activity code is disabled, the marked element will not be useable, and the associated code (if any) will neither be generated nor can be activated. |
| Title associated to the previous code. |
| Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid. |
| 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:
|
Grid Localizations
| An activity code is used to:
In this way, if the activity code is disabled, the marked element will not be useable, and the associated code (if any) will neither be generated nor can be activated. |
| Title associated to the previous code. |
| Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid. |
| 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:
|
Close
Action icon
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).
Close
Tab Screens
Presentation
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.
Close
Fields
The following fields are present on this tab :
Grid Functional sizing
| An activity code is used to:
In this way, if the activity code is disabled, the marked element will not be useable, and the associated code (if any) will neither be generated nor can be activated. |
| Title associated to the previous code. |
| Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid. |
| 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). |
| 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. |
| Define the maximum possible dimension taken into account in the table structures in the database. |
Close
Action icon
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
Close
Tab Tables
Presentation
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.
Close
Fields
The following fields are present on this tab :
Grid Table sizing
| 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. |
| Title associated to the previous code. |
| [object Object] |
| This number corresponds to the value linked to the sizing element of the line. |
Close
Action icon
Help
Is used to access the help defining the aim of the sizing variable, the values it can have and the impacted functions.
Close
Tab Init.
Presentation
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).
Close
Fields
The following fields are present on this tab :
Grid Transaction validation
| [object Object] |
| A positive response to the question leads to the validation of the transactions associated with the module. |
Grid Languages
| 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. |
| This check box can only be checked if the following two connections are met :
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 :
|
Grid Legislation
|
|
Grid Copy data
| 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. |
| 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
| 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. |
| 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. |
| 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
| 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). |
|
|
|
|
|
|
Close
Action icon
Tab Modifications
Presentation
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.
Close
Fields
The following fields are present on this tab :
Grid Transaction validation
| [object Object] |
| A positive response to the question leads to the validation of the transactions associated with the module. |
Grid Languages
| 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. |
| This check box can only be checked if the following two connections are met :
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 :
|
Grid Legislation
|
|
Grid Copy data
| 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. |
| 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
| 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. |
| 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. |
| 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
| 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). |
|
|
|
|
|
|
Close
Action icon
Tab Miscellaneous
Presentation
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.
Close
Fields
The following fields are present on this tab :
Grid
| Defines the custom/specific activity codes (i.e. starting with X, Y, or Z), which can be activated in the folder. |
| Title associated to the previous code. |
| [object Object] |
| If this field is set to Yes, the fields marked by the activity code in the dictionary are activated. |
| 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. |
| This indicator must be set to Yes in the case where :
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. |
Close
Tab Links
Presentation
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.
Close
Fields
The following fields are present on this tab :
System
| 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. |
|
|
| This field is used to define the memory size allocated to the process accessing the database (it is named sadoraor sadossaccording 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. |
|
|
| 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. |
|
|
| 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. |
|
|
| 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. |
|
|
|
|
|
Close
Action icon
Tab Links
Presentation
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:service@DOSSIER2.TABLE"
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.
Close
Fields
The following fields are present on this tab :
Connection
| This field, display only, corresponds to the code for the folder being worked on. |
| 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). |
| Defines the TCP/IP port in which the connection server expects the connection requests from the folder. |
| 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 :
|
| 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. |
| 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
|
|
|
|
Grid Folder links outside of solution
| Define the type of link :
|
| 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. |
| Network path defining the remote server to be connected to. |
| Number of the remote server to which a connection is made. |
| 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. |
| Defines the operating system of the server to which the link is made. |
| Define the linked folder to be connected to. This information is mandatory when the link is characterized, but not for a miscellaneous link. |
| 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). |
| Define the database type to which the user is to be connected. |
| 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. |
| 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). |
| Defines the user code (in the database sense) used for the connection. |
| Defines the password (in the database sense) for the user to be used to connect to the remote database. |
| This is the platform used by the Bridge Java to open a remote session. |
| This is the password of the User platform used by the Bridge Java to open a remote session. |
Close
Action icon
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).
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 Activeis 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.
Close
Reports
By default, the following reports are associated with this function :
ADOSSIER : Folder parameters
This can be changed using a different setup.
Specific Buttons
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. |
Menu Bar
Options / Import
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.
Options / Log
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.
Options / Size
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.
Batch / Import
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.
Batch / Export
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.
Batch / Export
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.