Import Export Service

Print this Page	2.1 Service Catalogue 06. Import Export Service	Close this Page

21.06 Import Export Service (IES):

1. Also published as "The Import Export Service" (TIES).

2. Since being editor of ISO/IEC 13238 IRDS Export-Import standard in 1998, we have been world-wide leaders in automated import-export services.

3. Information Resource Dictionary Service (IRDS) provides a declarative means to store, measure and estimate business requirements.

2. Two Step Service:

1. A business requirement is to migrate business data from one application to another.

2. While some create problems for themselves by making this a one step process, evidence over many years has shown that considerable simplicity can be achieved by using a two step process.

3. The first step is to import the old data into an Information Resource Dictionary as a means of discarding any legacy structure, repitition and integrity issues. Artificial intelligence is used to search and pull-out dictionary objects from the old data. Many passes may be needed to full out different kinds of dictionary objects.

4. The second step is to export from the Information Resource Dictionary to the new business application service where only knowledge of the new application are applied. Each new application is build in the first place from a Information Resource Dictionary, so this second step is just a natual continuation of procedures that have already been proven.

3. Original Data:

1. The only file format permitted for original data to be provided is as comma separated variable (CSV) files.

2. Any CSV cannot contain any kind of virus, but all other file formats can contain a virus or malware that can destroy a computer.

3. Any CSV file will only store normal latin (ASCII) character codes without any unknown language character codes.

4. The import export service can only begin after all original data is uploaded as plain text in CSV files.

4. Placeholders:

1. Business data is fragmented into objects with properties that are identified by glyphs as placeholders.

2. A benefit is that each glyph identifies a specific field value in the Information Resource Dictionary with little concern for structure or association.

3. Each field value can be verified against its range of permitted values so corrupted field values are not propogated into a database where they could cause damage.

4. The Information Resource Dictionary enables physical records to be extracted as a set of placeholders in compliance with the new database. This is critical where each field value is encrypted and hard to verify after the new database is complied. By design, a good encrypted database is meaningless and worthless to a criminal or any other person at the physical level.

5. Exceptions:

1. Data stored as images in a PDF file are not text and cannot be processd as specific field values. A PDF may be saved as a text file to discover what is stored as text and what is stored as an image - only the text can be processed.

2. Data stored in Office documents can be saved as a CSV or TXT or HTML document that can be processed. Raw Office documents are propriatory, may contain malware, may contain invalid character codes and can only be processed after they have been saved in a more reasonable file format.

3. Field values stored with symbols may not be able to be processed unless all such symbols can be deleted. Commas in numeric fields may cause CSV files to become unreadable - too many commas. Pound symbols in amount fields may cause files to become unreadable because the pound symbol is not known and invalid to most servers. Dates stored as 12/12/12 may lead to confusion with a number of possible solutions.

4. Business data stored without the benefit of a database tend to include duplicated field values. Where contradictory duplicate field values exist, then a number of possible solutions may have to be manually guessed at as a third step. Where the same field value has been entered in a number of different cells, then alternative spelling will exist that may have to be manually guessed at as a third step.

5. Field values stored as "as above" may be meaningless to the import export service. Data values as "not applicable" are meaningless to a database that shall only store a valid date value in a date type field. Data values as "-" are meaningless to a database that shall only store a valid integer values in an integer type field.

6. Mission:

1. The mission is the Import-Export service is to rapidly migrate legacy data files into a modern database that can be accessed by any number of sort and filter tools.

2. While glaring data integrity errors shall be rejected, the mission is to get the business data into a database where it can then be manually cleaned up with the benefit of data integrity tools.

3. The mission is not to add-value or to automatically correct all data integrity errors, however data integrity must be of a quality that permits the data to exist in the database.

7. How does it work:

1. Eliza is shown a set of files that are to be imported as step 1.

2. Eliza understands rows and columns and shall assign a placeholder to each column where the actual values match what has been specified as permitted values for that placeholder.

3. Eliza shall ask a person for clarification of columns that may be one from a set of placeholders, or even a new placeholder.

4. Eliza shall import the data into the Information Resource Dictionary where it can be interogated to be complete and correct - many different import steps 1 may be attempted until things look and feel right.

5. Some data integrity defects will be corrected in the Dictionary so the odd exception does not spoil the whole import step.

6. After step 1 import has proven to be complete and correct, or as correct as it is likely to get, then Eliza is asked to run step 2.

7. Step 2 creates a clean database that can be interogated with all the normal business facilities to ensure that field values are within expected ranges of permitted values.

8. Every Bespoke Application Service is unique and part of step 2 export may involve the specification of new and extra fields that did not exist before this export step 2.

8. Risk:

1. The original data may contain codes and field values that are not specified and are unknown following any amount of analysis - not all data has any meaning.

2. The original data may be stored using images, bit maps and file formats that are no longer readable by modern tools - data on floppy disks will be unreadable.

3. Eliza may not recognise the original data as having any relevance to a Bespoke Application Service - the value of the original data may be very low.

4. Data containing symbols and strange character codes may belong to a historic era that are no longer understood - IBM Lotus spreadsheet data may be unreadable.

5. Where the data can be viewed, the worst case scenario is that the data needs to be manually transcribed (cut and pasted) into the Bespoke Application Service.

Document Control:

1. Document Title: Import Export Service.

2. Reference: 162106.

3. Keywords: ITIL Import Export Service.

4. Description: Import Export Service.

5. Privacy: Public education service as a benefit to humanity.

6. Issued: 14 Feb 2017.

7. Edition: 1.6.