Dec 5, 2001 - This manual introduces the TIE Translator software, version 2. ...... German, Irish, Italian, Norwegian, Portuguese, Spanish, ..... 5 â³2nd DTM segment in Msg!â³ ..... allowing them to re -use their EDI experience. ...... Extensible Markup Language (XML), Version 1.0 (Second Edition), W3C Recommendation 6.
TIE is a registered trademark of TIE Holding N.V. This book is published by TIE Holding N.V. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publishers. Printed in the Netherlands. Notice: As TIE Holding is constantly working on improving their products, we reserve the right to continue making improvements even though these changes may not yet be reflected in the manual.
This manual introduces the TIE Translator software, version 2. It describes the features as per version 2, re lease 29 of the TIE Translator. It describes the functionality of the software itself, and gives necessary instructions on how to prepare the definitions that control the conversion between EDI -messages and in -house files. The manual is divided into seven chapters: The first chapter consists of this introduction, a discussion of the main concepts behind TIE Translator, a listing of the supported EDI standards, and some comments on how TIE Translator 2 is different from its predecessor, ETC 1.6. Here we also discuss the formal notation, which we use to describe the syntax of the definition files. Chapter 2 discusses how jobs are executed, with sections on the command line, the command file, options, and tracing. Chapter 3 looks at the In -house Definition including the layout and the various sections that are contained in it as well. This chapter also discusses how various in -house database structures are described and how fields are specified. In Chapter 4, the topic is the Message Definition, with the layout, syntax, and format specifiers being discussed. An example is included. The Link Definition is the subject of Chapter 5, with detailed examination of th e layout, and the three areas, construct, translate and link. In Chapter 6, the details of the Link language will be discussed, including the various variables, statements and expressions. There is also a section on buffering and a section on mapping XML. Appendix A: describes all warnings and errors that are generated by TIE Translator, why they are generated, and what to do to solve / avoid them. Appendix B: describes the TIE Translator INI variables and how to use them. Appendix C: gives a list of external references that further describe technologies such as XML and XPATH.
1.2
Main concepts behind TIE Translator
To enable the use of Electronic Data Interchange (EDI) typically a conversion has to be carried out between the EDI message format and the in-house database of the company that wants to use EDI. To send an EDI message, the user has to convert his in -house database format to an EDI standard, and when receiving an EDI message, this conversion has to be performed in the other direction. The files that are discussed in this manual, i.e. the Message Definition, the Link Definition, and the In house Definition are all plain text files. They can th erefore be generated with any text editor, but the TIE Mapping Manager provides a more manageable way of maintaining these definition files. Although they are discussed at length in this manual, the files themselves cannot be modified in the TIE Translator. The TIE Translator is a general-purpose structure translator, which can perform the conversion between many types of in-house files and EDI messages. It supports the syntax of many EDI standards, including UN/EDIFACT, ASC X12, CARGO -IMP, as well as a nu mber of other national and sector-specific standards. The TIE Translator can also handle XML documents, either as a message or as an in -house file.
1.2.1 The translation and construction process Construction is the process that converts in-house data into EDI me ssage format, while translation takes an EDI message and converts it into a format that can be used by the in -house application. The TIE Translator performs each conversion as a batch job: no user interaction is needed once the job has been specified (see chapter 2 to find out how to run a job). The TIE Translator is informed which data structure it needs to convert through a set of definition files, organized as an in -house definition file (EID) describing the structure of the in-house database and a set of message and link definition files. A message definition file (EMD) describes the structure of the EDI message, while a link definition file (ELD) determines how the conversion between the message and the in-house database is to be done. The use of these definition files is the key to the versatility of TIE Translator: one program can be used to perform conversions between many different structures, simply by handing it another set of definition files. If prepared correctly, different messages can even be constructed or translated using shared in-house definition files. For example, the construction of different EDI messages can be accomplished using the same in-house file. This may require one EID and a set of ELD and EMD files. Th e various possible combinations will be discussed further on in this manual. As all the translate and construct activity takes place in the background, this manual concentrates on the preparation of the definition files that provide TIE Translator with the information it needs to perform its function properly. The preparation of these files is a one -off affair, as long as the agreed upon messages and the in -house database structure do not change. To properly understand EDI translation and conversion, it is necessary to explain the essential concepts of databases and EDI formats.
1.2.2 Database concepts TIE Translator is able to use two different representations of in-house databases, which we call the relational database model and the hierarchical database model, as well as hybrid versions of those two. Here we describe the concepts of these models.
1.2.2.1 Relational database model Relational databases comprise: •
A set of tables,
•
A description of the relationships between the tables,
•
The concept of joined tables.
Tables Tables in the relational model contain data arranged in rows and columns. Columns are called fields, and each entry in a column has a value assigned from a set of possible values called the field's domain. Fields are usually named. A field's name is called a field-name. In this manual, the word field is used both for the entire column in a table and for a single column entry (i.e. a field of a record), sometimes it is also used for the field-name. Rows are called records . A record is a coherent set of named values, also called fields. Each record in a table has one value for each field in the table and is usually identified by a set of keys. A key is a single field, or a set of fields that uniquely identifies each record in the table (i.e. there is no pair of records with exactly the same value in the key fields). A key is called a candidate key if there is no subset of fields in the key, which also forms a key for the table. For example, consider the following table:
In this table, the field sets {A}, {B,C } and {D} are all candidate keys. The database designer chooses one of the candidate keys to be the primary key, i.e. the key that will be used to identify the records. All other candidate keys are then called secondary keys. Relationships Tables are related when they have one or more columns in common, e.g. when they share columns with the same field name and domain (the field names may be different, but then the relationship has to be explicitly defined). The relationship "connects" records from these two tables. Similarly, when two records have the same values in their related fields, we call these records related. There are, therefore, two abstract levels of relationship: Table level: Two different tables have one or more fields in common. Record level: Two records from related tables have the same values in their common fields. The relationship at table level expresses the potential existence of a relationship at record level. Three types of connections can relate two tables: 1:1: Each record of the firs t table is related to no more than one record of the second table, and vice versa. 1:M: Each record of the first table is related to 0 or more records of the second table, and each record in the second table is related no more than one record in the first table. M:N: Zero or more records of the first table can be related to zero or more records of the second table, and vice versa. A
B
C
D
A
B
E
F
1
A
XXX
UUU
1
A
111
ABC
2
A
YYY
VVV
1
A
222
DEF
2
C
ZZZ
WWW
2
A
333
GHI
2
C
444
JKL
2
C
555
MNO
primary key
foreign key
In a relationship based on a primary key in the first table and a foreign key in the second table, any given record in the first table will always be related to zero or more records in the second table, i.e. it is a 1:M relationship, as in the following table: A foreign key is a field that forms a relation with a primary key in a related table, and is generally not a key in its own table. The table with the primary key is called the parent table and the table with the foreign key is called the child table. A child table cannot be a parent table to any of its ancestors. Joined tables
Joining
A
B
1 2
A A
and
C
D
XXX YYY
UUU VVV
results in:
A
B
C
D
1
A
XXX
UUU
1
A
YYY
VVV
2
A
XXX
UUU
2
A
YYY
VVV
Joined tables are tables that are constructed from two other tables (say A and B) by joining them. When two tables are joined, a new table arises which contains all fields from both original tables and the records of the new table are constructed from the original tables in the following way: each co mbination of a record from table A with a record from table B appears exactly once in the new table. If table A has N records and table B has M records, the new table will have N times M records.
Hierarchy In the hierarchical model, records can also be related. Instead of a relationship link between two records, however, the order in which records appear denotes whether they are related. Within the hierarchical model, the different record types are related in the following way: •
There is one root type, all other types are child types,
•
Each parent type can be related to one or more child types,
•
Each child type is related to exactly one parent type.
This leads to the following tree -like structure of record types:
typeA
typeB
typeC
typeD
typeE
typeF
typeG
Here, typeA is the root type, and typeB through typeG are all child types. In addition, typeC and typeD are also parent types, as is typeA. Each record of type typeE, which occurs in the database, belongs to the record of type typeC, which occurred most recently before it, and, in turn, each record of type typeC belongs to the record of type typeA, which occurred most recently. So, if we have the following database: recno: type: 1 2 3 4 5 6 7
typeA typeB typeD typeA typeC typeE typeE
then record 2 and 3 belong to record 1, record 5 belongs to record 4 and records 6 and 7 belong to record 5. Normally, the information in a child record is more detailed. For example, records of type typeA might describe a whole order, where records of typeC would describe a single line of an order. Record tags can be numbers or strings, depending on what is available. We allow sets of tag values to identify a single record type, as we w ill explain later.
documented in Message Implementation Guidelines (MIGs). In general, messages are built up from segments, which in turn are constructed from elements. Elements come in two flavours: • •
Simple data elements , which contain a single data value Composite data elements, which contain a related set of simple data elements
Several simple data elements are identified as coded or as a qualifier. For those elements, a predefined set of codes must be allocated in order to identify the intended semantics of the element. Some of these associated code lists are included with the directory; others are defined in other recommendations from the United Nations or other international standards bodies. For some coded elements, there is no international standard code list. The codes for these elements are identified bilaterally, or by sector and national organisations. Composite data elements consist of two or more simple data elements, which are then called component elements. The component data elements in a composite data element belong together in the same way a price and a currency unit belong together in a price specification. The component data elements in a composite data element must be separated by component data element separators. The Segment Dictionary groups data elements into units of information called segments. A segment contains: •
A segment tag; the name of the segment
•
Data elements; separated by data element separators; and
•
A segment terminator; to terminate the segment.
Segments can appear repeatedly in a message. Such segments are known as repeating segments. Segments can also be nested to form segment groups, which can also be repeating segments. Informative-C, an appendix of ISO 9735, defines a notation to express the group structure of an UN/EDIFACT message. This notation is generally used. The next figure gives an example of a fictitious message in IC-notation. For detailed information about UN/EDIFACT formats and the IC notation, see [EDIFACT].
shows that the appearance of an NAD-segment with (conditionally) nested RFF- and CTA-segments is conditional and that it may appear four times at most. The EDI standards supported by TIE Translator are displayed here. Standard
Description
EDIFACT
UN/EDIFACT.
X12
ASC X.12.
CARGOIMP
Cargo-Imp standard for airfreight industry.
ODETTE
International automotive standard worldwide.
TIE Translator also supports other message formats, such as GENCOD, SEDAS as well as any XML 1.0 compliant document.
1.2.4 XML document concepts While the database concepts and the EDI concepts described above share the notion of a record oriented approach where a record can be completely scanned before the next one is open, XML documents use a quite different notion where the end of an XML element, which is structurally more or less equivalent to a record or segment (group), is ended explicitly after all the subsequent element data has been read. This, and the fact that descriptive markup is embedded in the data, makes XML documents quite different, even though they are fundamentally hierarchical documents, just like EDI messages and hierarchical databases. Extensible markup language, or XML, is a syntax specification published as a Recommendation by the World Wide Web Consortium (W3C). The TIE Translator supports version 1.0 of this specification, which is defined in [XML]. XML 1.0 is a subset of SGML, which is published as an ISO standard. Every document conforming to XML 1.0 is also a conforming SGML document. A typical XML document may look like the following: Linda Mann20x30 inches Oil1996 Still Life 6000 Chris From this example, several important features of XML documents can already be discovered. First of all, the document starts with an XML declaration on the first line. This declaration allows pars ers to recognize the character encoding used for the document, and to assess whether the document is supposed to be an XML document. Recognition of XML documents is based on the string
Feb 15, 2005 - Hierarchical database model. 4. 1.4.3. EDI concepts. 5. 1.4.4 .... and what to do to solve / avoid them. ... In practice this means you may obtain a ...... is defined as: the tag occurs in the list, and a test for inequality is defined
(1) Le coût de l'énergie .... substantielles en matière de coût énergétique. ... une facturation simple et sans souci grâce à la facturation électronique (factures ...
RTCA DO-160 (valid environmental tests) ..... To guarantee a speedy download ..... Downloading of all data in Argus, Application of holographic control seal.
In order to avoid electrical discharges, connect the ground terminals of all the modules to ... Respect the temperature and humidity ranges specified on the chapter about .... This one is a dual purpose key and is used for entering values and making
Lochgruppe für Befestigung mit Montageplatte nach DIN 18263 Teil 2. (siehe Montageanleitung) boring configuration for the fixture with adapter plate according.
Before starting up the DRO, carefully read the instructions of ... technical characteristics in this manual (1.3). ..... grinding sequence through its digital outputs.
voltage outside the range indicated in chapter 2 of this manual. Ground connection. In order to avoid electrical discharges, connect the ground terminals of all the .... whether the discrete mode is selected ( if PAR20(7)=0, which activates a digital
This fast, one-cord Fob may please you. ... repeat its Half Knot around the ... It just occurred to me that you could make all the First End's Half Knots go in the ...
DE MORAES, Naomi James Sutcliffe. âTechniques for Teaching ...... member of the Johnson & Johnson family of companies. He holds a BA in. French and a BA ...
HX. (6ter) Dont amortissements des souscriptions dans des PME innovantes (art. 217 octies). RC. Dont amortissements exceptionnel de 25% des constructions ...
