1. Business Informatics Group
Institute of Software Technology and Interactive Systems
Vienna University of Technology
Favoritenstraße 9-11/188-3, 1040 Vienna, Austria
phone: +43 (1) 58801-18804 (secretary), fax: +43 (1) 58801-18896
office@big.tuwien.ac.at, www.big.tuwien.ac.at
Electronic Data Interchange
188.422 E-Commerce Technologien
Philipp Liegl
2. Agenda
2
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
4. Different forms of data exchange
4
• Direct and vocal
• Usually during a face-to-face communication
• Mimic and gestural expression underpin the communication procedure
• Common context
• Vocal using a transport channel
• e.g. via radio or mobile phones
• focus on the spoken word
• Using scripture
• letters, books etc.
» EDI in this context?
5. The goal of Electronic Data Interchange – Exchange of business related data
independent of software, hardware and communication protocols.
Application Application
User User
User Application
Email
IM
SMS
…
XML messages
Web Forms
…
EDIFACT
UBL
SWIFT
CIDX
…
6. B2C vs. B2B
6
B2C
• Server dominates the business process
• Consumer reacts on the fly
B2B
• Applications must interact with each other
• Applications must follow an agreed
• business process (UMM)
• business document structure (CCTS)
6
7. B2C – Client-Server Computing
7
Messaging Layer
Presentation Layer
Web
Application
Server
Databases ERP Systems Legacy Applications
Persistence Layer
Client
HTTP request
HTTP response
Business Layer
8. B2B Application Computing
Messaging Layer
Document Layer
Business Layer
B2B Application Server
Messaging Layer
Document Layer
Business Layer
B2B Application Server
SOAP request over
HTTP, SMTP, ...
Common Process Logic
Databases ERP Systems …
Persistence Layer
Common Document Logic
Databases ERP Systems …
Persistence Layer
9. Agenda
9
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
10. EDI – define a format for the exchange of information between
applications
10
EDI
13. EDI standards
13
• Syntax rules which define the allowed characters
and their order of occurrence
• Codes (a vocabulary of allowed values)
• Message design defining the structure of information
15. Is every standard an EDI standard?
15
• 6d803ef64568e0191a85500f103ec39
• <items><item>Book</item></items>
• 1010111101011000010100111110011101010
• BPR*C*77.77*C*ACH*CTX*01*234056789*DA*0099109999*
• MSH|^~&||GA0000||VAERS PROCESSOR|20010331605||
ORU^RO1|20010422GA03|T|2.3.1|||AL|
ANSI X.12
HL7
EAN
XML
Standards are defined on many different levels and in
many different domains, however not every standard
is an EDI standard.
base-16
binary
17. United Nations Electronic Data Interchange for Administration,
Commerce, and Transport – UN/EDIFACT
17
UN/CEFACT =
United Nations Center for Trade Facilitation and Electronic Business
18. The United Nations and e-Business?
18
• To maintain international peace
and security
• To develop friendly relations
among nations
• To achieve international co-
operation
19. The organization of UN/CEFACT
19
United NationsUnited Nations
International
Court of Justice
Security
Council
General
Assembly
Economic And
Social Council
Economic And
Social Council
Trusteeship
Council
Secretariat
WTO (Trade) WHO (Health) WBG (Bank) WCO (Customs)
UN/ECEUN/ECE …
UN/CEFACT
Centre for the Facilitation of Procedures and Practices
in Administration, Commerce and Transport
UN/CEFACT
Centre for the Facilitation of Procedures and Practices
in Administration, Commerce and Transport
TMG
Techniques and
Methodologies Group
TMG
Techniques and
Methodologies Group
TBG
International Trade &
Business Processes
Group
TBG
International Trade &
Business Processes
Group
ICG
Information Content
Management Group
ICG
Information Content
Management Group
LG
Legal Group
LG
Legal Group
ATG
Applied
Technologies Group
ATG
Applied
Technologies Group
UN/CEFACT Forum
Committee for the Development of Trade,
Industry and Enterprise Development
Committee for the Development of Trade,
Industry and Enterprise Development
20. The organization of UN/CEFACT cont'd
1 February 2008
International Trade
and Business
Processes Group
International Trade
and Business
Processes Group
Applied Technology
Group
Applied Technology
Group
Information Content
Management Group
Information Content
Management Group
Techniques and
Methodologies Group
Techniques and
Methodologies Group Legal Group
Legal Group
Domains: Accounting & Audit - Agriculture - Architecture, Engineering & Construction - Business Process Analysis - Customs -
eGovernment - Electronic Trade Documents - Environmental Management - Finance - Harmonization - Health Care -
Insurance - International Trade Procedures - Social Services - Statistics Collection and Reporting - Supply Chain -
Transport - Travel, Tourism and Leisure
Plenary ChairPlenary Chair
___________________
BureauBureau
Plenary ChairPlenary Chair
___________________
BureauBureau
FMGFMG
ForumForum
ManagementManagement
GroupGroup
FMGFMG
ForumForum
ManagementManagement
GroupGroup
UNECE
Secretariat
UNECE
Secretariat
UN/CEFACT Forum
UN/CEFACT Plenary
21. The International Trade & Business Process Groups (TBGs)
Ministry of International
Commerce, Rome 21
24. Agenda
24
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
26. UN/EDIFACT
26
• Syntax
• Rules for the definition of a message structure
• Standardized codes
• Data elements
• Smallest data unit
• Segments
• Groups of related data elements
• Messages
• Ordered sequence of segments
• Defines a business transaction
27. Common paper vs. EDIFACT standard
27
• Predefined form
• Fields of the form
• Choices/Enumerations
• Context specific groups of fields
and compartments
• Logical grouping between the
different groups
• Identification using a fixed form
text
• EDI message
• Data element
• Coded data elements
• Segments
• Segment groups
• EDI syntax
28. EDIFACT specifics
28
• Hierarchically structured
• Data element identification
• Delimiter based
• Data fields with fixed length
• Mandatory and conditional status of data elements and segments
31. Batch vs. interactive EDIFACT
31
• Batch interchanges
• Like a letter: stand-alone, includes related topics relevant to the addressee
• May invite a reply at a later date
• Have control sequences that begin with "UN" such as
• UNA, UNB, UNG, UNH, UNT, UNE, and UNZ
• Interactive interchanges
• Like a telephone conversation
• Addressing topics in sequence
• Have control segment that begin with "UI" such as
• UIB, UIG, UIH, UIT, UIE, and UIZ.
• There is no UIA segment corresponding to the batch UNA segment.
See "Interactive EDI – IT and commerce in the 21st
century" by A.P. Barrett
for a deeper discussion (available in the IEEE library)
32. Simple Data Elements – specified in EDED
32
• Change indicators
a plus sign (+) for an addition
an asterisk (*) for an amendment to structure
a hash sign (#) for changes to names
a vertical bar (|) for changes to text for descriptions and
notes
a minus sign (-) for marked for deletion (within either
batch or interactive messages)
a letter X (X) for marked for deletion (within both batch
and interactive messages)
• Usage indicators
[B] = used in batch messages only
[I] = used in interactive messages only
[C] = common usage in both batch and interactive messages
33. Simple Data Elements
33
• 3164 City Name [C] (= both batch & interactive)
Desc: Name of a city
Repr: an..35
• Example: Vienna
• 2380 Date or time or period text [C]
Desc: The value of a date, a date and time, a time or of a
period in a specified representation.
Repr: an..35
• Example: Date the invoice arrived
• Example: 20081212
• 2031 Time variation quantity [I] (= interactive only)
Desc: To specify a time variation.
Repr: n..3
• Example: 1
34. Simple Data Elements with Code Lists
34
• 2379 Date or time or period format code
Desc: Code specifying the representation of a date, time
or period.
Repr: an..3
• Example: 2
• Code Values:
2 DDMMYY Calendar date: D = Day; M = Month; Y = Year.
3 MMDDYY Calendar date: M = Month; D = Day; Y = Year.
204 CCYYMMDDHHMMSS Calendar date including time with
seconds: C=Century;Y=Year;
M=Month;D=Day;H=Hour;M=Minute;S=Second.
[…]
35. Composite Data Element
35
• C507 DATE/TIME/PERIOD
• Desc: Date and/or time, or period relevant to the
specified date/time/period type.
010 2005 Date or time or period function code qualifier M an..3
020 2380 Date or time or period text C an..35
030 2379 Date or time or period format code C an..3
36. C507 example
36
• 3:120499:2
• 3 = Invoice document issue date time
• 120499 = 12. April 1999
• 2 = DDMMYY Calendar date: D = Day; M = Month; Y = Year
• 5:990412:101
• 5 = A period of time when saleable stocks are expected to cover
demand for a product.
• 990412 = 12. April 1999
• 101 = YYMMDD Calendar date: Y = Year; M = Month; D = Day.
37. 37
NAD NAME AND ADDRESS
010 3035 PARTY FUNCTION CODE QUALIFIER M 1 an..3
020 C082 PARTY IDENTIFICATION DETAILS C 1
3039 Party identifier M an..35
1131 Code list identification code C an..17
3055 Code list responsible agency code C an..3
030 C058 NAME AND ADDRESS C 1
3124 Name and address description M an..35
3124 Name and address description C an..35
3124 Name and address description C an..35
3124 Name and address description C an..35
3124 Name and address description C an..35
040 C080 PARTY NAME C 1
3036 Party name M an..35
3036 Party name C an..35
3036 Party name C an..35
3036 Party name C an..35
3036 Party name C an..35
3045 Party name format code C an..3
050 C059 STREET C 1
3042 Street and number or post office box identifier M an..35
3042 Street and number or post office box identifier C an..35
3042 Street and number or post office box identifier C an..35
3042 Street and number or post office box identifier C an..35
060 3164 CITY NAME C 1 an..35
070 C819 COUNTRY SUBDIVISION DETAILS C 1
3229 Country subdivision identifier C an..9
1131 Code list identification code C an..17
3055 Code list responsible agency code C an..3
3228 Country subdivision name C an..70
080 3251 POSTAL IDENTIFICATION CODE C 1 an..17
090 3207 COUNTRY IDENTIFIER C 1 an..3
Segment
38. Segment example
38
• Buyer:
Institute of Software Technology and Interactive Systems,
Vienna University of Technology
Favoritenstraße 9-11/188-3
1040 Vienna, Austria
• NAD+BY++Institute of Software Technology:and Interactive
Systems:Vienna University of Technology:Favoritenstraße 9-
11/188-3:1040 Vienna, Austria’
• NAD+BY+++Institute of Software Technology:and Interactive
Systems:Vienna University of Technology+Favoritenstraße 9-
11/188-3+ Vienna++1010+AT’
Segments are assembled to messages.
39. Segment Groups
39
• Aggregating several segments to groups
0160 ----- Segment group 3 ------------------ C 99---------+|
0170 RFF Reference M 1 ||
0180 DTM Date/time/period C 5----------+|
Possible examples:
• RFF-DTM-DTM-DTM-DTM-RFF-DTM-DTM
• RFF
• RFF-RFF-RFF
40. 40
0010 UNH Message header M 1
0020 BGM Beginning of message M 1
0030 DTM Date/time/period M 35
0040 PAI Payment instructions C 1
0050 ALI Additional information C 5
0060 IMD Item description C 999
0070 FTX Free text C 99
0080 GIR Related identification numbers C 10
0090 ----- Segment group 1 ------------------ C 9999--------+
0100 RFF Reference M 1 |
0110 DTM Date/time/period C 5-----------+
0120 ----- Segment group 2 ------------------ C 99----------+
0130 NAD Name and address M 1 |
0140 LOC Place/location identification C 99 |
0150 FII Financial institution information C 5 |
|
0160 ----- Segment group 3 ------------------ C 99---------+|
0170 RFF Reference M 1 ||
0180 DTM Date/time/period C 5----------+|
|
0190 ----- Segment group 4 ------------------ C 5----------+|
0200 DOC Document/message details M 1 ||
0210 DTM Date/time/period C 5----------+|
|
0220 ----- Segment group 5 ------------------ C 5----------+|
0230 CTA Contact information M 1 ||
0240 COM Communication contact C 5----------++
Segment
table
message
type
ORDERS
Trigger
Segments
42. Order
42
Institute of Software Technology and Interactive Systems
Vienna University of Technology
Favoritenstraße 9-11/188-3
A-1040 Wien
Hardware & Software GmbH
Wiedner Hauptstraße 12/8
1040 Wien
Bestellnr.: 123321 Bestelldatum: 12. März 1999
Lieferdatum: 3. Mai 1999
Agent: Hugo Heuschreck
EAN-Nummer Artikel Menge Einh. ÖS/Einh. ÖS Gesamt
34567892189 Sun-Workstation Sparc 10 3 Stück 200.000 600.000
98754390211 Compaq Pentium 10 Stück 40.000 400.000
1.000.000
200.000
1.200.000
43. ORDERS – full example according to directory D93A
43
UNH+ME0000001+ORDERS:D:93A:UN’
BGM+220+123321’
DTM+137:990312:101’
DTM+2:990503:101’
NAD+BY+++Institute of Software Technology:and Interactive
Systems:Vienna University of Technology+Favoritenstraße 9-11/188-
3+ Vienna++1010+AT’
CTA+PE:HH:Hugo Heuschreck’
NAD+SE+++Hard & Software GmbH+Wiedner Hauptstrasse 12/8+Vienna++
1040+AT’
TAX+7+VAT+++20
CUX+2:ATS:9’
LIN+1++34567892189:EN::9’
QTY+21:3:EA’
PRI+AAA:200000:PE’
LIN+2++98754390211:EN::9’
QTY+21:10:EA’
PRI+AAA:40000:PE’
UNS+S’
MOA+86:1200000’
UNT+18+ME0000001’
44. Every EDIFACT message type is defined in a unique manner:
44
CONTENTS
Purchase order message
0. INTRODUCTION
1.SCOPE
1.1 Functional definition
1.2 Field of application
1.3 Principles
2. REFERENCES
3. TERMS AND DEFINITIONS
3.1 Standard terms and definitions
4. MESSAGE DEFINITION
4.1 Segment clarification
4.1.1 Header section
4.1.2 Detail section
4.1.3 Summary section
4.2 Segment index (alphabetical sequence by tag)
4.3 Message structure
4.3.1 Segment table
47. Collisions
47
UNH Message Header M 1
...
----- Segment group 2 ------------------ C 20 --------+
NAD Name and Address M 1 |
LOC Place/Location identification C 9 |
FII Financial institution information C 5 |
|
----- Segment group 3 ------------------ C 9----------+ |
RFF Reference M 1 | |
DTM Date/time/period C 5 ---------+ |
|
----- Segment group 4 ------------------ C 9----------+ |
FII Financial institution information M 1 | |
PAI Payment Instructions C 5 ---------+ |
48. Agenda
48
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
49. PRO EDIFACT
49
• Shorter transaction times
• Lower transaction costs
• Reduction of recurring data collection – fault reduction
• Lower staff costs
• Better planning
• Optimization potential through innovative processes
• Just-in-Time (JIT) Production
• Lower stocks
• Reduction of paper based document transfer
• Cost reduction in terms of document handling
50. CONTRA EDIFACT
50
• Rather old-fashioned standard
• Verbose
• Inflexible
• Change requests last rather long
• Newer solutions (XML-based) provide greater flexibility
• Tool vendor support for COTS (Commercial of the shelf) software rather
low
• EDIFACT interfaces are expensive
• "BIG players only please"
51. Was EDI successful overall?
51
The rest of all business that should be
exchanging information electronically
FORTUNE 10000
(1000 in the top 10 Economics)
95%
5%
Using EDI
EDI Capable
2%
98%
Klaus-Dieter Naujok, 1999
52. Agenda
52
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
53. Business Document Standards
A
B
CD
E
A
B
CD
E Standard
Format
Standard:
Standard
Message Implementation Guide (MIG):
MIG
User Group
MIG
Company
MIG
Partner-specific
• Syntax
• Building Blocks
• Content
54. Message Implementation Guide
54
• Subset of an EDIFACT message for a certain
domain/industry/application scenario
• Example: MBS-PAYMUL message
• Defined Subset of PAYMUL message
• Entire EDIFACT rules are reflected in the standard
• Only segments and segment groups are marked as not used which are
conditional in the PAYMUL message
• More information:
• http://www.stuzza.at/1577_DE.pdf
55. Agenda
55
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
56. The UNeDOCs Project
56
"A generic methodology to link the paper based business world with the
electronic business world"
• Provide a smooth migration towards Digital Paper
• Electronic successor of the paper based UN Layout Key
• Combine a set of existing standards
• Core Components
• EDI
• XML
• Document presentation guidelines
60. Problems of current approaches
60
Multiple efforts for document standardization exist – most of them are
incompatible to each other
Inclusion of every possible element leads to a strong overhead
Transfer syntax specific standards may require difficult reengineering
Logical level business document definitions are difficult to communicate
between developers and stakeholders
Cross-industry and cross-domain integration is mostly not reflected
A promising global standard for business document definition exists:
UN/CEFACT‘s Core Components Technical Specification
61.
62. UN/EDIFACT
Web Services
Windows Workflow
…
UN/CEFACT's Modeling
Methodology (UMM)
Core Components
Technical Specification
(CCTS)
Functional Service
View
related standards
Business Operational
View
related standards
The Open-edi Reference Model – ISO 14662
BusinessTransactions
Business aspects
of business transactions
Information technology
aspects of business
transactions
viewed
as
comply
with
covered
by
covered
by
comply
with
transformed
to
Business Operational View
Functional Service View
63. Core Components at a
glance
63
• Reusable building
blocks for building
business documents
• Based on a common
semantic basis
• Context mechanism for
industry/domain specific
documents
• Flaw:
Core components are a
theoretical concept
64. Core Components cont'd
64
• Are the central building blocks of the Core Component Technical
Specification (CCTS)
• Platform independent
• Used to create shared libraries of interoperable business documents
• The ontological base of the CCTS is the United Nations Trade Data
Element Dictionary (UN/TDED)
• Initially started as part of ebXML standards suite
• Now a dedicated project independent of ebXML
65. Core Component (CC) example
65
• No business context
• Independent of industry or
domain
ACC Aggregate Core Component
BCC Basic Core Component
ASCC Association Core Component
66. Business Information Entity (BIE) example
66
• Core Components in a specific
business context (e.g. travel
industry)
• BIEs have a specific business
semantic
• Qualifiers (US_) help to define
and differentiate a BIE from its
associated CC and other BIEs
ABIE Aggregate Business Information Entity
BBIE Basic Business Information Entity
ASBIE Association Business Information Entity
67. By introducing the business context, core components
become business information entities
67
Core Components (CC) Business Information Entities (BIE)
BIEs are derived from CCs by restriction
69. Business Data Types (BDT) and Core Data Types (CDT)
69
• Business Data Types (BDT) are
derived from Core Data Types
(CDT) by restriction
• Business Information Entities use
Business Data Types
• Core Components use Core Data
Types
«CDT»
types:draft:coredatatypes:1.0::Code
«SUP»
+ CodeListURI: String [0..1]
+ CodeListSchemeURI: String
+ LanguageIdentifier: String [0..1]
+ CodeListAgencyName: String
«CON»
+ Content: String
«BDT»
LandUsageType_Code
«SUP»
+ CodeListAgencyName: String [0..1] = EasyBiz
+ CodeListSchemeURI: String [0..1] = urn:au:gov:vic:...
+ CodeListName: String [0..1] = LandUsageType
«CON»
+ Content: LandUsageType [0..1]
«BasedOn»
70. Data Types cont'd
70
• A data type consists of exactly one
content component (CON)
and multiple supplementary
components (SUP)
• Content components contain
information e.g. 15
• Supplementary components
contain meta information e.g.
temperature, Fahrenheit
«CDT»
types:draft:coredatatypes:1.0::Code
«SUP»
+ CodeListURI: String [0..1]
+ CodeListSchemeURI: String
+ LanguageIdentifier: String [0..1]
+ CodeListAgencyName: String
«CON»
+ Content: String
«BDT»
LandUsageType_Code
«SUP»
+ CodeListAgencyName: String [0..1] = EasyBiz
+ CodeListSchemeURI: String [0..1] = urn:au:gov:vic:...
+ CodeListName: String [0..1] = LandUsageType
«CON»
+ Content: LandUsageType [0..1]
«BasedOn»
71. Primitive Types (PRIM)
71
• Primitive Types (PRIM) are used to
set the value type of
supplementary components (SUP)
and content components (CON)
«PRIM»
Boolean
«PRIM»
String
«PRIM»
Decimal
«BDT»
types:draft:coredatatypes:1.0::Code
«SUP»
+ CodeListURI: String [0..1]
+ LanguageIdentifier: String [0..1]
«CON»
+ Content: String
72. Enumeration types (ENUM)
72
• Enumeration types (ENUM) are
used to restrict the value range
of supplementary components
(SUP) and content components
(CON)
«ENUM»
FoodOperationType
+ MFV: string = Mobile Food Vehicle
+ MUT: string = Mobile Unit
+ OTH: string = Other
+ STD: string = Stand
+ TMQ: string = Tent/Marquee
«ENUM»
HealthPremisesType
+ HasGamblingLicense: string = HasGamblingLicense
+ IsBingoPlayed: string = IsBingoPlayed
+ ProvidesFoodForGuest: string = ProvidesFoodForGuest
+ ProvidesFoodForPublic: string = ProvidesFoodFor...
«BDT»
HealthPremisesType_Code
«SUP»
+ CodeListAgencyName: String [0..1] = EasyBiz
+ CodeListName: String [0..1] = HealthPremisesType
+ CodeListSchemeURI: String [0..1] = urn:au:gov:vic:...
«CON»
+ Content: HealthPremisesType [0..1]
73. The UML Profile for Core Components (UPCC)
73
• Flaws of the Core Component Technical Specification
• Standardization process of Core Components is based on spread sheets
• No direct integration into modeling tools possible
• UML Profile for Core Components
• Independent project based on the CCTS
• Set of stereotypes, tagged values and OCL constraints
• Can be integrated into a modeling tool of choice
• Proof of concept based on UML modeling tool Enterprise Architect
• UML class diagrams are used for the modeling of Core Components
• Current version 1.0 (CCTS 2.01 compliant)
• Version 3.0 is about to be released soon (CCTS 3.0 compliant)
74. Library concept used to aggregate artifacts of the same type
74
BIELibrary CDTLibrary BDTLibrary PRIMLibrary ENUMLibraryDOCLibrary
bLibrary
from UMM 2.0 Base
Module
0..* 0..*0..*0..*0..*0..*
75. UPCC - example
75
holds the actual business
document but can also define
new ABIEs
aggregates ABIEs
aggregates BDTs
aggregates CCs
aggregates ENUM
aggregates PRIMs
