Embed Size (px)
Citation preview
1
Second Draft1
Business Process Project Team2
Technical Specification Document3
Draft Version 2.0 6/23/0045
6
Table of Contents7
8
! Document Introduction 29
10
! ebXML Business Process Metamodel 311
12
! Description of Metamodel Sub-groupings 513
14
! Illustrations of the Metamodel Sub-groupings 615
16
! Class Definitions 1117
18
! Scenarios for Use of the ebXML Business Process Metamodel 1619
20
! Auto Component Procurement Introduction and Example 2221
22
! Section: Auto Example UML Use Cases 2323
24
! Section: Auto Example UML Corresponding Collaborative25
Diagrams 2826
27
! Section: Auto Supply Chain Procurement Practices Not Captured28
in Current Use Cases 3529
30
2
31
The ebXML Business Process Metamodel Second Draft32
Business Process Project Team33
Technical Specification34
Draft Version 2.0 6/23/003536
37
The ebXML Business Process Metamodel38
39
Introduction4041
This document is a second draft technical specification for review by the ebXML Plenary.42
Comments are welcome. When registering your comment, please provide the following43
information:44
! Your name,45
! Your email address,46
! The document page and line number(s) associated with your comment,47
! Your comment,48
! Rationale for the comment, and,49
! Your recommended action for resolution of the issue or any recommended document50
add/change/delete modifications.51
52
Please e-mail comments to Marcia McLure, [email protected] within two weeks53
following the official posting date of June 23, 2000.54
55
This document includes the following sections:56
57
" The ebXML Business Process Metamodel Class Diagram58
" Metamodel Sub-groupings59
" Descriptions of the Metamodel Sub-groupings60
" Metamodel Sub-grouping Class Diagrams61
" Class Definitions62
" Scenarios for the Use of the ebXML Business Process Metamodel63
" Automobile Component Procurement Example64
" Issues65
66
67
Suggestions for document improvement are welcome. Thank you, in advance for your68
comments.69
70
ebXML Business Process Team71
3
72
73
The ebXML Business Process Metamodel74
75
This is the ebXML business process metamodel that more fully defines the contract/commitment76
section. This ebXML business process metamodel also enables re-usability of process77
definitions. We refer to this state of the metamodel as Version 2.0.78
79
The model consists of the following logical sub-groupings:80
81
1. Resources and Contracts (color coded in blue),82
83
2. Markets and Parties (color coded in green),84
85
3. Business Processes and Rules (color coded in yellow),86
87
4. Business Service Interfaces and Communication (color coded in purple), and the88
89
5. Information Model (color coded in brown).90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
4
The ebXML Business Process Metamodel114
Dua li ty
Bus ines s Tran s ac t ion C ons t raint
Th es e la y er s
will be d ef ined by
C ore Co m ponen ts
O rderingR ule
Mar ke tR oleT y pe
Agreem ent Ty pe
C hanges in res pons e to round one c om m ents :
Added two rec us iv e as s oc iat ions to ec onom ic res ourc e ty pe
(c las s if es and c om ponents)
Added as s oc iat ion "repres entat ion" f rom Bus ines s Ent ity t o
Inf orm at ion Ent ity
Added inheritanc e f rom Ec onom ic R es ourc eTy pe t o Bus ines s
Ent ity
Added inheritanc e f rom Partner R ole t o Bus ines s Ent ity
P ro c e ss Ca t e g o ry
C om po siteS tep
Bus ines s Proc es s D ef init ion0 ..* 0 ..*0 ..* 0 ..*
c las s if ies
r eferenc es
StepD ef init ion
1
1 ..*
1
1 ..*
F undam ental Inf orm at ion Ent it y
Dicti o na ry
Bus ines s D oc um ent
B usin e ss E ve n t0 ..*
0 ..*
0 ..*
0 ..*
res ults I n
In form a ti on En ti ty0 ..*
0 ..*
0 ..*
0 ..*
0. . *
0. . *
0. . *
0. . *0 ..1
0 ..1
0 ..1
0 ..1
repres entat ion
Bus ines s Ent it y
0. . *
1 .. *
0. . *
1 .. *
aff ec ts
0 ..1
0 ..1
0 ..1
0 ..1
repres entat ion
Bus ines s Mes s ageInterf ac e
d i rectio n
P arty T yp e
Ma rketRol e
1
0 ..*
1
0 ..*
Clas s if iesM a rket
0 ..*
0 ..*
0 ..*
0 ..*def ines
Bu sines s Ser v ic e
fu lf ills
0 .. *
1 ..*
0 .. *
1 ..*Realizes O neSideO f
Bus ines s Serv ic eInterf ac e
0.. *
0. . *
0. . *
0. . *
s upport s
A gre em en t
0 ..*
0 ..*
0 ..*
0 ..*c las s if ies
0 ..*
0 .. *
0 ..*
0 .. *
gov erns
P arty
0 ..*
0 ..*
0 ..*
0 ..*
c las sif ies
0 ..*0 ..*
0 ..*0 ..*
play s0 ..*
0 ..*
0 ..*
0 ..*
part ic ipates
0 ..*
0 .. *
0 ..*
0 .. *O ffers
0 ..*
0 ..*
0 ..*
0 ..*
ex pos esBus ines s Trans ac t ion
0 ..*0 .. *
0 ..*
dec ompos it ion0 .. *
0 ..1
0..1
0 ..1
+m a yForm0..1
ma p sT o
Bus ines s Mes s age
direc t ion : S tring
0.. *
0 .. *
0. . *
0 .. *ca rr iesdef ines
Inf orm at ionEx c hange
0 ..*
0 ..*
0 ..*
0 ..*
P artn e r Ro le
0 .. *
0 ..*
0 .. *
0 ..*
plays
0 ..*
2 ..*
0 ..*
2 ..*
oneS ideO f
1
0 ..*
1
0 ..*
To
1
0 ..*
1
0 ..*
From
Eco no m ic E ve nt
1
2
1
2
Con tra ct1
2
1
2
R es ourc e Catalog
E con o m i c Resou rce
+o wn s
Res ourc e Flow
C om m itm ent
0 ..*
0 ..*
0 ..*+ fu l f i l l
0 ..*0 ..*
1 ..*0 ..*
1 ..*
es tablish
Ec onom ic R es ourc e Ty pe
0 .. *
0. . *
0 .. *
0. . *ex pos es
0.. *0. . *
c las s if ies
0 .. *0 ..*
0 .. *
c las s if ies
0 ..*
0 .. *
0 ..*
0 .. *
c omponent0 ..*
0. . *
1. . *
0. . *
1. . *
res erv es
115
5
Metamodel Sub-groupings116
117The metamodel consists of the following logical sub-groupings:118
119
120
1. Resources and Contracts121This is a high level economic model, adapted from REA (Resources, Events, and122
Agents). It creates a very useful anchor point for the ebXML model, and establishes a123
pattern for how economic events should be transacted using this model.124
125
2. Markets and Parties126This is the part of the model that allows organizations to register themselves relative to127
the markets they perform in and the types of services they offer. This aligns with the first128
four of the seven layers of the eCO framework. Once a number of organizations have129
registered themselves, other organizations can start discovering new business partners by130
navigating among the layers of the markets and parties sub-model.131
132
3. Business Processes and Rules133This is the part of the model that describes the actual business processes that support the134
services offered by a given organization. It also describes the interactions required135
between the partners in order to obtain/perform the services offered.136
137
4. Business Service Interfaces and Communication138This is the part of the model that describes the ‘interface’ that the partners expose, against139
which the ‘opposing’ partner can interact, typically by sending business signals140
consisting of business documents. Document is a broad term that covers both complete141
documents in the traditional sense, i.e. a sales order, but also descriptions of business142
events relevant to the service obtained/performed.143
144
5. Information Model145146147148149150
6
151
Illustrations of the Metamodel Sub-groupings152
153The exact boundaries of each sub-grouping is subject to revision. The metamodel sub-groupings154
are as follows:155
156
157
1. Resources and Contracts158
Duality(f rom Logical View)
R eso urces a nd Con tracts
Agreem ent Ty pe(f rom Logical View)
Business Transaction(from Logica l V iew)
0..* 0..*0..*
decom position
0..*
Agreeme nt(f rom Logical View)
0..*
0..*
0..*
0..*cla ssi fies
0..1
0..1
0..1
+mayForm
0..1
Bus ines s Proces sD efinit ion
(from Logi ca l V iew)0..* 0..*0..* 0..*governs
BusinessEnti ty(f rom Logical View)
StepDefinition(from M a rke t )
1
1..*
1
1..*
Business Event(f rom Logical View)
0..*1..* 0..*1..* affects
0..*
0..*
0..*
0..*
r esu lt sIn
Economic Event(f rom Logical View)
ResourceCata log(f rom Logical View)
Economic Resource(from Logica l V iew)
Resou rce Flow
Commi tm ent(f rom Logical View)
0..*
0..*
0..*
+fulfill0..*
Contract(f rom Logical View)
0. .*
1..*
0. .*
1..*
estab lish
Economi c Reso urce Type(from Logica l V iew)
0..*
0..*
0..*
0..*
exposes
0..*0..*
cl assi fies
1..*
0..*
1..*
0..*
reserves
cl ass ifie s
0..*0..* 0..*
com ponent
0..*
159
7
2. Markets and Parties160161
Markets and Parties
Business Transaction(from Logical View)
MarketRoleType(from Logical View)
Party Type(from Logical View)
Market(from Logical View)
0..*0..*
0..*
0..*
0..*
0..*
defines
Economic Resource(from Logical View)
Partner Role(from Logical View)
2..* 0..*2..* 0..*
oneSideOf
MarketRole(from Logical View)
0..*1 0..*1
Classifies
Party(from Logical View)
0..*0..* 0..*0..* classifies
0..*
0..*
0..*
0..*
plays
0..*
0..*
0..*
0..*
participates
+owns
0..*
0..*
0..*
0..*
plays
BusinessService(from Logical View)
fulfills0..*
0..*
0..*
0..*
Offers
BusinessProcessDefinition(from Logical View)
0..*
1..*
0..*
1..*
RealizesOneSideOf
162163164165166167168169170171172173174175176177178179180181182183184185186
8
187
3. Business Processes and Rules188189190
B usiness P rocesses and R ules
Re-use
adressed as per
EDOC
Bu s in es s Trans action C ons tra in t
(fro m L o g i ca l V ie w)
Grouping of
exchanges wi thin
transact ion
BusinessEntity(f rom Logic al View)
Bus iness Event(f rom Logic al View)
1..* 0. .*1..* 0. .*affe cts
OCL
constraint
Bus iness Docum ent(fro m L o g i ca l V ie w)
Orde ringRule
P rocess Category
(fro m L o g i ca l V ie w)
Com pos iteS tep
S tepDefinit ion
( fro m M a rke t)
0..* 0..*0..* 0..*
resu ltsIn
Bu s in es s Proces s Defin itio n
(fro m L o g i ca l V ie w) 0..* 0..*0..* 0..*
classifies
refe re nces
1..*
1
1..*
1
Agreem ent(f rom Logic al View)
0..*
0..*
0..*
0..*
govern s
BusinessM essage
direction : Str in g
(fro m L o g i ca l V ie w)
0..*
0 ..*
0 ..*
0 ..*
carries
Business Transaction
(fro m L o g i ca l V ie w)
0..* 0..*0..*decom position
0..*0 ..10..1 0 ..1
+m ayForm
0..1
Inform ationExchange
(fro m L o g i ca l V ie w)
0..*
0..*
0..*
0..*
Bus inessService(f rom Logic al View)
0..* 1. .*0..* 1. .*R ealiz e sOn eSideO f
Bu s in es s ServiceInterfa ce
(fr om L og i ca l V ie w)
m apsTo
Partner Role(f rom Logic al View)
2..*
0..*
2..*
0..*
one SideOf
1
0..*
1
0..*
To
1
0. .*
1
0. .*From
Party(f rom Logic al View)
0. .*
0..*
0. .*
0..*
Offers
0..*
0..*
0..*
0..*
exp o ses
0..*0..*
0..*0..*
plays
191192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
9
4. Business Service Interfaces and Communication212213
Business Service Interface
Bus ines s Mes s ageIn terface
direction
( from Log i ca l View)
Bus ines s Service In terface
(from Log ica l View)
0 ..*
0 ..*
0 ..*
0 ..*
supports
Bus inessService(f rom Logical View)
Bus ines s Mes s age
direction : S tring
( from Log ica l View)
0 ..*de fines
Party(f rom Logical View)
0..*
0. .*
0..*
0. .*
exposes
0..*
0 ..*
0 ..*
0 ..*
Offe rs
Par tner Ro le
(f rom Logical View)
0..*0..* 0..*0..*
p lays
In form ationExchange
(from Log ica l View)
0. .*0..*
0. .*0..*
1
0..*
1
0..*
To
1
0..*
1
0..*
From
214215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
10
5. Information Model233
234
Information M odel
This is a p laceholder
wai ting to be replaced
or ali gned with t he core
componen ts model
Business Document(from L og ica l V iew )
Fundam ental Inform ation Entity
(from Log ica l V iew)
Dictionary(f rom Logical View)
Business Event(f rom Logical View)
Bus in es s Ent ity
(f ro m L ogica l View )
0..* 1..*0..* 1..*
affects
Information Entity(from Log ica l V iew)
0..*
0..*
0..*
0..*
0..*0..*
0..*0..*
0..1
0..1
0..1
0..1
rep resen tat io n
0..1
0..1
0..1
0..1
representa tion
235236237238239240241242243244245246247248249250251252253254255256257
11
Class Definitions258
259
Definitions of each of the classes are as follows:260
261
Agreement262An agreement is an arrangement between two parties that specifies in advance the conditions263
under which they will trade (terms of shipment, terms of payment, expectations of quotations264
and pricing, etc.) An agreement does not imply specific economic commitments.265
266
Agreement Type267An agreement type is the abstract classification of different types of agreements. Examples268
might include front-end agreements and yearly contracts.269
270
Business Document.271A business document is the description of a particular entity within a business, or the272
description of an agreement between organizations, or the description of a business event. The273
document is never the 'real' thing, just a description of it at a point in time. A business document274
is the central component of any information exchange among partner roles.275
276
Business Entity277Business Entitys are artifacts that are important in the execution of a company’s business278
processes. Business Entities undergo changes that are reflected as Business Events.279
280
Business Event281A business event is a significant change in the state of one or more entities within a business,282
e.g. the taking of an order or the release of a shipment.283
284
Business Message285A business message is a message sent between two partners. A business message fulfills the286
requirements of an information exchange.287
288
Business Message Interface289A business message interface is the description of the protocol, both functional and technical, of290
business messages targeted to business services interfaces of a partner role engaged in an291
information exchange with another partner role.292
293
Business Process Definition294A business process is a collection of business transactions between business partners and/or295
internal activities within one business. These transactions and/or activities together support the296
objective of the business process. A business process definition specifies the choreography of297
business transactions needed to complete a business process. The internal activities that may also298
be needed, are outside the scope of the ebXML business process model.299
300
Business Service301Business Services are interfaces to a business process. Each Business Service offered by a Party302
provides the ability for a trading partner to interact with that Party in some way.303
12
304
A Party or "Service Provider" offers a Business Service to "Service Consumers". Any Party can305
be both a provider and a consumer of Business Services. Example Business Services offered by a306
company that makes widgets might be: "Examine my catalogue of widgets", "Buy a widget",307
"Submit engineering change order", "Become a VAR", "Find the cheapest price on this item and308
then apply for a loan to pay based on my credit rating and ability to establish a long term309
relationship", "Initiate manufacturing corrective action".310
311
Business Service Interface.312A business service interface is the definition of how to interact with one partner role in order to313
make him/her perform a desired service. For example, a partner role can expose a business314
process interface for 'quotation service'. It will describe precisely what kind of business315
messages you need to send, what you will get back, and what you may expect to have happen as316
a result of the exchange.317
318
Business Transaction319A business transaction is a logical unit of business conducted by two or more parties. The320
market, the partner roles, and the process, are all in a definable, and self-reliant state prior to the321
business transaction, and in a new definable, and self-reliant state after the business transaction.322
In other words if you are still 'waiting' for your business partner's response or reaction, the323
business transaction has not completed. A business transaction in our model is reflected as the324
required exchange or series of exchanges of information between two (or more) partner roles in325
order to complete the transaction. For example, the exchange could consist of a request for quote326
and the return either of the actual quote, or of the confirmation that the request had been327
received. It would not make sense to have the transaction (interaction) consist of the request328
only.329
330
Business Transaction Constraint331 A business transaction constraint is a rule that guides and constrains the execution of business332
transactions within a business process.333
334
Commitment335A commitment is an obligation to perform an economic event at some future point in time.336
Commitments are fulfilled or executed by economic events. Order line items are examples of337
commitments.338
339
Composite Step340A composite step is a step composed of more than one logical step. This construct is used to341
provide greater flexibility in reusing step definitions.342
343
Contract344A contract is a mutual arrangement between parties that some actual economic exchanges will345
occur in the future. Contracts can have recursive relationships with other contracts, for example,346
yearly contracts with monthly releases and weekly or daily shipping schedules. Contracts are347
containers for collections of commitments. For example, a purchase order is a contract wherein348
the line items are commitments.349
350
13
Dictionary351The dictionary should contain data types, re-usable components, and the templates (DTD's) of352
the business documents, but not the documents themselves.353
354
Duality.355Duality is a relationship between Economic Events, where one is the legal or economic356
consideration of the other. Examples include a payment for a product or service.357
358
Economic Event359An economic event is the transfer of control of an Economic Resource from one party to another360
party. Examples would include sale, cash-payment, shipment, and lease.361
362
Economic Resource363An economic resource is a quantity of something of value that is under the control of an364
enterprise. Examples are cash, inventory, labor service and machine service.365
366
Economic Resource Type367An economic resource type is the abstract classification or definition of an Economic Resource.368
For example, in an ERP system, ItemMaster or ProductMaster would represent the Economic369
Resource Type that abstractly defines an Inventory Item or Product. Economic Resource Types370
may have recursive relationships, so that for example broad classifications like "product" could371
group smaller classifications like "product family", which in turn could have as members the372
specific "product masters" with SKU numbers.373
374
Fundamental Information Entity.375A fundamental information entity is in essence a data type. In business contexts we might need376
many more 'data types' with business semantics beyond the standard data types of 'int', float' etc.377
This class is a placeholder and will be further defined through discussions between the business378
process project team and the core components project team.379
380
Information Entity.381An information entity is a primitive or complex data structure. We haven't defined this yet, but382
it may be that the difference between a data structure and an information entity is that the383
information entity also contains business rules about the data.384
This class is a placeholder and will be further defined through discussions between the business385
process project team and the core components project team.386
387
Information Exchange.388An Information Exchange is a set of business messages exchanged between two partners,389
related to a specific a specific business transaction.390
391
Market.392A market is a 'meeting place' where organizations and individuals can exchange services or393
products. A market is defined in terms of the types of services and products that are likely to be394
exchanged. The "Yellow Pages" in a telephone book is an example of classifications of products395
and services, e.g. 'Legal Services', or 'Air condition products'. A person can then anticipate the396
existence of a 'Legal Services' market and an 'Air Conditioning' market.397
14
398
Market Role399A Market Role defines a conceptual grouping of Business Services that a Party can provide in a400
Market.401
402
Market Role Type403Market Role Types define and classify Market Roles.404
405
Ordering Rule.406An ordering rule describes the interdependencies (i.e. ordering) of business messages within an407
information exchange.408
409
Partner Role410A partner role is the role a party plays in a specific business process or business transaction.411
412
Party413A party is any organization or individual that participates in exchanges of products or services in414
one or more markets. A party is established first as an absolute entity and then in terms of the415
roles it plays in a market and in terms of the role it plays in a business transaction.416
417
Party Type.418A party type is a broad classification of the kind of organization or individual. Examples are419
'University', 'Corporation', 'Individual', 'Government'.420
421
Process Category.422A process category is a broad classification of business processes. At a macro level this423
classification could be like the "Yellow Pages" classification of services. At a finer level,424
processes could be classified to more functional groupings such as 'quotation', 'scheduling',425
The metamodel does not constrain the kinds of classification of processes.426
427
Resource Catalog428A resource catalog is basically a navigable guide to offered products and services (Economic429
Resource Types). It is the market equivalence of a company's product catalog. It would be430
intended for narrowing down the particular kind of product or service you are looking for,431
hopefully leaving you with multiple possible sources for that product or service.432
433
Step Definition434A step definition defines the steps in a business process. Step definition allows for the435
decomposition (and reuse) of steps and makes the interdependencies between steps explicit. Step436
interdependencies include predetermined step sequencing, and (implicit) business rules. A step437
definition always defines either an action taken by a single partner role or an interaction among438
partner roles.439
440
441
442
443
444
15
445
446
447
448
449
450
451
452
453
454
455
456
457
16
458
459
Scenarios for Use of the ebXML Business Process Metamodel.460461
The objective of ebXML is to “create a single global electronic market” that enables462
organizations to find each other and conduct business together through the exchange of463
information in the form of XML based business documents.464
465
From this statement we can glean the following layers of importance to the Business Process466
Metamodel:467
468
It must be support the definition of a “market”, the definition of processes for “conducting469
business”, the definition of required “exchanges of information”, and the definition of the470
“business documents” themselves.471
472
Therefore the following LAYERS of the business process must be supported by the metamodel:473
474
A. Market (for categorizing and organizing parties and their processes/services)475
B. Business Process (for conducting business)476
C. Information Exchange (in support of a business process)477
D. Business Document (for structuring information)478479480
Note: There is an alignment of these layers to the packages of the metamodel.481
The alignment is as follows:482
• The market layer uses the ‘Markets and Parties’ package and the economic resource483
part of the “Resources and Contracts” package.484
• The Business Process layer uses the “Business Process and Rules” package and the485
“Resources and Contracts” package.486
• The “Information Exchange” layer uses the “Business Information Model ” and the487
“Business Service Interface” packages.488
• The “Business Document” layer uses the business document and information entity489
part of the “Business Information Model” package.490
491
We also divide the scenarios for usage of the metamodel into the following ‘STAGES’:492
493
1. Designing/Describing markets, business processes, information exchanges and business494
documents.495
2. Implementing system to execute in conformance with described business processes,496
information exchanges and business documents497
3. Registering markets, business processes, information exchanges and business documents.498
4. Discovering markets, business processes, information exchanges and business499
documents.500
5. Actual execution of a business process through the exchange of business documents.501
502
503
504
17
505
So we can organize the scenarios as follows:506
507
5081.Design/Describe
2.Implementation
3.Register
4.Discover
5.Execution
A: Market Market-Design N/A Market-Registration
Market-Discovery.
N/A
B: BusinessProcess
Process-Design Process-Implementation
Process-Registration
Process-Discovery
Process-Execution
C: InformationExchange
Exchange-Design Exchange-Implementation
Exchange-Registration
Exchange-Discovery
Exchange-Execution
D: BusinessDocument
Document-Design
Document-Implementation
Document-Registration
Document-Discovery
Document-Execution
509In the following we describe, for each of the table entries above, how the user and/or a tool510
provider will make use of the metamodel, and how each of the other pieces of the ebXML511
architecture are related.512
513
For ease of understanding, we divide this discussion into the following distinct types of514
scenarios.515
‘From scratch design’ – An organization designing, implementing, registering a brand new516
market and process.517
‘Conversion’ – An organization converting an existing market and process design, and adjusting518
an existing implementation.519
“Discovery and adaption” – An organization discovering an existing party and process and520
adapting their existing implementation to interoperate.521
“Actual communication” – Two organizations actually conducting business by exchanging522
messages.523
524
Brand new business model.525
526
This scenario assumes for simplicity that none of the parts of the business model are yet in the527
repository and that the organization(s) designing it are willing to retrofit their applications to fit528
the new model.529
530
The stages the organization would go through are:531
532
1. Design: (For this stage the organization would either use established modeling tools and533
convert the output to DTD/XML compliant with the ebXML metamodel, or they would534
use newer lightweight ebXML front end tools to produce ebXML compliant DTD/XML535
directly)536
a) Market-Design: Determine and describe the market in terms of its domain and it’s537
parties.538
b) Process-Design: Determine and describe the business process in terms of its539
partner roles and business transactions540
c) Exchange-Design: Determine and describe each business transaction in terms of541
its required messages exchanged.542
18
d) Document-Design: Determine and describe each business document in terms of543
its attributes544
545
2. Implementation. (This may be accomplished using new lightweight adaptor tools to front-546
end their applications)547
a) Market implementation is not relevant548
b) Process-Implementation: Design and implement a Business Service Interface that549
covers all the business transactions specified in 1.b. above.550
c) Exchange-Implementation: Design and implement Business Message Interfaces551
that cover all the Information Exchanges specified in 1.c. above.552
d) Document-Implementation: Design and implement mappings from the documents553
specified in 1.d. above.554
When this is working they would register the market, party, partner-role, business555
process, information exchange and business documents and register themselves as556
capable of supporting this new model.557
558
3. Registration: Registration takes place by using a web-based front end to the ebXML559
repository and/or sending a model compliant xml file using the ebXML message560
exchange.561
a) Market-Registration: Register each market and party specified in 1.a.562
b) Process-Registration: Register business process specified in 1.b. and its associated563
business transactions and business rules.564
c) Exchange-Registration: Register for each business transaction specified in 1.b. the565
required information exchanges as specified in 1.c.566
d) Document-Registration: Register each business document specified in 1.d. above.567
568
The process and site-implementation for this “brand new” business process is now ready for569
business, next step would be “discovery and adaptation” by potential business partners (see570
below)571
572
Conversion573
574
This scenario assumes for simplicity that the company already has a complete model design575
described in some other format and protocol.576
577
The stages the organization would go through are:578
579
1. Design. (or in this case convert the existing explicit or implicit design)580
a) Market-Design: Extract and convert from existing model the market in terms of581
its domain and it’s parties. This conversion should yield an ebXML metamodel582
compliant XML based model ready for registration.583
b) Process-Design: Extract and convert from existing model the business process in584
terms of its partner roles and business transactions. This conversion should yield585
an ebXML metamodel compliant XML based model ready for registration.586
19
c) Exchange-Design: Extract and convert from existing model each business587
transaction in terms of its required messages exchanged. This conversion should588
yield an ebXML metamodel compliant XML based model ready for registration.589
d) Document-Design: Extract and convert from existing model each business590
document in terms of its attributes. Since many “libraries” of standard based591
document designs already exist, and since the metamodel here is very flexible, it592
is anticipated that little or no conversion be needed for standards based593
documents. Rather there would just be a qualification attribute of the exchange-594
design in 1.c. above as to which of several standards the documents involved595
belong to.596
597
2. Implementation. (This may be an activity of creating wrappers around the existing system598
to enable the sending and receiving of messages).599
a) Market implementation is not relevant600
b) Process-Implementation: Design and implement a Business Service Interface that601
covers all the business transactions specified in 1.b. above.602
c) Exchange-Implementation: Design and implement Business Message Interfaces603
that cover all the Information Exchanges specified in 1.c. above.604
d) Document-Implementation: Design and implement mappings from the documents605
specified in 1.d. above.606
607
3. Registration: Registration takes place by using a web-based front end to the ebXML608
repository and/or sending a model compliant xml file using the ebXML message609
exchange.610
a) Market-Registration: Register each market and party specified in 1.a.611
b) Process-Registration: Register business process specified in 1.b. and its associated612
business transactions and business rules.613
c) Exchange-Registration: Register for each business transaction specified in 1.b. the614
required information exchanges as specified in 1.c.615
d) Document-Registration: Register each business document specified in 1.d. above.616
Since your document may already be specified in another industry standard617
protocol, you may register just a hyper-link to where the specification is found in618
an ebXML compliant format.619
620
The process and site-implementation for this “converted” business process is now ready for621
business, next step would be “discovery and adaptation” by potential business partners (see622
below)623
624
Discovery and adaption625
626
This scenario assumes for simplicity that an organization can find a partner with an appropriate627
process and only needs to make adjustments to its applications in order to ‘play’. In this scenario628
the discovery comes first (so we have changed the sequence, but left the numberings intact as a629
reference back to the matrix). Once discovery has yielded an acceptable, process, information630
exchange, and document structure, the organization has only to adapt its applications.631
632
20
The stages the organization would go through are:633
634
4. Discovery: (This is done using web frond ends to the ebXML repository, or by sending635
XML ‘query’ documents through the ebXML message facility).636
a) Market-Discovery: Using appropriate keywords and wildcards find the market of637
interest. Starting from the market find possible parties who may be possible638
partners.639
b) Process-Discovery: Starting from each possible party discover his/her role in640
various processes. Find a process that matches the business transactions you need641
to transact.642
c) Exchange-Discovery: Starting from each business transaction discover if you are643
capable of producing and consuming the required information exchanges in the644
specified protocols.645
d) Document-Discovery: Starting from each information exchange, discover if you646
are capable of mapping into and out of the specified business documents.647
648
1. Design. Not applicable, in essence this organization is using a design already done by649
another organization.650
a. Market design was discovered in 4.a. above651
b. Process design was discovered in 4.b. above652
c. Exchange design was discovered in 4.c. above653
d. Document design was discovered in 4.d. above654
655
2. Implementation. (This may be an activity of creating wrappers around the existing system656
to enable the sending and receiving of messages).657
a. Market implementation is not relevant658
b. Process-Implementation: Design and implement a Business Process Service that659
covers all the business transactions specified in 1.b. above.660
c. Exchange-Implementation: Design and implement Business Message Interfaces661
that cover all the Information Exchanges specified in 1.c. above.662
d. Document-Implementation: Design and implement mappings from the documents663
specified in 1.d. above.664
665
3. Registration: Not required unless you want to establish a more formal ‘trading partner666
agreement’667
a. Market registration already done668
b. Process registration already done669
c. Exchange design may involve the registration of your business process interface670
to handle your end of the process. This may be validated against the business671
processes already registered for handling the other end.672
d. Document registration may involve the registration of your document handler673
interfaces to handle the incoming and outgoing messages. At this point it may be674
possible to send a series of “test messages” that traverses the whole process and675
proves that the two parties can in fact live up to the implicit or explicit ‘trading676
partner agreement’.677
21
Note: The described kind of registration of business process interfaces and document678
handler interfaces may not initially be part of ebXML scope, rather – initially - an eCO679
style self-registration on your own site might be workable.680
681
This business partner is now ready to do business with the partner/process previously registered.682
683
Actual communication684
685This scenario assumes that we have already designed, registered and implemented as per above.686
687
1. Design: Already done above688
2. Implementation: Already done above689
3. Discovery: Already done above690
4. Registration: Already done above691
5. Execution: The model drives the execution in the sense that the business transaction692
sequence within a process is (optionally) specified, and the message exchange sequence693
within a business transaction is (optionally) specified. So one could envision an694
implementation that actually accesses the ebXML repository to figure out what needs to695
happen next. More likely the parties implement their ebXML process compliant business696
process interfaces, and the exchanges happen directly between these business process697
interfaces, using message formats prescribed in the repository. These business process698
interfaces may themselves handle the mapping into or out of the organizations699
applications, or may interact with “wrappers” specifically designed for this purpose. In700
either case, the ebXML end of the mapping is prescribed by the registered documents.701
702
703
704
705
706
22
707
Automobile Component Procurement Example708
709
Introduction710
711
This is the first ebXML-BP metamodel example. More will come, including some that are much712
simpler than this one, which is deliberately complex in order to test the metamodel.713
714
This example is not "final". The intention is for this example to develop along with the ebXML715
project until it is fully populated with functional test data, and also to be accompanied by several716
other examples illustrating different scenarios.717
718
The reasons for starting with this particular process include:719
• it is a supply chain direct-component procurement example, instead of the usual office supply720
purchase;721
• the business practices cover most of the metamodel;722
• the business practices are well documented by an industry-wide group, AIAG (Automotive723
Industry Action Group);724
• the business practices are similar to supply chain relationships in other industries, e.g.725
appliances and retail.726
727
Example Sections728
729
1. UML Use Cases, with no reference to ebXML metamodel classes or technology.730
2. UML Collaboration Diagrams mapping the use cases to the current ebXML metamodel731
classes. (Note: not every detail of the use cases is shown in collaboration diagrams. Some732
sections were omitted as being repetitive, with no new mappings.)733
3. Uncaptured auto supply chain procurement practices - not yet included in the current use734
cases.735
23
736
Use Cases - Overview737738
739740
24
Contract Formation741
742743744745
25
Scheduling746747
748749
26
Delivery750751
752753
27
Payment754755
756757
28
Corresponding Collaboration Diagrams758759
In each rectangle, an object name is followed by an ebXML metamodel class name, e.g. Object: Class.760761
Overview762763
764
29
Contract Formation Step 1765766
767768769770
30
Contract Formation Step 2771772
773774
31
Contract Formation Final Step775776
777
32
Scheduling Final Step778779780
781
33
Delivery Final Step782783
784
34
Payment Final Steps785786
787788789790791792
35
Auto procurement practices not captured in current use cases793
794
1. Preliminary trading partner agreements may be formed before contracts are negotiated.795
These agreements may not carry any economic commitments. They would be mapped to the796
Agreement class in the ebXML metamodel.797
2. Intermediate consignees may be used in the Delivery use case, to pool components before798
delivery to the point of production, and/or to perform outside services.799
3. Variations in delivery authorization include regular purchase orders, delivery schedules,800
sequenced delivery schedules, and electronic Kanbans or JIT pull signals.801
4. Variations in payment authorization include evaluated receipts settlement, pay on802
production, pay to the ASN, and invoices.803
5. Variations in payment (to be researched).804805806807
