Edi....Ecommerce

400
-1

Published on

Ecommerce edi

Published in: Engineering, Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
400
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Edi....Ecommerce

  1. 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. 2. Agenda 2 • EDI motivation and definition • EDI standards • UN/EDIFACT: syntax and directories • EDI: chances and pitfalls • MIG: message implementation guide • Outlook
  3. 3. EDI for everyone? 3 Business Administration Consumer A2A B2C C2C B2B A2CB2A
  4. 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. 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. 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. 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. 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. 9. Agenda 9 • EDI motivation and definition • EDI standards • UN/EDIFACT: syntax and directories • EDI: chances and pitfalls • MIG: message implementation guide • Outlook
  10. 10. EDI – define a format for the exchange of information between applications 10 EDI
  11. 11. EDI standards 11 A B CD E
  12. 12. EDI standards 12 A B CD E A B CD E Standard Format
  13. 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
  14. 14. EDI standards cont'd 14 industry specific industry independent regional international ANSI X.12 ODETTE SWIFT UN/EDIFACT
  15. 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
  16. 16. EDI and OSI 16 http://www.telecommunications-tutorials.com
  17. 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. 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. 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. 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. 21. The International Trade & Business Process Groups (TBGs) Ministry of International Commerce, Rome 21
  22. 22. Known standards from UN/CEFACT 22 UN/EDIFACT ebXML UMM & CC UN Layout Key
  23. 23. The UN Layout Key 23
  24. 24. Agenda 24 • EDI motivation and definition • EDI standards • UN/EDIFACT: syntax and directories • EDI: chances and pitfalls • MIG: message implementation guide • Outlook
  25. 25. The four pillars of EDIFACT 25 EDI UN/EDIFACT Data exchange
  26. 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. 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. 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
  29. 29. EDIFACT subsets 29 EDIFICE EDITRANS ODETTE EDITEX EDITEC ETIS CEFIC EDIFURN EDIFOR EDIGAS EANCOM
  30. 30. 30 Batch EDIFACT at a glance
  31. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  41. 41. Branching Diagram ORDERS 41
  42. 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. 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. 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
  45. 45. UN/EDIFACT Directories 45 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
  46. 46. 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+...’
  47. 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. 48. Agenda 48 • EDI motivation and definition • EDI standards • UN/EDIFACT: syntax and directories • EDI: chances and pitfalls • MIG: message implementation guide • Outlook
  49. 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. 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. 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. 52. Agenda 52 • EDI motivation and definition • EDI standards • UN/EDIFACT: syntax and directories • EDI: chances and pitfalls • MIG: message implementation guide • Outlook
  53. 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. 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. 55. Agenda 55 • EDI motivation and definition • EDI standards • UN/EDIFACT: syntax and directories • EDI: chances and pitfalls • MIG: message implementation guide • Outlook
  56. 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
  57. 57. The UNeDOCs initiative 57 Paper Document aligned to UN Layout Key XML or UN/EDIFACT Electronic Edit Form
  58. 58. 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> QuoteRequest Quote PurchaseOrder Order Acceptance Order Rejection Buyer WSDL Seller WSDL XOR SOAP-Message Header Body <orderRejection> .... </orderRejection>
  59. 59. How serious is the problem? 59
  60. 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. 61. 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
  62. 62. 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
  63. 63. 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
  64. 64. 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
  65. 65. 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
  66. 66. 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
  67. 67. Dependency between Core Components and Business Information Entities 68
  68. 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»
  69. 69. 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»
  70. 70. 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
  71. 71. 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]
  72. 72. 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)
  73. 73. 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..*
  74. 74. UPCC - example 75 holds the actual business document but can also define new ABIEs aggregates ABIEs aggregates BDTs aggregates CCs aggregates ENUM aggregates PRIMs
  75. 75. 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)
  76. 76. Core Components – the (rough) big picture 77 UPCC 3.0 CCTS 3.0 UML 2.1 … … <xs:element name="…" … </xs:element> complies with store/ retrieve retrieve maintain submit core component definitions evalute definitions/ standardize definitions use model generate Core Component model UN/CEFACT Core Components Library User Library TBG 17 User
  77. 77. 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>liegl@big.tuwien.ac.at</Email> <Http>http://www.big.tuwien.ac.at</Http> </Contact> <? Presentation status=“questions” ?> </Lecturer>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×