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