Core Components
E-Commerce Technologies – WS09
16th December 2009
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
• 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
2
EDI for everyone?
A2A
Administration
A2C
B2A
C2C
B2B
Business
Consumer
B2C
3
B2B Application Computing
B2B Application Server
SOAP request over
Messaging Layer
HTTP, SMTP, ...
Common Document Logic
Document Layer
Business Layer
Databases
ERP Systems
Persistence Layer
B2B Application Server
Common Process Logic
…
Messaging Layer
Document Layer
Business Layer
Databases
ERP Systems
Persistence Layer
…
Status quo
Company A
Company B
Company C
Company D
Company E
Company F
Company G
Company H
5
Business document standards to the rescue?
6
© SAP AG
Necessary mappers
Necessary mappers
600000
500000
400000
Mappers 300000
200000
100000
0
5
10
20
50
100
200
500
1000
Enterprises
Necessary mappers
7
Reduction on a single format reduces the amount of
necessary mappers
A
A
B
E
D
C
E
B
Standard
Format
D
C
8
Standards over time
RIXML
XHTML
CPExchange
IMS
ODETTE EDI
EDITEX
HITIS
TWIST
OTA
FIXML
PIDX
papiNet
CIP4 JDF
XRML
FpML
FinXML
SPEC2000
OAGIS
CEFIC EDI
CIDX
OFX XML
HL7
EANCOM
cXML
eBIS-XML
EIDX
HTML
OGC
SWIFT ML
ACORD
EDIFACT
SIF
EDIPAP
GS1 XML
xCBL PRISM
UNIFI
PIDX EDI
RINET
EDIFER
ebXML
SGML
ebInterface
RosettaNet PIP
VICS EDI
GCA EDI
NACS
UBL
AIAG EDI
EDIBUILD
ARTS
MDDL
ESIDEL
EDIFICE
XML
ASC X12
CIAG EDI
HR-XML
IRML
CIDX EDI
MODA-ML
Energistics
StepML
DocBook
IFX
GML
1970
MISMO
GCI
VRXML
1980
Delimiter based
1990
2000
2010
Markup-Language based
9
The situation in Electronic Data Interchange today
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 911/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’
UN/EDIFACT is in use
since 1987
Fortune 1000
using EDI
95%
5%
… will not change
this situation
10
EDI today cont‘d
Small-and-medium sized
enterprises
98% able to participate in e-Commerce
use EDI
2%
EDI is too expensive to
implement
<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:Invoice"
xmlns:xsi="http://XMLSchema-instance"
xsi:schemaLocation="urn:Invoice.xsd">
<ID>IN 2003/00645</ID>
<IssueDate>2003-02-25</IssueDate>
<TaxPointDate>2003-02-25</TaxPointDate>
<ReferencedOrder>
<BuyersOrderID>S03-034257</BuyersOrderID>
<SellersOrderID>SW/F1/50156</SellersOrderID>
<IssueDate>2003-02-03</IssueDate>
</ReferencedOrder>
<ReferencedDespatchAdvice>
<ID>DEL-03/55-712</ID>
<IssueDate>2003-02-24</IssueDate>
</ReferencedDespatchAdvice>
<BuyerParty>
<ID/>AB123712</ID>
<PartyName>
<Name>Jerry Builder plc</Name>
</PartyName>
…
…lean XML based standard
would help
11
Business document
definition
approaches
Top-down
Bottom-up
A
A
B
union
Enterprise A
Enterprise B
Generic
standard
B
intersection
Enterprise A
Extension A
Enterprise B
Extension B
Core standard
Subset A
Subset
B
Subset
C
12
Requirements for interoperability between enterprises
• 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)
13
Agenda
• 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
14
UN/CEFACT‘s Core Components – Definition of reusable
building blocks
• 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
15
Assemble new artifacts, based on common, standardized
components
Core Components
Business document
16
Overview of Core Component related
UN/CEFACT specifications
Core Component Technical
Specification (CCTS)
Core Data Type Catalogue
UML Profile for Core
Components (UPCC)
based on
conforms
to
derive
use core component
definitions
Core Component
Library (CCL)
XML-Schema
conforms
to
Naming and Design Rules (NDR)
define unambiguous derivation rules
17
Business Semantics on the two top layers of ebXML
CC
BP
Trading Partner
Profile
Messaging
Registry & Repository
18
Core Components Technical Specification (CCTS)
• 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)
19
Reuse of document building blocks
UN/CEFACT
Core Component
Library (CCL)
Company A
Company C
Company B
Company X
20
Reduction of complexity through reusable document building
blocks
Article
Article ID
Description
Price
Color
Weight
Catalog_Article
Article ID
Description
Price
Color
Weight
Order_Article
Article ID
Description
Price
Color
Weight
Contextualization by omitting non-used elements
Invoice_Article
Article ID
Description
Price
Color
Weight
21
Core Components at a glance
• 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)
22
Core Component structure and semantics
• 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
© SAP AG
Object Class
Property Term
Representation Term
Structure of a context
category
Characteristic and
property
Value domain
Article
Descripton
Text
23
LineItem
ACC
CDT
--BCC
Number :Text
Core components in one slide
- BCC
Amount : CDT
Quantity
• Identification of objects
• Identification of object properties
- ASCC
item
Article
ACC
• Two types of properties
• Simple properties (text, number, date)
• Complex properties (other objects)
- ArticleNumber
BCC
: CDT
Text
Text
: CDT
BCC
- Description
Amount
BCC : CDT
- Price
CDT
Color : Text
- BCC
Quantity
- BCC
Weight: CDT
• Object type
=
Aggregate Core Component
• Simple Property
=
Basic Core Component
• Simple Property Data Type
=
Core Data Type
• Complex Property
=
ASociation Core Component
24
Core Components
• 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
Aggregate Core
Component (ACC)
Basic Core
Component (BCC)
Simple
characteristic
Complex
characteristic
Assocation Core
Component (ASCC)
Core Data Type (CDT)
CDT Content
Component
CDT Supplementary
Component
25
Aggregate Core Component (ACC)
• 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
ACC: Contract. Details
BCC: Contract. Identification. Identifier
BCC: Contract. Type. Code
BCC: Contract. Issue. DateTime
BCC: Contract. Price. Amount
ASCC: Contract. Effective. Period
ASCC: Contract. Performance. Metrics
Aggregate Core Component (ACC)
Basic Core Component (BCC)
Assocation Core Component (ASCC)
26
Association Core Component (ASCC)
• 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
ASCC
ConsignmentItem. Delivery. Party
Associating Object Class Term
ConsignmentItem
Property Term
Delivery
ASCC Property
Delivery. Party
Associated Object Class Term
Party
27
Association Core Component (ASCC) – example
simple BCC properties
Associated Core Component
Associating Core Component
ACC: Contract.Details
ACC: Period.Details
BCC: Identification. Identifier
BCC: Type. Code
BCC: Issue. DateTime
BCC: Price. Amount
ASCC: Effective. Period
ASCC: Performance. Metrics
Effective
Effective
BCC: Duration. Measure
BCC: Start. DateTime
complex ASCC properties
28
Basic Core Component (BCC)
•
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
ACC
ConsignmentItem. Details
BCC
ConsignmentItem. Identification. Identifier
ACC Object Class Term
ConsignmentItem
BCC
ConsignmentItem. NetWeight. Measure
BCC Property
Identification. Identifier
Property Term
Identification
Representation Term
Identifier
Core Data Type
Identifier. Type
29
Core Data Types (CDT)
• 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
CDT
Identifier. Type
Supplementary Component
Identifier. Scheme. Identifier
Content Component
Identifier. Content
Data Type Term
Identifier
Property Term
Content
String
…
Data Type Term
Identifier
Property Term
Scheme
String
Representation Term
Identifier
Normalized
String
…
30
Core data type (CDT) – example
Identifier. Type
Core Data Type
Content
Content Component
Scheme.Identifier
SchemeVersion.Identifier
SchemeAgency.Identifier
Supplementary Components
String
Binary
Integer
Normalized String
Double
Boolean
Token
Decimal
Float
TimePoint
TimeDuration
Primitive Types
Identifier Scheme
Code list
31
Core Data Types (CDT)
UN/CEFACT Data Type Catalogue 3.0
• 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
11 Primitive Types
Amount
Binary Object
Code
Date
Date Time
Duration
Graphic
Identifier
Indicator
Measure
Name
Ordinal
Percent
Picture
Quantity
Rate
Ratio
Sound
Text
Time
Value
Video
22 Core Data Types (CDT)
32
UN/CEFACT Data Type Catalogue – primitive types
• For each primitive type a set of allowed facets is defined
• Facets may further restrict a primitive type
Primitive Type
Name
Description
Binary
Binary
Binary is a finite sequence of binary digits
(bits)
Boolean
Boolean
Boolean denotes a logical condition through
a predefined enumeration of the literals true
(The Boolean condition is satisfied) and false
(The Boolean condition is not satisfied).
Decimal
Decimal
Double
Double
Allowed Facets
Remarks
Enumeration
Length
Minimum Length
Maximum Length
Pattern
None
Allowed literals = [true/false]
Decimal is a subset of the real numbers,
which can be represented by decimal
numerals
Enumeration
Fractional Digits
Minimum Inclusive
Maximum Inclusive
Minimum Exclusive
Maximum Exclusive
Pattern
Total Digits
Look for non-XSD reference for
expanding the definition.
Double is the IEEE double precision 64 bits
floating point type
Enumeration
Fractional Digits
Minimum Inclusive
Maximum Inclusive
Minimum Exclusive
Maximum Exclusive
Pattern
Total Digits
33
Allowed Facets according to
UN/CEFACT Data Type Catalogue 3.0
Facet Type
Facet Name
Enumeration
Enumeration
FractionalDigits
Fractional Digits
Length
Length
MaximumExclusive
Maximum Exclusive
Description
Value
Defines a specified set of values
A set of values from the value
domain of the data type.
Defines the maximum number of fractional digits to be used.
Non Negative Integer
Defines the number of units of length of the data type.
Non Negative Integer
Defines the upper limit of the range of allowed values. The upper
limit is no allowed value.
Value from the value domain
of the data type
[Note]
This format restriction shall not be used in combination with the
Maximum Inclusive format restriction.
MaximumInclusive
Maximum Inclusive
MaximumLength
Maximum Length
Defines the upper limit of the range of allowed values. The upper
limit is also an allowed value.
Value from the value domain
of the data type
Defines the maximum number of units of length.
Non Negative Integer
[Note]
This format restriction shall not be used in combination with the
Length format restriction
MinimumLength
Minimum Length
Defines the minimum number of units of length.
Non Negative Integer
[Note]
This format restriction shall not be used in combination with the
Length format restriction.
MinimumExclusive
Minimum Exclusive
Defines the lower limit of the range of allowed values. The lower
limit is no allowed value.
Value from the value domain
of the data type
[Note]
This format restriction shall not be used in combination with the
Minimum Inclusive format restriction.
MinimumInclusive
Minimum Inclusive
Pattern
Pattern
TotalDigits
Total Digits
Defines the lower limit of the range of allowed values. The lower
limit is also an allowed value.
Value from the value domain
of the data type
Defines a constraint on the lexical space of a datatype to literals in
a specific pattern.
Regular Expression
Defines a maximum number of digits to be used.
Positive Integer
34
UN/CEFACT Data Type Catalogue – CDT example
1.1.1 Usage Guidance
Identifier. Type is used to represent objects to enable a common identification of objects. The common identification should be based on
the common identification scheme concept used to create the individual identifiers. Typical examples are "Product_ Identifier. Type",
"Order_ Identifier. Type". The "Identifier. Type" should be used in case of an infinite set of objects, and Code. Type should be used in case
of a finite case of allowed values.
1.1.2 Identifier. Type Content Component
Dictionary Entry Name
Data Type Term Property Term
Identifier. Content
Identifier
Content
Allowed Primitives
Cardinality
Definition
Usage Rules Unique Identifier
Normalized String
String
Token
1..1
A character string used to uniquely identify one instance of
an object within an identification scheme that is managed
by an agency.
UNDTRTB546
1.1.3 Identifier. Type Supplementary Components
Dictionary Entry Name
Data Type Term
Property
Term
Representation
Term
Allowed
Primitives
Cardinality
Definition
Usage Rules
Unique Identifier
Comments
Identifier. Scheme. Identifier
Identifier
Scheme
Identifier
Normalized
String
String
Token
0..1
The identification of
the identifier scheme.
UNDT230W43
UNDTRTB546
It is required to have common concepts for the
definition of identifier scheme patterns.
The primitive is specified by the Identification Scheme.
Identifier. Scheme Version. Identifier
Identifier
Scheme
Version
Identifier
Normalized
String
String
Token
0..1
The identification of
the version of the
identifier scheme
UNDT230W43
UNDTRTB546
The primitive is specified by the Identification Scheme.
Identifier. Scheme Agency. Identifier
Identifier
Scheme
Agency
Identifier
Normalized
String
String
Token
0..1
The identification of
the agency that
manages the identifier
scheme
UNDT230W43
UNDTRTB546
The primitive is specified by the Identification Scheme.
35
Restriction of a primitive type : code list and identifier
schemes
• 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
36
From Core Components to Business Information Entities
• 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
based on
Business
Information Entity
37
ABIE
LineItem
Business Information Entities in one slide
• Core Components in a specific context
• Qualifiers help to distinguish BIEs
BDT
- BBIE
Number :Text
- BBIE
Amount : Quantity
BDT
ASBIE
- item
Article
ABIE
• Two different type of properties
• Simple properties (text, number, date)
• Complex properties (other objects)
BDT
- BBIE
Chemical_ArticleNumber : Text
- BBIE
Description: BDT
Text
- BBIE
Price : Amount
BDT
• Object type
=
Aggregate Business Information Entity
• Simple Property
=
Basic Business Information Entity
• Simple Property DT
=
Business Data Type
• Complex Property
=
ASociation Business Information Entity
38
Business Information Entities
Aggregate Business Information
Entity (ABIE)
Basic Business Information
Entity (BBIE)
Simple
characteristic
Complex
characteristic
Assocation Business
Information Entity (ASBIE)
Business Data Type
(BDT)
BDT Content
Component
BDT Supplementary
Component
39
Aggregate Business Information Entity (ABIE)
• 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
ACC: Contract. Details
BCC: Contract. Identification. Identifier
BCC: Contract. Type. Code
BCC: Contract. Issue. DateTime
BCC: Contract. Price. Amount
ASCC: Contract. Effective. Period
ASCC: Contract. Performance. Metrics
ABIE: Trade_ Contract. Details
Business
Context
BBIE: Trade_ Contract. Identification. Identifier
BBIE: Trade_ Contract. Business_ Type. Code
BBIE: Trade_ Contract. Issue. DateTime
BBIE: Trade_ Contract. Total_ Price. Amount
ASBIE: Trade_ Contract. Actual_ Performance. Metrics
40
From Aggregate Core Components (ACC) to
Aggreate Business Information Entities (ABIE)
• 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
41
Restrictions on the cardinality of the BCCs and ASCCs
ABIE: Trade_ Contract. Details
ACC: Contract. Details
BCC: Contract. Identification. Identifier [1..1]
BCC: Contract. Issue. DateTime [0..1]
ASCC: Contract. Performance. Metrics [0..*]
BBIE: Trade_ Contract. Primary_ Identification. Identifier [1..1]
BBIE: Trade_ Contract. Secondary_ Identification. Identifier [1..1]
BBIE: Trade_ Contract. First_ Issue. DateTime [0..1]
BBIE: Trade_ Contract. Definitive_ Issue. DateTime [1..1]
ASBIE: Trade_ Contract. Financial_ Performance. Metrics [0..*]
ASBIE: Trade_ Contract. Certified_ Performance. Metrics [1..1]
ASBIE: Trade_ Contract. BestCase_ Performance. Metrics [0..2]
42
Use and non-use of individual BCCs and ASCCs
ACC: Contract. Details
ABIE: Trade_ Contract. Details
BCC: Contract. Identification. Identifier
BCC: Contract. Type. Code
BCC: Contract. Issue. DateTime
BCC: Contract. Price. Amount
ASCC: Contract. Effective. Period
ASCC: Contract. Performance. Metrics
BBIE: Trade_ Contract. Identification. Identifier
BBIE: Trade_ Contract. Issue. DateTime
BBIE: Trade_ Contract. Price. Amount
ASBIE: Trade_ Contract. Performance. Metrics
• Non-used ASCC
• Contract. Effective. Period
• Non-used BCC
• Contract. Type. Code
43
Qualification of individual ASCC and BCC properties
ACC: Contract. Details
ABIE: Trade_ Contract. Details
BCC: Contract. Identification. Identifier
BCC: Contract. Type. Code
BCC: Contract. Issue. DateTime
BCC: Contract. Price. Amount
ASCC: Contract. Effective. Period
ASCC: Contract. Performance. Metrics
BBIE: Trade_ Contract. Primary_ Identification. Identifier
BBIE: Trade_ Contract. Issue. DateTime
BBIE: Trade_ Contract. Price. Amount
ASBIE: Trade_ Contract. Financial_ Performance. Metrics
• Qualified BCC property
• Trade_ Contract. Primary_ Identification. Identifier
• Qualified ASCC property
• Trade_ Contract. Financial_ Performance. Metrics
44
Restrictions on the content model of an
associated ACC for an ASCC
Associated Core Component
Associating Core Component
ACC: Contract. Details
BCC: Identification. Identifier
BCC: Type. Code
BCC: Issue. DateTime
BCC: Price. Amount
ASCC: Effective. Period
ASCC: Performance. Metrics
ACC: Period. Details
Effective
Effective
BCC: Duration. Measure
BCC: Start. DateTime
ABIE: Trade_ Contract. Details
BBIE: Identification. Identifier
BBIE: Type. Code
BBIE: Issue. DateTime
BBIE: Price. Amount
ASBIE: BestCase_ Effective. Optimistic_ Period
ABIE: Optimistic_ Period. Details
BestCase_ Effective
Effective
BBIE: Duration. Measure
45
Restriction on the data type of the BCC
ACC: Packing. Details
BCC: Sequence. Numeric
BCC: Level. Code
BCC: Type. Code
BCC: Type. Text
BCC: ...
ABIE: CI_ SupplyChain_ Packaging. Details
BBIE: Type. CI_Code
BBIE: Type. Text
BBIE: ...
• New Business Data Type CI_Code, derived from the Core Data Type
Code
46
Restrictions on the concept or conceptual domain of the ASCC
property or BCC property as reflected in the definition and usage
rules
ACC: Packing. Details
BCC: Sequence. Numeric
BCC: Level. Code
BCC: Type. Code
BCC: Type. Text
BCC: ...
ASCC: Linear. Dimension
ASCC: Contained. Package
ASCC: ...
A code specifying a type
of packaging.
A linear dimension or a set
of linear dimensions of this
packaging.
ABIE: CI_ SupplyChain_ Packaging. Details
BBIE: Type. CI_Code
BBIE: Type. Text
BBIE: ...
ASBIE: Linear. CI_ Spatial_ Dimension
The code specifying the type of CI
supply chain packaging.
The linear spatial
dimensions of this CI
supply chain packaging.
47
Qualifier hiearchies
• 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
48
Association Business Information Entity (ASBIE)
• 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
ASBIE
Waste_ ConsignmentItem. Waste_ Delivery. Waste_ Party
Associating Object Class Term
Waste_ ConsignmentItem
ASBIE Property
Waste_ Delivery. Waste_ Party
Property Term
Waste_ Delivery
Associated Object Class Term
Waste_ Party
49
Association Business Information Entity (ASBIE) – example
simple BBIE properties
ABIE: Trade_ Contract. Details
ABIE: Optimistic_ Period. Details
BBIE: Identification. Identifier
BBIE: Type. Code
BBIE: Issue. DateTime
BBIE: Price. Amount
ASBIE: BestCase_ Effective. Optimistic_ Period
BestCase_ Effective
Effective
BBIE: Duration. Measure
complex ASBIE property
50
Basic Business Information Entity (BBIE)
•
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
ABIE
Waste_ ConsignmentItem. Details
BBIE
Waste_ ConsignmentItem. Waste_ Identification. Waste_ Identifier
ABIE Object Class Term
Waste_ ConsignmentItem
BBIE Property
Waste_ Identification. Waste_ Identifier
Property Term
Waste_ Identification
Representation Term
Waste_ Identifier
Business Data Type
Waste_ Identifier. Type
51
Business Data Types (BDT)
• 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
52
Business Data Types cont‘d
BDT
Waste_ Identifier. Type
Supplementary Component
Identifier. Scheme. Identifier
Content Component
Waste_ Identifier. Content
Data Type Term
Identifier
Property Term
Content
Code List
Waste_Codes
Data Type Term
Identifier
Property Term
Scheme
Representation Term
Identifier
String
53
From Core Data Types to Business Data Types
Business Data Type
Core Data Type
Identifier
Chemical_Identifier
Content
based on Content
Scheme.Identifier
SchemeVersion.Identifier
SchemeAgency.Identifier
String
Binary
Normalized String
Scheme.Identifier
SchemeAgency.Identifier
Integer
Double
Boolean
Token
Decimal
Float
TimePoint
TimeDuration
Primitive Types
Core Code list
Core Identifier Scheme
based on
based on
Business Identifier Scheme
Business Code list
Core Components and Business Information Entities
may specify restrictions on
ACC
aggregated
in
ASCC
may specify restrictions on
points
to
Associated
ACC
may specify
restrictions on
define values
of
Core
Data Type
ASBIE
aggregated
in
points
to
may specify restrictions on
BCC
ABIE
Associated
ABIE
BBIE
define values
of
may specify restrictions on
Business
Data Type
Dependency between core components and business
information entities
Core Components
based on
Business Information Entities
LineItem
Chemical_ LineItem
Number: Text
Amount : Quantity
Number : Text
Amount : Quantity
based on
based on
Eintrag
Chemie_Eintrag
Article
ArticleNumber: Text
Description : Text
Price : Amount
Color : Text
Weight : Quantity
Core Data Type (CDT)
Chemical_ Article
Chemical_ ArticleNumber : Text
Description : Chemical_ Text
Price : Amount
Business Data Type (BDT)
BIEs are derived from Core Components by restriction only!
56
Shortcomings of core components
• No formal representation mechanism available for core components
• No direct integration in modeling tools available
• Core components are defined in an implementation neutral manner
«metaclass»
Class
«metaclass»
Attribute
«metaclass»
Association
«extends»
«extends»
«extends»
ACC
+
+
+
+
+
+
+
businessTerm: String [0..*]
definition: String
dictionaryEntryName: String
languageCode: String [0..1]
uniqueIdentifier: String [0..1]
versionIdentifier: String [0..1]
usageRule: String [0..*]
UML Profil
für Core
«metaclass»
Dependency
Components
BCC
+
+
+
+
+
+
+
+
businessTerm: String [0..*]
definition: String
dictionaryEntryName: String
languageCode: String [0..1]
sequencingKey: String [0..1]
uniqueIdentifier: String [0..1]
versionIdentifier: String [0..1]
usageRule: String [0..*]
Domain Specific
Language für Core
Components
ASCC
+
+
+
+
+
+
+
+
businessTerm: String [0..*]
definition: String
dictionaryEntryName: String
languageCode: String [0..1]
sequencingKey: String [0..1]
uniqueIdentifier: String [0..1]
versionIdentifier: String [0..1]
usageRule: String [0..*]
Web Ontology
Language für Core
Components
Core Component Technical Specification - CCTS 3.0
(implementation neutral)
«extends»
isEquiv alentTo
57
Agenda
• 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
58
Requirements vs. Technology
Business
Requirements
I
n
t
e
r
a
c
t
i
o
n
s
D
a
t
a
Technology
Implementation
59
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
Business
Methodology
Operational
(UMM)
View
related
UMLstandards
Profile
for Core Components
(UPCC)
transformed
to
Functional Service View
Information technology
aspects of business
transactions
comply
with
covered
by
XML Schema
Functional Service
BPEL/BPSS
View
Windows Workflow
related standards
…
Overview of Core Component related
UN/CEFACT specifications
Core Component Technical
Specification (CCTS)
Core Data Type Catalogue
UML Profile for Core
Components (UPCC)
based on
conforms
to
derive
use core component
definitions
Core Component
Library (CCL)
XML-Schema
conforms
to
Naming and Design Rules (NDR)
define unambiguous derivation rules
61
Business documents in UN/CEFACT's Modeling Methodology
«bTPartition»
«bTPartition»
:Buyer
:Seller
Initial
«ReqAction»
Submit Order
:OrderRejectionEnvelope
:OrderAcceptanceEnvelope
:
PurchaseOrder.Propose_Create_Request.Message
[OrderRejection !=
null]
ControlFailure
[OrderAcceptance !=
null]
«bESharedS...
:Order
[accepted]
«ABIE»
PurchaseOrder
:OrderAcceptanceEnvelope
«BBIE»
+ Government_Contract_Identification: Identifier [0..1]
+ Identification: Identifier
+ Processing_Type: Code [0..1]
+ Purchasing_Document_Completeness: Code [0..1]
+ Cancelled: Indicator [0..1]
+ Drop_Shipment: Indicator [0..1]
+ Provider_Request_Sent: Date Time [0..1]
+ Comment: Text [0..1]
«bESharedS...
:Order
[rejected]
«ABIE»
:OrderRejectionEnvelope
Tendering_Location
+Ship From
«ASBIE»
«ResAction»
«ASBIE»
«ASBIE»
«ABIE»
PurchaseOrder_Line_Item
«BBIE»
+ Identification: Identifier [0..1]
BusinessFailure
«BBIE»
+ Identification: Identifier [0..1]
+ Name: Text [0..1]
Process Order
:PurchaseOrder.Propose_Create_Request.Message
+Product 0..*
BusinessSuccess
0..1
+Postal 0..1
«ABIE»
Tendering_Address
«BBIE»
+ Postcode: Code [0..1]
+ Line One: Text
+ Line Two: Text [0..1]
+ Country Name: Text [0..1]
62
UPCC 3.0 Meta Model sickness
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
63
A UML Profile for Core Components (UPCC)
• 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)
64
The UML Profile approach
UML 2.1.2
based on
Core Component Technical Specification 3.0 (CCTS)
complies to
UML Profile for CCTS 3.0 (UPCC 3.0)
complies to
UPCC Business Document Model
complies to
Deployment Artifact (e.g. XML
schema)
complies to
ATG2 Naming and Design Rules 3.0
65
Dependency between UN/CEFACT‘s Modeling Methodology
(UMM) and the UML Profile for Core Components (UPCC)
UMM 2 foundation module
UML Profile for CCTS 3.0 (UPCC 3.0)
UMM 2 base module
66
The idea of a UML Profile
• 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
«metaclass»
Association
«metaclass»
Class
direction: Direction = Source -> Desti...
SourceRole.Aggregation: sourcerole.aggregation = shared
«extends»
«extends»
ABIE
+
+
+
+
+
+
+
ASBIE
uniqueIdentifier: String
versionIdentifier: String
languageCode: String [0..1]
dictionaryEntryName: String
definition: String
businessTerm: String [0..*]
usageRule: String [0..*]
+
+
+
+
+
+
+
+
uniqueIdentifier: String
versionIdentifier: String
sequencingKey: String
languageCode: String [0..1]
dictionaryEntryName: String
definition: String
businessTerm: String [0..*]
usageRule: String [0..*]
«metaclass»
Dependency
«metaclass»
Attribute
«extends»
basedOn
«extends»
isEquiv alentTo
«extends»
BBIE
+
+
+
+
+
+
+
+
sequencingKey: String
uniqueIdentifier: String
versionIdentifier: String
languageCode: String [0..1]
dictionaryEntryName: String
definition: String
businessTerm: String
usageRule: String [0..*]
67
UML Meta Model?
Meta-Meta-Model
M3
UML Infrastructure – Definition of the elements
that can be used to define the different UML
model types
«instanceOf»
UML Meta Model
M2
UPCC Profile
UML Superstructure – Definition of the different
UML model types
«instanceOf»
UML Model
M1
Model of a specific System
UPCC Model
«instanceOf»
M0
UML Model
instance
Instance of the specific model
68
The idea of a UML Profile cont'd - stereotypes
• Stereotypes are defined by extending a metaclass from the UML meta
model
«metaclass»
Classifier
A stereotype
«extends»
• UPCC meta model example
«metaclass»
Class
ABIE
«extends»
• ABIE stereotype used in a concrete UPCC instance
«ABIE»
US_Address
indicates a stereotype
69
The idea of a UML Profile cont'd – tagged values
• 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.
«metaclass»
Attribute
«extends»
BBIE
+
+
+
+
+
+
+
+
sequencingKey: String
uniqueIdentifier: String
versionIdentifier: String
languageCode: String [0..1]
dictionaryEntryName: String
definition: String
businessTerm: String
usageRule: String [0..*]
70
tagged values
The idea of a UML Profile cont'd – constraints
• 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() ….
71
Definition of each section in the UPCC 3.0 specification
1. Abbreviations of stereotypes
Stereotype Abbreviation
bDomainV
bCategory
bArea
ProcessArea
bProcessUC
bProcess
bProcessAction
bESharedState
bEInternalState
Full Stereotype Name
BusinessDomainView
BusinessCategory
BusinessArea
ProcessArea
BusinessProcessUseCase
BusinessProcess
BusinessProcessAction
SharedBusinessEntityState
InternalBusinessEntityState
1
cd BusinessDomainView - Conceptual
BusinessPartner
1..*
2. Conceptual Description (informative)
0..*
0..*
participates
BusinessCategory
BusinessDomainView
0..1
1..*
0..*
0..*
0..*
0..*
BusinessArea
BusinessProcess
ProcessArea
0..1
Stakeholder
0..1
0..1
0..1
0..*
0..*
0..*
0..*
isOfInterestTo
3. Stereotypes and Tag Definitions (normative)
4. Constraints (normative)
Stereotype
BusinessPartner
Base Class
Actor
Parent
Stakeholder
Description
A business partner is an organization type, an organizational unit type or a person type that participates in a
business process. Business partners typically provide input to and/or receive output from a business
process. Due to the fact that a business partner participates in a business process she or he has by default a
vested interest in the business process. It follows that a business partner is a special kind of stakeholder.
Tag Definition
Inherited tagged values:
- interest
37
«ABIE»
Academic_Qualification
5. Example
«BBIE»
+ Type: Code
+ Name: Text
+ AbbreviatedName: Text
«ABIE»
Academic_ExaminationResult
+Academic_Required «BBIE»
+ ECTS_EvaluationPoint: ECTSPoints
1..* + EvaluationPoint: Numeric
+ Reason: ExaminationList
+ Additional_Reason: Text [0..*]
+ Type: Code
«ASBIE»
«basedOn»
«basedOn»
«ACC»
CCLibrary (Core Component Library)::
Qualification
«BCC»
+ Type: Code [0..*]
+ Name: Text [0..*]
+ AbbreviatedName: Text [0..*]
«ACC»
CCLibrary (Core Component
Library)::ExaminationResult
+Required
«ASCC»
«BCC»
0..* + EvaluationPoint: Numeric [0..*]
+ Reason: Text [0..*]
+ Type: Code [0..*]
+ Approval: Indicator [0..*]
+ Condition: Text [0..*]
+ BusinessType: Code [0..*]
+ Status: Code [0..*]
72
UPCC in Enterprise Architect
Standalone data model
Integration in a UMM 2 model
73
Integration of UPCC in
UN/CEFACT's Modeling Methodology (UMM)
Foundation
BusinessRequirementsView
BusinessDomainView
BusinessPartnerView
BusinessEntityView
BusinessChoreographyView
BusinessTransactionView
BusinessCollaborationView
BusinessRealizationView
BusinessInformationView
74
Integration of UMM and UPCC cont‘d
UMM
UPCC
75
UPCC – the big picture
b L i b ra ry
Package
C C L i b ra ry
Package
DataType
C D TL i b ra ry
PR IM
Attribute
Package
Package
PR IML i b ra ry
EN U ML i b ra ry
Attribute
SU P
Enumeration
DataType
E NUM
IDS CHE ME
C ON
EnumerationLiteral
CodeLis t E nt ry
Class
basedOn
Class
CDT
BD T
Package
BD TL i b ra ry
Package
D OC L i b ra ry
Attribute
Attribute
basedOn
BC C
BBIE
Association
basedOn
ASC C
AC C
Association
Assocation
ASMA
+source
+source
+target
+target
basedOn
Class +target
+source
ASBIE
+source
Class
MA
Class +target
ABIE
Package
BIEL i b ra ry
76
UPCC package overview
• For each artifact type a dedicated library is assigned
• BDTLibrary
Business Data Type Library
• BIELibrary
Business Information Entity Library
• CCLibrary
Core Component Library
• CDTLibrary
Core Data Type Library
• DOCLibrary
Business Document Library
• ENUMLibrary
Enumeration Library
• PRIMLibrary
Primitive Type Library
77
PRIMLibrary - Primitive Type Library
78
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
PRIMLibrary – Primitive Type Library (conceptual)
bLibrary
PRIMLibrary
0..*
PRIM
80
PRIM Library – according to CCTS DT Catalogue 3.0
«PRIM»
Binary
«PRIM»
Float
«PRIM»
NormalizedString
«PRIM»
Boolean
«PRIM»
Integer
«PRIM»
String
«PRIM»
Decimal
«PRIM»
Double
«PRIM»
TimeDuration
«PRIM»
TimePoint
«PRIM»
Token
81
Restricting Primitive Types
• 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
82
Restriction of a Primitive Type – example
«PRIM»
String
83
ENUMLibrary – Enumeration Type Library
84
ENUMLibrary - Enumeration type library
• An enumeration library is used to aggregate
• Identifier schemes (IDSCHEME)
• Code lists (ENUM)
85
Enumeration Type Example
• Enumeration types (ENUM) are used to depict code lists
«ENUM»
ISO42173A
+
+
+
+
AED = United Arab Emi...
AFN = Afghani
CHF = Swiss franc
... = ...
86
Enumeration values (CodeListEntry)
• An enumeration consists of an enumerated set of values
(CodeListEntry)
• CodeListEntry carries additional meta-information about the code list
entry
«ENUM»
Count ry Codes
+
+
+
+
+
AFGHANISTAN: String = AF
ALAND ISLANDS: String = AX
ALBANIA: String = AL
YUGOSLAVIA: String = YU
...
87
Combining code lists to a new code list
«ENUM»
Union of Enumerat ions
«ENUM»
Enumerat ion 1
«ENUM»
Enumerat ion 2
88
Identifier scheme example
• Identifier schemes (IDSCHEME) are used to depict non-enumerated
identifier scheme values
«IDSCHEME»
Aus t ralian_book s _and_s erials
89
Reusing existing identifier schemes or code lists
• 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
«ENUM»
Count ry Codes
90
CDTLibrary – Core Data Type Library
91
CDTLibrary - Core Data Type Library (conceptual)
92
Core Data Types revisited
• 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!
93
CDT Library – example according to CCTS DT Catalogue 3.0
«CDT»
Amount
«CON»
+ Content: Decimal
«SUP»
+ Currency.Code: ISO42173A [0..1]
Additionally allowed primitives:
Decimal
Double
Float
Integer
94
Setting the value domain of content components and
supplementary components - example
«CDT»
Ident if ier
«ENUM»
ENUMLibrary (Enumerat ion Ty pe
Library ): : UNCEFACT_63055
«CON»
+ Content: String
«SUP»
+ Scheme.Identifier: String [0..1]
+ SchemeAgency.Identifier: UNCEFACT_63055 [0..1]
+ SchemeVersion.Identifier: String [0..1]
95
Setting the value domain of content components and
supplementary components - example
«CDT»
Ident if ier
«PRIM»
PRIMLibrary (Primit iv e Ty pe
Library CCTS DT 3. 0): : St ring
«CON»
+ Content: String
«SUP»
+ Scheme.Identifier: String [0..1]
+ SchemeAgency.Identifier: UNCEFACT_63055 [0..1]
+ SchemeVersion.Identifier: String [0..1]
96
CCLibrary – Core Component Library
97
CCLibrary – Core Component Library (conceptual)
98
CCLibrary – basics
• 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
99
«ACC»
Cons ignment
+
CCLibrary - example
Identification: Identifier [0..*]
«ASCC»
+Included
0..*
«ACC»
Cons ignment It em
«BCC»
+ ChargeableWeight: Measure [0..*]
+ DamageRemarks: Text [0..*]
+ DeclaredValueForCarriage: Amount [0..1]
+ DeclaredValueForCustoms: Amount [0..1]
+ DeclaredValueForStatistics: Amount [0..1]
+ DeliveryInstructions: Text [0..*]
+ FOB: Amount [0..1]
+ GrossVolume: Measure [0..*]
+ GrossWeight: Measure [0..*]
+ Identification: Identifier [0..*]
+ Information: Text [0..*]
+ InsuranceValue: Amount [0..1]
+ Invoice: Amount [0..*]
+ NetWeight: Measure [0..*]
+ Sequence: Ordinal [0..1]
+ SpecialInstructions: Text [0..*]
+ TotalCharge: Amount [0..1]
+ TotalExportExitToImportEntryCharge: Amount [0..1]
+ Type: Code [0..*]
+ TypeExtension: Code [0..*]
+Importation
«ASCC»
1..*
+Export
«ASCC»
1..*
+Transit
«ASCC»
«BCC»
+ Identification: Identifier [0..*]
+ Name: Text [0..*]
0..*
+Physical
«ASCC»
«ACC»
Count ry
0..*
«ACC»
S hippingMark s
«BCC»
+ Marking: Text [0..*]
+ MarkingInstructions.Code: Code [0..*]
«ASCC»
«ASCC»
BDTLibrary – Business Data Type Library
101
BDTLibrary – Business Data Type Library (conceptual)
102
Business Data Types
• Business Data Types (BDT) are
derived from Core Data Types
(CDT) by restriction
• Content Components (CON) hold
«CDT»
CDTLibrary (Core Dat a Ty pe Library CCTS DT
3. 0): : Code
«CON»
+ Content: String
«SUP»
+ List.Identifier: String [0..1]
+ ListAgency.Identifier: UNCEFACT_3055 [0..1]
+ ListVersion.Identifier: String [0..1]
the actual information (e.g. 12R17)
«basedOn»
• Supplementary components
«BDT»
Was t e_Code
provide additional meta information
«CON»
+ Content: String
for the content component
«SUP»
+ List.Identifier: String [0..1]
+ ListAgency.Identifier: WasteCode [0..1]
103
Setting the value domain of content components and
supplementary components of Business Data Types (BDT)
«CDT»
CDTLibrary (Core Dat a Ty pe Library CCTS DT
3. 0): : Code
«ENUM»
UNCE FA CT_3055
«CON»
+ Content: String
«SUP»
+ List.Identifier: String [0..1]
+ ListAgency.Identifier: UNCEFACT_3055 [0..1]
+ ListVersion.Identifier: String [0..1]
Must be a subset of
«basedOn»
«BDT»
Was t e_Code
«ENUM»
Was t eCode
«CON»
+ Content: String
«SUP»
+ List.Identifier: String [0..1]
+ ListAgency.Identifier: WasteCode [0..1]
The same applies to identifier schemes!
104
BIELibrary – Business Information Entity Library
105
BIELibrary – Business Information Entity Library (conceptual)
ASCC
bLibrary
specified in a
CCLibrary
BIELibrary
specified in a
CCLibrary
+basedOn
0..*
1
*
+associatedWith
ACC
ABIE
ASBIE
+basedOn
1
2
1
*
0..*
0..*
BCC
BBIE
BDT
+basedOn
1
specified in a
CCLibrary
+typified
*
1..*
1
Specified in a
BDTLibrary
106
BIELibrary – basics
• 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
107
Business Information Entity Library – example
«ABIE»
Was t e_Cons ignment
+
based on
Waste_Identification: Waste_Identifier [0..*]
«ASBIE»
1..*
+Waste_Included
«ABIE»
Was t e_Cons ignment It em
«BBIE»
+ Waste_ChargeableWeight: Waste_Measure [0..*]
+ Waste_DeclaredValueForCarriage: Waste_Amount [0..1]
+ Waste_DeclaredValueForCustoms: Waste_Amount [0..1]
+ Waste_DeclaredValueForStatistics: Waste_Amount [0..1]
+ Waste_DeliveryInstructions: Waste_Text [0..*]
+ Waste_GrossVolume: Waste_Measure [0..*]
+ Waste_GrossWeight: Waste_Measure [0..*]
+ Waste_Identification: Waste_Identifier [0..*]
+ Waste_Information: Waste_Text [0..*]
+ Waste_InsuranceValue: Waste_Amount [0..1]
+ Waste_Invoice: Waste_Amount [0..*]
+ Waste_NetWeight: Waste_Measure [0..*]
+ Waste_Sequence: Waste_Ordinal [0..1]
+ Waste_SpecialInstructions: Waste_Text [0..*]
+ Waste_TotalCharge: Waste_Amount [0..1]
+ Waste_Type: Waste_Code [0..*]
+ Waste_TypeExtension: Waste_Code [0..*]
+Waste_Export
«ASBIE»
1
+Waste_Importation
«ASBIE»
«ABIE»
Was t e_Count ry
«BBIE»
1 + Waste_Identification: Waste_Identifier [0..*]
+ Waste_Name: Waste_Text [0..*]
+Waste_Transit
«ASBIE»
0..*
«ABIE»
Was t e_S hippingMark s
«BBIE»
+ Waste_Additional_MarkingInstructions: Waste_Code
1..* + Waste_Marking: Waste_Text
+ Waste_MarkingInstructions: Waste_Text
+Waste_Physical
«ASBIE»
108
DOCLibrary – Business Document Library Library
109
DOCLibrary - Business Document Library – challenges
• 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)
110
DOCLibrary concepts
111
Business Document Library - example
Defined in a DOCLibrary
«MA»
Was t eMov ement Form
+Attached
«ASMA»
1..*
Defined in
BIELibrary
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y
Library ): : Was t e_Cons ignment
+
Waste_Identification: Waste_Identifier [0..*]
«ASBIE»
+Waste_Included
1..*
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y Library ): :
Was t e_Cons ignment It em
«BBIE»
+ Waste_ChargeableWeight: Waste_Measure [0..*]
+ Waste_DeclaredValueForCarriage: Waste_Amount [0..1]
+ Waste_DeclaredValueForCustoms: Waste_Amount [0..1]
+ Waste_DeclaredValueForStatistics: Waste_Amount [0..1]
+ Waste_DeliveryInstructions: Waste_Text [0..*]
+ Waste_GrossVolume: Waste_Measure [0..*]
+ Waste_GrossWeight: Waste_Measure [0..*]
+ Waste_Identification: Waste_Identifier [0..*]
+ Waste_Information: Waste_Text [0..*]
+ Waste_InsuranceValue: Waste_Amount [0..1]
+ Waste_Invoice: Waste_Amount [0..*]
+ Waste_NetWeight: Waste_Measure [0..*]
+Waste_Importation
1
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y
Library ): : Was t e_Count ry
0..*
«BBIE»
+ Waste_Identification: Waste_Identifier [0..*]
+ Waste_Name: Waste_Text [0..*]
«ASBIE»
+Waste_Transit
«ASBIE»
+Waste_Export
«ASBIE»
1
112
Combining UN/CEFACT’s Modeling Methodology (UMM) and
the UML Profile for Core Components (UPCC)
• 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
«ReqAction»
«ResAction»
:PurchaseOrderEnvelope
:PurchaseOrderEnvelope
:PurchaseOrderPendingEnvelope
:PurchaseOrderPendingEnvelope
Control
Failure
:PurchaseOrderRejectionEnvelope
[OrderPendingEnvelope
!= null]
[else]
:PurchaseOrderRejectionEnvelope
113
Combining UMM & UPCC
114
Combining UMM & UPCC cont‘d
Defined in UMM Business
Information View
Defined in SBDH
specification
«InfEnvelope»
Was t e Management : :
Was t eMov ement FormE nv elope
«SBDH»
S B DH Library : : S t andard B us ines s Doc ument Header
Defined in a DOCLibrary
«MA»
Was t eMov ement Form
+Attached
«ASMA»
1..*
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y
Library ): : Was t e_Cons ignment
+
Defined in
BIELibrary
Waste_Identification: Waste_Identifier [0..*]
«ASBIE»
+Waste_Included
1..*
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y Library ): :
Was t e_Cons ignment It em
«BBIE»
+ Waste_ChargeableWeight: Waste_Measure [0..*]
+ Waste_DeclaredValueForCarriage: Waste_Amount [0..1]
115
+Waste_Importation
From conceptual models to deployment artifacts
«ABIE»
US_Person
«BBIE»
+ DateofBirth: Date
+ FirstName: Text
Naming and Design Rules
«ASBIE»
+US_Work
«ABIE»
US_Address
«ASBIE»
+US_Private
«BBIE»
+ PostalCode: PostalCodeType
+ Street: Text
VIENNA AddIn
<xsd:complexType name="US_PersonType">
<xsd:sequence>
<xsd:element name= "DateofBirth" type="udt1:DateType">
<xsd:element name="FirstName" type="udt1:TextType"/>
<xsd:element name="US_Work" type="bie1:US_AddressType"/>
<xsd:element name="US_Private" type="bie1:US_AddressType"/>
<xsd:sequence>
</xsd:complexType>
<xsd:complexType name="US_AddressType">
[…]
</xsd:complexType>
116
Visualizing Inter ENterprise Network Architectures
VIENNA AddIn
UMM (UN/CEFACT’s Modeling
Methodology)
UPCC (UML Profile for Core
Components)
o Model validation
o Model validation
o Transformation to choreography languages (BPEL,
BPSS)
o Deployment artifact
generation (XSD)
o Automated model structure
generator
o Model-artifact creation
wizards
o Core Component Library
import
http://vienna-add-in.googlecode.com
117
118
Agenda
• 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
119
Different Structure and Semantic are currently the biggest
issues of XML standards
OAG
xCBL
Different
information elements
Overview of Core Component related
UN/CEFACT specifications
Core Component Technical
Specification (CCTS)
Core Data Type Catalogue
UML Profile for Core
Components (UPCC)
based on
conforms
to
derive
use core component
definitions
Core Component
Library (CCL)
XML-Schema
conforms
to
Naming and Design Rules (NDR)
define unambiguous derivation rules
121
Motivation: 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>
122
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
Business
Methodology
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
…
Transformation concepts of
UN/CEFACT's Naming and Design Rules
Business Information Entity Concept
XML Schema Construct
xsd:simpleType
Business Data Type (BDT)
OR
xsd:complexType
Basic Business Information Entity (BBIE)
xsd:element Local Declaration
xsd:complexType
Aggregate Business Information Entity (ABIE)
xsd:element Global Declaration
Association Business Information Entity (ASBIE)
xsd:element Local Declaration
124
Resulting XML files
Business Document Definitions
Root XML Schema File
includes
includes
BIE XML Schema File
includes
BDT XML Schema File
Business Data Type (BDT)
Basic Business Information Entity (BBIE)
Association Business Information Entity (ASBIE)
Aggregate Business Information Entity (ABIE)
125
Example for a business document schema
Defined in a DOCLibrary
«MA»
Was t eMov ement Form
+Attached
«ASMA»
1..*
Defined in
BIELibrary
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y
Library ): : Was t e_Cons ignment
+
Waste_Identification: Waste_Identifier [0..*]
«ASBIE»
+Waste_Included
1..*
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y Library ): :
Was t e_Cons ignment It em
«BBIE»
+ Waste_ChargeableWeight: Waste_Measure [0..*]
+ Waste_DeclaredValueForCarriage: Waste_Amount [0..1]
+ Waste_DeclaredValueForCustoms: Waste_Amount [0..1]
+ Waste_DeclaredValueForStatistics: Waste_Amount [0..1]
+ Waste_DeliveryInstructions: Waste_Text [0..*]
+ Waste_GrossVolume: Waste_Measure [0..*]
+ Waste_GrossWeight: Waste_Measure [0..*]
+ Waste_Identification: Waste_Identifier [0..*]
+ Waste_Information: Waste_Text [0..*]
+ Waste_InsuranceValue: Waste_Amount [0..1]
+ Waste_Invoice: Waste_Amount [0..*]
+ Waste_NetWeight: Waste_Measure [0..*]
+ Waste_Sequence: Waste_Ordinal [0..1]
+Waste_Importation
1
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y
Library ): : Was t e_Count ry
0..*
«BBIE»
+ Waste_Identification: Waste_Identifier [0..*]
+ Waste_Name: Waste_Text [0..*]
«ASBIE»
+Waste_Transit
«ASBIE»
+Waste_Export
«ASBIE»
1
126
Example for a business information entity schema
«ABIE»
Was t e_Cons ignment
+
Waste_Identification: Waste_Identifier [0..*]
«ASBIE»
1..*
+Waste_Included
«ABIE»
Was t e_Cons ignment It em
«BBIE»
+ Waste_ChargeableWeight: Waste_Measure [0..*]
+ Waste_DeclaredValueForCarriage: Waste_Amount [0..1]
+ Waste_DeclaredValueForCustoms: Waste_Amount [0..1]
+ Waste_DeclaredValueForStatistics: Waste_Amount [0..1]
+ Waste_DeliveryInstructions: Waste_Text [0..*]
+ Waste_GrossVolume: Waste_Measure [0..*]
+ Waste_GrossWeight: Waste_Measure [0..*]
+ Waste_Identification: Waste_Identifier [0..*]
+ Waste_Information: Waste_Text [0..*]
+ Waste_InsuranceValue: Waste_Amount [0..1]
+ Waste_Invoice: Waste_Amount [0..*]
+ Waste_NetWeight: Waste_Measure [0..*]
+ Waste_Sequence: Waste_Ordinal [0..1]
+ Waste_SpecialInstructions: Waste_Text [0..*]
+ Waste_TotalCharge: Waste_Amount [0..1]
+ Waste_Type: Waste_Code [0..*]
+ Waste_TypeExtension: Waste_Code [0..*]
+Waste_Export
«ASBIE»
1
+Waste_Importation
«ASBIE»
«ABIE»
Was t e_Count ry
«BBIE»
1 + Waste_Identification: Waste_Identifier [0..*]
+ Waste_Name: Waste_Text [0..*]
+Waste_Transit
«ASBIE»
0..*
«ABIE»
Was t e_S hippingMark s
«BBIE»
+ Waste_Additional_MarkingInstructions: Waste_Code
1..* + Waste_Marking: Waste_Text
+ Waste_MarkingInstructions: Waste_Text
+Waste_Physical
«ASBIE»
127
Agenda
• 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
128
Overview of Core Component related
UN/CEFACT specifications
Core Component Technical
Specification (CCTS)
Core Data Type Catalogue
UML Profile for Core
Components (UPCC)
based on
conforms
to
derive
use core component
definitions
Core Component
Library (CCL)
XML-Schema
conforms
to
define unambiguous derivation rules
Naming and Design Rules (NDR)
129
UN/CEFACT‘s Core Component Library (CCL) at a glance
• 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).
130
Working with core
components
Evaluation
Harmonization
Standardization
maintain
UN/CEFACT Core Components
Library
UN/CEFACT
new
Core
Components
retrieve
CCTS 3.0
use
UPCC 3.0
store/
retrieve
User
conformant with
UML 2.1
…
model
generate
…
User Library
Core Component Model
<xs:element name="…"
…
</xs:element>
Cut-out from the latest Core Component Library (CCL09A)
132
Shortcomings of the Core Component Library
• 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
133
Motivation for a Core Component Registry
Conceptual UML
Business Document
Business
Partner A
define
A
B
3
use
1
B
Core Components
2
4
<XML/>
C
A
transform
Service Interface
Definition
5
Core Component
Registry
store/
retrieve
6
Business
Partner B
Business
Partner C
defined
in
UN/CEFACT
Core
Component
Library
134
Federated Registry Approach
UN/CEFACT
CIDX
Shell
Automotive
BP
AIAG
ODETTE
SWIFT
Swiss
Bank
Assocation
Austrian
Bank
Assocation
Resources
•
Core Components Technical Specification 3.0
•
•
Core Component Data Type Catalogue 3.0
•
•
http://tinyurl.com/myspr6
Core Component Library CCL 09 A
•
•
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://www.unece.org/cefact/codesfortrade/CCTS-CatalogueVersion3.pdf
UML Profile for Core Components 3.0
•
•
http://www.unece.org/cefact/ebxml/CCTS-Version3.pdf
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
136
Questions?
<Lecturer>
<Name>Philipp Liegl</Name>
<Company>Vienna University of Technology</Company>
<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.umm-dev.org</Http>
</Contact>
<? Presentation status=“questions” ?>
</Lecturer>
137