Deployment Profile Template
v1.1
For OASIS ebXML Business Process Specification Schema v2.0.X
Public Review Draft 01, 04
December 2006
Artifact identifier:
ebXML_DPT-v1.1-ebBP20x-template-pr-01
Location:
http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-iic
Artifact Type:
template
Technical Committee:
OASIS ebXML Implementation, Interoperability and Conformance (IIC) TC
Chair:
Jacques Durand, Fujitsu <jdurand@us.fujitsu.com>
Editor:
Monica Martin, Sun Microsystems <monica.martin@sun.com>
Contributors:
Stephen Green, Individual Member <stephengreenubl@gmail.com>
Dale Moberg, Axway Software <dmoberg@us.axway.com>
Sacha Schlegel, Cyclone Commerce <sschlegel@cyclonecommerce.com>
Pete Wenzel, Sun Microsystems <pete.wenzel@sun.com>
Abstract:
(Refer to Section 1.1, Purpose.)
Status:
This document was last revised or approved by the OASIS ebXML IIC TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.
Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/ebxml-iic.
For information on whether any patents have
been disclosed that may be essential to implementing this specification, and
any offers of patent licensing terms, please refer to the Intellectual Property
Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ebxml-iic/ipr.php).
Notices
OASIS takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document or the
extent to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such
rights. Information on OASIS's procedures with respect to rights in OASIS
specifications can be found at the OASIS website. Copies of claims of rights
made available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or users of
this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to implement this
specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS Open 2006. All Rights Reserved.
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 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 OASIS,
except as needed for the purpose of developing OASIS specifications, in which
case the procedures for copyrights defined in the OASIS Intellectual Property
Rights document must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will
not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, 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.
Table of Contents
1.3 How to Use the Deployment
Profile Template
2 Profiling
the Modules of ebBP 2.0.x
3 Profile
Requirements Details
3.2 Defining a Business Transaction
Profile
3.2.1 Process Diagram of the
Business Transaction
3.2.2 Properties and Parameters of
the Business Transaction Pattern
3.2.3 Customization of the Business
Transaction Pattern
3.2.4 Common Characteristics for a
Business Transaction Pattern
3.2.5 Composing Complex Business
Collaboration Activities
3.3 Defining a Standard or
User-Defined Business Signal
3.3.1 Business Signal General
Profile
3.3.2 Common Characteristics for a
Business Signals
3.4 Defining the Business Document
Profiles
3.4.1 Profiling Table for Business
Documents
3.4.2 Profiling Table for
Attachments.
3.4.3 Common Characteristics for
Business Documents
3.5 Defining a Business
Collaboration Profile
3.5.1 Process Diagram of the
Business Collaboration
3.5.2 Properties and Parameters of
the Business Collaboration
3.5.3 Composing Complex Business
Collaboration Activities
3.5.4 Common Characteristics for
Business Collaboration
4.2 Deployment and Processing
Requirements for Business Documents
4.3 Deployment and Processing
Requirements for Business Transactions and/or Collaborations
4.4 Additional Aspects beyond
Business Transaction Specification
4.5 Additional Deployment or
Operational Requirements
1.1 Purpose
The ebXML ebBP 2.0 [ebBP2] contains several configurable features and options. Any use of ebBP requires a certain amount of standardization within a trading community. In order to foster interoperability on multiple levels between participants, these communities will want to (1) document additional conventions on ebBP process definitions and business content, and (2) define ebBP templates that may be partially filled-in, from which the user community can (or should) derive complete definitions. This profile template includes an initial set of modules to provide the capability to support these goals. More experience is being sought by relevant user communities and domains to continue to expand this profile template.
1.2 Terminology
The keywords must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119].
Source Specification: The specification or standard that is being profiled. Note, section references may exist in this document that are not for a source specification (such as to another section in this document). These are clearly differentiated.
Deployment Profile Template: Document that lists the
options in the source specification that may be selected by a user community,
that identifies content elements (e.g. message headers, XML values) the format
and/or value of which may be further standardized by a community, and that also
identifies typical operating conditions under which the source specification may
be used, and selected by a user community.
User Community: A group of users, e.g. within a supply-chain industry, the members of which decide to make a similar usage of the source specification in order to be able to interoperate.
Deployment Profile (or Deployment Guide): Document
that is an instance of the Deployment Profile Template. It defines which options
should / should not be used by this community, which format or value some
content elements should conform to, and under which operating conditions the
standard must be used by this community.
1.3 How to Use the Deployment Profile Template
There are three parts in the Deployment Profile Template that need to be instantiated in order to generate a Deployment Profile:
The section on the source specification modules (see section 2 below)
The section on the profiling requirement details (see section 3 below)
The section on operating conditions associated with the profile (see section 4 below)
Every feature from the source specification that is candidate for profiling is listed in a profiling table. Each profiling table corresponds to a functional subset of a CPA. In case a CPA element requires a detailed profiling recommendation, this will be specified in another table called a “profile requirement item” table, which is of the form:
|
Specification Feature |
<Description of the source
specification item to be profiled. This is pre-filled in the Deployment
Profile Template.> |
|
Specification Reference |
<Identifies the item in the
source specification. This is pre-filled in the Deployment Profile Template
> |
|
Profiling |
<how the item is profiled:
option narrowing/selection, content formatting, |
|
Alignment |
<dependency / alignment with
other data, e.g. binding, either with other |
|
Test References |
<references to related test
requirements or test cases, that would verify |
|
Notes |
<Profile-specific comments. This is left for a Deployment Profile to fill in.> |
When no recommendation is made for a profile requirement
item of the template, one of the following values MUST be used in the
“profiling” and “alignment” fields of
the table:
Not Applicable: for items that are not relevant to
the community.
No Recommendation: will indicate that there is no recommendation
or requirement for this feature item.
Pending: for items that are still under study for a recommendation, and for which some recommendation is likely to be specified in future versions of the Deployment Profile (yet, the user community did not want to wait for these to be specified before publishing a current version of the Profile or Guide.)
For items that specify text values, it should also be noted
whether or not the values are case-sensitive.
Two classes of users would be expected to collaborate in the instantiation of this Template to produce a Deployment Guide (or Profile):
Business Process Designers would detail the business-process specific requirements of the Message Service.
Technical Architects in user communities or vertical industries would make the technical decisions necessary to implement the business processes most effectively.
Consumers of a Deployment Guide include:
Business process implementers (IT departments), to deploy a Message Service solution according to the requirements of specific trading communities.
Software solution vendors, to identify all areas in which business process specification bodies require software flexibility, and what specific configurations are necessary to support such standards.
In this section, users will only specify which modules of the source specification are used in this profile (i.e. modules that business partners need to use or support in order to conform to the profile and communicate with others who do conform). For each used module, users also specify whether the module has been profiled or not. If yes, some profiling details should be given for this module in section 3 or 4. It is important and relevant to the development of all of these modules to reference and use the Business Transaction pattern matrices and well-formedness rules that exist in the technical specification. The pattern matrices provide guidance on the operational semantics surrounding the patterns. The well-formedness rules also further ensure consistency in the development of ebBP process definitions.
2.1 Modules
|
Module Name and Reference |
Business Transactions |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
|
Module Name and Reference |
Business Documents |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
|
Module Name and Reference |
Business Collaborations |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
|
Module Name and Reference |
Business Signals |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
|
Module Name and Reference |
Attachments |
|
Profiling Status |
Usage: <required / optional / never used in this profile> Profiled: <yes / no> |
|
Notes |
|
3.1 Introduction
This profile section provides detailed information about the key functional capabilities expressed in the ebBP and that may be used by a domain or user community to refine their use of this technical specification. Each table provides information on:
- The key function or capability, or specialization of that function
- The applicable information for that function or capability and possible usage
- Mapping that function to the element, attribute or group of attributes in the core or business signal schemas relevant to that function or capability
- References
back to the technical specification (where applicable) and/or to other
sections in this document relevant to that function or capability.
3.2 Defining a Business Transaction Profile
(NOTE: there should be one such section for each Business Transaction profile)
3.2.1 Process Diagram of the Business Transaction
Define the general flow of documents between partners, e.g.
using UML or related modeling or visualization notation. If business document
that are exchanged are to be profiled too, or constrained in any way, these
document profiles must be described in a later section (see Document Profiles)
and are only referenced from this diagram.
3.2.2 Properties and Parameters of the Business Transaction Pattern
The table or form that follows is used to identify the properties that are constrained for this business transaction profile. Several such tables may be used, depending on the Business Transactions that are profiled based on the Business Transaction pattern and used in a corresponding Business Transaction Activity. The profile will clearly state which elements are parameterized, which ones are fixed by the pattern, and where dependencies exist. Some range of values may also be defined for parameters. These properties are specified for each use of the Business Transaction Activity. It is important to note that the properties used in a Business Transaction Activity are in addition to those than the BT and BT pattern that is referenced. A separate profile may be created for BTA, as they also can be generically used in a modular process definition.
|
Form: Business Transaction properties |
|||
|
General properties |
Name |
[Provide the name attribute value for the business Transaction.] [name] attribute group |
|
|
Name ID |
[Used for referencing such as
identification of an element.] [name] attribute group |
||
|
Timing constraints |
[constraints on timing, e.g. TimeToPerform, time to acknowledge receipts] [TimeToPerform] element |
||
|
Non repudiation requirements |
[List non-repudiation requirements: non-repudiation of receipt, of identity/origin, and of content]. Note that these are related to business signals and the logical business document. [isNonRepudiationRequired]
attribute [isNonRepudiationReceiptRequired] attribute |
||
|
Type of business transaction |
[Which external category of business transaction is this profile associated with? E.g. which UMM transaction type? What kind of modification/customization does this profile represents w/r to the original transaction pattern? Are they within the selectable parameters of the patterns themselves? If not, what are the reasons for this customization (legal or other)?] [BusinessTransactionType] [BusinessTransactionHead] See: Set of concrete BT
patterns, operational matrices and extensibility pattern (Data Exchange)
derived from these. |
||
|
User-defined customization |
See upcoming section on customization of Business Transaction patterns. [DataExchange] element |
||
|
“BeginsWhen” Triggers |
[Event external to this activity that causes the activity to commence. Note, this external event must be publicly visible to the involved parties.] For example, when a product is delivered and a Receipt Advice to signal delivery or an Advanced Ship Notice is generated to signal that dispatch, an invoice is generated. [BeginsWhen] element |
||
|
“EndsWhen” Triggers |
[Event external to the activity that causes the activity to end. Note, this external event must be publicly visible to the involved parties.] For example, a registrant can have three times to pass a certification exam. If they fail three times and the certification process ends. [EndsWhen] element |
||
|
Pre-conditions |
[What other BT or message exchange is required to occur before this Business Transaction may take place.] Note: A description of a state external to this activity that is required before the activity can commence. Note, this external state must be publicly visible to the involved parties. Typically a PreCondition + other variables = BeginsWhen. For example, a purchase order must exist before an invoice can be generated. [PreCondition]
element |
||
|
Post-conditions |
[What other BT or message exchange is expected to take place after this Business Transaction occurs.] Note: PostCondition is a description of a state external to this activity that is required after the activity concludes (i.e. the state doesn't exist before the execution of this activity but does exist afterwards). Note, this external state must be publicly visible to the involved parties. Typically a PostCondition + other variables = EndsWhen. For example, a registrant fails to pass a certification exam three times, and a Business Failure occurs. [PostCondition]
element |
||
|
Roles and Parties |
Requesting role |
[any prescribed value or content rule for: Role name, ID ] [RequestingRole] element |
|
|
Responding role |
[any prescribed value or content rule for: Role name, ID ] [RespondingRole] element |
||
|
Requesting activity |
Document Envelope name and ID |
[any prescribed value or content rule for: name, ID, business document. How are these business documents referenced?] [DocumentEnvelope] element [name] attribute group |
|
|
(other Doc envelopes?) |
See above (can be 0…n). |
||
|
Business Signal Envelope Types Allowed and Used |
[any prescribed value or content rule for: name, ID, bus. doc. reference ] Define what business signals will be used with this Business Transaction Activity consistent with the BT patterns and BT used. If outside of this specification, see Section 3.2.3. For example, Receipt Acknowledgement and/or Acceptance Acknowledgement. [SignalEnvelopeType] complexType |
||
|
Business Signal Type |
Are the standard format of Business Signals used or a partner specific Signal? [SignalType] complexType |
||
|
Communication medium |
[What communication medium may/must
be used for this message exchange? For the associated business signals?] |
||
|
Responding activity |
Document Envelope name and ID |
[any prescribed value or content rule for: name, ID, bus. doc. Reference. How are these business documents referenced?] Note: Specify for each occurrence of the Document Envelope. The concept of a logical Business Document applies to the Document Envelope. That Business Document may be composed or assembled from many sources. There may be multiple Document Envelopes. There exists only one primary logical Business Document. See Section 3.4. [DocumentEnvelope] element [name] attribute group |
|
|
Business Signal Envelope Type Allowed and Used |
[any prescribed value or content rule for: name, ID, bus. doc. reference ] Define what business signals will be used with this Business Transaction Activity consistent with the BT patterns and BT used. If outside of this specification, see the succeeding section on Customization. For example, Receipt Acknowledgement and/or Acceptance Acknowledgement. [SignalEnvelopeType] complexType |
||
|
Business Signal Type |
[Are the standard format of Business Signals used or a partner specific Signal?] [SignalType] complexType |
||
|
Communication medium |
[What communication medium
may/must be used for this message exchange? For the associated business signals?] |
||
|
Complex Transactions |
Nested Transactions |
[Does this Business Transaction Activity depend on visibility to another Business Transaction specified in another process definition?] Note: This mechanism is for visibility only of a particular party. For example, a Supplier may only respond to a Purchase Order Request, after he has an indicator from a Distributor that a product component is available. The Supplier-Distributor relationship is specified elsewhere, such as in another Business Transaction outside of this definition. A ComplexBTA allows for nested BTAs to happen in a recursive sequential way and does not affect Business Transaction atomicity. The ComplexBTA provides a mechanism to implement / communicate dependencies between an actual business process (semantic process) and systems implementation of business processes (service choreography). A ComplexBTA is not a multi-party collaboration. [ComplexBusinessTransactionActivity]
element |
|
|
Composition |
Usage |
[How is this Business Transaction Activity to be composed?]
Note: When composition occurs in a domain or community, the transitions and condition expressions may differ. Therefore, they may be added later. This flexibility adds to the declarative power of ebBP. If the same Business Transaction Activity is defined for modular use and also within a Business Collaboration with other BTA, two profile items may be required to distinguish given the compositional characteristics may differ. As needed, add other criteria in the Operational profile. Map into the Business Collaboration profile item in upcoming section. |
|
|
Test References |
Spec (Spec package, ebBP v2.0.x) Note: Valid for all reference unless specified. |
||
3.2.3 Customization of the Business Transaction Pattern
This table or form that follows is used to identify the customized elements that the deployment profile allows or requires for the above business transaction pattern. The Business Transaction Pattern used for a Business Transaction and realized in a Business Transaction Activity allows certain specification by the involved parties. Customization may occur, within the scope of the specification, through an extensible pattern whereby the involved parties define the semantics and syntactic conditions. For example, [What kind of derivation can be done by the user, for defining business transactions that conform to this profile? If the derivation is outside of the scope of the available parameters of the template realized in this profile, is this a root pattern for future user-defined BTs? Is this pattern itself derived from a root BT?]
|
Customization Feature |
Description |
|
Extensions |
[If the customization extends outside of the standardized patterns, their selectable options, and defined semantics, what are the structure and semantics of such extensions?] [DataExchange] element |
|
Signal Variability |
[Are additional signals specified outside of the specification that should be included and aren’t available in the standard patterns of Business Transaction?] [SignalType] complexType (for specification) [SignalEnvelopeType] (for specification of the type of signal envelope such as ReceiptAcknowledgement) |
|
Others |
What other business semantics are to be used that exist outside of those specified (in addition to selections available via the technical specification and as held in the BT pattern matrices defined)? |
|
Test References |
Section 3.4.9.1, Spec |
|
Notes |
See upcoming section on customization of Business Transaction patterns. [DataExchange] element |
3.2.4 Common Characteristics for a Business Transaction Pattern
Across All
or Specific Usages
This profile item applies for Business Transactions within
or outside of the standard allowed set, if common characteristics apply. Specify
in common profile table for a particular Business Transaction pattern type
(i.e. for all Commercial Transactions).
|
Specification Feature |
[Commonality between different BTA based on a specific Business Transaction and BT pattern.] [BusinessTransactionHead] [BusinessTransactionType] See: Set of concrete BT patterns, operational matrices and extensibility pattern (Data Exchange) derived from these. |
|
Specification Reference |
Section 3.4.9, Spec |
|
Profiling |
Where applicable, this profile item involves common characteristics across all or some of the usages of a particular BT pattern. |
|
Alignment |
See Operational profile where applicable in Section 4. |
|
Common characteristics |
Which operational semantics apply as defined in the BT patterns or user defined matrices? Specify in detail such as document security, quality, non-repudiation, etc. |
|
Test References |
Section 3.4.9.1, Spec |
|
Notes |
|
3.2.5 Composing Complex Business Collaboration Activities
When Business Transaction Activities are defined based on the concrete Business Transaction or user-defined patterns, it is important to identify whether the overall picture whereby they could exist. For example a modular process definition may hold one Business Transaction Activity in a Business Collaboration. The expected outcome may be that several Business Transaction Activities can be combined in that Business Collaboration by a user community or domain, or a Business Collaboration with that one Business Transaction Activity is included in another process definition. In some of these cases, the condition expressions and use of transition are added to create a more complex Business Collaboration, CollaborationActivity or composed in different ways. A profile module for this capability is included in Section 3.5.3 and should be used in conjunction with this table.
|
Specification Feature |
[Composing Complex Business Collaboration Activities (for Business Transaction Activity)] [xi:include] [Specification] |
|
Specification Reference |
Section 3.4.6 (addresses use of
automated functions), Spec |
|
Profiling |
Are manual composition and/or use of XInclude to be used? If so, please specify. |
|
Alignment |
Partner agreements, references or other intentions may be defined outside of this technical specification. They serve as a guide to the composition of business process definitions using ebBP. What guides serve to assist in composition by the community involved? |
|
Test References |
See Section 3.5. |
|
Compositional characteristics |
Will the BTA and BC be combined in design or using the XInclude functionality? See Section 3.5. |
|
Notes |
The profile item should be consistent with and used alongside what is specified in Section 3.5 (and 3.5.3 specifically). These profile items are designed to be used in a complementary fashion. This profile item may map to operational details in Section 4 and also impacts Business Collaboration development in Section 3.5. This should be consistent with the profile items defined for Business Transaction Activities previously identified and as expressed in operational constraints in Section 4, where they apply. |
3.3 Defining a Standard or User-Defined Business Signal
(NOTE: there should be one such section for each Business Signal profiled)
3.3.1 Business Signal General Profile
This form that follows is used to define parts of a Business Signal, or constraints associated with these parts, that define a business signal profile. Note, that business signals are an integral part of the Business Transaction Activity, the BT and the pattern of which they are based. Such a profile will constrain the business signals that a user community may define and use, e.g. as use of the standard business signals or for those that are user-defined.
|
Form: Business Signal profile |
|||
|
General |
Profile identifier |
[identifier for this profile
item] |
|
|
Signal name |
[full name of the signal, e.g.
<ReceiptAcknowledgement>] |
||
|
Signal ID |
[name ID of the signal, to be
used in Signal element of ProcessSpecification] |
||
|
Schema location |
[to be used in xsi:schemaLocation
attribute] |
||
|
Signal Envelope Type |
[Also is consistent with and defines the value of isPositiveSignal attribute – positive or exception] |
||
|
Party and Role Info |
Originating Party |
[value to be used in
FromPartyInfo, in case this profile is associated with this originating
party. Specify also the type of this value.] |
|
|
Originating Role |
[value to be used in FromRole,
in case this profile is associated with a well-defined originating role.
Specify also the type of this value.] |
||
|
Destination Party |
[value to be used in
ToPartyInfo, in case this profile is associated with this destination party.
Specify also the type of this value.] |
||
|
Destination Role |
[value to be used in ToRole, in
case this profile is associated with a well-defined destination role. Specify
also the type of this value.] |
||
|
Security properties |
[List the message parts and
associated security requirements – non-repudiation parameters.] |
|
|
Message Part 1 |
[non-repudiation settings] |
|
|
Message Part 2 |
[non-repudiation settings] |
|
|
(others?) |
|
|
|
Process operational semantics |
Is non-repudiation of receipt
required? |
|
|
Certificates elements |
[List the certificates info and
ID.] |
|
|
Certificate 1 |
|
|
|
Certificate 2 |
|
|
|
(others?) |
|
|
|
Communication medium |
[What transport may/must be used
for this signal?] |
|
|
|
If this maps to a web service abstract operation (name), what are the:
[SignalMap] element [map] attribute group |
|
|
Business Transaction |
Business Transaction Activity |
[Specify what Business Transaction Activity of which these signals are integrated.] What role is associated with this signal? [businessTransactionActivityRef] attribute [roleRef] attribute |
|
Exception Signal |
Exception Signal Details |
If an exception signal is used, are there allowed reasons associated with such signals relative to the expectations of the involved parties? Note: Are these used for auditing or tracking purposes? For example, a Negative Acceptance Acknowledgement is related to Business or Performance reasons. |
|
Catastrophic Condition (Exception Signal) |
Exception Signals Details |
[Are general exceptions related to catastrophic conditions to be used? ] Note: These are outside of the choreography and Business Transactions themselves. [GeneralExceptionType] element |
|
Test References |
Sections 3.2 and 3.4.9.3, Spec Note: Requires cross-reference of SignalSchema and/or Schema, when the former standard signals are used. |
|
3.3.2 Common Characteristics for a Business Signals
Across All
or Specific Usages of a Particular Type
This profile item applies for Business Signals within or
outside of the standard allowed set, if common characteristics apply. Specify
in common profile table for a particular Business Transaction pattern type such
as for all Commercial Transactions for a Receipt Acknowledgement or more
generally for all Receipt Acknowledgements.
|
Specification Feature |
Commonality between different Business Signals
See: Set of concrete BT patterns, operational matrices and extensibility pattern (Data Exchange) derived from these. |
|
Specification Reference |
Section 3.4.9, Spec |
|
Profiling |
Where applicable, this profile item involves common characteristics across all or some of the usages of a Business Signal of a particular type (Receipt Acknowledgement, General Exception etc). |
|
Alignment |
See Operational profile where applicable in Section 4. |
|
Common characteristics |
Which operational semantics apply as defined in the BT patterns or user defined matrices? Specify in detail such as quality, non-repudiation, etc. |
|
Test References |
Section 3.4.9.1, Spec |
3.4 Defining the Business Document Profiles
(NOTE: there should be one such section for each Business Document profile)
In this section, the profiling of Business Documents is
outlined. Where applicable, Attachments may also be profiled with the
subsection provided.
3.4.1 Profiling Table for Business Documents
This form is used to define profiles for logical Business Documents that are to be used in Document Envelopes associated with Business Transactions.
|
Form: Business Document profile |
|||
|
Document name and ID |
[name] [nameID] [name] attribute group |
||
|
[Document Envelope(s) that instances of this Business Document profile can be bound to] [DocumentEnvelope] element |
|||
|
External References |
External Document Reference Name |
[reference to an external specification that this document must conform to. Any external elements (e.g. a UBL subset) that must be used for composing this document?] Note: This information may provide other third-party details to control the use of that Business Document. This could be a name, URN or other reference that cites an external specification or reference that defines the document. For example, a government procurement organization may choose variably to enable other requirements on structure to a Business Document. [externalDocumentDefRef |
|
|
Source Location |
[one or more locations for the reference business document.] [Specification] element |
||
|
Security requirements and
parameters |
|
[For example, tamper detection, confidentiality, authentication, etc.] Note: Relates to non-repudiation requirements associated with the BT pattern and BT used in the BTA. [documentSecurity] attribute
group |
|
|
Test References |
Section 3.4.9.5 on Business Document Flows, Spec |
||
|
Notes |
See the subsequent section on Attachments where applicable. |
||
3.4.2 Profiling Table for Attachments.
This form is used to define profiles for Attachments that may be used in Document Envelopes associated with Business Transactions and a logical Business Document.
|
Form: Attachments profile |
|||
|
Attachments |
Attachments Detail |
[These are typically unstructured documents that may be included with the logical Business Document such as an architectural drawing, image, etc.] [Attachment] element Is this attachment(s) always present? [minOccurs] attribute [maxOccurs] attribute What is its type? [mimeType] attribute |
|
|
[Name] [Name ID] |
[name] attribute group |
||
|
|
[Document Envelope(s) that
instances of Attachment profile can be bound to] |
[businessDocumentRef] |
|
|
|
Source Location |
[one or more locations for the reference attachment.] [Specification] element |
|
|
External References |
External Document Reference Name |
[reference to an external specification that this Attachment must conform to.] Note: This information may provide other third-party details to control the use of that Attachment. [externalDocumentDefRef] |
|
|
Security requirements and parameters |
Security |
[What security is required for the attachment?] [documentSecurity] attribute
group |
|
|
Test References |
Section 3.4.9.5 on Business Document Flows, Spec |
||
|
Notes |
See preceding section on logical Business Documents. Attachments are generally non-substantive in nature. |
||
3.4.3 Common Characteristics for Business Documents
Across All
or Specific Usages of a Particular Type
Any profiling info that is common to all Business Documents
parts or Attachments may be moved up to the general Business Document /
Attachments profile table. This profile item applies for Business Documents
and/or Attachments, if common characteristics apply. Specify in common profile
table for a class or type of business document such as all purchase orders.
|
Specification Feature |
Commonality between different Business Documents
See: Set of concrete BT patterns, operational matrices and extensibility pattern (Data Exchange) derived from these. |
|
Specification Reference |
Section 3.4.9, Spec |
|
Profiling |
[Where applicable, this profile item involves common characteristics across all or some of the usages of a logical Business Document of a particular type (all purchase orders for example), e.g. any reference to a particular vocabulary, external XML schemas, core components – UBL or UBL subset, OAG, etc.] |
|
Alignment |
Besides conformance to a document structure, any semantic constraint on content, format of fields, rules of composition. If some external methodology is used, what are the usage rules? See Operational profile where applicable in Section 4. |
|
Common characteristics |
Which operational semantics apply as defined in the BT patterns or user defined matrices? Specify in detail such as quality, non-repudiation of use and content, etc. [isNonRepudiationRequired] [documentSecurity] attribute
group |
|
Test References |
any reference to content validation artifact – semantic rules, Schematron file, etc. |
3.5 Defining a Business Collaboration Profile
(NOTE: there should be one such section for each Business Collaboration profile)
3.5.1 Process Diagram of the Business Collaboration
The general flow of documents between partners is described
here e.g. using UML or other visualization process notation. This general flow
should reference Business Transactions or profiles of these.
3.5.2 Properties and Parameters of the Business Collaboration
This table or form is used to identify the properties that are constrained by this business collaboration profile.
|
Form: Business Collaboration
properties |
||
|
General properties |
Name Name ID |
[Provide the name attribute value for the Business Collaboration.] [name] attribute group [BusinessCollaboration] element |
|
Timing constraints |
[constraints on timing, e.g. TimeToPerform for the Business Collaboration] [TimeToPerform] element |
|
|
Roles and Parties |
[What are the externally exposed roles? External roles map to the actual roles in a Business Collaboration.] [ExternalRoles] element |
|
|
Roles and Parties (continued) |
[What are the top-level or abstract partner roles?] [Role] element |
|
|
Referenced Business Transaction,
BT Pattern, and BTA |
[Used only when the concrete patterns are not used. Specify a URI for the definition of the pattern used.] [pattern] attribute |
|
|
Conditions on Business
Collaboration |
“BeginsWhen” Triggers |
[Event external to this Business Collaboration that causes the activity to commence. Note, this external event must be publicly visible to the involved parties.] [BeginsWhen] element |
|
|
“EndsWhen” Triggers |
[Event external to the activity that causes the activity to end. Note, this external event must be publicly visible to the involved parties.] [EndsWhen] element |
|
|
Pre-conditions |
[What other events, activities or message exchange is/are required to occur before this Business Collaboration may take place. Note, this external state must be publicly visible to the involved parties.] Note: A description of a state external to this Business Collaboration that is required before the Business Collaboration can commence. Typically a PreCondition + other variables = BeginsWhen. [PreCondition]
element |
|
|
Post-conditions |
[What other events, activities or message exchange is/are expected to take place after this Business Collaboration occurs. Note, this external state must be publicly visible to the involved parties.] Note: PostCondition is a description of a state external to this Business Collaboration that is required after the Business Collaboration concludes (i.e. the state doesn't exist before the execution of this Business Collaboration but does exist afterwards). Typically a PostCondition + other variables = EndsWhen. [PostCondition]
element |
|
Complex Business Collaborations |
Nested Business Collaborations |
[Does a Business Collaboration exist only in the context of another Business Collaboration (i.e. is dependent and an inner collaboration)?] [collaborationGroup] group |
|
|
Constraints |
Are there constraints on composition? Also see Section 4 for operational profile. |
|
Test References |
Sections 3.4, 3.4.1, 3.4.10, Spec |
|
3.5.3 Composing Complex Business Collaboration Activities
It is important to identify whether the overall picture of how Business Collaborations are anticipated for usage when Business Transaction Activities are developed. Business Collaborations may be modular or complex, include only one BTA or many, and have specific usages planned by a user community or domain. In conjunction with Section 3.2.5 (see section on Composing Complex Business Collaboration Activities), user communities may specific their compositional needs and/or preferences.
|
Specification Feature |
[Composing Complex Business Collaboration Activities] [xi:include] [Specification] |
|
Specification Reference |
Section 3.4.6 (addresses use of
automated functions), Spec |
|
Profiling |
Are manual composition and/or use of XInclude to be used? If so, please specify. |
|
Alignment |
Partner agreements, references or other intentions may be defined outside of this technical specification. They serve as a guide to the composition of business process definitions using ebBP. What guides serve to assist in composition by the community involved? |
|
Test References |
Section 3.4.6.3, Spec For the use of XInclude, this is limited to packages. Therefore, one or more package elements may be included using this function. This element must be inserted before validation occurs. The identification of these packages must be unique in the ebBP process definition (i.e. the nameID must be unique to avoid collisions). Also see Section 3.5.3. |
|
Compositional characteristics |
Will the BC and BTA (one or multiple are possible) be combined in design or using the XInclude functionality? What is name and nameID of the package to be included? The current ebBP technical specification allows use of the XInclude functionality. This can allow automated inclusion of packages, such as for compositional purposes. This may differ from or complement composing BTA and BC as the constructs are defined in design by a user community. |
|
Notes |
The profile item should be consistent with and used alongside what is specified in Section 3.2. This profile item may map to operational details in Section 4 and may also impact Business Transaction (Activity) development in Section 3.2. This should be consistent with the profile items defined for Business Transaction Activities previously identified and as expressed in operational constraints in Section 4, where they apply. |
3.5.4 Common Characteristics for Business Collaboration
This profile item applies to Business Collaboration if
common characteristics apply. Specify in common profile table for a set of or
all specified Business Collaborations. For example, a community may use the
Business Collaboration in a modular fashion where each includes only one BT
activity to allow flexibility of composition. Another domain may choose to
defer statement of timing to configuration, such as for the Collaboration
Protocol Profile (CPP) or Agreement (CPA) which is supported in this version of
the specification.
|
Specification Feature |
Commonality between different Business
Collaborations [BusinessCollaboration] [BinaryCollaboration] [MultiPartyCollaboration] |
|
Specification Reference |
Section 3.4.10, Spec Also supported by Sections 3.4.1
and 3.4.5, Spec |
|
Profiling |
Where applicable, this profile item involves common characteristics across all or some of the usages of Business Collaborations. |
|
Alignment |
See Operational profile where applicable in Section 4. |
|
Common characteristics |
What common characteristics may apply, for example:
|
|
Test References |
Section 3.4.10.1, Spec |
|
Notes |
This profile module should be consistent with the Operational specifics in Section 4 and may be influenced by the documented assumptions for the Properties and Parameters for Business Collaborations specified earlier in this section. |
This section defines the operational aspect of the profile: type of deployment that the above profile is supposed to be operated with, expected or required conditions of operations, usage context, etc.
4.1 Management Authority
For Business
Transaction and/or Collaborations Profiles and Definitions
|
Management Authorities |
Profile requirements |
|
Who is (are) the authority(ies) in charge of managing the BT / BC final definitions? Who has the authority and responsibility for:
|
e.g. each party could store and
manage Business Transactions (BT), or they could be stored and managed in a
third-party repository, e.g. in a registry/repository with a standardized
user authenticated interface to query and retrieve them. |
|
Who is the authority in charge of managing BT / BC templates from which final definitions can be instantiated? Who has the authority and responsibility for:
|
|
|
Others |
|
4.2 Deployment and Processing Requirements for Business Documents
|
Business Document definitions Management
Process |
Profile requirements |
|
Is a specific registry or
repository for storing Business Document required? What is its accessibility?
If so, provide access details. |
|
|
Is there a set of predefined Business Document profiles or templates that users should conform to? |
|
|
What is the validation process for Business Document instances? |
|
|
Others |
|
4.3 Deployment and Processing Requirements for Business Transactions and/or Collaborations
|
BT Management Process |
Profile requirements |
|
Storage: Is a specific
registry or repository for storing BTs or BT artifacts required? What is its
accessibility? If so, provide access details. |
|
|
BT creation: Is there a set of predefined BT profiles that should be used to create final definitions? How were they created? Any particular process to follow to create a definition? |
|
|
Security: How will certificates be managed and distributed? (procedure) |
|
|
Validation: What is the validation process for BTs that must conform to this profile?
|
How should a BT / BC final definition be tested for conformance to this profile? |
|
Monitoring: What are the
monitoring and auditing requirements for this business transaction? |
|
|
Others |
|
4.4 Additional Aspects beyond Business Transaction Specification
|
Additional Agreement |
Profile requirements |
|
Are there additional profiling
aspects (e.g. business-related) out of specification scope that this BT / BC profile
is part of, and that should be associated with it? |
|
|
|
|
4.5 Additional Deployment or Operational Requirements
|
Operational or Deployment
Conditions |
Profile requirements |
|
Operational or deployment
aspects that are the object to further requirements or recommendations. |
Recommended or required practices. |
|
|
|
5.1 Normative
[ebCPPA] OASIS, ebXML Collaboration-Protocol Profile and Agreement Specification
Version 2.0, http://www.oasis-open.org/committees/download.php/204/ebcpp-2.0.pdf,
[ebMS] OASIS, ebXML
Message Service Specification Version 2.0, http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.pdf,
[ebBP] OASIS, ebXML Business Process Schema Specification Committee Specification Version
2.0.4, http://docs.oasis-open.org/ebxml-bp/2.0.4/ebxmlbp-v2.0.4-Spec-cs-en.pdf,
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
5.2 Non-Normative
[ebDPT] OASIS, Metadata for Deployment Profile Templates, http://www.oasis-open.org/committees/download.php/19253/ebxml-iic-Deployment_Profile_Template-CD.doc.
In addition to editors or direct contributors, any individuals were members of the committee during the development of this specification or of a previous version of it, or commented to its development: The ebXML Business Process TC.
|
Rev |
Date |
By Whom |
What |
|
0.1 |
March, 2005 |
P. Wenzel J. Durand |
Initial Draft. |
|
0.6 |
|
Jacques Durand |
Add some editorial corrections, and content corrections based on feedback. |
|
0.8 |
|
M. Martin |
Add inclusion for package for Specification, add schema references, general improvements |
|
1.0 |
|
M. Martin |
Typographical and formatting cleanup only |