EDI/Edifact Plugin: Unterschied zwischen den Versionen
Cg (Diskussion | Beiträge) |
Cg (Diskussion | Beiträge) |
||
Zeile 46: | Zeile 46: | ||
Non-formal specification are PDF, HTML and Text formats. |
Non-formal specification are PDF, HTML and Text formats. |
||
The biggest challenges in dealing with Edifact is the trouble to get formal (machine readable) specifications. |
|||
SEF format files provide all required information and would be perfect for this task - however, SEF seems to be obsolete and SEF specifications for |
SEF format files provide all required information and would be perfect for this task - however, SEF seems to be obsolete and SEF specifications for |
Version vom 16. Juni 2015, 14:11 Uhr
Inhaltsverzeichnis
Edi/Edifact Message Plugin[Bearbeiten]
The Edifact Message plugin provides extensive support for Edifact message processing.
Background Information[Bearbeiten]
Edifact is an international standard for the exchange of business transaction messages, such as invoices, orders, quotes etc. Edifact transactions is heavily used in B2B communications, and supported by SAP, Oracle, IBM and other business processing systems.
Edifact messages consist of a number of records (called "segments"), which themself contain a number of data elements. Both non-composite and composite data elements are possible.
Edifact messages are surrounded by a header- and trailer segment.
An edifact transaction may contain multiple individual messages, and is itself surrounded by a transaction header segment and a transaction trailer segment.
For comprehensive documentation and a full specification, see United Nations Economic Commision for Europe in general, and Introducing UN/Edifact in particular.
Edifact Messages[Bearbeiten]
UN/Edifact defines the overall format and layout of edifact messages. Standard specifications are typically published twice a year. New revisions typically add additional data elements, additional segment types and messages. New revisions are typically backward compatible. That is previous definitions are seldom (if ever) obsoleted.
All messages and segments contains a tag (or message type) field, which allows for the type of message/segment to be identified. Thus, in theory, it is possible to extract field values from arbitrary messages, even if the concrete message layout is unknown.
However, the semantic interpretation of a particular datum highly depends on its position inside the message. For example, a DTM-segment's datetime value can be extracted easily, but its interpretation (delivery date, invoice date, quotation date etc.) is only possible if the overall message structure is known.
Message Subsets[Bearbeiten]
The definitions as published by UN/Unice define the overall structure of messages and segments. However, most concrete application do not need/use/support the full set of possible segments in a message. Many segments are specified as optional and not supported/expected by many concrete users.
For this typical B2B transaction systems expect and handle only subsets of the over all message set and subsets of the possible segment set within those messages.
Meta Descriptions[Bearbeiten]
In order for a correct semantic interpretation, modification and verification of data elements, a meta description is required, which specifies the format of a message (segment order and grouping) and of data aelements (alphanumeric, numeric, minimum/maximum size and value etc.).
Such specifications are published by UN/Unice for the overall framework, and by companies for the B2B partners. Specifications exist in both formal (machine readable) formats and in non-formal (human readable) formats. Formal specification formats are SEF (Structured Edifact Format Specification) and XSD (XML Schema definitions). Non-formal specification are PDF, HTML and Text formats.
The biggest challenges in dealing with Edifact is the trouble to get formal (machine readable) specifications.
SEF format files provide all required information and would be perfect for this task - however, SEF seems to be obsolete and SEF specifications for newer versions are hard to find (which is a pity). SEF files are not available from UN/Unice.
XSD seems to be the way to go, but official XSD sepcifications are rare and not published by UN.
DFDL is a new XML-based definition standard, which is very promising in theory. However, it is relatively new. Only a small subset of Edifact messages is formally specified in this format.
Official documents from UN/Unice include PDF, HTML and Text files. Although being informal, existing html and text files seem to follow a common layout and structure.
Edifact Plugin Components[Bearbeiten]
Edifact Smalltalk Class Library[Bearbeiten]
This library contains all real functionality of the edifact plugin. The expecco action library (edifact.ets) contains interfacing blocks to the functions found there.
Edifact Message Decoder[Bearbeiten]
Includes a general message/segment/data decoder, which is able to read arbitrary (unknown) messages. Such textual messages (wirre data) is decoded and presented as a hierarchy of objects, which model the message, segments and elements. The decoder can decode arbitrary messages - i.e. a meta description is not required for basic decoding.
Edifact Message Encoder[Bearbeiten]
This encodes a message object back into the external edifact wire representation. It cares for the character set, separator definitions etc. In general, the original input is regenerated (with minor differences) when the a decoded edifact message is encoded back to wire data.
Edifact Object Representation Framework[Bearbeiten]
These classes model edifact objects as messages, segments, composite- and non-composite data elements. Without a meta descritpion of the message set, data elements can by accessed by numeric indices (segment#, element#). With a meta description, elements are accessable by more user friendly names, such as the official UN standard field names (C009, C123, 4056 etc), or user assigned application field names (delivaryDate, deliveryLocation, street, city etc.)
Edifact Schema Definition Framework[Bearbeiten]
This set of classes represent a meta description of edifact objects. They can be hand-written, dynamically constructed or read in from external specification files in various formats.
Edifact Schema Definition Readers[Bearbeiten]
These classes read external meta specifications in various formats and create a schema object. Schema objects are needed to correctly interpret element data, to acces elements by user friendly names, and to create new messages which have the correct segment and segment group structure. Readers exist for the following formats:
- XSD
- DFDL
- SEF
- HTML (as in UN docs)
- Text (as in UN docs)
- bots (import specs written in the python programming language, written for the bots processor)
- internal private format
Edifact Plugin Library for Expecco[Bearbeiten]
Back to Online Documentation.