United Nations Centre for Trade Facilitation and Electronic
Business
DRAFT
1
2
3
4
5
6
7
UN/CEFACT
8
Business Document Header
9
Technical Specification 3.0
10
ODP step 3 Working Draft
11
Revision [A7]
12
13
14
15
16
17
18
19
16 November 2010
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
20
Abstract
21
[Ed Note: Create chapter 5 and after first, then back to this clause within ODP3]
22
23
This UN/CEFACT <…> specification defines <…>. It is based on <…>. This
specification will be used by UN/CEFACT to <…>. It will also be used by <…>.
24
Page 2
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
25
Table of Contents
26
Abstract
27
Table of Contents .............................................................................................3
28
1
Status of This Document ..........................................................................6
29
2
SBDH Project Team Participants .............................................................7
30
2.1
Acknowledgements .....................................................................7
31
2.2
Disclaimer ...................................................................................7
32
2.3
Contact Information .....................................................................8
33
3
34
3.1
Summary of Contents of Document ............................................9
35
3.1.1
Notation ......................................................................................9
36
3.2
Audience ...................................................................................10
37
3.3
Related Documents...................................................................10
38
3.3.1
Normative Reference ................................................................10
39
3.3.2
Non-Normative Reference ........................................................10
40
4
41
4.1
Goals of the Technical Specification .........................................11
42
4.2
Requirements ............................................................................11
43
4.3
Conformance.............................................................................11
44
4.4
Caveats and Assumptions ........................................................12
45
4.5
Guiding Principles .....................................................................12
46
5
47
5.1
Background ...............................................................................13
48
5.2
Solution .....................................................................................13
49
5.3
Business Opportunity and Benefits of the SBDH ......................14
50
5.4
Scope ........................................................................................15
51
52
2
Introduction ..............................................................................................9
Objectives ..............................................................................................11
Overview ................................................................................................13
Entity scope .................................................................................................16
5.4.1
16
Page 3
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
53
5.4.2
Syntax scope.............................................................................16
54
5.4.3
Layered scope...........................................................................16
55
Extension point from previous version .........................................................16
56
5.5
16
57
6
58
6.1
Constraints on SBDH ................................................................18
59
6.2
Principle of SBDH .....................................................................18
60
6.3
Services ....................................................................................19
61
6.4
Routing ......................................................................................19
62
6.4.1
Bi-lateral aspect ........................................................................19
63
6.4.2
Multi-lateral aspect ....................................................................20
64
6.4.3
Multi-partner environment .........................................................20
65
6.5
Packaging .................................................................................21
66
6.6
SBDH with the payload encryption ............................................22
67
6.7
Layered Processing Model ........................................................23
68
6.8
Traditional Approach - carry entire information on a message - 24
69
6.9
New Approach –information distribution method .......................24
70
6.10
Conceptual Metamodel .............................................................25
71
6.10.1
Document Profile (旧名 Identifier) .............................................26
72
6.10.2
Manifest ....................................................................................26
73
6.10.3
Routing .....................................................................................27
74
6.10.4
Processing ................................................................................27
75
7
76
7.1.1
Use case ...................................................................................28
77
7.1.2
Actor (business participant) ......................................................29
78
7.2
Use case description .................................................................29
79
7.2.1
Use Case Elaboration ...............................................................31
80
7.2.2
Use Case Sample 1 - Traditional approach with bi-lateral - ......33
81
7.2.3
Sample Use Case 2 - Reference approach with Bi-lateral – .....34
SBDH Convention ...............................................................................18
Use Case Analysis .................................................................................28
Page 4
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
82
7.2.4
Extension of reference approach to multi-lateral.......................36
83
7.3
Work Flow Analysis ...................................................................36
84
7.3.1
Work Flow of Reference Model.................................................38
85
8
86
8.1
Document Profile.......................................................................40
87
8.2
Manifest ....................................................................................42
88
8.3
Routing ......................................................................................42
89
8.4
Processing ................................................................................45
90
Glossary
50
91
8.5
Appendix A SBDH XML Schema ..............................................51
92
8.6
Appendix B XML Sample Instance ............................................51
93
94
8.7
Appendix C Business Message Template ..Error! Bookmark not
defined.
95
8.8
Appendix D SBDH Adaption Model <informative> ....................52
96
Disclaimer …… ..............................................................................................54
97
Copyright Statement.......................................................................................55
Date Elements Elaboration.....................................................................40
98
99
Page 5
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
100
1 Status of This Document
101
[Ed Note: Create chapter 5 and after first, then back to this clause within ODP3]
102
103
104
105
106
This UN/CEFACT technical specification has been developed in accordance with the
UN/CEFACT/TRADE/R.650/Rev.4/Add.1/Rev.1 Open Development Process (ODP)
for technical specifications. The Standard Business Document Header (SBDH)Team
is developing it for Internal Review.
107
108
This technical specification contains information to guide in interpretation or
implementation.
109
Specification formatting is based on the Internet Society’s Standard RFC format.
110
Distribution of this document is limited to SBDH project teams.
111
This version: 3.0.Daft A of 2010/09/01
112
Previous version: 1.3 DRAFT 2004/06/04
113
114
This document may also be available in these non-normative formats: XML, XHTML
with visible change markup. See also translations.
115
116
Hereinafter, this specification abbreviates and inscribes the Standard Business
Document Header as SBDH.
117
118
Copyright © 2010 UN/CEFACT, All Rights Reserved. UN liability, trademark and
document use rules apply.
119
120
Page 6
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
121
2
BDH Project Team Participants
122
[Ed Note: Create chapter 5 and after first, then back to this clause within ODP3]
123
124
125
126
We would like to recognize the following for their significant participation in the
development of this United Nations Centre For Trade Facilitation and Electronic
Business (UN/CEFACT) Business Document Header technical specification.
127
WGChair
Mark Crawford
128
Project Team Leader
Shingo Sakaguchi
129
NEC Cooperation
Lead Editor
Shigehiro Shimano
130
SAP
NEC Cooperation
Contributors
Michael Rowell
Oracle
Scott Hinkelman
Oracle
Serge Cayron
Jostein Frømyr
EdiSys
Martin Forsberg
Ecru Consulting
131
132
2.1 Acknowledgements
133
134
2.2 Disclaimer
135
Page 7
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
136
137
138
139
The views and specification expressed in this technical specification are those of the
authors and are not necessarily those of their employers. The authors and their
employers specifically disclaim responsibility for any problems arising from correct or
incorrect implementation or use of this technical specification.
140
2.3 Contact Information
141
ATG Chair:
142
143
BDH Project Leader:
Shingo Sakaguchi, NEC Cooperation, sakaguchisxb@zx.necst.nec.co.jp
144
Lead Editor:
Shigehiro Shimano, NEC Cooperation,
145
Mark Crawford, SAP, mark.crawford@sap.com
s-shimano@bu.jp.nec.com
146
147
Page 8
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
148
3 Introduction
149
[Ed Note: Create chapter 5 and after first, then back to this clause within ODP3]
150
151
3.1 Summary of Contents of Document
152
This specification consists of the following Sections and Appendices.
153
Abstract
Informative
Table of Contents
Informative
Section 1: Status of this Document
Informative
Section 2: Project Team
Informative
Section 3: Introduction
Informative
Section 4: Objectives
Informative
Section 5: <non normative overview>
Informative
Sections 6 through XX: <Normative Sections>
Normative
Section X: Glossary
Normative
1. Notation
154
155
156
157
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
specification, are to be interpreted as described in Internet Engineering Task Force
(IETF) Request For Comments (RFC) 2119.1
158
Wherever xsd: appears in this specification it refers to a construct taken from one of
159
the W3C XML Schema recommendations. Wherever ccts: appears it refers to a
160
construct taken from the UN/CEFACT Core Components Technical Specification.
161
Example – A representation of a definition or a rule. Examples are informative.
162
<Note> – Explanatory information. Notes are informative.
Key words for use in RFCs to Indicate Requirement Levels - Internet Engineering Task Force, Request For
Comments 2119, March 1997, http://www.ietf.org/rfc/rfc2119.txt?number=2119
Page 9
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
163
164
165
166
<R n> – Identification of a rule that requires conformance. Rules are normative. In
order to ensure continuity across versions of the specification, rule numbers are
randomly generated. The number of a rule that is deleted will not be re-issued. Rules
that are added will be assigned a previously unused random number.
167
Courier – All words appearing in bolded courier font are values, objects or
168
keywords.
169
When defining rules, the following annotations are used:
170
< > = optional
171
< > = variable
172
| = choice
173
3.2 Audience
174
The audience for this UN/CEFACT – SBDH Technical Specification is:
175
176
177
178

All organizations that manage infrastructure operations and business
processes, for various functional areas (e.g. ordering, invoicing, planning,
or financial) which create, route and process standard business
documents can benefit from the use of the SBDH.
179

UN/CEFACT Forum participants
180
181
3.3 Related Documents
2. Normative Reference
182
183

Core Components Technical Specification (CCTS) 3.0
184

Data Type Catalogue (DTC) 3.0
185

UN/CEFACT Modeling Methodology (UMM) Base Module 2.0
186

UN/CEFACT Modeling Methodology (UMM) Foundation Module 2.0
187

XML Naming and Design Rules (XML NDR) 3.0
188

UN/CEFACT Context Methodology (UCM) 1.0 (Draft)
189
3. Non-Normative Reference
190
191

UML 2
Page 10
SBDH 3.0 Draft A2 ODP Step 3
192

193

194

11 November 2010
Business Message Template (BMT) 1.0
195
4 Objectives
196
[Ed Note: Create chapter 5 and after first, then back to this clause within ODP3]
197
198
4.1 Goals of the Technical Specification
199
200
201
This technical specification has been developed to provide for a standard way to
facilitate the exchange of business documents between business partners. It can be
employed for business documents to be routed, processed or other operations by
202
applications or services.
203
204
205

Define SBDH data elements suit as for both bi-lateral and multi-lateral
interface.
206

Define collaboration framework between SBDH and a service registry
207
208
209
4.2 Requirements
210
211
Users of this specification should have an understanding of basics data modelling
concepts and basic information exchange concepts.
212
4.3 Conformance
213
Designers of <…> in governments, private sector, and other standards organizations
214
215
216
217
218
external to the UN/CEFACT community have found this specification suitable for
adoption. To maximize reuse and interoperability across this wide user community,
the rules in this specification have been categorized to allow these other
organizations to <…> while allowing for discretion or extensibility in areas that have
minimal impact on overall interoperability.
219
220
221
Accordingly, applications will be considered to be in full conformance with this
technical specification if they comply with the content of normative sections, rules
and definitions.
Page 11
SBDH 3.0 Draft A2 ODP Step 3
222
223
11 November 2010
Rules in categories <…> can not be modified. Rules in categories <…> may be
tailored within the limits identified in the rule and the related normative text.
Conformance SHALL be determined through adherence to the
content of the normative sections and rules. Furthermore each rule
is categorized to indicate the intended audience for the rule by the
following:
Rule Categorization
ID Description
1 Rules which must not be violated by individual organizations
else conformance and interoperability is lost – such as named
types.
<R
B998>
2 Rules which may be modified by individual organizations while
still conformant to the <...> structure – such as <...>.
1
3 Rules which may be modified by individual organizations while
still conformant to agreed upon data models – such as the use
of <...>
4 Rules that if violated lose conformance with the UN/CEFACT
data/process model – such as <...>
5 Rules that relate to <...> that are not used by UN/CEFACT and
have specific restrictions on their use by other than
UN/CEFACT organizations.
6 Rules that relate to <...> that are determined by specific
organizations.
7 Rules that can be modified while not changing <...>.
224
4.4 Caveats and Assumptions
225
<As appropriate>
226
4.5 Guiding Principles
227
228
The following guiding principles were used as the basis for all rules contained in this
specification.
229

<As Appropriate>
230
231
Page 12
SBDH 3.0 Draft A2 ODP Step 3
232
11 November 2010
5 Overview
233
234
[Ed Note: any statement related with Unified Business Agreements and Contracts (UBAC) and
235
236
237
238
This specification defines the business document header (SBDH), a header
information in business document level, for which is exchanged in standard way by
business partners. This header information will enable any applications or services
determine the logical routing requirements and/or the logical processing
239
240
241
242
243
requirements of a business document. In fact, The SBDH is useful at the business
application and middleware levels to provide for the routing and identifying of
business documents. The SBDH can enable this both internal and external routing,
eliminating the need to understand the entire message and process entire business
documents. [Ed. Note – we need something that supports this sentence]
regal matter will remove from this version of SBDH specification]
244
245
5.1 Background
246
247
Nowadays a number of enterprises can connect each others electronically by
means of globally matured internet infrastructure; moreover, a lot of enterprises
248
249
250
251
252
253
achieve their business on that environment individually. However, it is difficult
to collaborate with other enterprises due to accomplish business collaboration
among them electronically because most of them has developed own system
regardless taking account of system collaborations to the others. Obviously, the
collaborations will have difficulty by lacking of interoperability in connecting
individual syntaxes and semantics of business documents.
254
5.2 Solution
255
SBDH is designed for facilitation of business collaborations among enterprises
256
257
258
259
260
261
262
and / or governments by achieving system collaboration based on business
documents interoperability. For achieving this, it is necessary for each system
to interpret a syntax and semantic of the business document. Services or
applications will help such interpretation within business transactions. SBDH
will provide to lead proper services or application by its routing and processing
information along with business documents due to systems collaboration.
Functionality of those services or application depicted in below figure 1.
Page 13
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
Identification of
Document
[by indication]
Process of
Document
Route of document
263
264
Figure 1 Conceptual activities due to applications or a services by information of SBDH
265
The SBDH which will enable integration of documents between
266
・internal applications
267
・enterprise applications
268
・business-to-business infrastructure
269
・services on a cloud
270
・some combination of the above
271
272
Consequently, the SBDH information will enable any applications or services
determine the logical routing requirements and/or the logical processing
273
requirements of a business document.
274
5.3 Business Opportunity and Benefits of the SBDH
275
276
277
278
279
Although routing and processing instructions are not necessarily an integral part of a
document, use of the SBDH will allow organizations, with applications which are not
yet fully process-centric, to take part in the process-centric approach and avoid
wasted effort in developing customized routing and processing scenarios for each
category - of business data.
280
281
Trading Partner organizations using different communication and integration
approaches will find the SBDH a benefit since the business data payload will contain
282
283
the information needed by the communication software to route and process this
data in a standard way.
284
285
286
287
288
289
290
Operational decisions can be made by accessing the information in the SBDH and
using that information to discover by which process context the business data should
be driven. Routing and processing of SBD is facilitated regardless of whether all
applications use a document driven, application programming interface (API), or
agent approach. The use of logical parameters in the SBDH will minimize Trading
Partner relationship management in both the originating and receiving organizations
since the physical parameters can be derived from the values in the document.
Page 14
SBDH 3.0 Draft A2 ODP Step 3
291
11 November 2010
5.4 Scope
292
293
294
295
296
297
298
299
The BDH is limited to
business document header
information within a business
document message. It does
not address the business
document content, or the
message layer header, or
300
301
302
303
the transport layer. It is
agnostic as to the binding
used. It contains all of the
attributes necessary to
304
support multiple Message and Transport Layers.
305
5.4.1 Transport Layer
306
307
The transport layer header deals with communications protocols and physical
addresses which are outside the scope of this technical specification.
308
309
310
Authentication information that is not for the business documents but for application
or services due to communication or translation to a business document is also
outside the scope of this technical specification.
311
5.4.2 Message Layer
312
313
314
The message layer is typically a message envelope and protocol that provides
intermediaries in multi-hop environments. It also supports faults. It is outside the
scope of this technical specification.
315
5.4.3 Document Layer
316
317
318
319
320
The document layer consists of the business document header and the business
document content. The business document content is outside the scope of this
technical specification. However, the Business Document Header may contain
information such as context to better understand and process the business
document content.
321
5.4.3.1Business Document Header
322
The BDH contains processing support :
323
324
- The routing of business documents from one point to another. This refers to both
the transfer of information from an external originator to receiver as well as from one
Page 15
SBDH 3.0 Draft A2 ODP Step 3
325
326
11 November 2010
intermediate application or service to another. Information in the SBDH can help
ensure that a document gets to the correct recipient.
327
328
[Ed. Note – need to think about how to better say the bullet to address
the multi-hop aspect]
329
330
331
[Ed. Note – does it define the details of the routing by specifying the
hops that are supposed to happen, or does it collect the statistics of the
hops that have actually occurred, or some combination?]
332
333
[Ed Note – There is an issue around multi-hop business processes and
if that belongs in the SBDH or the ASN]
334
335
336
[Ed. Note - As we move to cloud and look at smaller and smaller
messages we have to somehow maintain the state of the message and
the state of the data. Is this a wrapper or body issue? ]
337
338
339
340
341
- The simplified processing of documents.
Processing refers to taking action on data, for example transforming it
from one format into another. Information in the SBDH can reduce the
effort required to determine the correct processing action.
5.4.4 Business Entity Scope
342
343
The BDH provides the semantic information needed for the routing to the
ultimate end point (UEP), processing and business domain context of
344
345
Business Document Message. The SBDH can optionally provide service and
correlation information, at the business domain level.
346
5.4.5 Syntax scope
347
348
The BDH will not restrict the syntax used for the business document message –
to include XML, EDI (EDIFACT or X12 base), ASN1 or any other syntax.
349
Although the BDH is agnostic as to the business document message syntax,
350
351
the BDH itself is expressed in xml syntax, defined in an xml schema that is fully
conformant to the UN/CEFACT XML NDR.
352
5.4.6 Layered scope
353
5.5 Extension point from previous version
354
355
356
357
In the previous version of the SBDH, all the information relating to SBDH will be
loaded on a business message in every business transactions. In this version,
BDH information is controlled by distributed environments in two. One
environment is as same as previous environment so the partial information will
358
be carried by the business message. Another environment is a registry and
Page 16
SBDH 3.0 Draft A2 ODP Step 3
359
360
361
362
363
364
365
366
11 November 2010
repository where the rest of information has been stored before a business
transaction is executed, and nodes such as communicator, translator, or
intermediary will take SBDH information indirectly by way of registry and
repository for to accomplish those roles instead of taking SBDH information
from the message directly. Retrieving its information from the registry and
repository, those nodes will use pointers to access of the registry and
repository objects. In this specification defined such a retrieving manner and
entities.
367
Page 17
SBDH 3.0 Draft A2 ODP Step 3
368
6 BDH
369
6.1 Constraints on BDH
11 November 2010
Convention
370
371
When using the BDH, the following constraints apply to the values provided in
the header.
372

Independence from proprietary routing rules.
373
374

Location transparency in all except the ultimate end point(UEP) facing functions

Addressing transparency in all except the UEP facing functions
375
376

All proprietary semantics, syntax, and formats must be transformed into interoperable
377

semantics and syntax.
Protocol independence in all except the UEP facing functions.
378
6.2 Principle of BDH
379
380
The following table identifies the principles used to decide what kind of information is
stored in the SBDH, and what is not.
IN
OUT
Information known at the time of creation
of the SBD by the Business Data
Creation Application (BSCA) or
Translator / Parser. e.g., SBD type.
Information that can be known only at the
time a message is sent. e.g., Transport
Message Id.
Logical information that may be used to
identify relevant physical information.
e.g., partner name and role.
Physical information useful for
configuring the physical message
transfer. e.g., channel information of
partner such as protocol, port, etc. This
physical information is to be extracted
out of some profile, such as an OASIS
CPP/A using the logical information
provided.
Logical information that be used to route
the document to specific external
applications or services.
Physical information identifying an
external application such as its URL.
Logical Information that may be used to
identify specific internal applications to
services from where the document
originated.
Physical information identifying a specific
internal application such as its IP
address.
381
Page 18
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
382
6.3 Services
383
384
385
386
A service provides suitable solution to the customers, initiators / receivers, who
exchange business documents. Generally, a service will have functionality such as
creating a proprietary business document, transforming the business document from
proprietary syntax to a standard syntax, or deliver it to specific receiver properly.
387
In the SBDH, “service” is:
388
389
・A kind of package of functionality, which is defined by standards
organizations or by members of a collaboration community.
390
391
392
393
・A software as a service in a cloud which can identify it uniquely by its
name or identification in a specific cloud. Sometimes a service
composed from several services; SBDH can have entities such for a
complex service.
394
6.4 Routing
395
396
397
398
This section describes the use of the term routing at the technical messaging service
level and at the SBDH level, since the term is used differently in both of these
aspects. At the business domain level, which is routing performed by the SBDH,
routing describes the flow of a business document being transferred from one
399
400
401
402
403
404
405
originating partner to another receiving partner. At the lower level, the technical
messaging service uses predefined transfer mechanism such as HTTP to move the
data across the Internet. At the network protocol level, individual packets are
transferred from one router to another across the Internet network. Because there
are two kinds of routing - technical and business - it is useful to separate the headers
into technical and business headers. SBDH routing does not refer to the lower levels
of routing as they are transparent of the SBDH.
406
407
However, the routing fields in the SBDH are capable of being mapped to the
technical headers so that the document can be transmitted successfully to the
408
partner.
409
6.4.1 Bi-lateral aspect
410
411
412
413
In this specification, bi-lateral aspect implies a form of representative association
between business partners who have a specific common rules for interaction only
within a coupled pair which depicted below diagram where each node bounded by
dash line.
Page 19
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
Initiator/Ultimate end point A
Initiator/ Ultimate end point B
Initiator/ Ultimate end point C
Bi- lateral boundary
414
415
Figure 2
Image of bi-lateral aspect
416
417
418
In general, the common rules will be composed by absorbing individual interaction of
semantics and syntaxes; therefore, uniqueness of those rules is very high. So simply,
those rules have few abilities to work for the other coupled pair interaction.
419
6.4.2 Multi-lateral aspect
420
421
422
423
424
In this specification, multi-lateral implies a form of representative association among
business partners who have a specific rule to a centralized node for interaction with
other peer node which has a coupled pair association only between them which
depicted below diagram where each peer node and the centralized node bounded by
dash line.
Initiator/Ultimate end point A
Initiator/ Ultimate end point B
Initiator/ Ultimate end point C
Intermediary
Bi- lateral 境界
425
426
Figure 3
Image of multi-lateral aspect
427
428
429
430
431
432
In general, it is necessary for interaction among peer nodes that business agreement
will be resolved by between business partners (peer nodes), and technical
agreement related to interoperability will be resolved between a peer node and the
centralized node. Technically, once interoperability between them has functioned,
multi-lateral environment would be easier to expand business to other partner than
bi-lateral environment.
433
6.4.3 Multi-partner environment
Page 20
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
434
435
436
437
The SBDH could be used in the scenarios where a SBD has to be sent to multiple
partners or information related to a SBD needs to be collected from multiple partners.
In that case the logical Receiver value could represent a ‘distribution list’, and the
sending Communications application could send the SBD to multiple receivers.
438
439
440
441
442
The SBDH presupposes a point-to-point (sender-receiver) model. Effectively this
infers that any hub-spoke or multi-party scenario will be broken down into
collaborations between two partners. If it is extended to support an n-1 (hub-spokes)
model, where n roles are interacting on a “business document” to do end-to-end
processing, say order-to-cash, in a ‘multi-hop’ situation where the ‘middleman’ strictly
443
444
445
446
performs a store and forward function without changing the SBD contents, the
business document creating application should be insensitive to the presence of the
middleman . If the SBD is altered by an intermediate role player, the logical Recipient
should be that role player, not a subsequent recipient.
447
448
449
450
451
In a store and forward ‘multi-hop’ situation, legally relevant items such as the
originator of a data message for example, may need to be retained with the
identifying sender or receiver. The use of different types of technologies for example,
the actions of an encryption service provider who unwraps and decrypts the
message then re-encrypts it, may not preserve legally needed information that is
452
453
needed when the payload arrives at the intended addressee. But by using the SBDH,
the information is still preserved.
454
6.5 Packaging
455
[Ed Note: need to check with Jostin about section 6.5 and 6.6]
456
457
458
459
Since the SBDH information is added to the business content that has been
originally included in the business document, it is integral to the business document
itself. It can be packaged as a part of the SBD, or for example as a separate MIME
part
460
461
There are varied reasons why the implementer would choose an integrated
packaging approach or a non-integrated approach.
462
The following arguments favor the integrated approach.
463
464
465
466
467
-
-
If SDBH is an integral part of the XML instance document, the document
can be parsed at a high level and routing and processing decision can
easily be made.
In order systems, if the SBDH is contained in a separate MIME body part,
once the message is received by the Communications application, the
Page 21
SBDH 3.0 Draft A2 ODP Step 3
468
469
470
471
472
473
474
11 November 2010
linkage between the two MIME body parts can be lost and the routing /
processing functionality becomes more complex.
The next arguments favor a non-integrated (e.g. a separate MIME parts) approach:
-
-
If the packaging is not integrated then the SBD can be easily encrypted
separately from the SBDH, and the information in the SBDH can be more
readily available to applications.
Modern middleware can handle the linkage between separate MIME parts.
475
6.6 SBDH with the payload encryption
476
477
478
When using the integrated approach, once the message is inside one of the
partner’s firewalls, the issue of application layer security and confidentiality may arise
under certain, special cases.
479
480
481
482
483
This added concern over security and confidentiality may be an issue on the entire
SBDH and payload block or on some of the tags in the SBDH or payload.
Specifically identifiers or keys or financial information are examples that may require
additional security and confidentiality. The requirement may be that only certain
authorized individuals have the permission to view the contents.
484
485
486
487
488
489
490
491
492
For instance, a security requirement may be that the middleware environment
administrators should not have visibility to the payload, which could contain sensitive
trading partner data the receiving application would be able to decrypt the data,
potentially long after the data transport process has ended Some protocols may
require the payload to be encrypted by the sender, prior to transport, and to remain
encrypted once received. If the SBDH was received encrypted along with the
payload, which would prevent further routing from occurring. In these situations,
requiring strict security and confidentiality within the firewalls, there are two
recommendations.
493
494
The first is to utilize selective encryption. Selective encryption is an XML encryption
option, which is available using the XML Encryption specification.
495
496
497
498
When using the older protocols, such as PKCS7, it will be more difficult to use
selective encryption. An alternative recommendation is that the SBDH is either not
encrypted or decrypted upon receipt. In the case where the payload needs to be
encrypted, there are two alternatives to handle this:
499
500
501
a) The first alternative is to send the SBDH and the attached,
encrypted payload in the manifest block. Both objects are contained in
one MIME part in one message .
Page 22
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
502
503
504
505
b) The second alternative is to send the encrypted payload as a
separate MIME part. This option allows multiple recipients to read the
SBDH, while ensuring that only select recipients may read the sensitive
contents in the payload.
506
507
508
509
510
The manifest attachment is also the recommended way of sending a non-XML
document or file. For example, an EDI document, with an SBDH should be sent as a
manifest attachment. In this case, the non-XML payload can be encrypted and sent
as the attachment, allowing the SBDH to be transported and received not encrypted
or to be decrypted without impact to the rest of the payload.
511
6.7 Layered Processing Model
512
513
The layered processing model shows how the SBDH may be populated, extracted
and processed.
514
An interesting SBDH element to consider is “Time Created” - each of the layers
515
would have their own such element;
516
For example,
517
Document Creation Date Time
518
Message Creation Date Time
519
Transport Initiation Time
520
521
522
523
The Document processor at the receiving end needs to worry or care about only the
Document creation time, and not others. However, for auditing purposes, the other
information may need to be logged, but such processing is outside the scope of
SBDH.
524
Page 23
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
525
6.8 Traditional Approach - carry entire information on a message -
526
527
528
In this specification, traditional approach means a single way to pass the SBDH
information to the Receiver in a business transaction. In a nutshell, this approach will
convey entire SBDH information to be contained in a message.
529
Information related to message block and transport block is out of scope from SBDH.
Standard Business Document Header
Document
Message
Transport
Virtual
Virtual
Physical
Document
Message
Transport
530
531
Figure 4 Layered processing model in traditional approach
532
6.9 New Approach –information distribution method
533
534
535
536
537
538
In this specification, this new approach means a collaborative way to pass the SBDH
information to the Receiver in a business transaction. In a nutshell, this approach is a
combination of traditional method with reference method, separating the whole set of
SBDH information in two containers: one for in message the other for in registry and
repository (R&R). The message will carry subset of SBDH with key of pointers to
R&R objects. Once a functionality node such as communicator or translator has got
539
540
541
the message, it will retrieve the information from R&R with its key of pointers due to
necessary to handle a business document. In rest of this specification, this approach
calls “reference approach”.
Page 24
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
Standard Business Document Header
Pointer to a service registry
Normative
Document
Document
Document
Document
Message
Message
Message
Message
Document Tier
Message Tier
Nonnormative
Transport
Transport
Bi-Lateral
Transport
Bi-Lateral
Transport
Transport Tier
Bi-Lateral
Multi-Lateral
Service Registry
(Static Information)
542
(Composit Service Registry)
543
Figure 5 Layered processing model in reference approach
544
545
6.10 Conceptual Metamodel
546
547
In UMM 2.0, SBDH is disposed conceptually as a member of information envelope
that depicted in below diagram.
cla s s UMM
b Informa t ion
from UMM base module
SBDH
InfE nv elop e
1
ASMA
1
0..*
MA
from Standard Business
Document Header
Specification
ASMA
from UPCC
1..*
ABIE
548
549
Figure 6 Abstract business information model
550
UMM foundation model 2.0 figure 49
551
Where bInformation:
Business Information
Page 25
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
552
infEnvelope:
Information Envelope
553
BM:
Business Message
554
MA:
Message Assembly
555
ASMA:
Association Message Assembly
556
ABIE:
Aggregation Business Information Entity
557
ASBIE:
Association Business Information Entity
558
559
The SBDH will have members of information such as routing, processing, and identifying of
560
metamodel.
business documents for engaging its role. The below diagram shows Abstract SBDH
561
cla s s SBDH Ov erv iew
<<???>>
SBDH
0..1
<<ABIE>>
Document Profile
0..1
<<ABIE>>
Ma nifes t
<<ABIE>>
Rout ing
<<ABIE>>
Proces s ing
562
563
Figure 7 SBDH 3.0 Abstract Metamodel
564
565
566
567
568
569
570
571
4. Document Profile (旧名 Identifier)
Document profile entities that used by the both of ultimate end points and
intermediaries, applications / or services, for identifying the business document
without parsing an entire set of entities of it.
5. Manifest
Manifest entities that describe the related items or attachment (i.e. binary file), if any
being set in this package.
Page 26
SBDH 3.0 Draft A2 ODP Step 3
572
573
574
575
576
11 November 2010
6. Routing
Routing entities that used by the both of ultimate end points and intermediaries,
applications / or services, for taking the business document to suitable positions for
achieving business transaction.
7. Processing
577
578
Processing entities that describe the both of ultimate end points and intermediaries,
applications / or services, for executing the business document to suitable
579
transformation or any operation for achieving business transaction.
580
Page 27
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
581
7 Use Case Analysis
582
583
584
585
586
587
The SBDH is compliant to and defined by using modeling elements of the UMMMetamodel. The UMM is part of the Business Collaboration Framework (BCF).
Figure 8, below, describes the scenario that the SBDH solution addresses. Basically,
two partners engage in a UMM compliant business transaction that mandates the
mutual exchange of one or more business messages. These messages, in turn,
must be processed for relevant business data.
c la s s Us a e C a s e An a ly s is
Platform Business
Transaction
Sender
Receiver
<<include>>
Process Business
Message
Business Data
Processor
Communicator
Parser / Translator
Intermediary
<<include>>
Business Data
Creator
Business Data
Processor
Parser / Translator
Communicator
Process Business
Data
Intermediary
<<include>>
Transport Protocol
Process
<<include>>
Parse / Translator
Business Data Store
588
589
590
591
592
593
Figure 8 Typical Use Case Diagram
The use case diagram in Figure 8 illustrates the case where the both sender and
receiver process business messages. Each actor is generalized from SBDH
consumers and providers who have exclusive roles for each others but a single
purpose for achieving business transactions.
594
8. Use case
595
596
597
598
-
599
600
601
-
602
Perform Business Transaction
Business transaction is defined in UMM2.0 see UMM2.0 page 56.
“a business transaction is the basic building block to define choreography
between authorized roles. ・・・””
Process Business Message (Business process)
Business transaction is defined in UMM2.0 see UMM2.0 page 30.
“The business process describes the behaviour of a business process use case
between the involved business partners. It is a tool to identify requirements to
Page 28
SBDH 3.0 Draft A2 ODP Step 3
603
604
collaborate between two or more business partners. A business process refines a
business process use case by describing its dynamic behaviour.”
605
606
607
-
608
609
610
611
-
612
613
614
-
615
11 November 2010
Process business Data
This use case means to generate or to be persistent business entities by, usually,
legacy systems or ERP applications.
Transport Protocol Process
This use case means to deliver business messages which contain business
documents to in a specific way in internet protocol level like http, smtp, or etc. that
agreed on individual business partner.
Parse / Translate
This use case means to recognize business documents and then to translate it
from a proprietary format to a standard format, or vice versa.
9. Actor (business participant)
616
617
618
619
-
Sender who is an initiator in a business transaction.
-
Receiver who is an ultimate end point in a business transaction.
-
Business Data Creator who is an agent for specialized in business data
620
621
-
622
623
-
624
625
626
-
generation of the process business data use case.
Parser / Translator who is an agent for specialized in business data translation
especially in the parse/translate use case.
Communicator who is an agent for specialized in business data communication
especially in the transport protocol process use case.
Intermediary who enable to be in charge of a parser/translator, communicator, or
centralized node where business messages will be exchanged across the node
among business partners.
627
628
7.1 Use case description
629
630
631
632
633
Business Documents and their matching header data are created from data residing
in the private space of the sender. Therefore, the Business Documents may be
created using private semantics and syntax to describe and format the business data.
The Business Documents can be used for purposes such as creating a purchase
order, or an invoice, or some other purpose.
634
Business Documents can be created using:
635

legacy semantics
636

legacy syntax
Page 29
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
637

standard semantics
638

standard syntax, or
639

some combination of the above
640
641
The Business Documents values will be derived from key semantics. The key
semantic values must possess the intelligence required to:
642
643

Ultimately derive the information for routing and processing the standard
Business Document.
644
645

Map the Business Documents logical values to the physical location and
addressing parameters required by the Communications Services.
646
647
648

Identify the appropriate Parser/Translator for this Business Document.
Several parser/translators may exist depending upon the semantic and
syntactical requirements of the Business Documents. "Data-dependent
649
routing” intelligence must be contained in the key values.
Page 30
SBDH 3.0 Draft A2 ODP Step 3
10.
650
11 November 2010
Use Case Elaboration
u c Bu s in e e S e rv ic e
Store Business
Data
Process
Business Data
Business Data
Processor
<<include>>
<<include>>
Create Business
Data
Receive Business
Data
<<include>>
Transport
Protocol
Process
<<include>>
Communicator
Send Business Data
<<include>>
<<call>>
<<include>>
Refer Header Entity
Intermediary
<<include>>
<<call>>
Parse /
Translator
Parser /
Translator
Retrive Header
Entity
<<include>>
Normarize
Business Data
<<include>>
<<include>>
Transform Business
Data
<<include>>
Denormarize
Business Data
651
652
Figure 9 Conceptual Use Case Diagram
653
654
Use Case
Description
Role on SBDH
1
Create Business Data
For initiation of business
transaction, as a first step, a
sender side of system will
create a proprietary form
business document.
none
2
Store Business Data
For termination of business
transaction, at last, a receiver
side of system will store a
proprietary form business
none
Page 31
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
document.
3
Send Business Data
The send business data use
case which is one of the
transport protocol use case will
behave by communicator who
send business messages.
Communicator will use
routing information in
SBDH.
4
Receive Business Data
The receive business data use
case which is one of the
transport protocol use case will
behave by communicator who
receive business messages.
Communicator will use
routing information in
SBDH.
5
Transform Business Data
The transform business data
use case which is one of the
parse / translate use case will
behave by translator who
transforms business messages.
Translator will use
process information in
SBDH.
5.1
Normalize Business Data
The normalize business data
use case which is transform
business data use case will
behave by translator who
transforms business messages
from a proprietary format to a
standard format.
Translator will use
process information in
SBDH.
5.2
Denormalize Business
Data
The denormalize business data
use case which is transform
business data use case will
behave by translator who
transforms business messages
from a standard format to a
proprietary format.
Translator will use
process information in
SBDH.
6
Refer Header Entity
The refer header entity use
case which is common use case
and behave by a communicator,
translator, or intermediary who
refers a registry / repository for
gaining information
A new use case.
7
Retrieve Header Entity
The retrieve header entity use
case which is common use case
and behave by a communicator,
translator, or intermediary who
refers a registry / repository for
gaining information of
necessary action by one.
A new use case.
655
Page 32
SBDH 3.0 Draft A2 ODP Step 3
11.
656
11 November 2010
Use Case Sample 1 - Traditional approach with bi-lateral -
657
658
659
This use case sample developed in previous version of SBDH and it represents
essentials of SBDH usage case to hold interoperability of business message
exchange within different message format.
660
Preconditions
661
662
663
-
Business agreement has executed between business partners.
-
Technical agreement which based on the business agreement has executed, too.
664
665

SBDH will be adopted in business transaction.

Information entity in SBDH that be used on applications or services will be
predefined.
Sender A System Boundary
Sender
Proprietary
Order Form
①
Receiver B System Boundary
Library
Library
P S
S P
P S
S P
②
⑤
③
Receiver
Proprietary
Order Form
⑥
⑦
④
SBDH
SBDH
SBD
Order Form
SBD
Order Form
SBDH
Message envelope
SBD
Order Form
Sender A System Boundary
Receiver B System Boundary
Transport /
Communication
Parser /
Translator
666
P: Proprietary semantic and/or proprietary syntax
S: Standard semantic and/or standard syntax
: Conversion Configuration
667
668
Figure 10 Complete Business Transaction flow image of a classical approach with bi-lateral
669
1. In sender A system, legacy system creates an order business document by a sender A
670
671
672
673
674
675
676
mode
proprietary form, and then the system pass the document to Parse / Translator.
2. Translator will translate the proprietary form document to a standard document with a predefined
configurations stored in local library. It generates SBDH, too. At last, in this phase, the local
system pass the both standardized form business document and its header, SBDH, to a
communicator.
3. The communicator will package them in a transport message that is predefined with the business
partner. And then, the communicator will send the receiver it by internet.
Page 33
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
677
4. As soon as, the communicator in receiver B system will receive the message from Sender A, the
678
679
680
681
682
683
684
685
686
communicator will decide to a proper translator for the business document to denormalize in the
proprietary format, and then the communicator will pass it to the translator.
5. The translator will tack back just the translator of Receiver A did. Simply, it will translate the
business document from the standard format to the proprietary form Receiver B based on the
technical agreements. The configuration for the demoralization predefined and stored in locally,
such database system or registry. Every time in demoralization, the translator will look for the
configuration in it.
6. Finally, receiver B system will store the business document by local manner on legacy system
when the system receives the business document in the proprietary format from the translator.
687
688
Sample Use Case 2 - Reference approach with Bi-lateral –
12.
689
690
691
692
693
This use case sample extends from the above use case. A brief summary that
described in this manner is in section 5.5. The differences between the both, one
carries all the information in terms of SBDH in a message, the other carries partial
information in a message and the rest of information has been prestored in a registry
/ repository. Eventually, any actor will get the SBDH information for achieving its role
694
from the registry / repository in anytime as necessary.
695
Preconditions
696
-
697
698
699
700
701
702
703
Business agreement has executed between business partners.

Technical agreement will not be required between business partners, but it’ll
be required with communication service and / or translation service.
-
SBDH will be adopted in business transaction.
-
Information entity in SBDH that be used on services will be predefined and
prestored in a Registry / Repository.
-
Also, configurations for the normalization and denormalization will be prestored
in a Registry / Repository.
704
705
Page 34
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
Sender A System Boundary
Receiver B System Boundary
SBDH
SBDH
Sender
Receiver
Proprietary
Order Form
Proprietary
Order Form
①
⑦”
Registry & Repository
P A S, PB  S, ・・・, PN  S,・・・
S  PA, S  PB, ・・・, S PN, ・・・
SBDH
Sender
SBDH
①’
②
Proprietary
Order Form
⑦’
③
⑤
Message envelope
Transport /
Communication
Parser /
Translator
⑥
Proprietary
Order Form
Message envelope
④
①”
SBDH
SBD
Order Form
Intermediary
Sender
(Service Boundary)
⑦
P: Proprietary semantic and/or proprietary syntax
S: Standard semantic and/or standard syntax
: Conversion Configuration
: looking at and retrieving SBDH information
706
707
708
709
Figure 11 Complete Business Transaction flow image of a reference approach with bi-lateral
710
1. In sender A system, legacy system creates an order business document by a sender A
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
mode
proprietary form, and then the system pass the document to communicator.
2. The communicator will package the business message contained the business document and
SBDH in a predefine transport message with the intermediary. And then, the communicator will
send it to the communicator in the intermediary by internet.
3. As soon as, the communicator in the intermediary will receive the message from Sender A, the
communicator will decide to a proper translator for the business document to denormalize in the
proprietary format, and then the communicator will pass it to the translator.
4. The translator will translate the proprietary form document of Sender A to a standard document
with a predefined configurations stored in Registry and Repository.
5. The translator passes the normalized business document to the other translator, which can be the
same translator, in the intermediary boundary.
6. That translator will tack back just the previous translator did. Simply, it will translate the business
document from the standard format to the proprietary form Receiver B. The configuration for the
denormalization predefined and stored in Registry and Repository, such database system or
registry. Every time in denormalization, the translator will look for the configuration in it.
7. The communicator in intermediary will repackage the business message contained the business
document and SBDH in a predefine transport message with the intermediary. And then, the
communicator will it to the communicator in the Receiver B by internet.
Page 35
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
729
730
731
732
8. Finally, receiver B system will store the business document by local manner on legacy system
733
734
This approach can realize that the sender A achieves a business transaction to the
receiver B with the business documents made by proprietary format of the sender A.
when the system receives the business document in the proprietary format from the translator.
9. Throughout step 2 to 7, any nodes such as communicator or translator enable to looking at and
retrieve SBDH information which is specific to the business document in anytime as necessary.
SBDH
SBDH
Sender
Sender
Proprietary
Order Form
Proprietary
Order Form
Service Boundary
Receiver B System Boundary
Sender A System Boundary
Receiver B Virtual System Boundary
735
736
Figure 12 Perspective view from Sender
737
738
739
Also, this approach can realize that the receiver B achieves a business transaction to
the sender A with the business documents made by proprietary format of the
receiver B.
SBDH
SBDH
Sender
Proprietary
Order Form
Sender
Proprietary
Order Form
Service Boundary
Sender A System Boundary
Receiver B System Boundary
Sender A Virtual System Boundary
740
741
742
Figure 13 Perspective view from Receiver
13.
Extension of reference approach to multi-lateral
743
Adding extra end points – other senders and / or other receivers – on the sample use
744
745
746
747
case 2 which aren’t as difficult as adding them on the sample use case 1 because of
unnecessity to have technical agreements and its related integration among them
instead of necessity to have technical agreement between each end points and
intermediary.
748
749
7.2 Work Flow Analysis
750
751
There are three basic workflows for the SBDH solution, each addressing a different,
but complementary, implicit business function: originating, controlling, and receiving
Page 36
SBDH 3.0 Draft A2 ODP Step 3
752
753
11 November 2010
business data. Figure 14, below, illustrates the prescribed SBDH workflow for
exchanging business data.
a ct Send er
Business Application
/ Service
Parser / Translator
Communicator
Create Business Data
Transform data and/or
semntics?
Business Data
[CREATED]
Descriptor Data
[CREATED]
[YES]
Transform Business Data
Business Data
[TRANSFORMED]
Descriptor Data
[TRANSFORMED]
[NO]
Send Business Data
Business Message
[SENT]
END
754
755
Figure 14 Typical work flow in Sender Part
756
757
758
759
First, a Business Document and its matching header are created from information
residing in the private space of the sender (for example, one or more internal
business services). This data might be compliant (semantically and syntactically) to
some standard; otherwise it must undergo a data transformation process. Note that
760
761
762
763
764
the data and its corresponding header may initially contain the information elements
and semantics mandated by the SBDH solution; otherwise the data transformation
service will ensure that such elements are created. Finally, a communications
service constructs a business message using the SBD with its SBDH. This message
is sent to a peer through a predefined transport protocol.
765
766
The other workflow delineated by the SBDH solution is shown in Figure 10 and
illustrates the process of receiving a business message.
Page 37
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
a ct Receiv er
Communicator
Business Message
[RECEIVED]
Parser / Translator
Business Application /
Service
Transform data and
semantics
END
[No]
Receive Business Data
Store Business Data
[Yes]
Transform Business Data
Business Data
[TRANSFORMED]
767
768
Figure 15 Typical work flow in Recipient Part
769
770
771
772
It is assumed that the message received by the Communications Service contains
the key data elements and semantics mandated by the SBDH solution. Key
elements associated with information routing are then identified. The message may
be sent to a parser/translator service or directly to a Business Data Processor
773
774
service for processing and storage. If data transformation occurs, certain SBDH
elements will facilitate the process.
775
14.
Work Flow of Reference Model
776
777
778
The other extra workflow delineated by the SBDH solution is shown in Figure 16 and
that illustrates the process of retrieving SBDH information from a registry and / or
repository.
779
780
This activity can be happen in any time within a business transaction. It also denoted
as the red arrows in figure 11. Any nodes such as communicator, translator , or
781
782
intermediary enable to get the SBDH information from registry and repository to
access using pointer to it of SBDH entities contained in a business message.
Page 38
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
a c t Re fe re n c e _Ap p roa c h
Communicator/ Translator/ Intermediary
Registry / Repogitry
BusinessMessage
[RECEIVED]
Complement
Descriptor?
Extract Descriptor Data
Retrieve Descriptor Data
[Yes]
Pointer of R&R Object
[REQUEST]
ReturnDescriptor Data
DescriptorData
[REPLY]
Receive Extra Dedcriptor
Data
[No]
END
783
784
Figure 16 Typical workflow for the reference approach
785
786
Page 39
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
787
8 Date Elements Elaboration
788
789
790
The SBDH entities are composed from routing, processing, manifest, and profiling of
business documents. These entities will support to realize the business transaction
and those patterns which are specified in UMM 2.0.
791
c la s s Doc u me n t Profile
<<some BIE>>
SBDH
+
Version: Text
0..1
<<ABIE>>
Doc u me n t Profile
+
+
+
+
+
+
0..1
<<ABIE>>
Rou t in g
<<ABIE>>
Ma n ife s t
Standard: Text
Instance_Idenfification: Idenfifier
Type: Text
Type Version: Text
Multiple Type: Indicator [0..1]
Creation: Date Time
+
Manifest Items: Number
+
Mode: Indicator = Regular or Reference
Sender
1..*
Description: Text
MIME: Code
URI: Identifier
Language Code (add): Code
Receiver
1..*
<<ACC>>
Ma n ife s t _Bin a ry F ile
+
+
+
+
<<ABIE>>
Proc e s s in g
1..*
Intermediary
0..1
0..*
<<ABIE>>
Pa rt y
+
+
<<ABIE>>
Bu s in e s s Sc op e
Identification: Identifier [0..1]
Type: Code [0..1]
+
+
+
Type: Code
DocumentInstance_Identification: Identifier [0..1]
Identification: Identifier [0..1]
0..*
0..1
<<ABIE>>
C on t a c t
+
Person_Name: Text
0..1
0..1
<<ABIE>>
C orre la t ion Doc u me n t
+
+
+
<<ABIE>>
Bu s in e s s Se rv ic e
Creation: DateTime [0..1]
Identification: Identifier [0..1]
Response: DateTime [0..1]
+
+
+
Name: Text [0..1]
Identifier: Text [0..1]
ServiceRegistry URL: Text [0..1]
<<ABIE>>
C ommu n ic a t ion
+
+
+
Index
Email_URI: Identifier [0..1]
Phone_Complete: Number [0..1]
Fax_Complete: Number [0..1]
+
+
<<ABIE>>
Se rv ic e T ra n s a c t ion
+
+
+
+
+
+
+
+
Type: Code [0..1]
Nonrepudiation Requirement: Indicator [0..1]
Intelligible Check Rquirement: Indicator [0..1]
Application Erroe Response Request: Indicator [0..1]
Receipt Acknowledgement Time: Date Time [0..1]
Acknowledgement Acceptance Time: Date Time [0..1]
Completion Requirement Time: Date Time [0..1]
Recurrence: Number [0..1]
0..1
Re g is t ry Ob je c t
PathSegment: Text [0..1]
Word: Text [0..*]
0..1
0..1
792
793
Figure 17 SBDH3.0 data model overview
794
[EdNOTE: The business information entities may change after they have been
795
processed through the UN/CEFACT harmonization and approval process. ]
796
8.1 Document Profile
797
798
799
800
801
Document profile entities which represent identification information of business
documents will be used by services or application to recognize what business
document is without parsing whole entity of a business document.
<DocumentProfile block> (Standard Business Document. Details) Characteristics
containing identification about the document. REQUIRED, object.
Page 40
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
802
803
804
805
806
807
1. Standard (Standard Business Document. Standard Type. Code): The
originator of the type of the Business Data standard, e.g. SWIFT, OAG,
EAN.UCC, EDIFACT, X12; references which Data Dictionary is being used.
Used for the task of verifying that the grammar of a message is valid.
Comment: This information may be provided in a URI if XML; probably not if
EDI. REQUIRED, String.
808
809
810
2. TypeVersion (Standard Business Document. Standard Type Version.
Identifier): Descriptor which contains versioning information or number of the
standard that defines the document which is specified in the ’Type’ data
811
812
element, e.g. values could be ‘1.3’ or ‘D.96A’, etc. . This is the version of the
document itself and is different than the HeaderVersion. REQUIRED, string.
813
814
3. InstanceIdentifier (Standard Business Document. Instance. Identifier):
Descriptor which contains reference information which uniquely identifies this
815
816
817
818
instance of the SBD between the sender and the receiver. This identifier
identifies this document as distinct from others. There is only one SBD
instance per Standard Header. The Instance Identifier is usually automatically
generated by the middleware. REQUIRED, string.
819
820
821
822
823
824
825
826
827
4. Type (Standard Business Document. Type. Code): A logical indicator
representing the type of Business Data being sent or the named type of
business data. This attribute identifies the type of document and not the
instance of that document. The instance document or interchange can contain
one or more business documents of a single document type or closely related
types. The industry standard body (as 1142 referenced in the ‘Standard’
element) is responsible for defining the Type value to be used in this field (e.g.
‘order’, ‘catalogItemNotification’, ‘INVOIC’, etc.). Comment: The type may be
linked to the service. REQUIRED, string.
828
829
830
831
832
833
834
835
836
5. MultipleType (Standard Business Document. Multiple Document Type.
Indicator): A flag to indicate that there is more than one type of Document in
the instance. A “false” denotes that Type contains only one type of document;
a “true” denotes that Type contains more than one type of document and that
the name provided by the Standard authority identifies the multiple documents
and not a single document. The instance document or interchange can contain
one or more business documents of a single document type or multiple related
document types. (E.g. Order, OrderSummary; or Invoice, TaxCon) Boolean,
OPTIONAL.
837
838
6. CreationDateAndTime (Standard Business Document. Creation. Date Time):
Descriptor which contains date and time of SBDH/document creation. In the
Page 41
SBDH 3.0 Draft A2 ODP Step 3
839
840
841
842
11 November 2010
SBDH the parser translator or service component assigns the SBD a Date and
Time stamp. The creation date and time expressed here most likely will be
different from the date and time stamped in the transport envelope.
REQUIRED, dateTime.
843
844
845
846
8.2 Manifest
Manifest entities which describe the related items or attachment (i.e. binary file),
if any being set in this package.
847
848
<Manifest block> (Manifest. Details): Manifest that describes the related items or
attachments (i.e., binary files), if any, being sent in this package. OPTIONAL, Object.
849
850
1. NumberOfItems (Manifest. Item Count Number. Numeric): The count of
number of items associated with this package. Includes the base payload and
851
852
853
854
any attachments. REQUIRED, Integer
2. ManifestItem (Manifest. Item. Binary Object): Provides information about the
referenced item information; Repeatable if there is more than one item or
attachments; REQUIRED, Object, Repeatable. Includes:
855
856
857
858
a) MimeTypeQualifierCode (Binary Object. Mime. Code): Code describing
whether the contents are XML or EDIFACT or X12, etc. syntax. Types are
defined by IANA (see http://www.iana.org/assignments/media-types/)
REQUIRED, String.
859
860
861
862
863
864
b) UniformResourceIdentifier (Binary Object. Uniform Resource. Identifier):
URI of the Manifest Item taken from its namespace; [For the useful
guidance on how to reference external and internal message documents,
the reader is referred to the RFC on Content Id URIs. This RFC 2392
(obsoletes 2111) can be found at the following location:
http://www.faqs.org/rfcs/rfc2392.html]; REQUIRED, String.
865
866
c) Description (Binary Object. Description. Text): Text Description of Item;
OPTIONAL, String.
867
868
d) LanguageCode (Binary Object. Language. Identifier): Language of Item in
ISO 639; OPTIONAL, String.
869
870
871
872
8.3 Routing
Routing entities which represent logical routing information to go from node to
node to accomplish reaching the ultimate end point.
Page 42
SBDH 3.0 Draft A2 ODP Step 3
873
874
875
876
877
878
879
880
881
11 November 2010
<Routing block> (Routing. Details): Routing that describes the related partners or
intermediary. REQUIRED, object.
1. Mode Indicator (Rooting. Mode boolean)
The indicator has two kinds of instances:
-
“Tradition” which means that a business message carries information based on
traditional approach.
-
“Reference” which means that a business message carries information based on
reference approach.
REQUIRED, boolean
882
883
884
<Sender Block> (Sender_ Party. Details): Logical party representing the
organization that has created the standard business document. This block is
repeatable. If the Sender block is repeated then the first sender will be the primary
885
886
887
888
sender and the second sender will be the secondary sender. The secondary sender
will be used for internal routing purposes only to further identify the internal routing.
The primary sender is REQUIRED, object. The secondary sender can repeat 1 to
multiple times and is OPTIONAL, object.
889
890
1. Identifier (Sender_ Party. Identification. Identifier): Descriptor with information
to identify this party; REQUIRED, String.
891
892
2. Authority (Identification Scheme. Agency. Identifier): Descriptor that qualifies
the identifier used to identify the sending party; REQUIRED, String.
893
894
895
3. Contact Information (Sender_ Party. Contact. Contact): Information about the
contact for this document; Can repeat 0 to multiple times. OPTIONAL, object.
Includes:
896
897
a) Contact (Contact. Name. Name): contact for business, REQUIRED,
String;
898
899
b) Email Address (Contact. EMail Address. Text): email address of contact;
OPTIONAL, String;
900
c) Fax Number (Contact. Fax Number. Text): of contact; OPTIONAL, String;
901
902
d) Telephone Number (Contact. Telephone Number. Text): of contact;
OPTIONAL, String;
903
904
e) Contact Type Identifier (Contact. Role Identification. Identifier): role of
the contact in this business process; OPTIONAL, String.
Page 43
SBDH 3.0 Draft A2 ODP Step 3
905
906
907
908
909
910
911
11 November 2010
< Receiver Block> (Receiver_ Party. Details): Logical party representing the
organization that receives the SBD. This block is repeatable. If the Receiver block is
repeated than the first receiver will be the primary receiver and the second receiver
will be the secondary receiver. The secondary receiver will be used for internal
routing purposes only to further identify the internal routing. The primary sender is
REQUIRED, object. The secondary sender can repeat 1 to multiple times and is
OPTIONAL, object.
912
913
1. Identifier (Receiver_ Party. Identification. Identifier): Descriptor with
information to identify this party; REQUIRED, String.
914
915
2. Authority (Identification Scheme. Agency. Identifier): Descriptor that qualifies
the identifier used to identify the receiving party; REQUIRED, String. Includes:
916
917
3. ContactInformation (Receiver_ Party. Contact. Contact): Information about
the contact for this document; OPTIONAL, object. Can repeat 0 to multiple
918
times. Includes:
919
920
a) Contact (Contact. Name. Name): contact for business, REQUIRED,
String;
921
922
b) EmailAddress (Contact. EMail Address. Text): email address of contact;
OPTIONAL, String;
923
c) FaxNumber (Contact. Fax Number. Text): of contact; OPTIONAL, String;
924
925
d) TelephoneNumber (Contact. Telephone Number. Text): of contact;
OPTIONAL, String;
926
927
e) ContactTypeIdentifier (Contact. Role Identification. Identifier): role of the
contact in this business process; OPTIONAL, String.
928
929
<Intermediary Block> (Intermediary_ Party. Details): Intermediary which will be in
charge of communicator or translator will reside in cloud, and it has ability of to tie
930
nodes due to simplify processes.
931
The Intermediary is OPTIONAL.
932
933
4. Identifier (Intermediary_ Party. Identification. Identifier): Descriptor with
information to identify this party; REQUIRED, String.
934
935
5. Authority (Identification Scheme. Agency. Identifier): Descriptor that qualifies
the identifier used to identify the Intermediary party; REQUIRED, String.
936
937
938
6. Contact Information (Intermediary _ Party. Contact. Contact): Information
about the contact for this document; Can repeat 0 to multiple times.
OPTIONAL, object. Includes:
Page 44
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
939
940
a) Contact (Contact. Name. Name): contact for business, REQUIRED,
String;
941
942
b) Email Address (Contact. EMail Address. Text): email address of contact;
OPTIONAL, String;
943
c) Fax Number (Contact. Fax Number. Text): of contact; OPTIONAL, String;
944
945
d) Telephone Number (Contact. Telephone Number. Text): of contact;
OPTIONAL, String;
946
947
e) Contact Type Identifier (Contact. Role Identification. Identifier): role of
the contact in this business process; OPTIONAL, String.
948
949
8.4 Processing
950
Processing entities which represent logical processing information execute by
951
952
each nodes to accomplish providing a proper business document which the
ultimate end point enable to interpret.
953
954
<BusinessScope block> (Business Scope. Details): The business scope contains 1
to many [1..*] scopes. It is not mandatory to put all intermediary scopes in an SBDH.
955
956
957
958
Only those scopes that the parties agree to are valid. The following examples are all
valid: transaction; business process; collaboration. A Profile may be used to group
well-formedness rules together. The business scope block consists of the Scope
block. OPTIONAL, Object.
959
960
961
962
963
1. <Scope block> (Business Scope. Scope): Indicates the type of scope, the
identifiers for the scope, other supporting information and the scope content
itself. The importance of the Scope is that it allows the SBDH to operate under
auspices of an agreement; that parties agree that they only include reference
agreements (i.e. make a reference of SBDH and RosettaNet or OASIS CPP/A).
964
965
Additional types of agreements are expected to be defined in the future.
OPTIONAL, Object.
966
967
968
969
970
a) Type: (Business Scope. Scope Type. Code): Indicates the kind of scope;
an attribute describing the Scope. Example entries include: UN/CEFACT
Transaction, UMM:BusinessCollaboration, BusinessProcess,
ebXML:BusinessService, BusinessServiceAction, BCF:AuthorizedRole, or
Role Party. Could be used to indicate role reversal. MANDATORY, String.
971
972
b) InstanceIdentifier: (Business Scope. Scope Instance. Identifier): A unique
identifier that references the instance of the scope (e.g. process execution
973
instance, document instance). For example, the Instance Identifier could
Page 45
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
974
975
976
977
be used to identify the specific instance of a Business Process. This
identifier would be used to correlate all the way back to the business
domain layer; it can be thought of as a session descriptor at the business
domain application level. OPTIONAL, String.
978
979
980
981
982
c) Identifier: (Business Scope. Scope. Identifier) An optional unique
descriptor that identifies the "contract" or "agreement" that this instance
relates to. It operates at the level of business domain, not at the transport
or messaging level, by providing the information necessary and sufficient
to configure the service at the other partner's end. Valid values for the
983
984
985
986
987
Identifier may be in the form of a: URI, URN, ebXML CPAID, RosettaNet
TPA, EDIFIEC or Partner Defined. Partners agree on how to describe the
contract. A reference to the definition of legal compliance can be used as
values in Identifier as well. It references the type of parent scope (e.g.
process model, document specification). Several methods may be use to
988
989
identify scopes: for example, Global identifiers (GUID) , relative identifiers
(role name sequence number, local name). OPTIONAL, String.
990
The following objects are the first extensions of the Business Scope to be defined:
991
・ the BusinessService block
992
・ and the CorrelationInformation block.
993
994
995
In the future, the BusinessScope block will be extended with additional business
scope and context extensions or substitutions, as these become defined by the
business.
996
997
998
999
< BusinessService block> (Business Service. Details): Initiator's description of the
service to be carried out on the SBD by receiver. The SBDH may be used to place a
business document in the proper context for the UMM/Business Collaboration
Framework (BCF) service layer and transaction layer. The SBDH does not model the
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
BCF environment; it places the document within the context of a BCF environment
which is modeled elsewhere in UN/CEFACT specifications. As such, a particular
document will be in the context of one service transaction and one business
transaction (i.e. in two different layers of the stack). OPTIONAL, Object.
1. BusinessServiceName (Business Service. Name): Initiator's description of
service to be carried out on the SBD by receiver. Comment: A business
service is a network component responding to business transaction requests
initiated by other services. It has network identity as a business service.
Business services monitor the execution of service collaborations. The service
protocol implemented in the SBDH operates only in the document layer of the
Page 46
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
1010
1011
1012
e-business network; it is not concerned with Transport or Message Layers. In
the context of an ebXML business process model, a service is a set of related
actions for an authorized role within a party. OPTIONAL, String.
1013
1014
1015
1016
1017
1018
2. ServiceTransaction (Business Service. Service Transaction. Name):
BusinessServiceTransaction is a specific instruction to be executed by the
'BusinessServiceName' on the received Standard Business Document. The
ServiceTransaction element identifies a process within a BusinessService that
processes the SBD. BusinessServiceTransaction SHALL be unique within the
Service in which it is defined. OPTIONAL, Object.
1019
1020
1021
(The following elements are an expression at a business level of wha service
an application wants and should not be construed as instructions to an
infrastructure application.)
1022
1023
1024
1025
1026
a) TypeOfServiceTransaction (BusinessService. ServiceTransaction.
TypeOfServiceTransaction. Identifier): The value of the
TypeOfServiceTransaction element is specified by UMM as: ‘Requesting
Service Transaction’ or ‘Responding Service Transaction’. OPTIONAL,
String.
1027
1028
1029
1030
1031
1032
b) IsNonRepudiationRequired (Business Service. Service Transaction. Is
Non Repudiation Required. Indicator): Non repudiation of origin and
content means that the originator must digitally sign the business data and
the recipient must store the business data (including the digital signature)
in its original form for the duration mutually agreed to in a trading partner
agreement. OPTIONAL, Boolean
1033
1034
1035
1036
c) IsAuthenticationRequired (Business Service. Service Transaction. Is
Authentication Required, Indicator): If IsNonRepudiationRequired is true,
this tag is superfluous. Otherwise, the tag indicates whether the identity of
the sending role is verified. OPTIONAL, Boolean
1037
1038
1039
1040
d) IsNonRepudiationOfReceiptRequired (Business Service. Service
Transaction. Is Nonrepudiation Of Receipt Required. Indicator): Indicates
that both partners agree to mutually verify receipt of requested business
data and that the receipt must be non reputable. OPTIONAL, Boolean
1041
1042
1043
1044
e) IsIntelligibleCheckRequired (Business Service. Service Transaction. Is
Intelligible Check Required. Indicator): Both partners agree that a
responding partner role must check (e.g. via use of a document digest)
that received data is not garbled (unreadable, unintelligible) and has
Page 47
SBDH 3.0 Draft A2 ODP Step 3
1045
1046
11 November 2010
integrity (i.e. has not been altered) before acknowledgment of proper
receipt is returned to the requesting partner. OPTIONAL, Boolean
1047
1048
1049
1050
1051
1052
f)
IsApplicationErrorResponseRequested (Business Service. Service
Transaction. Is Application Error Response Requested. Indicator): Both
partners agree that a responding partner’s receiving business application
must check for application level errors; and if any are detected, must
respond with an Error Response Acknowledgment noting the errors
detected. OPTIONAL, Boolean
1053
1054
1055
1056
1057
g) TimeToAcknowledgeReceipt (Business Service. Service Transaction.
Time To Acknowledge Receipt): Specifies the time period by which a
Receipt Acknowledgment must be returned by the responding partner’s
receiving business application. The requesting and responding partners
jointly agree on the time period. It is measured from the time a business
1058
1059
1060
1061
1062
data request is sent by a requesting partner until the time verification of
receipt is "properly received" by the requesting business partner. The
Receipt Acknowledgment only indicates receipt of data by the business
application; it does not indicate business acceptance of the contents of the
message. If the TimeToAcknowledgeReceipt element is used, it indicates
1063
1064
that a Receipt Acknowledgment is requested. OPTIONAL,
TimeExpression
1065
1066
1067
1068
1069
1070
1071
h) TimeToAcknowledgeAcceptance (Business Service. Service
Transaction.Time To Acknowledge Acceptance): Specifies the time period
that an Acceptance Acknowledgment (which indicates business
acceptance of the contents of the document) must be returned by the
responding role. The requesting and responding partners jointly agree on
the time period. It is measured from the time a requesting partner sends
business data until the time an acknowledgement of acceptance is
1072
1073
1074
"properly received" by the requesting partner. If the
TimeToAcknowledgeAcceptance element is used, it indicates that an
Acceptance Acknowledgment is requested. OPTIONAL, TimeExpression
1075
1076
1077
1078
1079
i)
TimeToPerform (Business Service. Service Transaction.Time To
Perform): Specifies the time period by which this transaction must be
completed (measured from the time the business data is "properly
received"). The requesting and responding partners jointly agree on the
time period. OPTIONAL, TimeExpression
1080
1081
j)
Recurrence (Business Service. Service Transaction. Recurrence):
OPTIONAL, Unsigned Integer
Page 48
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
1082
< Registry Object block> (Registry Object Details):
1083
1084
1085
Registry Object entities which represent pointers of the registry object for retrieving
residing SBDH information in registry and repository. This notation took from the ISO
20944-2.
1086
1087
a) PathSegment (Business Service. Index_RegistryObject.PathSegment):
REQUIRED, Text
1088
b) Word (Business Service. Index_RegistryObject.Word): REQUIRED, Text
1089
1090
1091
1092
1093
1094
<CorrelationInformation block> (Correlation. Details): A block of information used
to correlate a requesting SBD to a responding SBD and to the contract in an
executing choreography. A requesting document in the choreography could have: no
response, a notification, or a response document. Therefore, the requesting and
responding part of the choreography is not always one unit of activity. Using the
correlation block, parties explicitly identify the document being responded to, rather
1095
1096
1097
1098
1099
than having only the content of the document to identify the requesting document.
UN/CEFACT BPSS correlates information at the transaction level but not at the
business domain level, which is the function of this block. This is valuable
information for both parties’ business data creator applications to correlate their
document exchanges. The requesting document is often, but not necessarily, the
1100
1101
1102
very first document in the sequence. If the Requesting document is being sent, some
of the information in this block is not necessary - the block attributes are OPTIONAL,
Object. Includes:
1103
1104
1105
1106
1. RequestingDocumentCreationDateTime (Correlation Requesting Document.
Creation. Date Time): Descriptor which contains date and time of the
requesting SBDH and SBD, assigned to the requesting SBDH and SBD by the
parser translator or service component. OPTIONAL, DateTime.
1107
1108
1109
2. RequestingDocumentInstanceIdentifier (Correlation Requesting Document.
Identification. Identifier): Identifier of requesting SBDH and SBD instance.
OPTIONAL, String.
1110
1111
1112
1113
3. ExpectedResponseDateTime (Correlation. Expected Response. Date Time):
Date and time when response is expected. This element could be populated in
an initial message of a correlation sequence, and should be echoed back in a
subsequent response. OPTIONAL, DateTime.
1114
1115
1116
Page 49
SBDH 3.0 Draft A2 ODP Step 3
1117
11 November 2010
Glossary
Term
BCF
Description
UN/CEFACT Business Collaboration
Framework.
Business Document (BD)
BPSS
A document used by a back office application,
typically expressed in a proprietary format. The
BD is typically transformed into a SBD via a
middleware application such as a parser or a
translator.
Business Process Specification Schema. A
UN/CEFACT requirements document.
Business Data Creator
The legacy, ERP or other application that
creates business transactions for funtional
processes, such as ordering, invoicing, etc.
Business Service Interface
The business layer interface described in
(BSI)
ebXML.
Collaboration-Protocol Profile
An explicit TPA format defined by OASIS.
/ Agreement (CPP/A)
Communications Application
The application that transmits the SBD from the
Sender to the Receiver.
DUNS
ebMS
The identifier within the Dun & Bradstreet
Unversal Numbering System for partner
identification.
The electronic business Messaging Service
specified by ebXML. Also known as ebXML-MS
EDI
Electronic Data Interchange
EDIFACT
Electronic Data Interchange for Administration,
Commerce and Transport
GLN
The EAN Global Location Number for partner
identification.
Messaging Service Interface
The messaging interface described in ebXML
(MSI)
The application that transfers BDs from internal
private format to an external SBD format
including the SBDH.
Standard Business Document A document expressed in a format approved by
a standards organization such as UN/CEFACT,
(SBD)
EAN.UCC, Rosettanet, etc. Documents are
typically shared between external trading
Parser/Translator
Page 50
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
partners in a SBD format.
Standard Business Document The business level header in a standard format
as described in this document. The SBDH is
Header (SBDH)
designed to be either an integral part of a
Standard Business Document, or an object
associated with the Standard Business
Document.
Trading Partner Agreement
An agreement between trading partners
describing how they will exchange business
(TPA)
information.
United Nations Centre for Trade Facilitation
UN/CEFACT
and
Electronic Business
UMM
UN/CEFACT Modeling Methodology
WSDL
W3C Web Services Definition Language.
XML
eXtensible Markup Language
1118
1119
1120
1121
1122
1123
8.5 Appendix A SBDH XML Schema
[Ed note: this part will be developing by NDR after the completion of body
parts.]
8.6 Appendix B XML Sample Instance
[Ed note: this part will be composed after the completion of Appendix A.]
1124
Page 51
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
1125
8.7 Appendix D SBDH Adaption Model <informative>
1126
1127
1128
1129
1130
[Ed note: the below diagram, a registry and repository, which is restructured
conceptually from actual model using CCTS conventions. SBDH will access to get
information from it to achieve business transaction when translator or communicator
need to entities for its execution will retrieve these from the below R&R. the model
will subject to change by completion of this specification]
cla s s OSR4_0
Serv ice Prov id er. Det a ils
Pict ure. Det a ils
+
+
+
+
Identification: Identifier
Title Name: Text
NIME Type: Text
Degital Iamge: Binary
0..1
+
+
+
+
Logo
0..1
1
Main
Identification: Identifier
Name: Text
Description: Text [0..1]
Active: Text
0..1
1
0..1
1
+
+
+
+
+
+
+
Main
0..1
Icon
C ont a ct . Det a ils
Web
Identification: Identifier
1
0..*
e-mail
Unit Name: Text [0..1]
Description: Text [0..1]
1
0..*
FAX
Postal Code: Text [0..1]
Address one: Text [0..1]
Address two: Text [0..1] 1 Telephone 0..*
Address three: Text [0..1]
0..*
1
C ommunica t ion. Det a ils
+
+
+
+
Identification: Identifier
Complete Number: Text
URL: Ideintifier
Description: Text [0..1]
Logo
1
Serv ice As s emb ly . Det a ils
Sales
0..1
+
+
+
Identification: Identifier
Name: Text
Description: Text [0..1]
Sub
category
1
0..*
Int erfa ce. Det a ils
Specification +
1 ++
+
0..*
+
Identifier: Identification
Name: Text
Description: Text [0..1]
URL: Text [0..1]
Version: Text [0..1]
Document .
Det a ils
Providing
0..*
1
0..*
1
Providing
1
+
+
+
+
+
+
+
+
+
+
+
+
+
0..1
Promotion
0..1
Manual
0..1
Verification
+
+
+
+
+
+
+
Ideintifier: Identification
Name: Text
Description: Text [0..1]
Version: Text [0..1]
File Name: Text
Binary Object: Binary Object
MIME Type: Text
0..1
0..*
Plan
relative
Detail
Document . Det a ils
SLA
1
refering
1..*
Identification: Identifier
Assembly Name: Text
Description: Text [0..1]
1
Version: Text [0..1]
OriginService: Text [0..1]
DestinationService: Text [0..1]
0..*
Identification: Identifier
Provider Identification: Identifier
Name: Text
Description: Text [0..1]
Version: Text [0..1]
Service Level: Number [0..1]
Verification: Indicator [0..1]
Standard: Indicator [0..1]
Result: Indicator [0..1]
Active: Indicator
Release Date : Date
Knowledge: Indicator [0..1]
LogoId: Identifier [0..1]
Definition
0..*
C omp onent Serv ice. Det a ils
+
+
+
+
+
1
0..*
C omp os it e Serv ice. Det a ils
Service
0..*
0..*
+
+
+
+
+
+
Combine
C a t eg ory . Det a ils
+
+
+
+
+
SLA option
E x t ens ion. Det a ils
Reference Serv ice.
Det a ils
Identification: Identifier
Name: Text
Description: Text
Version: Text [0..1]
Platform Name: Text [0..1]
+
+
+
+
Idintification: Identifier
Service Name: Text
Provider: Text
Description: Text [0..1]
Version: Text [0..1]
Idenfication: Identifier
Attribute Identification: Identifier
Attribute Name: Identifier
Type: Code
1
Serv ice Op t ion. Det a ils
1
1..*
E x t ens ion. Det a ils
+
+
+
+
Identification: Identifier
Value
Attribute Identification: Identifier
Attribute Name: Text
0..*
1
Type: Code
+
+
+
+
+
+
+
+
+
+
+
+
+
Indentication: Identifier
Option Idenfication: Identifier
Option Name: Text
Description: Text [0..1]
Fee: Amount [0..1]
Initial Cost: Amount [0..1]
Initial Cost Memo: Text [0..1]
Purchase Cost: Amount [0..1]
Cut Off Day: Date [0..1]
Sales Class: Code [0..1]
First Month Caluculus: Code [0..1]
Last Month Caluculus: Code [0..1]
Active: Indicator
Pect ure. Det a ils
1..*
C ont ra ct . Det a ils
+
+
+
+
+
+
+
+
+
+
+
+
+
Web
0..*
Sub s crip t ion_ Serv ice. Det a ils
+
+
Identification: Identifier
Access Point_ Name: Text [0..1]
Logo
Web
Ag ent _ Org a niz a t ion. Det a ils
Partner
+
0..1 +
+
C ommunica t ion. Det a ils
0..1
+
+
+
+
Telephone
0..*
0..*
Main
Identification: Identifie
Name: Text
Description: Text
Active: Indicator
Subscription
Utilized
0..*
+
+
+
+
+
+
Identification: Identifier
Tenant_ Identification: Identifier
Family Name: Text
Given Name: Text
Middle Name: Text [0..1]
Description: Text [0..1]
Reg is t ra t ion. Det a ils
+
Recorded.: Recorded. Date [0..1]
Consuming
Affiliate
Affiliate
0..*
Pa rs on. Det a ils
Aut horiz a t ion. Det a ils
0..*
0..* C ommunica t ion. Det a ils
0..*
Fax
0..1
0..1
1..*
Identification: Identifier
Tenant_ Identification: Identifier 0..*
Name: Text
Information: Text [0..1]
e-mail
1..*
e-mail
+
+
+
+
C ont a ct . Det a ils
Main
Name: Text
Identification: Identifier
Description: Text
T ena nt _ Org a niz a t ion. Det a ils
Web
0..1
Web
Identification: Identifir
Tenant_ Identification: Identifir
Service_ Identification: Identifir
Option_ Identification: Identifir
Partner_ Identification: Identifir [0..1]
Status: Code
Item: Quantity
Initial_ Price: Amount [0..1]
Issue: Date Time
Effective: Date Time [0..1]
End: Date Time [0..1]
Close Out: Date Time [0..1]
Memorandum_ Description: Text [0..1]
Pa rt y . Det a ils
Affiliate
+
+
+
+
Identification: Identifier
Tenant_ Identification: Identifier
Name: Text [0..1]
Description: Text [0..1]
Res ource. Det a ils
0..*
0..1
Affiliate
+
+
Identification: Identifier
Description: Text
0..*
UItilization
0..*
0..*
Logging
Pa ra met er. Det a ils
+
+
+
Aut hent ica t ion. Det a ils
+
Identification: Identifier
Identification: Identifier
Data_ Type: Text
Value: Text
Utilized
1131
1132
1133
1134
The above diagram will be updated and translated by the F to F (week of 14 in Nov.
2010).
Page 52
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
1135
1136
1137
1138
1139
Page 53
SBDH 3.0 Draft A2 ODP Step 3
11 November 2010
1140
Disclaimer ……
1141
1142
1143
1144
The views and specification expressed in this document are those of the authors and
are not necessarily those of their employers. The authors and their employers
specifically disclaim responsibility for any problems arising from correct or incorrect
implementation or use of this design.
1145
Page 54
SBDH 3.0 Draft A2 ODP Step 3
1146
11 November 2010
Copyright Statement
1147
1148
Copyright © UN/CEFACT <Year>. All Rights Reserved.
1149
1150
1151
1152
This document and translations of it may be copied and furnished to others, and
derivative works that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and distributed, in whole or in
1153
1154
1155
1156
1157
part, without restriction of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the copyright
notice or references to UN/CEFACT except as required to translate it into languages
other than English.
1158
1159
The limited permissions granted above are perpetual and will not be revoked by
UN/CEFACT or its successors or assigns.
1160
1161
This document and the information contained herein is provided on an "AS IS" basis
and UN/CEFACT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
1162
1163
1164
1165
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
1166
1167
1168
1169
Page 55