Refer to documentation Implementation
Presentation
An import/export template is identified by an alphanumeric code. Other than a title, two sections are used to define the technical characteristics of the template.
Close
Fields
The following fields are present on this tab :
| This code identifies the import/export template. |
| Use this field to assign a description to each record. |
| Select this check box to activate the current record. Disabled records keep their content and setup but cannot be used by recalling their code:
The authorizations for a given function can prohibit the creation of an active record. In this case, the check box is disabled by default. It can only be modified by an authorized user or through a signature workflow. |
| This field indicates the name of the import/export template's factory owner. If the factory owner is SAGE, you can't modify anything on the screen. |
Close
Presentation
This section defines the following general characteristics of the template:
Close
Fields
The following fields are present on this tab :
General
| This field indicates the object code to be imported or exported. This field is optional for exports. The identifying block displays the name of the main table to export. |
| This field initializes the context and checks the access rights. It is useful if the same object is used by several functions. Indeed, users must have the appropriate rights to access the function to be able to use the template. This field is mandatory. |
| Select a module for the setup. Use this field to specify if the screen has to be created in the folder database. This is the case when the module linked to the screen is active on the folder. |
| An activity code is used to:
If the activity code is disabled:
|
| This access code makes it possible to prohibit access to the current record for some users. If the field is populated, only users that have this access code with read access rights (and write access rights respectively) can view (or with write access rights, modify) the record. This access code makes it possible to prohibit access to the current record for some users. If the field is populated only users that have this access code with read access rights (and write access rights respectively) can view (or with write access rights, modify) the record. The execution right associated with a user code is processed in a particular way in the case of the import/export templates: If a user has not been granted the execution right, he cannot use the template to import or export data. |
| This field defines the standard process that includes the labels of the actions called in import/export processes. These processes are used to carry out initializations, additional controls, and if required, updates. The structure of such a program is in the technical appendix. The standard processes usually named IMPXXX, XXX being the import code, are supplied for a certain number of imports. For additional information on these actions, refer to the corresponding appended documentation. |
| This field defines the specific/custom process that is called before the standard process, and which is used to carry out the same actions by de-activating if necessary what is carried out by the standard process. The possible actions are initializations, additional controls, and updates if required. For additional information on these actions, refer to the corresponding appended documentation. |
Structure
| This field defines the structure used to manage the data in the file to be imported or exported. For further information, refer to the corresponding paragraph. |
| Specify the character used as the separator between two fields. To enter a non-printable character, enter a backslash followed by three numbers representing the ASCII code of the character with decimal bases. |
| Specify the separator used between two records (data groups). To enter a non-printable character, enter a backslash followed by three numbers representing the ASCII code of the character with decimal bases. The commonly used separators are:
|
| The field delimiter is added in the first and last position for alphanumeric fields. For numeric and date fields, no delimiter is required. It is usually one of the following characters:
|
| Enter the format of the characters used in the file:
|
Export
| If this field is checked, it will be possible to use this template in the export of data. |
| This non-editable field stores the value of the sequence number when the last export took place. When performing chronological exports, this is useful to process only what has been modified since the last export. |
Transcoding
| When the ASCII character set is used, you can apply various standardized formats:
|
| This field defines the decimal separator used for numbers. If this field is empty, the system considers that the decimal separator is a full stop. |
| This field defines how the date type fields are coded. You can only specify the order and the number of characters in the year. For the import, any separation characters between fields are filtered. Dates in the DD-MM-YY or DD/MM/YYYY formats are correctly decoded. The decoding sub-program takes the engine's adxdcs variable into account. This variable is set via the DCS parameter that is found in the general parameters to define how a year is decoded over two characters. DCS represents the pivot year that defines the century change. For example, if DCS is equal to 1940, any year made up of two numbers:
It is then possible to express the years between 1940 and 2039 with two numbers. |
| Title associated with the previous code. |
| The fields of local menu type are stored as a number representing their rank in the table. According to the value of this field, the template will export or expect to find an import.
The local menu titles are only the labels used in display, and the value stored in the database being the rank in the table. It is possible to change the title of the local menus at the time of an import for the search algorithm to operate correctly. Changing local menu titles can only be done in single-user mode. This is not designed for regular or automatic transfers. |
| Title associated with the previous code. |
Import
| If this field is checked, it is possible to use this template to import data. |
| Use this field to modify an already existing record during import. |
| When this box is checked, the data import feeds the import/export storage space with the wrong data. The fact that the storage space is fed does not prevent the creation of an error file. |
| This field indicates that the data integration into the database is made using specific/custom actions defined in the process whose name is given in the Import process field. This specific/custom process includes a restricted number of entry points and therefore requires the writing of a process including all the controls that should be carried out. Its use resides in the fact that it is possible to group controls to optimize the import program. The structure of the specific/custom imports is described in the appendix. You can find the following actions:
|
| If this box is unchecked, the workflow events related to basic operations such as creation or modification in object management mode are no longer called. If imports are started and generate mass updates, this avoids the release of several events of this type. This can impair the performance of the import and cause the mass sending of messages. However, this does not mean that the workflow events related to the import's release are disabled. |
Grid Identifiers
| Current line of the grid. |
| This field defines the group's overlapping level. Level 1 is the main level. An N+1 level defines a sub-level of the preceding N level. |
| This field identifies the group by a code containing a maximum of five characters. This code will be mentioned in the field grid of the following tab, and in the file itself, as a group header. |
| This indicator grid defines the structure of the record groups. Refer to the corresponding paragraph. |
| This field defines the key of the linked table used to access the detail of the group records from values of the upper-level tables used in the link expression. |
| This field defines the link expression. It is a series of values separated by a semicolon that gives the key values linking the detail table to the header record. |
| For a file with a fixed length, you need to indicate the number of characters for each record. |
Close
Presentation
The different fields to be imported are defined in this grid. They are organized in groups identified by the Code column in which one of the codes defined in the indicator grid of the first section is found. The field can remain blank if no table has been defined.
This section contains the grid defining the detailed structure of the groups existing in the first section. Note that:
Fields
The following fields are present on this tab :
Grid Fields
| Current line of the grid. | |
| This field is only entered if the group indicator grid in the previous tab is not empty. It is used to attach the information to be exported or imported to a group of data. | |
| This field defines the database table where the data to be imported or exported is defined. Note that:
| |
| This field indicates the name of the field of the table to be imported or exported. Different syntaxes are possible to define the information to be extracted or integrated:
| |
| Add a comment to make the configuration easier to understand. | |
| Three choices are possible in this field:
| |
| This column is only useful in the case of a fixed-length format. In this case, the position gives the gap concerning the start of the block or the record. The position is in numbers of bytes, 1 being the start of the section or record. The positions must be compatible with the size of the record. | |
| This field determines the length of the field for a sequential file. | |
| This column is only entered if the format is fixed length. For numeric amounts, the format entered is defined in the nnn or nnn.mmm format, remembering that these numbers can be:
For an alphanumeric format, the only formatting directives that are possible are < or > (left or right alignment, remembering that the character strings are completed with spaces). | |
| This field is used when imports/exports are carried out under the XML format. When an XML file is created, more information is required. For example, to create an XSD file describing the structure of the XML file and then control its validity with syntax check tools integrated into the different ETL software. This field defines whether a template has to be associated with the description entered in the XSD description. If this field is entered, the XSD field will contain a specification of the following type: You can find in online tutorials (like this one) syntaxes to use for patterns. | |
| This field is used when imports/exports are carried out under the XML format. When an XML file is created, more information is required. For example, to create an XSD file describing the structure of the XML file and then control its validity with syntax check tools integrated into the different ETL software. This field defines the code of the tag describing the field exported in the template as it appears in the XML file. | |
| This field is used when imports/exports are carried out under the XML format. When an XML file is created, more information is required. For example, to create an XSD file describing the structure of the XML file and then control its validity with syntax check tools integrated into the different ETL software. This field defines whether the field is mandatory or not. If the value of this field is set to Yes, the XSL file will contain a specification of minOccurs="1" type. | |
| This number, if it exists, refers to a transcoding table used to transcode the field that is read and make it comply with the expected format. |
File generation
| Select the type of export that you want to do. It can be:
|
| This field defines the path of the default data file proposed during the launch of the import or export. This data file is used in automatic mode when launching an import or export chain. This file path can be relative. In this case, the database directory is supposed to be the database directory for the software's installation. The path can include the # character. In this case, there will be a sequential number management:
For example, if the export sequence number is equal to 156, /u/tmp/fil# makes it possible to generate the /u/tmp/fil156 file. |
| This field forces the final directory to which the file will be transferred after having been imported. If no value is defined, the directory mentioned in the import/export general parameters is used. |
Action icon
Fields
The following fields are included in this window :
Block number 1
| Define the table for which the fields to be inserted must be selected. |
| Current line of the grid. |
| Define the field name for the table as it will be expressed in the software. A field with the name FIELDNAME defined in an ABV abbreviation table can be accessed using the [F:ABV]FIELDNAME syntax. For custom/specific fields, the field name must start with X_, Y_, or Z_. In the database, each zone corresponds to one or more fields, according to whether or not the zone is sized. The corresponding fields are called FIELDNAME_0, FIELDNAME_1, FIELDNAME_2. To enter and display the corresponding field on a screen, it is given the same name in the screen dictionary. The screen and the table will be used simultaneously in object management. |
| Title associated with the previous code. |
| If the field is set to Yes, it is inserted into the main table. By default:
|
Close
Use this field to insert, from the current line in the grid, a group of fields coming from a template's table.
This function is only present for templates with fixed-length file types. It recalculates the position of each of the fields in the current data group (sharing the same line indicator). The recalculation is carried out from position 1 in the first field of the group and adds the length of each field to obtain the following field's position.
Close
By default, the following reports are associated with this function :
PRTSCR : Screen print
This can be changed using a different setup.
Click this button to validate your import/export template. |
The following fields are included on the window opened through this button : Block number 1
Block number 2
Close This button is used to copy the record definition from or to another folder. |
The following fields are included on the window opened through this button : Grid Range
Grid Criteria
Close This button gives access to a screen in which it is possible to define the default values for the criteria to filter the exported data.
|
This function, which can be accessed when the export format is XML, is used to create an XSD file that describes the file structure created by the template. This file is created in the sub-directory following the directory where the folders are, in the application server:
This XSD file is used to define the data format to carry out a preliminary syntax validity check using ETL tools. The syntax obtained includes (besides standard headers) lines such as:
<xs:complexType name="ADI">
<xs:sequence>
<xs:element name="ADI_NUMTAB" type="ADI_NUMTAB" minOccurs="1" maxOccurs="1"/>
<xs:element name="ADI_CODE" type="ADI_CODE" minOccurs="0" maxOccurs="1"/>
...
</xs:sequence>
</xs:complexType>
<xs:simpleType name="ADI_NUMTAB">
<xs:restriction base="xs:int">
<xs:minExclusive value="-32768"/>
<xs:maxExclusive value="32767"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ADI_CODE">
<xs:restriction base="xs:string"/>
<xs:maxLength value="5"/>
<xs:pattern value="{[A-Z]}*"/>
</xs:restriction>
</xs:simpleType>
Here are examples of numerical fields, and then alphabetical fields. A few comments on the way this syntax is managed:
This menu item allows access to the documentation management on the first paragraph of the documentation (if there is one) associated with the current record.
This menu item allows access to link management. It is used to define the links between the current record and other records (for example, the links between functions and parameters). These links are specific to the documentation and are used to load the generation of documentation structures.
This menu item launches a documentation generation. You can also launch it from the Generation button at the bottom of the screen.
You can launch three types of generation one by one or simultaneously
The range suggested by default takes into account the current record, but you can modify it at launch time.
In addition to the generic error messages, the following messages can appear during the entry :
The object has not been defined for importing. The Import checkbox is not checked in the Miscellaneous tab.
The same code associated with different groups has already been entered.
This message is displayed when a link has been expressed in the group grid using a ZZZ field that is not referenced in any of the tables (XXXXX, YYYYY, ...) defined in the previous lines.
In the field grid, for the G group, there is no line indicating the place where the group identifier is found (/ syntax).
An attempt has been made, in the lines describing the fields, to insert a field coming from a table that has not been linked to the main table in the group.
The length defined by the numeric format (mmm) is different from the length of the field defined in the previous column (nnn).
No directory existence test is made on the file path defined by default in the template. The directory could not exist yet. This test is only done on launching an import or export.
Consider the following principles when setting up an import template:
If data exports are always possible regardless of the object, this is not always the case for the import. The automatic mechanisms for decoding data flows and the call to the conditions linked to the object greatly automate the import. However, this is not sufficient for an automatic import of complex objects. Thus, not all objects can be imported.
In the reference folder, an editable import template is supplied for each object for which the import is possible. But this import can also be linked to specific features. This is defined in the online help associated with the import templates for which specific cases exist. This help is accessible by selecting Alt + F1 when the template is loaded.
The list of corresponding help, sorted by module, can be found here.
Choosing the structure of the files to be imported or exported depends on the extraction or integration possibilities found in the external software.
In all cases, you must organize data in logical groups of lines, which can be of different types (such as header, detail, sub-detail) or a single type. You can define the organization of these groups in the grid of identifiers located in the first section of the template.
Each group is associated with one of the tables in the database. The first being the main table of the object. The others are defined by the links from the previous tables. When using the template to carry out an object export, you can define the links with any table in the database in which a theoretic link exists to extract the linked data. On the other hand, for an import template, you can only use the tables updated by the object. It is not possible to simultaneously import the order and the customer, for instance. The order object was not designed for this.
This grid can be blank if a data structure to be imported or exported is based on the use of only the main table. In this case, the Code column for the next page will remain blank. You do not need to create several data groups if several linked tables have to be exported simultaneously. If fields extracted from different tables are displayed in a single data group, the export process will attempt to resolve the links between tables using the link structure described in the dictionary. This implies that there is only one link possible from the main table in the group to the described table. If not, the first link encountered will be used, even if it is not the correct one.
There is a specific case where it is necessary to create at least one group: if the template is defined with a fixed length. In this case, you need to define the record length somewhere from the table of groups). If the group indicator is not mandatory in the list of fields, defining this group with an empty code is sufficient: only one group can then be defined and the Code column will no longer be entered in the next section.
The identifier grid is only accessible if the object is of a single type. If group indicators are defined, each is associated with a level, a table, and the link conditions that make it possible to create links between them.
The main table is set to level 1 for import or export. This table is not entered in the grid but is deduced from the object associated with the template.
The level of any table linked to a previous table is equal to the level of the previous table if a one-to-one link exists between these two tables, and corresponds to this level plus one if several records are linked to a record in the previous table. The link is characterized by the key for the destination table to be read and by the key segment expression whose value defines the linked lines.
If you define groups like in the following example:
Level | Group |
1 | A |
2 | B |
2 | C |
3 | D |
Then you will obtain the following overlapping information:
Group A record 1 |
|
|
| Group B record 1.1 |
|
| Group B record 1.2 |
|
| ... |
|
| Group B record 1.N |
|
| Group C record 1.1 |
|
|
| Group D record 1.1.1 |
|
| Group D record 1.1.2 |
|
| ... |
|
| Group D record 1.1.M |
| Group C record 1.2 |
|
|
| Group D record 1.2.1 |
|
| ... |
| Group C record 1.Q |
|
|
| Group D record 1.Q.1 |
|
| ... |
|
| Group D records 1.Q.R |
Group A record 2 |
|
|
| Group B record 2.1 |
|
| ... |
|
To explain this setup, the following example takes an export template including the companies and sites:
The grid below summarizes the Identifiers as they would be entered:
Level | Code | Table | Key | Link | Comment |
1 | CPY | COMPANY | CPY0 |
| Main group record |
1 | CUR | TABCUR | TCU0 | [CPY]RGCCUR | 1 linked record |
2 | FCY | FACILITY | FCY1 | [CPY]CPY | N linked records |
2 | ADP | ADOVAL | ADW0 | [CPY]CPY | M linked records |
File formats are determined by the type. It can be one of the following:
This is a field with variable length where all the fields are separated by a separator (the separator field being SC).
Field 1 record 1 | SC | Field 2 record 1 | SC | ... | Field N record 1 | SC |
Field 1 record 2 | SC | Field 2 record 2 | SC | ... | Field N record 2 | SC |
This is a file with variable length where all the fields are separated by a separator (the field separator). When the record is complete, another separator (the SL line separator) replaces the field separator.
Field 1 record 1 | SC | Field 2 record 1 | SC | ... | Field N record 1 | SL |
Field 1 record 2 | SC | Field 2 record 2 | SC | ... | Field N record 2 | SL |
This is a file with variable lengths of the same type as the record separator file (two distinct separators). But, in addition, the fields of character string type are contained by a field delimiter (called DC). In the following example, the second field is of alphanumeric type.
Field 1 record 1 | SC | DC | Field 2 record 1 | DC | SC | ... | Field N record 1 | SL |
Field 1 record 2 | SC | DC | Field 2 record 2 | DC | SC | ... | Field N record 2 | SL |
This is a file where the fields are defined with a fixed length without a field separator. You must give the total length of the record in a setup. There can be a line separator. In this case, do not include its length in the record length.
In the same way, you can define the length of each group when blocks of data are set up in the indicators grid.
Fld 1 rec 1 | < ---------Field 2 record 1------------ > | ... | < --Field N record 1-- > | SL |
Fld 1 rec 2 | < ---------Field 2 record 2------------ > | ... | < --Field N record 2-- > | SL |
It is a format where data is defined in XML tags.
Upon export, the file contains information related both to the model and the extraction. You can also use the Options/Export schema of a template menu to export an XSD file describing the structure of the file created by the template.
Upon import, data is less important. It is possible to limit this data in the file to be imported.
This format is the variable Record separator format or the delimited format (if the Field delimiter field is entered).
If in the import/export template several levels are defined, only one line is generated.
Level 1 flag | Field 1 record 1 | SC | DC | Field 2 record 1 | DC | SC | ... | Level 2 flag | Field 1 record 2
| SC | DC | Field 2 record 2 | SL |
During import, the use of this format type implies a grouping of all detail lines of a specific level under the same header if all the fields in the header are strictly identical.
This format is the same as the Flat A format with an additional header line corresponding to the titles of the template fields.
For example, this format is used in Germany for GDPDU files.