Import via temporary database tables has been realised as a third way to transfer data to IDL Konsis besides the "classic" way via files ("txt" files, ASCII files) and direct import via program to program interfaces. This is particularly interesting for interfaces realised with IDL Importer, since this tool is sepcialised for reading data from database tables, converting them and writing into other database tables. Other tools may be used for this purpose, too, when observing the following rules.
For this purpose a special import table per data stock was defined in IDL Konsis. Besides the attributes of the data to be imported this table contains a prefix, that mainly consists of a job number. This job number specifies data belonging together. In some cases the attributes are longer than in the original table providing the facility of transformation from external keys into internal keys. The following fields (emphasized are required) are included in the import tables beside the attributes defined in the '#DB' format:
| Attribute | Short Description | Meaning |
|---|---|---|
| I1XX_JOBID | Number of the job | allocated job id in I001 |
| I1XX_RECORD_NR | Consecutive number | sequential number of the data record within the job |
| I1XX_IMP_ERROR | Error at import? (Y/N) | Flag designating, whether this record has been imported |
| I1XX_MODIFIER | User id of the last modification | |
| I1XX_DATETIME | Timestamp of the last modification | |
| I1XX_LOCKUSER | LOCK user identification | |
| I1XX_LOCKDATE | LOCK timestamp |
The list application "IE job control" (short word IEJOB or via action menu of the calling application IMPORT) displays all jobs contained in the special import tables. You have to define a new job directly in the database table I001, before you can write data into the import table. The attributes of I001 have to be set as follows (emphasized are required):
| Attribute | Short Description | Meaning |
|---|---|---|
| I001_JOBID | Number of the job | The next subsequent job id has to be entered. The user is responsible for determination of this unique number. It is recommended to use the prepared table I000 for this purpose. An entry for the sequence name (I000_SEQ_NAME) with the value "NEXT_JOBID" is to be entered once. The corresponding consecutive value (I000_ACT_VAL) can be used in a database sequence manner. Means: First increment the number in I000_ACT_VAL inside of a transaction and then use this number as the next job number. |
| I001_USERID | User id | User id in IDL Konsis that is to be used for execution of this job in IDL Konsis |
| I001_ENABLED | Release (Y/N) | The release of a job for execution can be controlled here. The execution is only allowed, if its value is 'Y'. |
| I001_FOLLOW_JOBID | Consecutive number of a aubsequent job | not yet implemented |
| I001_WITH_DELETE | Import with previous deletion (Y/N) | Flag, whether existing data are to be deleted before import |
| I001_START_FROM | Earliest import timestamp | Timestamp for the first possible execution of import |
| I001_JOB_START | Beginning | Start timestamp of the job |
| I001_JOB_END | End | End timestamp of the job |
| I001_JOB_SUCCESS | Success status of the job (Y/N) | Flag, whether success or failure |
| I001_IEF_PROJID | Project id | Project id of the job. You always have to enter the value 'KON' here. |
| I001_IEF_OBJID | Object type | Object type of the job. For import the value 'IEO' has to be entered here. |
| I001_IEF_OBJID | Object id | Data type of the job. You have to enter the name of the corresponding import/export format data type here, e.g. 'KTOSAL' for account balances. |
| I001_MODIFIER | User id of the last modification | |
| I001_DATETIME | Timestamp of the last modification | |
| I001_LOCKUSER | LOCK user identification | |
| I001_LOCKDATE | LOCK timestamp | |
| I001_JOB_CREATOR | Data provider | Text for identification of the origin of the data of this job |
| I001_JOB_CREATED | Timestamp of data delivery | When were the data inserted into the import table? |
The job number of the generated job has to be used for subsequent writing of data into the import table. The import into IDL Konsis can be started via application "IE job control" (IEJOB). Start and end of this processing as well as a processing status are recorded in the IE job control.
The import/export format '#DB' is used for this type of import. It is designated with the new format type 'TABLE' in the table for import/export formats (IEF). The IEF definition contains the name of the import table in the attribute "Default filename / table".
According to the fields in IEFFEL the names of attributes of database tables are given. For technical reasons the character "-" is replaced by "_". As with format KTOSAL the field FAC for fact with ID I100-FAC corresponds to the attribut I100_FAC.
Messages at loading of data into the temporary table as well as messages at the actual import are written into a database table, too, instead of a protocol file. This protocol can be viewed by the new list application "Import protocol", which can be called via object menu of "IE job control" (IEJOB). This protocol distinguishes betweeen messages from data delivery and messages from data import via parameter "Job step".
An import job can be deleted completely via action "Delete" in "IE job control" (IEJOB). Then the job control record itself is deleted as well as all corresponding records in the import table and the allocated protocol.
Via action "Copy IE jobs" in "IE job control" (IEJOB) it is possible to copy data records of an existing job into a new generated job. If a job has records with errors, the option to copy only these exists.
With these release this new feature supports the following data stocks (object types):
| object type | table |
|---|---|
| KTOSAL | I100 |
| ICKTOSAL | I101 |
| CNTSAL | I102 |
| KST | I103 |
| ANLBEW | I104 |
| KTO | I105 |
| POS | I106 |
| POSKTO | I107 |
| KAPBEW | I108 |
| RUEBEW | I108 |
| SPIBEW | I108 |