Edi....Ecommerce

Business Informatics Group

Institute of Software Technology and Interactive Systems Vienna University of Technology

Favoritenstraße 9-11/188-3, 1040 Vienna, Austriaphone: +43 (1) 58801-18804 (secretary), fax: +43 (1) [email protected], www.big.tuwien.ac.at

Electronic Data Interchange

188.422 E-Commerce Technologien

Philipp Liegl

Agenda

2

• EDI motivation and definition

• EDI standards

• UN/EDIFACT: syntax and directories

• EDI: chances and pitfalls

• MIG: message implementation guide

• Outlook

EDI for everyone?

3

Business

Administration

Consumer

A2A

B2C

C2CB2B

A2CB2A

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?

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

…

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

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

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

Agenda

9


• EDI standards




• Outlook

EDI – define a format for the exchange of information between applications

10

EDI

EDI standards

11

A

B

CD

E

EDI standards

12

A

B

CD

E

A

B

CD

E StandardFormat

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

EDI standards cont'd

14

industry specific

industry independent

regional international

ANSI X.12

ODETTE SWIFT

UN/EDIFACT

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 inmany different domains, however not every standard is an EDI standard.

base-16

binary

EDI and OSI

16

http://www.telecommunications-tutorials.com

United Nations Electronic Data Interchange for Administration, Commerce, and Transport – UN/EDIFACT

17

UN/CEFACT = United Nations Center for Trade Facilitation and Electronic Business

The United Nations and e-Business?

18

• To maintain international peace

and security

• To develop friendly relations

among nations

• To achieve international co-

operation

The organization of UN/CEFACT

19

United NationsUnited Nations

International Court of Justice

SecurityCouncil

GeneralAssembly

Economic AndSocial Council

Economic AndSocial Council

TrusteeshipCouncil

Secretariat

WTO (Trade) WHO (Health) WBG (Bank) WCO (Customs) UN/ECEUN/ECE …

UN/CEFACTCentre for the Facilitation of Procedures and Practices

in Administration, Commerce and Transport

UN/CEFACTCentre for the Facilitation of Procedures and Practices

in Administration, Commerce and Transport

TMG

Techniques and Methodologies Group

TMG


TBG

International Trade & Business Processes

Group

TBG

International Trade & Business Processes

Group

ICG

Information ContentManagement Group

ICG

Information ContentManagement Group

LG

Legal Group

LG

Legal GroupATG

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

The organization of UN/CEFACT cont'd

1 February 2008

International Tradeand Business

Processes Group

International Tradeand Business

Processes GroupApplied Technology

Group

Applied TechnologyGroup

Information Content Management Group

Information Content Management 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

ForumForumManagementManagement

GroupGroup

FMGFMG

ForumForumManagementManagement

GroupGroup

UNECESecretariat

UNECESecretariat

UN/CEFACT Forum

UN/CEFACT Plenary

The International Trade & Business Process Groups (TBGs)

Ministry of International Commerce, Rome 21

Known standards from UN/CEFACT

22

UN/EDIFACT

ebXML

UMM & CC

UN Layout Key

The UN Layout Key

23

Agenda

24


• EDI standards




• Outlook

The four pillars of EDIFACT

25

EDI

UN/EDIFACT

Dataexchange

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

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

EDIFACT specifics

28

• Hierarchically structured

• Data element identification

• Delimiter based

• Data fields with fixed length

• Mandatory and conditional status of data elements and segments

EDIFACT subsets

29

EDIFICE

EDITRANS

ODETTE

EDITEX

EDITEC

ETIS

CEFIC

EDIFURN

EDIFOR

EDIGAS

EANCOM

30

BatchEDIFACT at a glance

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)

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

Simple Data Elements

33

• 3164 City Name [C] (= both batch & interactive)Desc: Name of a cityRepr: 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

Simple Data Elements with Code Lists

34

• 2379 Date or time or period format codeDesc: 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.

[…]

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

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

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

http://www.unece.org/trade/untdid/d08a/tred/tred3035.htm

http://www.unece.org/trade/untdid/d08a/trcd/trcdc082.htm

















Segment example

38

• Buyer:Institute of Software Technology and Interactive Systems, Vienna University of TechnologyFavoritenstraße 9-11/188-31040 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.

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

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 typeORDERS

Trigger Segments

Branching Diagram ORDERS

41

Order

42

Institute of Software Technology and Interactive SystemsVienna University of Technology

Favoritenstraße 9-11/188-3A-1040 Wien

Hardware & Software GmbHWiedner Hauptstraße 12/81040 Wien

Bestellnr.: 123321 Bestelldatum: 12. März 1999Lieferdatum: 3. Mai 1999

Agent: Hugo Heuschreck

EAN-Nummer Artikel Menge Einh. ÖS/Einh. ÖS Gesamt34567892189 Sun-Workstation Sparc 10 3 Stück 200.000 600.00098754390211 Compaq Pentium 10 Stück 40.000 400.000

1.000.000200.000

1.200.000

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+++20CUX+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’

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

UN/EDIFACT Directories

45

90.190.291.191.292.1

93.293.S93.WS.93A

D.93AD.94AD.94BD.95AD.95B…D.07A

See also: http://www.unece.org/trade/untdid/directories.htm

Sequences – right or wrong?

46

(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+...’

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 ---------+ |

Agenda

48


• EDI standards




• Outlook

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

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"

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

Agenda

52


• EDI standards




• Outlook

Business Document Standards

A

B

CD

E

A

B

CD

E StandardFormat

Standard:

Standard

Message Implementation Guide (MIG):

MIGUser Group

MIGCompany

MIGPartner-specific

• Syntax

• Building Blocks

• Content

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

Agenda

55


• EDI standards




• Outlook

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

The UNeDOCs initiative

57

Paper Documentaligned to UN Layout Key

XML or UN/EDIFACT

Electronic Edit Form

Business documents in a service oriented world

58

<types/><message/><portType><operation>

<input/><output/><fault/>

</operation><operation>

...</operation>

</portType>

<types/><message/><portType><operation>

<input/><output/><fault/>

</operation><operation>

...</operation>

</portType>

Quote Request

Quote

Purchase Order

Order Acceptance

Order Rejection

Buyer WSDL Seller WSDL

XOR

SOAP-MessageHeaderBody

<orderRejection>....</orderRejection>

How serious is the problem?

59

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

UN/EDIFACTWeb Services

Windows Workflow…

UN/CEFACT's ModelingMethodology (UMM)

Core Components Technical Specification

(CCTS)

Functional Service View

related standards

Business Operational View

related standards

The Open-edi Reference Model – ISO 14662B

usin

ess

Tra

nsac

tion

s

Business aspectsof business transactions

Information technologyaspects of business

transactions

viewedas

complywith

coveredby

coveredby

complywith

transformedto

Business Operational View

Functional Service View

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

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

Core Component (CC) example

65

• No business context• Independent of industry or

domain

ACC Aggregate Core ComponentBCC Basic Core ComponentASCC Association Core Component

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 EntityBBIE Basic Business Information EntityASBIE Association Business Information Entity

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

Dependency between Core Components and Business Information Entities

68

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»

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


«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»

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]


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]

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)

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..*

UPCC - example

75

holds the actual businessdocument but can also definenew ABIEs

aggregates ABIEs

aggregates BDTs

aggregates CCs

aggregates ENUM

aggregates PRIMs

76

bLibrary

Package

CDTLibrary

Package

CCLibrary

Package

PRIMLibrary

Package

ENUMLibrary

Package

BDTLibrary

Package

DOCLibrary

Package

BIELibrary

Type

PRIM

Attribute

SUP

Attribute

CON

Enumeration

ENUM

Class

CDT

Class

BDT

Attribute

BBIE

Attribute

BCC

Class

ACC

Class

ABIE

Association

ASCC

Association

ASBIE

+source

basedOn

basedOn

+target+target

basedOn

basedOn

+source

UPCC meta model (conceptual)

Core Components – the (rough) big picture

77

UPCC 3.0

CCTS 3.0

UML 2.1

…

…<xs:element name="…"

…</xs:element>

complies withstore/retrieve

retrieve

maintain

submit core component definitions

evalute definitions/standardizedefinitions

use

model generate

Core Component model

UN/CEFACT Core ComponentsLibrary

User Library

TBG 17

User

Questions?

78

<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>[email protected]</Email><Http>http://www.big.tuwien.ac.at</Http>

</Contact><? Presentation status=“questions” ?>

</Lecturer>