Electronic Data Interchange
188.422 E-Commerce Technologien
Philipp Liegl
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
Agenda
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
2
EDI for everyone?
A2A
Administration
A2C
B2A
C2C
B2B
Business
Consumer
B2C
3
Different forms of data exchange
• 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?
4
The goal of Electronic Data Interchange – Exchange of business related data
independent of software, hardware and communication protocols.
Email
SMS
…
IM
User
User
XML messages
Web Forms
…
User
Application
EDIFACT
UBL
Application
SWIFT
CIDX
…
Application
B2C vs. B2B
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
B2C – Client-Server Computing
HTTP request
Messaging Layer
HTTP response
Presentation Layer
Business Layer
Databases
ERP Systems
Client
Web
Application
Server
Legacy Applications
Persistence Layer
7
B2B Application Computing
B2B Application Server
SOAP request over
Messaging Layer
HTTP, SMTP, ...
Document Layer
Common Document Logic
Business Layer
Databases
ERP Systems
Persistence Layer
B2B Application Server
Messaging Layer
Document Layer
Business Layer
Common Process Logic
…
Databases
ERP Systems
Persistence Layer
…
Agenda
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
9
EDI – define a format for the exchange of information between
applications
EDI
10
EDI standards
Necessary mappers
600000
A
500000
400000
B
E
Mappers 300000
200000
D
100000
C
0
5
10
20
50
100
Enterprises
200
500
1000
Necessary mappers
11
EDI standards
A
A
B
E
D
C
E
B
Standard
Format
D
C
12
EDI standards
• 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
13
EDI standards cont'd
industry specific
ODETTE
SWIFT
industry independent
ANSI X.12
UN/EDIFACT
regional
international
14
Is every standard an EDI standard?
• 6d803ef64568e0191a85500f103ec39 base-16
• <items><item>Book</item></items> XML
• 1010111101011000010100111110011101010 binary
• \BPR*C*77.77*C*ACH*CTX*01*234056789*DA*0099109999*
EAN
ANSI X.12
• MSH|^~\&||GA0000||VAERS
PROCESSOR|20010331605||ORU^RO1|20010422GA03|T|2.3.
1|||AL|
HL7
Standards are defined on many different levels and in
many different domains, however not every standard
is an EDI standard.
15
EDI and OSI
16
http://www.telecommunications-tutorials.com
United Nations Electronic Data Interchange for Administration,
Commerce, and Transport – UN/EDIFACT
UN/CEFACT =
United Nations Center for Trade Facilitation and Electronic Business
17
The United Nations and e-Business?
• To maintain international peace
and security
• To develop friendly relations
among nations
• To achieve international cooperation
18
The organization of UN/CEFACT
United Nations
International
Court of Justice
Security
Council
General
Assembly
Economic And
Social Council
Trusteeship
Council
Secretariat
WTO (Trade)
WHO (Health)
WBG (Bank)
WCO (Customs)
UN/ECE
…
Committee for the Development of Trade,
Industry and Enterprise Development
UN/CEFACT
Centre for the Facilitation of Procedures and Practices
in Administration, Commerce and Transport
UN/CEFACT Forum
TMG
Techniques and
Methodologies Group
LG
Legal Group
TBG
International Trade &
Business Processes
Group
ICG
Information Content
Management Group
ATG
Applied
Technologies Group
19
The organization of UN/CEFACT cont'd
UN/CEFACT Plenary
Plenary Chair
___________________
Bureau
UNECE
Secretariat
FMG
UN/CEFACT Forum
Forum
Management
Group
International Trade
and Business
Processes Group
Applied Technology
Group
Information Content
Management Group
Techniques and
Methodologies 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 1 February 2008
Transport - Travel, Tourism and Leisure
The International Trade & Business Process Groups (TBGs)
Ministry of International
Commerce, Rome
21
Known standards from UN/CEFACT
UN Layout Key
UN/EDIFACT
ebXML
UMM & CC
22
The UN Layout Key
23
Agenda
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
24
The four pillars of EDIFACT
EDI
Syntax
Data
elements
Segments
Messages
Data
exchange
UN/EDIFACT
25
UN/EDIFACT
• 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
26
Common paper vs. EDIFACT standard
• Predefined form
• Fields of the form
• EDI message
• Data element
• Choices/Enumerations
• Context specific groups of fields
and compartments
• Coded data elements
• Segments
• Logical grouping between the
different groups
• Segment groups
• Identification using a fixed form
text
• EDI syntax
27
EDIFACT specifics
• Hierarchically structured
• Data element identification
• Delimiter based
• Data fields with fixed length
• Mandatory and conditional status of data elements and segments
28
EDIFACT subsets
EDIFURN
EDIFICE
EDITEX
EDITEC
EDIFOR
EDIGAS
EANCOM
ODETTE
ETIS
EDITRANS
CEFIC
29
Batch
EDIFACT
at a glance
30
Batch vs. interactive EDIFACT
• 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)
31
Simple Data Elements – specified in EDED
• Change indicators
a plus sign (+)
an asterisk (*)
a hash sign (#)
a vertical bar (|)
a minus sign (-)
a letter X (X)
for an addition
for an amendment to structure
for changes to names
for changes to text for descriptions and
notes
for marked for deletion (within either
batch or interactive messages)
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
32
Simple Data Elements
• 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
33
Simple Data Elements with Code Lists
• 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.
[…]
34
Composite Data Element
• 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
35
C507 example
• 3:120499:2
• 3
= Invoice document issue date time
• 120499
• 2
= 12. April 1999
= DDMMYY Calendar date: D = Day; M = Month; Y = Year
• 5:990412:101
• 5
• 990412
• 101
= A period of time when saleable stocks are expected to cover
demand for a product.
= 12. April 1999
= YYMMDD Calendar date: Y = Year; M = Month; D = Day.
36
NAD NAME AND ADDRESS
010 3035 PARTY FUNCTION CODE QUALIFIER
020 C082 PARTY IDENTIFICATION DETAILS
3039 Party identifier
1131 Code list identification code
3055 Code list responsible agency code
030 C058 NAME AND ADDRESS
3124 Name and address description
3124 Name and address description
3124 Name and address description
3124 Name and address description
3124 Name and address description
040 C080 PARTY NAME
3036 Party name
3036 Party name
3036 Party name
3036 Party name
3036 Party name
3045 Party name format code
050 C059 STREET
3042 Street and number or post office box identifier
3042 Street and number or post office box identifier
3042 Street and number or post office box identifier
3042 Street and number or post office box identifier
060 3164 CITY NAME
070 C819 COUNTRY SUBDIVISION DETAILS
3229 Country subdivision identifier
1131 Code list identification code
3055 Code list responsible agency code
3228 Country subdivision name
080 3251 POSTAL IDENTIFICATION CODE
090 3207 COUNTRY IDENTIFIER
Segment
M 1 an..3
C1
M an..35
C an..17
C an..3
C1
M an..35
C an..35
C an..35
C an..35
C an..35
C1
M an..35
C an..35
C an..35
C an..35
C an..35
C an..3
C1
M an..35
C an..35
C an..35
C an..35
C 1 an..35
C1
C an..9
C an..17
C an..3
C an..70
C 1 an..17
C 1 an..3
37
Segment example
• 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 911/188-3:1040 Vienna, Austria’
• NAD+BY+++Institute of Software Technology:and Interactive
Systems:Vienna University of Technology+Favoritenstraße 911/188-3+ Vienna++1010+AT’
Segments are assembled to messages.
38
Segment Groups
• Aggregating several segments to groups
0160
0170
0180
----- Segment group 3
RFF Reference
DTM Date/time/period
------------------ C
M
C
99---------+|
1
||
5----------+|
Possible examples:
• RFF-DTM-DTM-DTM-DTM-RFF-DTM-DTM
• RFF
• RFF-RFF-RFF
39
0010
0020
0030
0040
0050
0060
0070
0080
UNH
BGM
DTM
PAI
ALI
IMD
FTX
GIR
Message header
Beginning of message
Date/time/period
Payment instructions
Additional information
Item description
Free text
Related identification numbers
M
M
M
C
C
C
C
C
0090
0100
0110
----- Segment group 1 ------------------ C
RFF Reference
M
Trigger
DTM Date/time/period
C
9999--------+
1
|
5-----------+
0120
0130
0140
0150
----- Segment group 2 -----------------NAD Name and address
LOC Place/location identification
FII Financial institution information
0160
0170
0180
----- Segment group 3
RFF Reference
DTM Date/time/period
0190
0200
0210
----- Segment group 4 ------------------ C
DOC Document/message details
M
DTM Date/time/period
C
0220
0230
0240
----- Segment group 5
CTA Contact information
COM Communication contact
99----------+
1
|
99
|
5
|
|
99---------+|
1
||
5----------+|
|
5----------+|
1
||
5----------+|
|
5----------+|
40
1
||
5----------++
Segments
C
M
C
C
------------------ C
M
C
------------------ C
M
C
1
1
35
1
5
999
99
10
Segment
table
message
type
ORDERS
Branching Diagram ORDERS
41
Order
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
34567892189
98754390211
Artikel
Menge Einh.
Sun-Workstation Sparc 10
3 Stück
Compaq Pentium
10 Stück
ÖS/Einh.
200.000
40.000
ÖS Gesamt
600.000
400.000
1.000.000
200.000
1.200.000
42
ORDERS – full example according to directory D93A
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/1883+ 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’
43
Every EDIFACT message type is defined in a unique manner:
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
44
UN/EDIFACT Directories
90.1
90.2
91.1
91.2
92.1
93.2
93.S
93.W
S.93A
D.93A
D.94A
D.94B
D.95A
D.95B
…
D.07A
See also: http://www.unece.org/trade/untdid/directories.htm
45
Sequences –
right or wrong?
(1)
DOC+...’
NAD+...’
RFF+...’
AJT+...’
DOC+...’
NAD+...’
MOA+...’
TAX+...’
DTM+...’
AJT+...’
RFF+...’
DOC+...’
(2)
DOC+...’
MOA+...’
PAI+...’
STS+...’
AJT+...’
RFF+...’
FTX+...’
DOC+...’
RFF+...’
MOA+...’
TAX+...’
DTM+...’
(3)
DOC+...’
DOC+...’
NAD+...’
RFF+...’
MOA+...’
DTM+...’
STS+...’
DOC+...’
MOA+...’
AJT+...’
RFF+...’
RFF+...’
(4)
DOC+...’
DTM+...’
DOC+...’
NAD+...’
MOA+...’
DOC+...’
MOA+...’
DTM+...’
AJT+...’
RFF+...’
FTX+...’
FTX+...’
(5)
DOC+...’
MOA+...’
DOC+...’
NAD+...’
RFF+...’
DOC+...’
MOA+...’
AJT+...’
AJT+...’
DTM+...’
AJT+...’
RFF+...’
46
Collisions
UNH Message Header
...
----- Segment group 2 -----------------NAD Name and Address
LOC Place/Location identification
FII Financial institution information
----- Segment group 3
RFF Reference
DTM Date/time/period
M
1
C
M
C
C
20
1
9
5
------------------ C
M
C
----- Segment group 4 ------------------ C
FII Financial institution information
M
PAI Payment Instructions
C
--------+
|
|
|
|
9----------+ |
1
| |
5 ---------+ |
|
9----------+ |
1
| |
5 ---------+ |
47
Agenda
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
48
PRO EDIFACT
•
•
•
•
•
•
•
•
•
•
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
49
CONTRA EDIFACT
• 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"
50
Was EDI successful overall?
Using EDI
EDI Capable
98%
95%
5%
FORTUNE 10000
(1000 in the top 10 Economics)
2%
The rest of all business that should be
exchanging information electronically
51
Klaus-Dieter Naujok, 1999
Agenda
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
52
Business Document Standards
Standard:
A
A
• Syntax
B
E
E
B
Standard
Format
• Building Blocks
• Content
D
C
D
C
Message Implementation Guide (MIG):
Standard
MIG
User Group
MIG
Company
MIG
Partner-specific
Message Implementation Guide
• 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
54
Agenda
• EDI motivation and definition
• EDI standards
• UN/EDIFACT: syntax and directories
• EDI: chances and pitfalls
• MIG: message implementation guide
• Outlook
55
The UNeDOCs Project
"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
56
The UNeDOCs initiative
XML or UN/EDIFACT
Paper Document
aligned to UN Layout Key
Electronic Edit Form
57
Business documents in a service oriented world
Buyer WSDL
<types/>
<message/>
<portType>
<operation>
<input/>
<output/>
<fault/>
</operation>
<operation>
...
</operation>
</portType>
Quote Request
Quote
Purchase Order
Order Acceptance
Order Rejection
XOR
Seller WSDL
<types/>
<message/>
<portType>
<operation>
<input/>
<output/>
<fault/>
</operation>
<operation>
...
</operation>
</portType>
SOAP-Message
Header
Body
<orderRejection>
....
</orderRejection>
58
How serious is the problem?
59
Problems of current approaches
 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
60
Business Transactions
The Open-edi Reference Model – ISO 14662
Business Operational View
Business aspects
of business transactions
comply
with
covered
by
viewed
as
UN/CEFACT's Modeling
Methodology
Business Operational
(UMM)
View
Core
related
Components
standards
Technical Specification
(CCTS)
transformed
to
Functional Service View
Information technology
aspects of business
transactions
comply
with
covered
by
UN/EDIFACT
Functional Service
Web Services
View
Windows Workflow
related standards
…
Core Components at a
glance
• 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
63
Core Components cont'd
• 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
64
Core Component (CC) example
• No business context
• Independent of industry or
domain
ACC
BCC
ASCC
Aggregate Core Component
Basic Core Component
Association Core Component
65
Business Information Entity (BIE) example
• 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
BBIE
ASBIE
Aggregate Business Information Entity
Basic Business Information Entity
Association Business Information Entity
66
By introducing the business context, core components
become business information entities
Core Components (CC)
Business Information Entities (BIE)
BIEs are derived from CCs by restriction
67
Dependency between Core Components and Business
Information Entities
68
Business Data Types (BDT) and Core Data Types (CDT)
• 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
69
Data Types cont'd
• 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
70
Primitive Types (PRIM)
• Primitive Types (PRIM) are used to
set the value type of
«PRIM»
Boolean
«PRIM»
String
supplementary components (SUP)
«BDT»
types:draft:coredatatypes:1.0::Code
and content components (CON)
«SUP»
+ CodeListURI: String [0..1]
+ LanguageIdentifier: String [0..1]
«CON»
+ Content: String
«PRIM»
Decimal
71
Enumeration types (ENUM)
• Enumeration types (ENUM) are
used to restrict the value range
«ENUM»
HealthPremisesType
+
+
+
+
HasGamblingLicense: string = HasGamblingLicense
IsBingoPlayed: string = IsBingoPlayed
ProvidesFoodForGuest: string = ProvidesFoodForGuest
ProvidesFoodForPublic: string = ProvidesFoodFor...
«ENUM»
FoodOperationType
+
+
+
+
+
MFV:
MUT:
OTH:
STD:
TMQ:
string = Mobile Food Vehicle
string = Mobile Unit
string = Other
string = Stand
string = Tent/Marquee
of supplementary components
(SUP) and content components
(CON)
«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]
72
The UML Profile for Core Components (UPCC)
• 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)
73
Library concept used to aggregate artifacts of the same type
74
UPCC - example
holds the actual business
document but can also define
new ABIEs
aggregates ABIEs
aggregates BDTs
aggregates CCs
aggregates ENUM
aggregates PRIMs
75
UPCC meta model (conceptual)
bLibrary
Package
CCLibrary
Package
Type
CDTLibrary
PRIM
Attribute
SUP
Class
Attribute
basedOn
CON
ASCC
Class
Package
BDTLibrary
Attribute
Package
DOCLibrary
Association
ASBIE
+source
+source
Class +target
ACC
ENUMLibrary
ENUM
BBIE
basedOn
Package
Enumeration
BDT
BCC
Association
PRIMLibrary
basedOn
CDT
Attribute
Package
Class
+target
basedOn
ABIE
Package
76
BIELibrary
Core Components – the (rough) big picture
evalute
definitions/
standardize
definitions
maintain
UN/CEFACT Core Components
Library
TBG 17
submit core
component
definitions
retrieve
CCTS 3.0
use
store/
retrieve
User
model
User Library
UPCC 3.0
complies with
UML 2.1
…
generate
…
Core Component model
<xs:element name="…"
…
77
</xs:element>
Questions?
<Lecturer>
<Name>Philipp Liegl</Name>
<Company>Vienna University of Technology</Company>
<Department>Business Informatics Group</Department>
<Address>
<Street>Favoritenstraße 9-11/188</Street>
<ZIP>1040</ZIP><City>Vienna</City>
<Country>Austria</Country>
</Address>
<Contact>
<Email>liegl@big.tuwien.ac.at</Email>
<Http>http://www.big.tuwien.ac.at</Http>
</Contact>
<? Presentation status=“questions” ?>
</Lecturer>
78