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 Core Components E-Commerce Technologies – WS09 16 th December 2009 Philipp Liegl

2. Agenda 2 Part A: Motivation Part B: Introduction to Core Components Technical Specification (CCTS) Part C: UML Profile for Core Components Part D: From Core Components to deployment artifacts Part E: Core Component Library

3. EDI for everyone? 3 Business Administration Consumer A2A B2C C2C B2B A2C B2A

4. 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 DatabasesERP Systems … Persistence Layer Common Document Logic DatabasesERP Systems … Persistence Layer

5. Status quo 5 Company A Company B Company C Company D Company H Company G Company F Company E

6. Business document standards to the rescue? 66 © SAP AG

7. Necessary mappers 7

8. Reduction on a single format reduces the amount of necessary mappers 8

9. Standards over time 9

10. The situation in Electronic Data Interchange today 10 UNH+ME0000001+ORDERS:D:93A: UN’BGM+220+123321’DTM+137:990 312: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’ … UNT+18+ME0000001’ Fortune 1000 using EDI 95% 5% UN/EDIFACT is in use since 1987 … will not change this situation

11. EDI today cont‘d 11 use EDI 2% 98% able to participate in e-Commerce Small-and-medium sized enterprises EDI is too expensive to implement …lean XML based standard would help IN 2003/00645 2003-02-25 S03-034257 SW/F1/50156 2003-02-03 DEL-03/55-712 2003-02-24 AB123712 Jerry Builder plc …

12. 12 Subset A Top-downBottom-up Generic standard Exten- sion A Core standard Exten- sion B Enter- prise A Enter- prise B Enter- prise A Enter- prise B ABAB intersection union Subset B Subset C Business document definition approaches

13. Requirements for interoperability between enterprises 13 How are documents exchanged between enterprises? Common definition in which order documents are exchanged Global process choreography vs. local process choreography Use of technologies for the unambiguous definition of process choreographies UN/CEFACT‘s Modeling Methodology 2.0 (UMM) Which documents are exchanged between enterprises? Common definition of the artifacts which are exchanged between enterprises Business document standards UML Profile for Core Components 3.0 (UPCC)

14. Agenda 14 Part A: Motivation Part B: Introduction to Core Components Technical Specification (CCTS) Part C: UML Profile for Core Components Part D: From Core Components to deployment artifacts Part E: Core Component Library

15. UN/CEFACT‘s Core Components – Definition of reusable building blocks 15 Semantic building blocks for the definition of business document data Context free – reuse in multiple business sectors Customization of generic core components to specific business sectors and application domains

16. Assemble new artifacts, based on common, standardized components 16 Core ComponentsBusiness document

17. Overview of Core Component related UN/CEFACT specifications 17 Core Component Technical Specification (CCTS) UML Profile for Core Components (UPCC) based on Core Component Library (CCL) conforms to use core component definitions derive XML-Schema Naming and Design Rules (NDR) conforms to define unambiguous derivation rules Core Data Type Catalogue

18. Business Semantics on the two top layers of ebXML 18 Messaging Trading Partner Profile Registry & Repository CC BP Core Components UMM

19. Core Components Technical Specification (CCTS) 19 Official UN/CEFACT version 2.01 Current specification under development: CCTS 3.0 Defines the meta-level concepts of Core Components Written in implementation neutral English prose Visualization of Core Component Concepts using Unified Modeling Language (UML) Editor: Mark Crawford, SAP Labs LLC, (USA)

20. Reuse of document building blocks 20 Core Component Library (CCL) UN/CEFACT Company A Company C Company BCompany X

21. Reduction of complexity through reusable document building blocks 21 Article ID Description Price Color Weight Article Article ID Description Price Color Weight Catalog_Article Article ID Description Price Color Weight Order_Article Article ID Description Price Color Weight Invoice_Article Contextualization by omitting non-used elements

22. Core Components at a glance 22 Semantic building blocks Reference data models Business messages Based on a common semantic basis Core Component Library (CCL) Implementation neutral definition Used to be part of the ebXML standard framework Today dedicated UN/CEFACT project (Core Component Technical Specification)

23. Core Component structure and semantics 23 Core Component Names are referred to as Dictionary Entry Names (DEN) DENs are based on ISO 11179 (formerly known as ISO/IEC 11179 Metadata Registry (MDR) standard) Standardized naming Facilitates storage and retrieval of information Facilitates common understanding of information Object Class Structure of a context category Property Term Characteristic and property Representation Term Value domain ArticleDescriptonText © SAP AG

24. Core components in one slide 24 Identification of objects Identification of object properties Two types of properties Simple properties (text, number, date) Complex properties (other objects) Object type= A ggregate C ore C omponent Simple Property= B asic C ore C omponent Simple Property Data Type= C ore D ata T ype Complex Property= AS ociation C ore C omponent LineItem Article - item ACC - ASCC - BCC - ArticleNumber - BCC - Number-BCC - Description - Price - Color - Weight - BCC - Amount Text Quantity : : : : : : : Text Amount Text Quantity CDT

25. Core Components 25 Foundational concept of the Core Components Technical Specification Used for all aspects of data and information modeling Distinction between three different categories of core components

26. Aggregate Core Component (ACC) 26 Collection of related pieces of information that together convey a distinct meaning Independent of any business context In data modeling terms an ACC is the representation of an entity or class with attributes and associations Aggregate Core Component (ACC) Basic Core Component (BCC) Assocation Core Component (ASCC)

27. Association Core Component (ASCC) 27 Defines a role in an association between on ACC (associating ACC) and another ACC (associated ACC) ASCC consists of an ASCC property plus the object class of the parent ACC ASCC property consists of a property term that expresses the nature of the association and the name of the object class being associated An ASCC property is reusable across object classes. Once it has been given the object class of the parent ACC, it becomes an ASCC that is unique for a given object class

28. Association Core Component (ASCC) – example 28 complex ASCC properties simple BCC properties

29. Basic Core Component (BCC) 29 Represents a property of an ACC A BCC consists of a BCC property plus the object class of the parent ACC A BCC is reusable across object classes Once it has been given the object class of a parent ACC, it becomes a BCC that is unique to the object class to which it is assigned

30. Core Data Types (CDT) 30 A CDT represents the full range of values that can be used for representing an instance of a Basic Core Component Every CDT has a content component and zero or more supplementary components

31. Core data type (CDT) – example 31 Identifier. Type Content Scheme.Identifier SchemeVersion.Identifier SchemeAgency.Identifier String Normalized String Binary BooleanDecimal Double Float Integer TimeDuration TimePointToken Primitive Types Core Data Type Content Component Supplementary Components Identifier SchemeCode list

32. Core Data Types (CDT) UN/CEFACT Data Type Catalogue 3.0 32 Released with every Core Component Technical Specification Defines allowed Core Data Types (CDT) and Primitive Types Binary Boolean Decimal Double Float Integer Normalized String String TimeDuration TimePoint Token Amount Binary Object Code Date Date Time Duration Graphic Identifier Indicator Measure Name Ordinal Percent Picture Quantity Rate Ratio Sound Text Time Value Video 11 Primitive Types22 Core Data Types (CDT)

33. UN/CEFACT Data Type Catalogue – primitive types 33 For each primitive type a set of allowed facets is defined Facets may further restrict a primitive type

34. Allowed Facets according to UN/CEFACT Data Type Catalogue 3.0 34

35. UN/CEFACT Data Type Catalogue – CDT example 35

36. Restriction of a primitive type : code list and identifier schemes 36 Code lists represent a set of pre-defined values, based on a primitive type typically enumerated Example: ISO Country Code Lists Identifier schemes provide production rules for a certain primitive type (in most cases String) typically not enumerated provided e.g. as regular expression Example: Bank account numbers

37. From Core Components to Business Information Entities 37 Core Components act as conceptual models that are used to define business information entities (BIE) Business Information entities are created by the application of context by restricting a generic core component Business Information Entities and Core Components are complementary in many respects A Business Information Entity must always be based on a Core Component Core Component Business Information Entity based on

38. Business Information Entities in one slide 38 Core Components in a specific context Qualifiers help to distinguish BIEs Two different type of properties Simple properties (text, number, date) Complex properties (other objects) Object type=Aggregate Business Information Entity Simple Property=Basic Business Information Entity Simple Property DT=Business Data Type Complex Property= ASociation Business Information Entity LineItem Article - item ABIE - ASBIE - BBIE - Chemical_ArticleNumber - BBIE - Number- BBIE - Description - Price - Amount Text Quantity : : : : : Text Amount BDT

39. Business Information Entities 39

40. Aggregate Business Information Entity (ABIE) 40 An Aggregate Business Information Entity (ABIE) is derived from an ACC and refines the business semantic definition for a specific business context An ABIE may be qualified at the object class level, its properties may be qualified at the property term level

41. From Aggregate Core Components (ACC) to Aggreate Business Information Entities (ABIE) 41 An ABIE can reflect restrictions on the content model of the underlying ACC through Restrictions on the cardinality of the BCCs and ASCCs Use and non-use of individual BCCs and ASCCs Qualification of individual ASCC and BCC properties Restrictions on the content model of an associated ACC for an ASCC Restrictions on the data type of the BCC Restrictions on the concept or conceptual domain of the ASCC property or BCC property as reflected in the definition of the usage rules

42. Restrictions on the cardinality of the BCCs and ASCCs 42

43. Use and non-use of individual BCCs and ASCCs 43 Non-used ASCC Contract. Effective. Period Non-used BCC Contract. Type. Code

44. Qualification of individual ASCC and BCC properties 44 Qualified BCC property Trade_ Contract. Primary_ Identification. Identifier Qualified ASCC property Trade_ Contract. Financial_ Performance. Metrics

45. Restrictions on the content model of an associated ACC for an ASCC 45

46. Restriction on the data type of the BCC 46 New Business Data Type CI_Code, derived from the Core Data Type Code

47. Restrictions on the concept or conceptual domain of the ASCC property or BCC property as reflected in the definition and usage rules 47 A code specifying a type of packaging. The code specifying the type of CI supply chain packaging. A linear dimension or a set of linear dimensions of this packaging. The linear spatial dimensions of this CI supply chain packaging.

48. Qualifier hiearchies 48 ASCC properties and BCC properties may have different qualifiers applied This may result in the ABIE, having a greater number of qualified properties, than its corresponding ACCs unqualified properties Note that this is still considered a restriction, since each BIE property represents a restriction to its corresponding core component property Multiple qualifiers create a qualifier hierarchy, with each additional qualifier reflecting a further restriction of its less qualified BIE property The multi-qualified ABIE Electronic_ Trade_ Contract. Details qualifies the qualified ABIE Trade_ Contract. Details which qualifies the ACC Contract. Details

49. Association Business Information Entity (ASBIE) 49 An ASBIE has the structure of, and represents another ABIE An ASBIE is based on an ASCC, but exists in a business context An ASBIE consists of an ASBIE property plus the object class of the parent ABIE An ASBIE property is reusable across object classes, but once it has been given the object class of the parent ABIE, it becomes an ASBIE that is unique for the given ABIE it is assigned to

50. Association Business Information Entity (ASBIE) – example 50 simple BBIE properties complex ASBIE property

51. Basic Business Information Entity (BBIE) 51 A Basic Business Information Entity is a Basic Core Component (BCC), used in a specific business context Multiple BBIEs can be derived from a single BCC A BBIE consists of an BBIE property plus the object class of the parent ABIE A BBIE property is reusable across object classes, but once it has been given the object class of the parent ABIE, it becomes a BBIE that is unique for the given ABIE it is assigned to

52. Business Data Types (BDT) 52 A Business Data Type is used to set the value domain of a Basic Business Information Entity For every approved CDT, a corresponding unrestricted BDT will be created This BDT will have no restrictions of the set of values of its source CDT’s content and supplementary components Additional BDTs may be created that restrict the set of values of its source CDT’s content and supplementary components The restrictions represent a qualification of the BDT similar to the qualification of BIEs

53. Business Data Types cont‘d 53

54. From Core Data Types to Business Data Types Identifier Content Scheme.Identifier SchemeVersion.Identifier SchemeAgency.Identifier Chemical_Identifier Content Scheme.Identifier SchemeAgency.Identifier Core Data Type Business Data Type String Normalized String Binary BooleanDecimal Double Float Integer TimeDuration TimePointToken Primitive Types based on Core Identifier Scheme Core Code list Business Identifier Scheme Business Code list based on

55. Core Components and Business Information Entities ACC ASCCASBIE ABIE Associated ABIE Associated ACC BCCBBIE Core Data Type Business Data Type may specify restrictions on may specify restrictions on may specify restrictions on aggregated in aggregated in define values of define values of points to points to

56. Dependency between core components and business information entities 56 Number: Text Amount : Quantity Article ArticleNumber: Text Description : Text Price : Amount Color : Text Weight : Quantity Eintrag Chemical_ LineItem Number : Text Amount : Quantity Chemical_ Article Chemical_ ArticleNumber : Text Description : Chemical_ Text Price : Amount Chemie_Eintrag LineItem Core Data Type (CDT)Business Data Type (BDT) Core Components Business Information Entities based on BIEs are derived from Core Components by restriction only!

57. Shortcomings of core components 57 No formal representation mechanism available for core components No direct integration in modeling tools available Core components are defined in an implementation neutral manner Core Component Technical Specification - CCTS 3.0 (implementation neutral) UML Profil für Core Components Domain Specific Language für Core Components Web Ontology Language für Core Components

58. Agenda 58 Part A: Motivation Part B: Introduction to Core Components Technical Specification (CCTS) Part C: UML Profile for Core Components Part D: From Core Components to deployment artifacts Part E: Core Component Library

59. Requirements vs. Technology 59 Business Requirements Technology Implementation InteractionsInteractions DataData

60. XML Schema BPEL/BPSS Windows Workflow … UN/CEFACT's Modeling Methodology (UMM) UML Profile for Core Components (UPCC) Functional Service View related standards Business Operational View related standards The Open-edi Reference Model – ISO 14662 Business Transactions Business aspects of business transactions Information technology aspects of business transactions viewed as comply with covered by comply with transformed to Business Operational View Functional Service View

61. Overview of Core Component related UN/CEFACT specifications 61 Core Component Technical Specification (CCTS) UML Profile for Core Components (UPCC) based on Core Component Library (CCL) conforms to use core component definitions derive XML-Schema Naming and Design Rules (NDR) conforms to define unambiguous derivation rules Core Data Type Catalogue

62. Business documents in UN/CEFACT's Modeling Methodology 62

63. UPCC 3.0 Meta Model sickness 63 Health warning If you want to learn modeling, it is not a good idea to start with the meta model If you are an experienced modeler the meta model serves as reference A tool builder must implement the meta model to provide the modeling environment for the modeler

64. A UML Profile for Core Components (UPCC) 64 Major shortcoming of Core Components missing formalized representation model no direct integration into modeling tools possible UPCC goals Define UML Profile for CCTS to allow for an unambiguous representation of Core Components in UML Support validation of structure and semantics of CCTS compliant information models Provide an unambiguous basis for the derivation of XML Schema artifacts Make CCTS information modeling available to a broad user community Help to improve model interchange between UML tools of different vendors Version Version 1.0 (official UN/CEFACT standard) – compliant to CCTS 2.01 Version 3.0 (under development) – compliant to CCTS 3.0 Editor: Philipp Liegl, Vienna University of Technology (Austria)

65. The UML Profile approach 65

66. Dependency between UN/CEFACT‘s Modeling Methodology (UMM) and the UML Profile for Core Components (UPCC) 66

67. The idea of a UML Profile 67 Provide a generic extension mechanism for customizing the UML meta model to a particular application domain UML Profile comprises three distinctive parts Stereotypes Tagged Values Constraints

68. UML Meta Model? 68 UML Infrastructure – Definition of the elements that can be used to define the different UML model types UML Superstructure – Definition of the different UML model types Model of a specific System Instance of the specific model M3 M2 M1 M0 UPCC Profile UPCC Model

69. The idea of a UML Profile cont'd - stereotypes 69 Stereotypes are defined by extending a metaclass from the UML meta model UPCC meta model example ABIE stereotype used in a concrete UPCC instance indicates a stereotype

70. The idea of a UML Profile cont'd – tagged values 70 Tagged values are defined as part of a stereotype Define a stereotype in more detail Tagged Value: always a Key-Value pair Example: A basic core component has a dictionary entry name, a definition etc. tagged values

71. The idea of a UML Profile cont'd – constraints 71 Provide additional restrictions on the usage of certain stereotypes and their interdependencies In the UPCC specification constraints are specified in two representative forms Free form text Object Constraint Language Specification (OCL) Example: An ABIE shall contain only BBIEs and ASBIEs. An ABIE shall contain at least one BBIE or ASBIE. OCL: context Class inv: self.ABIE() ….

72. Definition of each section in the UPCC 3.0 specification 72 1.Abbreviations of stereotypes 2.Conceptual Description (informative) 3.Stereotypes and Tag Definitions (normative) 4.Constraints (normative) 5.Example

73. UPCC in Enterprise Architect 73 Standalone data modelIntegration in a UMM 2 model

74. Integration of UPCC in UN/CEFACT's Modeling Methodology (UMM) 74 Foundation BusinessRequirementsView BusinessDomainView BusinessRealizationView BusinessPartnerView BusinessEntityView BusinessChoreographyView BusinessTransactionView BusinessCollaborationView BusinessInformationView

75. Integration of UMM and UPCC cont‘d 75 UMM UPCC

76. UPCC – the big picture 76

77. UPCC package overview 77 For each artifact type a dedicated library is assigned BDTLibraryBusiness Data Type Library BIELibrary Business Information Entity Library CCLibraryCore Component Library CDTLibraryCore Data Type Library DOCLibraryBusiness Document Library ENUMLibraryEnumeration Library PRIMLibraryPrimitive Type Library

78. PRIMLibrary - Primitive Type Library 78

79. PRIMLibrary - Primitive Type Library A primitive type library is used to aggregate primitive types (PRIM) Primitives are used to set the value domains of content components (CON) and supplementary components (SUP) of Core Data Types (CDT) and Business Data Types (BDT) A primitive type has two specializations: Enumeration type (ENUM) – represents a code list Identifier scheme type (IDSCHEME) – represents an identifier scheme

80. PRIMLibrary – Primitive Type Library (conceptual) 80

81. PRIM Library – according to CCTS DT Catalogue 3.0 81

82. Restricting Primitive Types 82 Primitive Types may be restricted using the concept of facets Allowed facets per primitive type are specified in the CDT DT Catalogue 3.0 e.g String: allowed facets: Enumeration Length Minimum Length Maximum Length Pattern In UPCC facets per primitive type are specified using constraints

83. Restriction of a Primitive Type – example 83

84. ENUMLibrary – Enumeration Type Library 84

85. ENUMLibrary - Enumeration type library 85 An enumeration library is used to aggregate Identifier schemes (IDSCHEME) Code lists (ENUM)

86. Enumeration Type Example 86 Enumeration types (ENUM) are used to depict code lists

87. Enumeration values (CodeListEntry) 87 An enumeration consists of an enumerated set of values (CodeListEntry) CodeListEntry carries additional meta-information about the code list entry

88. Combining code lists to a new code list 88

89. Identifier scheme example 89 Identifier schemes (IDSCHEME) are used to depict non-enumerated identifier scheme values

90. Reusing existing identifier schemes or code lists 90 Solution A: Import identifier scheme or code list directly into the UML tool Prerequisite: Scheme or lists must be provided in pertinent XMI format Solution B: Point to an existing identifier scheme or code lists using a URI

91. CDTLibrary – Core Data Type Library 91

92. CDTLibrary - Core Data Type Library (conceptual) 92

93. Core Data Types revisited 93 Core Data Types are used to set the value domain of CCTS 3.0 Basic Core Components Properties Core Data Types are the basis for all CCTS 3.0 conformant Business Data Types (BDT) UN/CEFACT releases a set of allowed Core Data Types in the UN/CEFACT Data Type Catalogue All CDT definitions must comply to the Data Type Catalogue No new CDTs may be created, otherwise compatibility to the UN/CEFACT Core Component Library is lost!

94. CDT Library – example according to CCTS DT Catalogue 3.0 94 Additionally allowed primitives: Decimal Double Float Integer

95. Setting the value domain of content components and supplementary components - example 95

96. Setting the value domain of content components and supplementary components - example 96

97. CCLibrary – Core Component Library 97

98. CCLibrary – Core Component Library (conceptual) 98

99. CCLibrary – basics 99 A Core Component Library is a UML representation of the UN/CEFACT Core Component Library A business document modeler must not create new Core Components, but reuses existing Core Components from the UN/CEFACT Library If user-specific Core Components are created, compatibility to the UN/CEFACT Library is lost Might be considered in case only partner specific compatibility is required Usual workflow: Use Core Component from the CCLibrary and create new Business Information Entities

100. CCLibrary - example

101. BDTLibrary – Business Data Type Library 101

102. BDTLibrary – Business Data Type Library (conceptual) 102

103. Business Data Types 103 Business Data Types (BDT) are derived from Core Data Types (CDT) by restriction Content Components (CON) hold the actual information (e.g. 12R17) Supplementary components provide additional meta information for the content component

104. Setting the value domain of content components and supplementary components of Business Data Types (BDT) 104 Must be a subset of Agency Identifier Codes Identifier Codes, relevant for the waste domain The same applies to identifier schemes!

105. BIELibrary – Business Information Entity Library 105

106. BIELibrary – Business Information Entity Library (conceptual) 106

107. BIELibrary – basics 107 A business document modeler takes a Core Component from the Core Component Library and tailors it to the specific needs of a specific domain The Core Component becomes a Business Information Entity For each Core Data Type used to set the value domain of Basic Core Components, a Business Data Type must be created Business Information Entities are used to assemble business documents A BIELibrary may be thought of, as a certain repository of reusable business document building blocks Since each Business Information Entity is based on a Core Component, a common understanding of the document semantics is guaranteed

108. Business Information Entity Library – example 108 based on

109. DOCLibrary – Business Document Library Library 109

110. DOCLibrary - Business Document Library – challenges 110 CCTS mandates a strict corset Every Business Information Entity concept must be based on the respective Core Component concept e.g. ASBIE must be based on ASCC There must not be a BIE without and underlying CC These restrictions are necessary to enforce adherence of business document modelers to a common semantic business document base Business documents are assembled using Business Information Entities Concepts are necessary to allow an aggregation of different Business Information Entities UPCC introduces two new concepts Message Assembly (MA Association Message Assembly (ASMA)

111. DOCLibrary concepts 111

112. Business Document Library - example 112

113. Combining UN/CEFACT’s Modeling Methodology (UMM) and the UML Profile for Core Components (UPCC) 113 Business Documents are aggregated in dedicated business document libraries (DOCLibrary) Connect the business document artifacts to action pins of UMM business transactions Defined in a DOCLibrary

114. Combining UMM & UPCC 114

115. Combining UMM & UPCC cont‘d 115

116. From conceptual models to deployment artifacts 116 VIENNA AddIn […] Naming and Design Rules

117. 117 Visualizing Inter ENterprise Network Architectures http://vienna-add-in.googlecode.com under construction

118. 118

119. Agenda 119 Part A: Motivation Part B: Introduction to Core Components Technical Specification (CCTS) Part C: UML Profile for Core Components Part D: From Core Components to deployment artifacts Part E: Core Component Library

120. Different Structure and Semantic are currently the biggest issues of XML standards Different names & meanings Different positions Different information representation Different information elements OAGxCBL

121. Overview of Core Component related UN/CEFACT specifications 121 Core Component Technical Specification (CCTS) UML Profile for Core Components (UPCC) based on Core Component Library (CCL) conforms to use core component definitions derive XML-Schema Naming and Design Rules (NDR) conforms to define unambiguous derivation rules Core Data Type Catalogue

122. Motivation: Business documents in a service oriented world 122

123. 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 Business Transactions Business aspects of business transactions Information technology aspects of business transactions viewed as comply with covered by comply with transformed to Business Operational View Functional Service View Naming and Design Rules

124. Transformation concepts of UN/CEFACT's Naming and Design Rules 124 Business Information Entity ConceptXML Schema Construct Aggregate Business Information Entity (ABIE) Association Business Information Entity (ASBIE) Basic Business Information Entity (BBIE) Business Data Type (BDT) xsd:simpleType xsd:complexType xsd:element Local Declaration xsd:complexType xsd:element Global Declaration xsd:element Local Declaration OR

125. Resulting XML files 125 Root XML Schema File BDT XML Schema File BIE XML Schema File includes Aggregate Business Information Entity (ABIE) Association Business Information Entity (ASBIE)Business Data Type (BDT) Business Document Definitions Basic Business Information Entity (BBIE)

126. Example for a business document schema 126

127. Example for a business information entity schema 127

128. Agenda 128 Part A: Motivation Part B: Introduction to Core Components Technical Specification (CCTS) Part C: UML Profile for Core Components Part D: From Core Components to deployment artifacts Part E: Core Component Library

129. Overview of Core Component related UN/CEFACT specifications 129 Core Component Technical Specification (CCTS) UML Profile for Core Components (UPCC) based on Core Component Library (CCL) conforms to use core component definitions derive XML-Schema Naming and Design Rules (NDR) conforms to define unambiguous derivation rules Core Data Type Catalogue

130. UN/CEFACT‘s Core Component Library (CCL) at a glance 130 Standardized set of Core Components and Business Information Entities New versions of the CCL are usually released twice a year Most recent version: CCL 09A provided in two parts: UN/CEFACT Message components Library Includes parts of the CCL as audited by the Information Content Management Group (ICG), which support the development of UN/CEFACT Messages by the Applied Technology Group (ATG). UN/CEFACT Reference Components Library All parts of the CCL, including the UN/CEFACT Message Components Library, as harmonized by the International Trade and Business Processes Group (TBG).

131. Working with core components UPCC 3.0 CCTS 3.0 UML 2.1 … … <xs:element name="…" … conformant with store/ retrieve maintain new Core Components Evaluation Harmonization Standardization use model generate Core Component Model UN/CEFACT Core Components Library User Library UN/CEFACT User

132. Cut-out from the latest Core Component Library (CCL09A) 132

133. Shortcomings of the Core Component Library 133 Core Component Library is based on a Microsoft Excel-Sheet Integration into Core Component Modeling tools is difficult No efficient storage and retrieval or Core Component artifacts possible No Core Component versioning To overcome these limitations the Information Content Group (ICG) currently develops the UN/CEFACT Registry Specification However, no core component registry implementation exists as of today

134. Motivation for a Core Component Registry 134 Core Component Registry A B Conceptual UML Business Document transform Business Partner A define Business Partner B Business Partner C store/ retrieve Service Interface Definition C BA Core Components use 1 3 4 5 6 UN/CEFACT Core Component Library defined in 2

135. Federated Registry Approach UN/CEFACTCIDXAutomotiveSWIFT Swiss Bank Assocation Austrian Bank Assocation ODETTEAIAGShellBP

136. Resources 136 Core Components Technical Specification 3.0 http://www.unece.org/cefact/ebxml/CCTS-Version3.pdf Core Component Data Type Catalogue 3.0 http://www.unece.org/cefact/codesfortrade/CCTS-CatalogueVersion3.pdf UML Profile for Core Components 3.0 http://75.43.29.149:8080/download/attachments/2162938/Specification_UPCC3_odp5_draft_20 091016-preview.docx UN/CEFACT's Naming and Design Rules 3.0 http://tinyurl.com/myspr6 Core Component Library CCL 09 A http://www.unece.org/cefact/codesfortrade/unccl/CCL09A.xls Relevant chapters from the dissertation "Business Documents for Inter-Organizational Business Processes" http://umm-dev.org/wp-content/uploads/2009/12/Relevant_Chapters_For_CC.pdf Relevant for the excercises!!!

137. Questions? 137 Philipp Liegl Vienna University of Technology Favoritenstraße 9-11/188 1040 Vienna Austria liegl@big.tuwien.ac.at http://www.umm-dev.org