3rd Discussion Draft1
June 11, 2010
Business Processes, Data and Context
1. Document Objective
The primary objective of this document is to highlight the use of “context” in various
UN/CEFACT technical specifications and to facilitate their consistent application in
discovering and contextualizing UN/CEFACT artefacts including the development of context
schemes and values for business processes.
2. Modelling Requirement
As envisaged by UN/CEFACT technical specifications stakeholders, business process
modellers and application developers need to discover, re-use or adapt existing artefacts
(business processes, core data components and XML schemas) as well as develop new ones.
How discover and re-use are to be realized is left to the ingenuity of implementers and tool
developers and is therefore subject to interpretation, variation and innovation. The following
discussion focuses on what and how discover and contextualization needs might be fulfilled
in a more consistent and predictable manner.

Discovery - relies on the user to specify a search string (i.e. a known value for
business domain or context) that could identify an artifact defined to a specific level
of detail or granularity. Refinement of the search string is essential because various
artefacts may use common term(s) to identify themselves (e.g. “order” is commonly
used for various process and data artefacts) or themselves plus their constituent parts.
Powerful search capabilities are also important in harmonization procedures to
discover terms that have been used to contextualize data and business processes.
An ebXML registry provides the ability for a user-defined content cataloguing
service to be configured for each object type defined by the mapping. The purpose of
the cataloguing service is to selectively convert content into [ebRIM] compatible
metadata when the content is submitted. The generated metadata enables the selected
content to be used as parameter(s) in a domain specific parameterized query.
(Registry2, lines 1861-1866)

Contextualization – relies on the user to “specialize” an existing component by
adding characteristics to the business process and data that are unique a specific
business environment. The CCTS and the Core Component Library harmonization
procedures give guidance and rules to be followed in restricting, qualifying or
extending existing components.
1
Prepared by Ed Buchinski with input from Colin Clark, Niki Sahling, Ian Watt and Will Keenan
UN/CEFACT Registry Implementation Specification (Version 1.3) 11 November, 2008.
http://www.uncefactforum.org/ICG/Documents/ICG%20Archive/UNCEFACT_Registry_Specification_V1.3.zip
2
1
It is assumed that any solution for business process context schema development must be
based on a common understanding of how the context values are to be applied in discovering
and contextualizing business processes and core components to create business information
entities and re-usable business processes.
3. Classification and Artifact Discovery
The Common Business Process Catalog Technical Specification (CBPC)3 provided initial
guidelines to assist UN/CEFACT in classifying business processes, enabling users to discover
these processes and to expedite reuse of standardized business process models. Based on the
Porter Value Chain, it provided eight values for Business Areas and five values of Process
Areas.
Since then pressures have arisen for TBG14 to extend the current set of values4 for Business
Domain, Business Areas, Process Areas, Business Processes and Authorized Roles, to
formalize naming conventions and to establish maintenance procedures and for UN/CEFACT
to formally adopt specific schemas for all context categories defined by CCTS.
Open issue: Context Methodology development is on the way – other
projects should start to think about the integration of context concepts
Core Component Technical
Specification (CCTS)
Core Data Type
Catalogue
UN/CEFACT
Context
Methodology
based on
conforms
to
n of
ratio
s
Integ concept
ext
t
n
o
c
UML Profile for
Core Components
(UPCC)
use core component
definitions
derive
Core Component
Library (CCL)
XML-Schema
UN/CEFACT's
Modeling
Methodology (UMM)
conforms
to
define unambiguous derivation rules
Naming and
Design Rules
(NDR) 8
UN/CEFACT Common Business Process Catalog – Technical Specification. (Version 1.0) 30th
September, 2005. http://www.uncefactforum.org/TBG/TBG14/TBG14%20Documents/cbpctechnical-specification-v1_0-300905-11.pdf
3
4
There is a lack of differentiation among schema values that apply ot multiple business processes (e.g.
business areas and process areas) versus use values from multiple context schemes to identify one
business domain or context versus schemas in which individual value sets identify only one process,
role or business entity.
2
Figure 1 – Thinking About Integration of Context Concepts5
4. UN/CEFACT Technical Specifications
A significant impediment to understanding how discovery and contextualization may be
realized arises from the multiple meanings and business circumstances (a.k.a. domains and
contexts) in which business concepts are used as exemplified by the evolving UN/CEFACT
technical specifications and available tools that promote component harmonization and re-use.
Some crucial concepts, their definitions and sources, are identified below to foster consensus
building and to clarify how they are to be used in creating and contextualizing process and
data models.
Classification – according to the CBPC, “Classification describes a property of an
information object or its relation to other information objects and enables the
grouping of these objects. … The prime purpose of classifying the business
processes in the Business Process Catalog is to enable potential users to readily
identify processes that have been defined in the catalog that might meet their business
needs.” (CBPC, lines 420-427)
The Context Classification concept represents the common semantics used for
identifying the terms qualifying the business usage of artefacts. Contextualizing this
common view to all artefacts contained within the Registry enables a starting point
for discovery. From the end users perspective it is advantageous to discover specific
content through its business usage and find all pertinent artefacts for a specific
context. (Registry, lines 784-789)
Figure 2 – Conceptual View of Registry Storage Mechanism (Registry, line 775)
Every stored UN/CEFACT Artifact SHOULD be classified and registered, and
SHOULD inherit attribute metadata from the abstract Registry Class as indicated in
this model. (Registry, lines 799-801)
5
Slide 8 presented to UN/CEFACT Standard Development Advisory Team, Feb 3, 2010 Conference
Call.
3
Figure 3 - Registry view of context classification and registration information
The [ebRIM] classification mechanism MAY be used for grouping subsets of context
values within one or more Business Context instances. It adopts the tree structure
graph where each node has zero or more child nodes. Consequently every code list
used for classifying a business context MUST be added within the Registry as a
ClassificationNode under the corresponding ClassificationScheme root node
containing the corresponding code list values. (Registry, lines 880-885)
If several code lists are identified for a Registry context category, they SHOULD be
added to the tree as sibling ClassificationNodes (see Figure [4]) (Registry, lines 885887)
Figure 4 - Example of [ebRIM] Classification Mechanism
4
The Common Business Process Catalog (CBPC) will be stored in the Registry. The
information model to which common BPs MUST conform to is given in Figure 18
thereafter. It shows the objects and their relationships that specify the BP, and the
various classification schemes that enable the CBPC to be searched by potential users.
These classifications together with the BP Names and Roles support the CCs
Contexts as well as provide a Normative and Sub normative classification which will
bring together any related BPs (based on the ISO classification and modified Porter
Value Chain classification as described in the CBPC specification). (Registry, lines
1377-1385)
Figure 5 - Abstract Data Strucutre for the CBPC Information Model (Registry, line
1485)
Business Domain – according to the UMM6, a “BusinessDomainView captures all
of the business processes which may be of interest for the domain under
5
consideration. In order to enable users to readily identify business processes, these
business processes are classified into business categories. This classification is done
by creating business areas and process areas.” (UMM, lines 387-390)7
NOTE - A business domain refers to the range of business activities that are
delimited by the business functions, participants and entities included in a business
process scenario or use case diagram. A domain name alone is insufficient to convey
the scope of a business process and to distinguish between a simple versus a complex
scenarios or use cases.
Business Domain Categories (i.e. Areas) – according to UMM, “A business
area corresponds to a division of an organization and a process area corresponds to a
set of common operations within the business area. A business area might be
composed of other business areas. This means, a business area may form a hierarchy.
… The lowest level of a business area hierarchy includes process areas or business
processes use cases.” (UMM, lines 433-435)
The following metadata information SHALL be extracted from the BRS and
submitted to the Registry in the appropriate XML exchange format (refer to Chapter
4). This metadata SHALL be compliant with the approved values of the classification
schemes maintained in the Registry, as appropriate:
• Title
• Business context
� Business domain
� Business process(es)
� Document identification
�…
• Version
• Submitting organization. (Registry, lines 1312-1323)
The RSM MAY conform to the RSM DTD Template or it can be a text document In
this case the following metadata information has to be submitted to the Registry in
the XML exchange format defined in the next chapter:
• Title
• Associated BRS
• Business context
� Business domain
� Business process(es)
�…
• Version
• Responsible and submitting organization
• Revision history information. (Registry, lines 1338-150)
All UMM Artefacts defined in the [RSM] document (CC, BIE, BC, etc.) MUST be
added to the submission to the Registry in XMI format. (Registry, lines 1361-1362)
7 UML Profile for UN/CEFACT’s Modeling Methodology (UMM Foundation Module Candidate for 2.0 Draft for Implementation Verification
2010‐01‐29. http://www.untmg.org/umm/spec/foundation/2_0.
6
The details of the Common BPs MAY be expressed in XML format following the
BPSS. … Each BP in the CBPC is at its most general level represented by a
normative category of inter-enterprise activity. The normative categories are one
example of the division of an enterprise into business areas as recommended by the
UMM8. None of the reviewed classification schemes directly satisfy all requirements,
but the one that comes closest is the Porter Value Chain. The categorization selected
for the catalogue is based on development and extension of that model. The
categories selected are example components for the Business Categories as reflected
by the TBG Groups: Supply Chain, Transportation and Logistics, ….. They will
have to be defined and maintained within a formalized classification schema.
(Registry, lines 1388 – 1415)
Business Context – A specific business context is formally described using a set of
context values. Every context category must have a valid value, even if this value is
In All Contexts or None. The value None is appropriate for official constraints
context because there will be instances where there are no official constraints. (CCTS
3.0, lines 5807-5810)
A business context contains a combination of values for all approved context
categories and defines a unique and meaningful business context. …. The identifier
references the business context in a unique and unambiguous way. There are no
specific rules for the structure of the identifier; however the preferred identification
scheme is the ITU‐T Rec. X.667|ISO/IEC9834‐8 Universally Unique Identifier
(UUID) scheme. (UPCC, line 1133)
The Unified Context Methodology is “a methodology for managing the
representation and use of business context information, especially for UN/CEFACT
technologies. This includes representing the business contexts of Business
Information Entities (BIEs), using business context during message assembly to
produce messages for specific business contexts, and using business context to (semi) automatically customise generic business processes. … Context is metadata that
defines circumstances in which particular data is or is not relevant. That is to say,
context information is information that is used to identify the scope (relevance,
applicability, business context) of some other information. … In order to create a
workable context model and methodology, it is necessary to understand what context
information needs to be modelled and how it will be used. The concept of context
naturally leads to categorization of context values which can be expressed as a
context category. A context category is a group of one or more unordered values used
to express a characteristic of a business circumstance. (UCM, lines 177-193)
The Business Context concept plays a central role in the discovery process of
Registry content. It can be the starting point of a user search and the way to grouping
Registry Entry instances having common aspects on semantic and domain. A drilldown system for the discovery of Registry instances based on the content
classification SHOULD show only existing business contexts for each context
category classifying at least one business context and not the whole list of context
values, which in several cases amount to a huge list. Every business context can
8
11 UMM, proposed Chapter 8, section dealing with the Business Domain View (BDV).
7
appear as an element for the category list where it is classified. (Registry, lines 9991006)
«BusinessProcessContextValue»
Process Context
«ClassificationScheme»
CCBP
«BusinessProcessRoleContextV...
Process Role Context
«GeopoliticalContextValue»
Geopolitical Context
«ABIE»
Waste_Consignment
+
Waste_Identification: Waste_Identifier [0..*]
«IndustryClassificationContexVa...
Industry Context
«BusinessContext»
Waste Management Business Context
«OfficialConstraintsContextValu...
Official Constraints Context
«ProductClassificationContextV...
Product Classification Context
«SupportingRoleContextValue»
Supporting Role Context
«SystemCapabilitiesContextVal...
System Capabilities Context
Figure 6 - Business Context Example
The example above shows the aggregate business information entity Waste
Consignment Item and its associated Waste Management Business Context. The
context definition has eight associated context values according to the predefined
context categories of UN/CEFACT. An example of the process context is shown in
detail on top of the Figure above. As outlined by the attached classification schema,
the process context follows the UN/CEFACT Catalogue of Common Business
Processes. (UPCC, lines 1158-1163)
UCM uses graph theory to define and understand the concept of context, context
categories, context values and context operands. It is necessary to understand graph
8
theory and terms to properly understand and apply UCM. A graph is a set of nodes
(points) connected by edges. A root node is a starting point of a graph. An edge is an
ordered pair of vertices represented by a connection between two nodes. (UCM,
lines 217-221)
A specific business context is formally described using a set of context values. Every
context category must have a valid value, even if this value is In All Contexts or
None. The value None is appropriate for official constraints context because there
will be instances where there are no official constraints. (CCTS 3.0, lines 5807-5810)
A business context contains a combination of values for all approved context
categories and defines a unique and meaningful business context. …. The identifier
references the business context in a unique and unambiguous way. There are no
specific rules for the structure of the identifier; however the preferred identification
scheme is the ITU‐T Rec. X.667|ISO/IEC9834‐8 Universally Unique Identifier
(UUID) scheme. (UPCC, line 1133)

Business Process Context – “provides a way to unambiguously identify the
business activity. To ensure consistency with business process activities, it is
important to use a common point of reference. The definitive point of reference for
international standards is the UN/CEFACT Catalogue of Common Business
Processes.
[X8] Assigned business process contexts shall be from the standard hierarchical
classification provided as part of the UN/CEFACT Catalogue of Common
Business Processes.
[X9] Business process context values may be expressed as a single business
process, or as a hierarchical set of business processes.
[X10] Business process context values may be taken from extensions to the
business processes described in the UN/CEFACT Catalogue of Common
Business Processes as provided for in that document.
[X11] When business process extensions are used, they shall include full
information for each value sufficient to unambiguously identify which extension
is providing the value used.” (CCTS 3.0, p.149)

Business Process Role Context – (i.e. UMM Authorized Role) - describes
those aspects of a business situation that are specific to an actor or actors within the
business process. Its values are taken from the set of role values provided by the
UN/CEFACT Catalogue of Common Business Processes. A business process role
context is specified by using a value or set of values from this source.
[X30] Business process role context values shall be taken from an approved list
provided by the business process model library being employed.
9
[X31] The UN/CEFACT Catalogue of Common Business Processes shall be the
definitive source of business process role context values for all UN/CEFACT
BIEs. (CCTS 3.0, p. 152)

Supporting Role Context – “identifies those parties that are not active participants
in the business process being conducted but who are interested in it. A supporting
role context is specified with a value or set of values from a standard classification.
[X32] Supporting role context values shall be taken from the UN/EDIFACT code
list for DE 3035 party roles.
[Note] – Code List Duplication Users are cautioned that duplication exists in the
current version of the required code list. UN/CEFACT will review this code list
to clarify duplicates and identify non-Supporting Role Context values.” (CCTS
3.0, p. 152)

Context Graph - is the organization of possible values used to identify
specific business circumstances. (UCM, lines 319-320)
ContextEdge
Should source and
target be renamed
parent and child?
constraints
{Target must be different to source}
{Both nodes are from same graph as edge}
+edge 0..* {At most one edge connects any pair of nodes}
Or should we talk about
indirect source and
indirect target rather
than ancestor and
descendant?
+graph 1
0..*
ContextGraph
+graph 1
+source 1
1
+node 1..*
1
ContextGraphInformation
+
+
+
+
+
+
+
0..*
ContextGraphIdentifier: String
ContextGraphName: String [0..1]
ContextGraphDescription: String [0..1]
ContextGraphVersionIdentifier: String
ContextGraphVersionDate: Date [0..1]
ContextGraphAgencyIdentifier: String
ContextGraphAgencyName: String [0..1]
1 +target
ContextNode
+
+
+
+
ContextNodeIdentifier: String
ContextValue: String
ContextValueName: String [0..1]
ContextValueDefinition: String [0..1]
constraints
{Is a ContextRootNode, or has exactly 1 ancestor ContextRootNode}
{(ContextValueSource,ContextValue) pair is unique within tree rooted at ContextRootNode}
0..*
+Source
1
ContextRootNode
Scheme Or List
constraints
{Not a target of any edge}
+ Identifier: String
+ VersionIdentifier: String
+ AgencyIdentifier: String
Figure 7 - Context Graph
The ContextGraphID URN scheme MUST use the following pattern:
10
urn:<organization>:<org hierarchy>[:<org
hierarchy level>]*:context:<major>:<status>
URN:
Where:

[Ed Note – take NDR example and insert here]
(UCM, p. 18)

Context Value – “ is derived from a business process model which presumably
uses values that have their meaning defined somewhere. For example, if the value is
taken from a code list (specified in the classification scheme), then the meaning of
the code should be provided by the code list specification. As an alternative solution,
the meaning could optionally be a uniform resource identifier that points to the
definition.” (CCTS 3.0, p. 146)
b0dd9fcd-c7ad-4123-b7a6--6491df798ff
a0dd9fcd-c7ad-4123-b7a6--6491df798ff
c0dd9fcd-c7ad-4123-b7a6--6491df798ff
Figure 8 - Context Node Identifiers (Proposed Example for UCM)
In the above example, the ContextNodeIdentifiers are shown inside the notations of
the ContextNodes. UUIDs are used in this example for the ContextNodeIdentifiers this and would be identified as such the ContextGraphInformation.
The Context Node with the ContextNodeIdentifier beginning with ‘a0’ is a
ContextRootNode, and represents North America by using a ContextValue from the
Composition of macro geographical (continental) regions, geographical sub-regions,
and selected economic and other groupings
Code list agency from the UN Statistics Division. It has the following property
values:





ContextNodeIdentifier: a0dd9fcd-c7ad-4123-b7a6--6491df798ff (the UUID of
the node)
ContextValue: 21 (a code from the code list representing North America)
ContextValueName: N. America
ContextValueDefinition: North America
Source (Sheme or List)
o
Identifier: ?
o
VersionIdentifier: 15 (April 2009)
o
AgencyIdentifier: ?
(http://unstats.un.org/unsd/methods/m49/m49regin.htm)
The Context Node with the ContextNodeIdentifier beginning with ‘b0’ represents
United States by using a ContextValue from the ISO Country Codes 3166-1 code list
from ISO. It has the following property values: ….
11

Core Components – the CCTS “defines a meta model and rules necessary for
describing the structure and contents of conceptual and logical data models and
information exchange models. The CCTS is described using the Unified Modeling
Language (UML). … It provides a means to identify, capture and maximize the reuse of business information to support and enhance information interoperability.”
(CCTS 3.0, p. 2).
The Core Component Library that is maintained in the Registry contains the
approved CCs, the submitted CCs, the deprecated CCs and the CCs that are being
developed by registered users. It should be noted that the root registry class attributes,
illustrated in Section 3.1.3, Status, Start Date, User Version, Registrar, Registration
Authority and Submitting Organization are naturally inherited by all child nodes of
the parent components. (Registry, lines 1163-1168)
The key differentiator between CCs and BIEs is the concept of business context.
Business context is a mechanism for categorizing and refining CCs according to their
use in a particular data model or business circumstance. In CCTS, business context is
formally described for specific business circumstances for each BIE. This is
accomplished by assigning values to a set of context categories (See Section 9). Once
these business contexts are identified, BIEs can be defined to take into account any
necessary qualification and refinement needed to support the use of the underlying
CC in the given business context. (CCTS 3.0, p.23)
Figure [9] shows an example of a contextualised CC, i.e. a Business Information
Entity. It should be noted that, in this example, only the geopolitical context has
specific values. No [ebRIM] RegistryObject is created for any of the 7 other context
categories since they each hold their default value. (Registry, lines 1138-1142)
Figure 9 - Example (not exhaustive) of Financial Account Business Information
Entity for a European Union context
12
In UCM, a ‘Contextualized’ is anything which has a context. More specifically, a
‘Contextualized’ has a context grammar expression in terms of context nodes from a
context graph.
In the simplest case, a ‘Contextualized’ has the context that was assigned to it by a
business specialist. This is known as a ‘BasicContextualized’. A BBIE is an
example of a ‘BasicContextualized’, e.g.
BBIE
CI_ Creditor_ Financial Institution. Austrian Bankleitzahl_
Identification. Identifier
(assigned) context = (~AT) && ( ~Banking)
Where a ‘Contextualized’ contains multiple other ‘Contextualized’ items, it is called
an ‘AggregationContextualized’, and its context is calculated (not assigned) by taking
the union (“||”) of the contained ‘Contextualized’ items.
An ASBIE is ‘AssociatedContextualized’ that is associated with another
‘Contextualized’ item. The context of an ‘AssociatedContextualized’ is the context
assigned to it intersected (“&&”) with the context of the item it is associated with.….
The calculated context of the ASBIE is the intersection ….
The way in which the context assigned to an ‘AssociatedContextualized’ is
intersected with the context of the associated ‘Contextualized’ extends down into any
structure of the ‘Contextualized’ itself. With the effective contexts added (after
intersecting), …. the effective context of the final BBIE is NULL, i.e. not in any
context, so the final BBIE is out of context (and effectively disappears) when the
ABIE is used via this ASBIE. ( Draft Example Proposed for Inclusion in UCM)
XML NDR defines core components as – “A building block for the creation of a
semantically correct and meaningful information exchange package. It contains only
the information pieces necessary to describe a specific concept” (XML NDR, lines
5519-15521

Namespace - A namespace is an abstract container for a collection of elements,
attributes and types that serve to uniquely identify one such collection from all other
collections. ….. UNCEFACT assigns XML artefacts to UNCEFACT namespaces
following the namespace scheme shown in Figure 5-5. Each organization that intends
to adhere to this specification will assign their XML Schema defined content in a
namespace that follows a scheme similar to the UN/CEFACT namespace scheme
shown in Figure 5-5. This scheme will reflect the hierarchy of the organization and
the package structure of the CCTS compliant model from which the XML Schema is
derived. (XML NDR, lines 684 -694)
13
Figure 9 – UN/CEFACT XML Schema Namespace Data Structure ((XML NDR, lines
Both the organizational hierarchy and the package structure of a CCTS v3.0
compliant model is reflected in the namespace in the resulting set of XML Schema
Files. (XML NDR, lines 697-699)
14
Figure 10 - UN/CEFACT XML Schema Modularity Scheme (XML NDR, line
796)
The determination of the data package value is at the discretion of the originating
organization. The data package can be hierarchical within a set of related data
packages in one or more business processes. However, the hierarchy should be kept
as simple as possible. It is better to have multiple data packages at the same level in a
hierarchy than to create deeply nested package hierarchies. This approach enables the
use of individual package focused Root XML Schema Files that only use a tight set
of related components without importing the entire library. (XML NDR, lines 822828)
[Note:] While the package hierarchy relationship allows the reuse of specific BIEs, it
also means that any changes to a BIE within one package affects the BIEs use in
other packages that reuse it. Model developers must consider this in their design. For
this reason, linking of BIEs across packages is strongly discouraged. (XML NDR,
lines 1078-1080)
UN/CEFACT uses the business process context value to create different namespaces.
Each organization adhering to this specification will choose a context category value
to incorporate into their namespace. This context category should be the dominant
context category for their use. (XML NDR 3.0, lines 443-447)
Example 8-1 shows a namespace declaration for the context category Business
Process Value where the value is Order Management. (XML NDR 3.0, lines 14311432)
15
[Note:] Implementations of this specification require the use of a semantically
meaningful namespace prefix like “ordman“ for the Business Process – Order
Management. (XML NDR 3.0, lines 1443-1446)

Package – according to CCTS 3.0, a package “is a collection of semantically unique
Business Information Entities in a given context.” (See p. 158). By comparison,
UMM considers a package to be “The business requirements view results in a
categorization of the business domain (manifested as a hierarchical structure of
packages) and a set of relevant business processes (manifested as use cases). ( UMM
2.0, lines 199-201)
The Business Partners are described within their own package (Business Partner
View). (UMM 2.0, line 206).
Furthermore, the Business Entity View also contains one or more packages which
represent the conceptual data structures of the Business Entities. (UMM 2.0, lines
209-211).
A business library is realized as a package. Elements which inherit from a business
library (or subtypes of it), are candidates for registration in a registry. A business
library therefore acts as container for elements, which should be registered and
retrieved together to be semantically complete. (UMM 2.0, lines 265-267)
A business library is a container for objects, which together build a semantic unit.
(UMM 2.0, line 282)
The goal of the [UPCC] approach specified in this document is outlined in the UML
package diagram below.
16
UML 2.1.2
based on
Core Component T echnical Specification 3.0 (CCT S)
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
AT G2 Naming and Design Rules 3.0
Figure 11- Overview of UPCC
UPCC model is organized using stereotyped UML packages. Every package serves
its own purpose and holds a set of well defined artefacts. The different packages are
described in detail in the different subsections of this specification. (UPCC, p. 16)
A BIE is a context specific instantiation of a conceptual core component. A BIE will
be part of a package within a library. The package represents a set of BIEs being used
in a specific context and tailored to meet the unique requirements for the package.
BIEs are semantically unique within a package, but may be semantically similar in
name and definition to, albeit with a different content model than, BIEs in other
packages. (CCTS, p. 56)
XML Schemas – “The intent of this NDR is to express everything that is necessary
in a UN/CEFACT XML Schema to enable integration of business information within
an XML Schema conformant XML instance message. To accomplish this, the XML
Schema will address all aspects of the business information to include: • Business
semantics – …. • Business context – …. (XML NDR 3.0, lines 973-995)
[An] XML instance document should be intuitive and reasonably clear in the context
for which they are designed. (XML NDR 3.0, lines 309-310)
The various XML Schema files that are incorporated within the UN/CEFACT library
are built through the application of context categories, unique namespaces and the
rules of this specification.:
• XML Schema Files, Context and Namespaces
17
• Root XML Schema Files
• Business Information Entities XML Schema Files
• Business Data Type XML Schema Files 8
• Code List XML Schema Files;
o General Code List XML Schema Components
o Common Code List XML Schema Components
o Business Code List XML Schema Components (XML NDR 3.0, lines
1401-1412)
The XML Schema files have dependencies upon one another. Figure 8-1 further
shows these dependencies and shows how these dependencies are realized using the
xsd:include and xsd:import XML Schema features. (XML NDR 3.0, lines 14131416)
The CCTS identifies a set of context categories – such as business process,
geopolitical, system capabilities, business process role – the values of these
categories collectively define the context in which context specific BIEs are defined.
This NDR specification captures the context through the use of an annotation
application information element (<xsd:annotation> <xsd:appInfo>) accompanying
each element declaration. (XML NDR 3.0, lines 437-442)
CCTS defines the concept of usage rules to convey instructions on how to use a
CCTS artifact in a given context. Usage rules have a ccts:ConstraintType which
classifies the rules as being structured (expressed in a formal language such as the
Object Management Group’s Object Constraint Language (OCL)) or unstructured
(free form text). Usage Rules are communicated through zero or more
ccts:UsageRule XML Schema Elements within an xsd:appInfo. (XML NDR, lines
1321-1327)
XML Schemas represent Directories that can be stored in the Registry. The user can
search and retrieve them via the Registry Web site. The UN/CEFACT Artifact for
XML Schema Directory storage as outlined in Figure 8 is mapped to the RIM
adopting the [ebRS] File Folder metaphor mechanism. (Registry 1252-1255)
5. Modelling Views / Packages
A business process modelled using UMM consists of three views (i.e. business requirements,
business collaboration and business information) each covering a set of well defined artefacts.
These artefacts can be addressed as individual entities or as a group of related entities
depending on user interests or business circumstances.

Business Requirements View – identifies the business processes in the domain
and the business problems that are important to stakeholders. … in the language of
the business experts and stakeholders. … The business requirements view results in
a categorization of the business domain (manifested as a hierarchical structure of
packages) and a set of relevant business processes (manifested as use cases). The
result may be depicted in use case diagrams. … The Business Partners are described
within their own package (Business Partner View). A Business Process Activity
Model may show state changes to Business Entities. Business Entities are
“real‐word” things having business significance and are shared among the business
18
partners involved in the collaboration. The Business Entities and their lifecycles of
state changes are modeled in the Business Entity View. Furthermore, the Business
Entity View also contains one or more packages which represent the conceptual data
structures of the Business Entities. (UMM, lines 214-230)

Business Collaboration View – is used to define and document the global
choreography between collaborating business partners… Within the Business
Choreography View, the Business Transaction View contains and documents the
requirements of Business Transaction Use Cases … The dynamics of a Business
Transaction Use Case are described by a Business Transaction. A business
transaction defines a simple choreography of exchanging business information
between two authorized roles and an optional response. A business transaction
identifies the business actions of each partner responsible for sending and receiving
the business information. These actions correspond to the requirements of any
solution that must be implemented on each business partner’s side in a serviceoriented collaboration architecture. Within the Business Choreography View, the
Business Collaboration View contains and documents the requirements of Business
Collaboration Use Cases and their participating Authorized Roles. The dynamics of a
Business Collaboration Use Case are described by a Business Collaboration Protocol.
A Business Collaboration Protocol choreographs the flow among business
transactions, and/or nested Business Collaboration Protocols. This flow depends on
the states of business entities. When a Business Collaboration Use Case is identified,
but different sets of parties may execute this collaboration, the different Realizations
(executions) may be modeled within the Business Realization View, as a Business
Realization Use Cases. (UMM, lines 231-247)

Business Information View – execution of a business transaction usually results in
the change of state of one or more business entities. Thus, the information exchanged
in a transaction should be limited to the minimum information needed to change the
state of a business entity. Nevertheless, UMM allows the definition of an information
exchange in a document‐centric approach – even if this is not recommended. A
Business Information View contains Business Information Artefacts … [that UMM
recommends be] … modeled in accordance to UN/CEFACT’s Core Components
Technical Specification and Message Assembly Guidelines. In order to model Core
Components by means of UML, UN/CEFACT provides the Profile for Core
Components (UPCC). (UMM 2.0, lines 248-256)
A BusinessInformationView is a container of artefacts that describe the information
exchanged in a BusinessTransaction. As previously mentioned;
RequestingInformationPin and RespondingInformationPin are classified9 by an
InformationEnvelope which is a subclass of a BusinessInformation. A
BusinessInformation serves as an abstract container for all of the information
exchanged between the RequestingAction and the RespondingAction or vice versa,
respectively. (UMM 2.0, lines 1164-1168)
A UPCC model is organized using stereotyped UML packages. Every package
serves its own purpose and holds a set of well defined artefacts. The different
9
Does UMM require a classification scheme to be created for Information Envelopes or can the
Information Envelope and the corresponding “Pins” be classified using a Business Entity Name?
19
packages are described in detail in the different subsections of this specification.
(UPCC, p. 16)
«metaclass»
Package
from UMM 2.0 Base
Module
«extends»
bLibrary
+
+
+
+
+
+
+
businessTerm: String [0..*]
copyright: String [0..*]
owner: String [0..*]
reference: String [0..*]
status: String [0..1]
uniqueIdentifier: String
versionIdentifier: String
+
+
baseURN: String
namespacePrefix: String [0..1]
BDTLibrary
CCLibrary
+
+
DOCLibrary
baseURN: String
namespacePrefix: String [0..1]
BIELibrary
+
+
baseURN: String
namespacePrefix: String [0..1]
+
+
PRIMLibrary
baseURN: String
namespacePrefix: String [0..1]
CDTLibrary
+
+
baseURN: String
namespacePrefix: String [0..1]
+
+
baseURN: String
namespacePrefix: String [0..1]
ENUMLibrary
+
+
baseURN: String
namespacePrefix: String [0..1]
Figure 12 - UPCC Module Management - Abstract Syntax
The example in [Figure 13] shows how UPCC artefacts are integrated into the business
information view of UN/CEFACT’s Modeling Methodology. The bLibrary, where all
business information relevant artefacts are assembled is positioned directly under the business
information view of the UMM. Business documents exchanged in a UMM business
transaction are assembled in a DOCLibrary. Thereby, a single DOCLibrary is created for
each exchanged business document. (UPCC, lines 1183-1987)
20
Figure 13 – Example package structure for a UMM business information view
[Figure 13] shows an example for the DOCLibrary in the business information view
of a UMM model. Thereby, the user drags and drops the relevant information
envelope (InfEnvelope) from the business information view of UMM into the
DOCLibrary of the UPCC. Using a UML aggregation, the user connects the message
assembly (WasteMovementForm) to the information envelope
(WasteMovementFormEnvelope). Additionally, the user may connect a standard
business document header to the information envelope by dragging and dropping it
from the relevant SBDH library. Note that the SBDH specification is still under
development. (UPCC, lines 1190-1196)
The body of an information envelope consists of exactly one element, which is of
type message assembly (MA). This single message assembly serves as the root
element of a business document definition and is connected to the information
envelope using a standard UML aggregation. Message assemblies are used to
aggregate different aggregate business information entities (ABIE) to a specific
business document. Association message assemblies (ASMA) are used to connect
different message assemblies to each other and to connect aggregate business
information entities to message assemblies. For each business document exchanged
in a UMM business transactions a dedicated DOCLibrary is created.
The example in [Figure 13]: shows how UPCC artefacts are integrated into the
business information view of UN/CEFACT’s Modeling Methodology. The bLibrary,
where all business information relevant artefacts are assembled is positioned directly
under the business information view of the UMM. Business documents exchanged in
a UMM business transaction are assembled in a DOCLibrary. Thereby, a single
DOCLibrary is created for each exchanged business document. (lines 1167-1178)
21
«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 the
SBDH
specification
Defined in the
UMM business
information view
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_SpecialInstructions: Waste_Text [0..*]
+ Waste_TotalCharge: Waste_Amount [0..1]
+ Waste_Type: Waste_Code [0..*]
+ Waste_TypeExtension: Waste_Code [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
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y Library ): :
1..*
Was t e_S hippingMark s
+Waste_Physical
«ASBIE»
«BBIE»
+ Waste_Additional_MarkingInstructions: Waste_Code
+ Waste_Marking: Waste_Text
+ Waste_MarkingInstructions: Waste_Text
«ASBIE»
+Waste_Despatch
1
«ASBIE»
+Waste_Delivery
1
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y Library ): :
Was t eMov ement _P art y
«ASBIE»
+Waste_RFID
«BBIE»
+ Waste_AccessRights: Waste_Code [0..*]
+ Waste_AssignedToRole: Waste_DateTime [0..1]
+ Waste_Branch: Waste_Indicator [0..*]
+ Waste_Classification: Waste_Code [0..*]
+ Waste_ContractualArrangementExclusion: Waste_Indicator [0..1]
+ Waste_Country: Waste_Identifier [0..*]
+ Waste_Description: Waste_Text [0..*]
+ Waste_EstimatedMarginalTaxBracket: Waste_Percent [0..1]
+ Waste_Identification: Waste_Identifier [0..*]
+ Waste_Language: Waste_Code [0..*]
+ Waste_Name: Waste_Text [0..*]
+ Waste_QualityAssurance: Waste_Indicator [0..1]
+ Waste_ResidenceCountry: Waste_Identifier [0..1]
+ Waste_Role: Waste_Code [0..*]
+ Waste_Type: Waste_Code [0..*]
«BBIE»
+ Waste_Identification: Waste_Identifier [0..*]
+ Waste_SeriesEnd: Waste_Identifier [0..1]
+ Waste_SeriesStart: Waste_Identifier [0..1]
Figure 14 - Example for a UMM/UPCC Integration
22
1..*
«ABIE»
B IE Library (B us ines s Inf ormat ion E nt it y
Library ): : Was t e_Label
Based on the preceding discussion of UN/CEFACT technical specifications concerning
context use for discovering and contextualizing business artefacts, the following sections
explore requirements for context schema adoption, development and publication with a
focus on business process related schemas.
6. Which Schemas?
.
The BRS specification template identifies a business process by using a business domain
name and a business process name based on CBPC (in most instances) plus the name selected
by the project team. There is no recommended scheme for business domain. Do we need one
or is the business context a valid alternative and is the business domain identified the most
fully using values from one or more CCTS context categories?. According to the UCM a
business context needs to be identified by a context graph identifier (a UUID). Do these need
to be registered and published?
The CCTS identifies three context categories that are directly related to business process
modelling: business process, authorized role and supporting role
The CBPC specifies two classification schemes, which are endorsed by both the UMM and
CCTS: business area and process area. Furthermore, CBPC provides a defined set of 8
values for business area based on the Porter Value Chain and five values based on the
business process life cycle for process area. The Registry on the other hand defines has
identified the TBG group names instead of the Porter Value Chain values recommended by
CBPC.
Additional UMM, provides two business process views (business domain view and business
collaboration view) that could be classified using a business process classification scheme.
The domain view consists of two sub-views: business partner and business entity which
imply a need for separate classification schemes. The business collaboration have three subviews that could be classified using one or more values from business process, authorized
role, supporting role, business partner and business entity.
UN/CEFACT needs to review and to define which context schemes are to be used to classify
and contextualize business processes.
7. Process Related Naming Conventions
While naming conventions and quality controls exist for core components there is no
counterpart for naming and harmonizing business processes names. Development of a formal
naming convention is essential to support consistent business process naming and discovery.
The need for a naming convention arises primarily to register artefacts that are to be posted to
a repository. .
[A mechanism] SHALL be put in place to manage the version of evolving
UN/CEFACT Artefacts so as to ensure their overall consistency within the Registry.
(Registry, lines 1494-1496)
23
A variety of implicit naming conventions and practices have evolved for business process and
information artefacts included in UMM and the BSP initiative. The following represents
some of these conventions including their source if applicable.
 UMM Business Views and Packages (Domain. Requirements, Collaboration)
The UMM enables a business process to be elaborated in successive steps starting with
the terminology and perspective of a business expert and subsequent refine in detail and
perspectives of the systems analyst. In so doing UMM carries the same name for the
respective views. Artefacts belonging to the respective views are included in a UMM
package and need to be accessible as a group10. Both UMM and the Registry give no
guidance for naming for views or packages.
One approach would be to re-use the name for all the artefacts within a given view or
package and to qualify the process name by the name for the view. For example, the
artefacts for a business process “order” could be differentiated by a uniform set of
qualifiers domain, requirements, and collaboration (e.g. order – domain, order –
requirements, order collaboration).
To identify the stakeholders or business entities that pertain to a given process the search
string would include the business process package name plus the generic name
“stakeholders”, “participants”, “entities “ or a combination of these terms (e.g. order –
requirements: participants)

Business Information View
According to UMM a business entity such as an order is defined to the extent needed
depending on the “view” and the information object that is being interchanged by a
business process defined for that view. Thus an “order” information object can be: a
business entity, a business envelope, or a business message consisting of a header and a
body. The name conventions are to use a common entity name (e.g. order) and to qualify
by qualify it with a stereotype name <<bEntity>> or a process name
(e.g. :OrderRequestEnvelope)11.

UMM Business Process Names (Process, Transaction, Collaboration, Realization)
A UMM artefact is classified by its stereotype name, such as bEntity, bTransaction,
bCollaboration, etc. which is enclosed in brackets <<stereotype name>>) and a name for
a business process or business entity that that are enclosed in a UML symbol. Note the
variation in the name for the “ordering” process artefacts in the following UMM
examples which imply a refinement in the business process specification.
10
Huemer, Christian et al. A 3-level e-Business Registry Meta Model.
NOTE – the example names appear to have been truncated in the UMM. Need to clarify if UMM
naming conventions would require the name to be PlaceOrderBusinessTransaction:OrderRequestEnvelope
11
24
Use cases and activity diagrams are distinguished from each other by the name for
diagram type “uc” and “ad” plus the name of the business transaction .collaboration
/realization usually the business process name. Use of “ad” and “uc” has been deleted
from the examples in UMM 2.0. In addition the example name (but not the diagram
type) may indicate the business cycle phase in which the business transaction belongs
(e.g. order negotiation).
An implicit naming convention appears in UMM and the eWaste BRS which adds the
“management” to the business process name (e.g. order management instead of simply
order). This example is also used in XML NDR.
Each business process artifact needs to be consistently named and uniquely identified if is
to be discovered and accessed individually or as a set of related artefacts (i.e. view or
package). Should the UMM define naming conventions for all the UMM artefacts
including use cases, activity diagrams and class diagrams as well as components such as
business partner types and business entities.

Role (Authorized, Supporting)
The name for a role is determined by the business modeller although efforts have been
made to date to establish normative list of role names with accompanying definitions (e.g.
TDED / ISO 6505?). Examples in UMM offer a modicum of distinction between
authorized role name and business partner name by adding “organization” to names that
can be confused for role (e.g. seller versus seller organization).
Various business transactions/collaborations/realizations can re-use a given authorized
role name. The meaning for the role is “contextualized” by the business process artefact
and is unique that that context even though the names may be identical. To facilitate role
name re-use context schemes for role must ensure that the definitions are applicable to
multiple processes..
8. Name Use, Overlap and Collision
Concepts used in a business process may be identical or related to counterparts used to define
the information that is exchanged. Common concepts facilitate understanding provided that a
concept’s meaning and use are clearly understood by modellers and the community of users.
Following are some concepts that give rise to conflicting interpretation in business process
modelling and business information entity definition.

Business Process Name (e.g. Order)
25
- identifies various business process artefacts across multiple business process views
- identifies a business information envelope and or information body
- specified in business information header to identify the target application/process

Role Name (e.g. Importer)
- specifies the authorized role in a business transaction and/or collaboration
- qualifies a core component to create a specific business information entity
- qualifies one or both classes and/or property term in an association core component

Supporting Role Name
- identify information intended for a third party in a collaboration
- used to name a participant in a nested collaboration

Business Partner Type
- used in business processes to identify the stakeholders type
- used in documents to identify meta-data for the actual stakeholders participating in
an actual transaction

Event Name
- serves as a trigger in a business process expressed as “Begins When” and “Ends
When”
- recorded in business documents as stage in a business process

Entity Lifecycle Name
- recorded as a state of a business entity within a business process
- recoded as a status of a business transaction within a business document
The first three type of information in the above list represent CCTS defined context
categories and will likely need to be developed and managed as code lists. The need for a
separate list of “supporting role” has been questioned over time and the need for it could be
reassessed.
It is possible that the value set for event and entity lifecycle is finite and closely linked to
business transaction patterns and could become another code set to be developed.
There is a need to review the uses that these categories of meta-data are useful and to
determine if a single set of code values will suffice for the envisaged uses.
The context values appear as qualifiers of core components, property terms and associations.
These context values are being discovered by consulting the applicable column in an Excel
spreadsheet. Do these qualifiers represent a separate context scheme? Do they represent one
or three sets of qualifier categories?
The Core Component Library (CCL) includes business process names as qualifiers of core
components when required to create context specific BIEs. The qualifiers may be used with
object classes and/or property terms in ACCs or ASCCs to create ABIEs and ASBIEs.
The need to segregate the various “qualifiers” for posting to one or more of a classification
scheme for CCTS contexts remains to be evaluated and implemented if context values are to
be discovered by searching classifications schemes and coded lists.
26
9. Process and Data Model Coordination
The UMM recognizes a close relationship between a business process and the data that is
required to support a shared understanding of the purpose and status of business transactions
and collaborations.
As illustrated by the evolving UPCC specification, the meta-models for UMM and UPCC are
being integrated to permit cross-validation of the respective models. This implies that there
will be a need to coordinate changes to both the process and data models. These types of
coordinated changes are being made between groups defining RSMs, message libraries, XML
schemas and the CCL management team.
Should the BRSs be updated following UMM model development? Should the information
models (e.g. business entity, information envelope) associated with a business process be
aligned with BIEs in the CCL?
The name of the business process is one that is jointly selected by the project and TBG 14
teams using a common known business term. These names may also be used for business
entities as well ACCs in the core component library.
To support harmonization and re-use of existing values for the business process, authorized
role and supporting role contexts, a set of procedures, probably paralleling the ones
established for CCL may need to be developed and implemented by TBG. To facilitate
registration and discovery of business processes section 11 provides a draft list of meta-data
for business processes. Harmonizing and coordinating the use of this meta-data will enable
business processes to be identified consistently and thereby facilitate business process
registration, discovery and re-use.
14.
Context Schema and Value Set Requirements
The UN/CEFACT Registry technical specification, when implemented, is expected to
provide the means of registering and maintaining various code sets including context
categories12.
The UPCC defines a set of libraries for CCs and BIEs that may be used to build documents
and maintain these as document libraries in accordance with CCTS 3.0. Code lists (e.g. ISO
country codes, UN locodes, etc.) are maintained as an <<enumeration>> or a SchemaID.
Each list is to have a set of attributes identified in UMM, CCTS and Registry specification
that is applicable for a classification.
A number of classification schemes / code lists are identified in CCTS 3.0 as candidate
standards to be used for classifying and contextualizing UN/CEFACT artefacts. To date there
is no determination to what extent each of the CCTS recognized classification standards
conform to the data structure recommended in various UN/CEFACT technical specifications.
NOTE – there is a need to verify that the Registry specification has endorsed the Genericode
specification for code list (a.k.a. OASIS Code List Requirements). Furthermore there is a need for the
Registry to registry the various business process packages but these are not mentioned in version 1.3 of
the Registry specification.
12
27
The UCM requires that classification schemes be represented as a hierarchical data structure
that may require certain code lists to be restructured (see UCM example for country names13)
Following is subset of generic requirements, taken from version 1.1 of the OASIS
recommendation,14 that might form the basis for discussion to ensure alignment of
UN/CEFACT schema requirements in addition to development and maintenance of “context”
values sets.
1. The code list representation format should be a pure code list representation that is not tied to any
particular code list validation process or software
2. The code list metamodel should be expressed as a UML logical model, not just as a physical model (e.g. an
XML schema)
3. The code list format should support complex code list definitions, but it should not be complex to define
simple code lists
4. Support for multiple, alternative codes
5. Arbitrary metadata can be added at all levels in the code list representation
6. Codes are part of the metadata for the code list entries
7. Each code list has a unique identifier, independent of its individual versions
8. Documentation and annotations can be applied to definitions
9. Documentation has a language identifier, and there can be documentation in multiple language
10. Short and long names are supported
Additional the code set considerations will need to address maintenance procedures,
administration and publication media.
11.
Business Process Meta-Data Requirements
Based on the requirements that appear in the various UN/CEFACT technical specifications, it
appears that a separate column would need to be provided for the following information.
Some initial guidance is also given concerning the formulation of values in those columns.
1. Business domain/context – represented as a UUID in accordance with UCM
requirements for business context identification.
2. Business area – value taken from normative category as per CBPC. Value set
updated based on BRS or UMM worksheet for business area submitted to TBG14.
3. Process area – value taken from sub-normative category as per CBPC. This would a
stable code set or enumeration.
13
Provide URL for country example.
http://docs.oasis-open.org/codelist/cd-genericode-1.0/doc/oasis-code-list-representationrequirements-1.0.1.pdf
14
28
4. Business process name – harmonized value which originates with TBG project
group.
5. Business process description – based on “scope” statement provided in BRS, refined
based on development of UMM compliant business process model. Could be
expanded to include exceptions to avoid confusing with another model that appears
similar in intent of purpose.
6. Business process transaction name – could be omitted if a naming convention is
adopted that this name is equal to “business process name plus the qualifier “action”
or possibly “activity”
7. Business process collaboration name - could be omitted if a naming convention is
adopted that this name is equal to “business process name plus the qualifier
“management”
8. Authorized role – harmonized to conform to values in the “authorized role” context
code list. Code list to be updated if value represent a new name. Meaning and name
may need to be refined based on information provided in the submitted BRS.
9. Stakeholders – name of business partner types to be taken from a coded list
maintained by a designated business process harmonization authority (e.g. TBG14).
If there is a need to segregate “participants” from “interested” partner types this could
be done by adding a qualifier after the name to avoid development of two coded lists
with common value names.
10. Business entities – harmonized value which originates with a TBG project team and
coordinated with TBG17. Since a business entity is eventually represented as a
business document, this name may need to be revised to conform with value in the
finalized RSM.
11. Event name – required if an event triggers an action (i.e. a business transaction).
Should correspond to the name of a business process function represented in a
business use case.
12. XML schema namespace – based on the business process name, a unique prefix that
is used to designate a business process name within an XML schemas for documents
used with this business process/
12.
Business Process Library
The Buy-Ship-Pay initiative is continuing to develop business transactions models
(use cases and activity diagrams) in conjunction with TBG groups. To date the focus
has been on business processes pertinent to the supply chain as defined by the TBG1
program of work. This model is being developed using A UMM compliant modelling
tool and represents a nascent business process library.
The BSP Reference Model applies the UMM naming conventions as provided for in the
Vienna Add In and implemented in the Enterprise Architect modelling tool (a hierarchical
structure consisting of business area/process areas/business process view/business
29
transactions). The examples include instances of business transactions placed within process
areas subdivided by process areas as well as business area/process area hierarchy.
Unlike the CCL, the BSP initiative does not include a published set of procedures for
TBG participants to submit their business requirements specifications (BRS) and to
harmonize the respective use cases, activity diagrams and UMM / XMI compliant
models.
13.
Contextualizing Business Processes
Expectations exist that business processes are amenable to contextualization but specifics are
lacking on how and what aspects of a business model can be contextualized. UMM offers
some examples but these aren’t described as contextualization. For example, a nested
collaboration represents a re-usable business collaboration that is embedded in collaboration.
Business process patterns provide as set of default values that may be customized for a given
business circumstance. The business realization stereotype represents an assignment of a
defined collaboration to additional partners. But is this contextualization or re-use and does
the distinction matter?
UMM 2.0 makes provision for collaborations within collaborations (i.e. stereotype named
<<nested collaboration>> plus business process name).
The need for an analogous meta-model has not been established for business processes. To
support harmonization and re-use of existing values for the business process, authorized role
and supporting role contexts, a set of procedures, probably paralleling the ones established by
TBG 17 need to be developed and implemented by the TBG Permanent Group. Section 10
provides a draft Excel spreadsheet for to support business process values set harmonization
and re-use.
Contextualization of business processes might need to be formalized by a meta-model for
core business processes that would parallel CCTS core components and formalize the
contextualization of business processes in a manner analogous to CCTS business information
entities.
To date, the CCTS 3.0 meta-model for BIEs and qDTs is the only technical specification that
fosters the development of “contextualized”artefacts. A harmonization procedure facilitates
consistent evolution of “context” values (i.e. qualifiers) and suppresses “duplicate”
proliferation across TBG projects. The resulting qualifiers are embedded and published as
core component libraries, following quality assurance reviews by ATG and ICG.
14.
Next Steps
Circulate this discussion document to interested UN/CEFACT participants with formative
roles in developing and using the concepts and value sets related to context seeking their
input and confirmation that the excerpts included in this paper are accurate and complete.
Present this discussion paper to the TBG Steering Committee for discussion seeking
consensus of on context requirements and how these are to be fulfilled.
30
31