2 Design Objectives

2.1 Goals/Objectives/Requirements/Problem Description

ebBP definitions describe interoperable business processes that allow business partners to collaborate and achieve a given business goal. These definitions MUST be executed by software components that collaborate on behalf of the business partners.

The goal of the ebBP technical specification is to provide the bridge between eBusiness process modeling and execution of eBusiness software components.

The ebBP technical specification provides for the nominal set of specification elements necessary to specify a Business Collaboration between business partners, and to provide configuration parameters for the partners’ runtime systems in order to execute that Business Collaboration between a set of eBusiness software components.

A business process definition created with the ebBP technical specification is referred to as an ebBP definition.

The ebBP technical specification is available as an XML Schema (http://www.w3.org/2001/XMLSchema). The ebBP XML schema, that provides the specification for XML based ebBP definitions, can be found at this location:

http://docs.oasis-open.org/ebxml-bp/ebbp-2.0

(schema: ebbp-2.0.4.xsd)

The ebBP XML signal schema can be found at this location:

http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0

(signal schema: ebbp-signals-2.0.4.xsd)

In order to accommodate varying tool capabilities surrounding namespaces and directories using URIs, the URI for each schema has been updated. Current URI paths are found on the OASIS ebBP public web site at:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-bp

Under “’Technical Work Produced by the Committee’”

The schemas reflect the latest computable formats for an ebBP process definition.

2.2 Caveats and Assumptions

This technical specification is designed to specify the run time aspects of a Business Collaboration.

It is not intended to incorporate a methodology, and does not directly prescribe the use of a methodology. This specification does not by itself define Business Documents Structures. It is intended to work in conjunction with already existing Business Document definitions, and/or the document metamodel defined by the ebXML Core Components specifications.

The ebBP technical specification recognizes and concretely expresses the six defined, Business Transaction patterns-Commercial Transaction, Notification, Information Distribution, Request-Response, Request-Confirm, and Query Response. In the future, it is expected that new or additional business requirements (such as for metadata) may be defined for contractual agreements, acceptance, revocation of offers, etc. through efforts such as that of UN/CEFACT at a minimum.

Examples, sample instances and the glossary are non-normative in this technical specification. They are provided to aid the user community and implementers to use the ebBP v2.0.4 technical specification and associated schemas. In addition to portions of this technical specification, the ebBP and Business Signal schemas are related to and normative to this technical specification. The examples are held outside of the non-normative and normative packages to enable frequent updates.

2.3 Detailed Specification of Model Components

As with all the other specifications in the ebXML framework, an ebBP process definition may be effectively used with other technologies. The ebXML framework has been composed of several independent, but related or aligned, components. Specifications for each component can be used individually, composed as desired, or integrated with other evolving technologies.

From the onset, these specifications have sought to be aligned as much as practical and capable of being composed together and used with other technologies. That flexibility and composability are important aspects not only to the adoption of these standards but their effective use and successful deployment into heterogeneous environments and across domains. In the context of this technical specification, Business Collaborations may be executed using the ebBP process definition and/or used with other technologies. As it relates to the other specifications in the ebXML framework, an ebBP process definition supports the loose coupling and alignment needed to execute Business Collaborations. This specification may also be used when several other software components are used to enable the execution of Business Collaborations. One example is the use of web services mapped to business transactions activities. The ebBP technical specification is used to specify the business process related configuration parameters for configuring a Business Service Interface (BSI) to execute and monitor these collaborations. The ebBP business semantics and syntax are also well-suited to enable definition of modular process building blocks that are combined in complex activities to meet user community needs.

This section discusses:

· How the ebBP technical specification fits in with other ebXML specifications and may be used with other emerging technologies (such as WSDL). An ebBP process definition does not preclude composition with other process related technologies.

· How to use the ebBP artifacts at design time, either for specifying brand new collaborations and transactions, or for re-using existing ones.

· How to specify core transaction semantics and parameters needed for or that may be used by a Collaboration-Protocol Profile (CPP) or Collaboration Protocol Agreement (CPA).

· Run-time transaction and collaboration semantics that the ebBP schema specifies and the BSI is expected to manage.

As this technology matures and relevant profiles emerge, more compatibility points will be specified or conformance information (where appropriate and applicable) defined in the context of heterogeneous technology integration. For example, an ebBP profile is under development in OASIS ebXML Implementation, Interoperability Conformance (IIC) TC, based on their deployment template.

2.3.1 Use of ebBP With Other Specifications

The ebBP technical specification provides the structure and semantics of Business Collaboration definitions.

A Business Collaboration consists of a set of roles that collaborate by exchanging Business Documents through a set of choreographed transactions.

As shown in the following figure, Business Documents are defined at the intersection between the ebBP technical specification and the ebXML Core Component specifications. An ebBP definition will reference, but not define, a set of logical Business Documents. Within an ebBP definition, Business Documents are either defined by some external document specification, or assembled from lower level information structures called core components. The assembly is based on a set of contexts, many of which are provided by the business processes, i.e. collaborations that use the documents in their Document Flows.

The combination of the business process specification and the document specification become the basis against which business partners can make agreements on conducting electronic business with each other.

Figure 1: ebBP Definition and other ebXML artifacts

The user will extract and transform the necessary information from an existing Business Process and Information Model and create an XML representation of an ebBP definition.

The XML representation of the ebBP definition gets stored in the ebXML repository and registered in the ebXML registry for future retrieval. The ebBP definition would be registered using classifiers derived during its design.

When implementers want to establish trading partner Collaboration Protocol Agreement, the ebBP definition document, or the relevant parts of it, are simply referenced by the CPP and used in the CPA XML documents. ebXML CPP and CPA XML documents MAY reference business process specifications in XML such as an ebBP definition.

If one or more parties wish to participate on the basis of one or more web service definitions the corresponding WSDL file(s) associated to the BTA(s) that is(are) representing the party MAY be generated and MAY be referenced in the CPA if necessary.

Guided by the CPP and CPA specifications the resulting XML document then MAY become the configuration file for one or more BSI, i.e. the software component that MAY manage either business partner’s participation in a Business Collaboration.

2.4 Relationship to Other Specifications and Standards

This section describes the relationship of ebBP technical specification to other specifications and/or standards. Later in Section 3, use of this specification with CPA is discussed in further detail.

2.4.1 Relationship to CPP/CPA

An ebBP definition is, along with protocol specifications, the object of the agreement between two or more parties. The ebBP definition MAY therefore be incorporated with or referenced by ebXML trading partner CPP or CPA. The CPA articulates the technical mechanisms that configure a runtime system and encourage interoperability between two parties that may use different applications or software from different vendors.

Each CPP MAY declare its support for one or more Roles within the ebBP definition. An ebBP definition is also a machine interpretable specification needed for a BSI, which will enforce its definition at run-time. The CPP profiles and CPA agreements contain further technical parameters resulting in a full specification of the run-time software at each trading partner. The CPA currently supports the notion of business transactions between collaborating roles.

Messaging and CPA support conversations between parties. Each individually and collectively map to the ebBP. The ebBP schema (and technical specification) provides guidance to the CPA and messaging service regarding the processes used, the constraints expected, and the relationship that exists between the parties.

2.4.2 Relationship to Core Components

The ebBP technical specification does not by itself support the definition of Business Documents. Rather, an ebBP definition merely points to the definition of logical Business Documents.[3] Such definitions MAY either be XML based, or – as attachments – MAY be any other structure, or completely unstructured (e.g. related to images, EDI, binary data). XML based Business Document Specifications MAY be based on the ebXML Core Components Technical Specification (CCTS) such as OASIS Universal Business Language (UBL) specifications. In the addition to the non-normative appendices to this technical specification, example instance will be included in a separate package, publicly available on the OASIS web site to aid user communities. These examples or illustrations of ebBP v2.0.4 instance use relevant document vocabularies such as UBL and its corresponding Small Business Subset (SBS) to equate the use of ebBP in real-world scenarios.

In ebBP, transitions are handled by state changes, whether sequential or determined through the transitions. These transition conditions MAY relate to the sequential ordering handled by the messaging and where those ebBP expectations MAY be enforced. The relationship between the Messaging Service Interface and the BSI are further described in the appendices to this technical specification.

2.4.3 Relationship to ebXML Message Service Specification

The ebBP technical specification will provide choreography of business messages and signals. The ebXML Message Service Specification provides the infrastructure for message / signal identification, typing, and integrity; as well as placing any one message in sequence with respect to other messages in the choreography.

Messaging and CPA support conversations between parties. Each individually and collectively may map to the ebBP. The ebBP schema (and technical specification) provides guidance to the CPA and messaging service regarding the processes used, the constraints expected, and the relationship that exists between the parties.

2.4.4 Relationship to WSDL

This version of the ebBP technical specification provides a mapping between BTAs (i.e. the usage of a Business Transaction definition in a Business Collaboration definition) and operations of one or multiple web services. The support of WSDL operations is intended for the design of Business Collaborations in which one or more of the business partners are not capable of supporting ebXML interchanges. The mapping provides the capability to map request, possible responses and signals to abstract operation messages. The reference to an actual WSDL file is specified as part of the Collaboration Profile Agreement (such as namespace references).

The correlation between the different operation invocations is implemented at run-time. The specification does not provide any design-time correlation specification but recommends the use of run-time correlation and endpoint references based on emerging addressing mechanisms such as WS-Addressing, WS-MessageDelivery or others.

Correlation can provide additional functionality that could be desired where complex composed activities occur, and visibility of the parties and their activities must be managed.

Implementation note

The possible capabilities of the underlying infrastructure and services chosen may impact the capability to support business requirements defined by the involved parties. For example, specific constraints may apply to WSDL-based exchanges that may not exist for those implementations using ebXML Messaging Service.

2.4.5 Relationship to Registry/Repository

Although independent, the ebXML components are designed to work together in a loosely coupled fashion. At a minimum, the ebXML Registry/Repository could allow the discovery and use of ebBP instances. If artifacts are given a classification, the instances and the profiles of the BT patterns could be part of a business process catalogue. They may be available to an industry group, enterprise or entity. The ebXML Registry/Repository provides the capability to version and manage such artifacts (See preceding figure and a similar one in Section 3).

3 Language Overview

The ebBP technical specification defines a standard language for business process specification. An ebBP definition works with the ebXML CPP/CPA specification to bridge the gap between Business Process Modeling and the configuration of eBusiness software (See following figure). The software component that manages Business Collaborations on behalf of one business partner is referenced in this specification as the BSI. A detailed discussion on the BSI can be found in the appendices to this technical specification. The BSI supports predictable eBusiness interactions. However, this does not specifically limit the use of ebBP technical specification to those interactions. This technical specification supports the computable and executable language used for Business Collaboration, rather than the processing accomplished from the view of a single party. Predictability is supported within the scope of and at the level of abstraction that a Business Collaboration operates. The functions are described in this technical specification.

A business process specification may be used to guide other executable process mechanisms to drive enterprise components where Business Collaboration definition enables monitoring and/or control (rather than creation) of service behavior.

Figure 2: Business Process Specification and Business Service Interface Configuration

Using business process modeling, a user MAY create a complete business process and information Model.

Based on this model and using the ebBP technical specification the user will then extract and format the nominal set of elements necessary to configure an ebXML runtime system in order to execute a set of ebXML Business Transactions. The result is an ebBP definition.

Alternatively the ebBP definition MAY be created directly, without prior explicit business process modeling.

An ebBP definition contains the specification of Business Transactions and the choreography of these Business Transactions that are included in Business Collaborations.

This ebBP definition may then be the input to the formation of ebXML trading partner Collaboration Protocol Profiles and Collaboration Protocol Agreements.

These ebXML trading partner Collaboration Protocol Profiles and Collaboration Protocol Agreements in turn serve as configuration files for BSI software component.

Implementation Note:

When a reference is generically made to a “BSI”, it may logically represent middleware, applications, backend systems, software or services. These components may exist within a logical enterprise (one or more domains of control). The BSI was a key component in the original ebXML framework.

The BSI represents an important component in realizing eBusiness automation and deployment. The BSI MAY be configured from an ebBP definition and a CPA. The architecture of the ebBP technical specification consists of the following functional components:

· A representation of Business Collaboration using accepted business process modeling techniques. Representations in this specification use the Business Process Modeling Notation (BPMN).

· XML Schema definition of the ebBP definition. Each ebBP definition MUST conform to this schema definition.

· Business Signal Definitions

Together these components allow you to specify the run time aspects of a business process model within the scope of this current version of the ebBP . However, all the parameters of the ebBP definition are intended to be specified at design time rather than specified or inferred at run-time. However, some values may be acquired or quantified at other than design time.

These components are shown in Figure 3 that follows.

Figure 3: Relationship of ebBP technical specification to UMM, CPP/CPA and Core Components

Implementation Note:

Throughout this document, typically business partner is used when related to agreement between parties. Trading partner is used when related to CPA. Party is typically used when related to a role that a business partner plays, such as a responding party.

3.1 XML Schema Representation of Business Process Definitions

The corresponding XML Schema representation of the ebBP technical specification provides the specification for XML based definitions of an ebBP schema, and MAY serve as a target for production rules from other representations. Thus, a user MAY either create an ebBP definition directly as an XML document or from other representations.

Any methodologies and/or metamodels used for the creation of ebBP definitions MUST at a minimum support the production of the elements and relationships contained in the XML representation of the ebBP technical specification and defined in the ebBP schema. Well-formedness rules are specified in order to facilitate the understanding and use of the XML schema representation of the ebBP technical specification.

The complete XML schemas (core and signal) and their association documentation are provided in separate Schema and Signal Schema packages. Example XML instances are provided in a non-normative package outside of this technical specification and the appendices to aid user communities.

3.2 Business Signal Definitions

A Business Signal is an object that is transmitted back to the activity that initiated the transfer of execution control. Business signals have a specific business purpose and are separate from lower protocol and transport signals as defined in the ebXML Message Service Specification. The state of a given Business Transaction Activity (BTA) instance can be explicitly calculated at run-time by evaluating these signals. As such they are instrumental in establishing a Business Collaboration protocol that insures that the representation of the state of a Business Collaboration instance for each party, is strictly identical. For example, an Acceptance Acknowledgement signal is generated after an application, service or middleware[4] has successfully processed and business validated a Business Document. The process of exchanging signals and state changes of a Business Transaction enables "state alignment" between the parties involved. The structures of ebXML Business Signals are ‘universal’ and do not vary from transaction to transaction. Thus, they can be defined once and for all. The Signal schema is in the packages that support this technical specification.

The ebBP technical specification provides both the structure and choreography of Business Signals. The ebXML Message Service Specification provides a reliable messaging infrastructure. This is the basis upon which the ebBP technical specification builds its protocol for business state alignment using Business Signals. The Business Signal payload structures are optional and normative and are intended to provide business semantics to the Business Signals.

A schema is provided for the possible Business Signals. Examples of sample signal instances are available in addition to this technical specification and the appendices. They may be found on the OASIS web site in a non-normative example package.

3.3 Well-Formedness Rules

A starting set of well-formedness rules is provided to aid implementers in using ebBP technical specification constructs. In Section 3.8, well-formedness rules exist for the use of, at a minimum:

· Business Collaborations

· Time To Perform

· Notification of Failure and exceptions

· Condition expressions and variables

· Web services operations

· Packages and includes

Referential and functional constraints are described in Section 3.8. Other well-formedness rules will be defined as more industry and user community knowledge and requirements are available.

3.4 Key Concepts of This Technical Specification

The ebBP specification specifies the structure and semantics of machine processable Business Collaborations definitions. These semantics are aligned with guiding principles relevant to business processes such as the UMM.

At a high level, a Business Collaboration consists of a set of roles collaborating through a set of choreographed Business Transactions by exchanging Business Documents.

These basic semantics of a Business Collaboration are illustrated in Figure 4.

Figure 4: Illustration of the basic semantics of a Business Collaboration

Two or more business partners participate in the Business Collaboration through roles. The roles always exchange messages in the context of Business Transactions. Each Business Transaction consists of one or two predefined Business Document Flows. One or more Business Signals MAY additionally be exchanged as part of a Business Transaction to ensure state alignment of both parties. The Business Collaboration is defined as a choreography of Business Transactions performed relative to each other.

The following section describes the concepts of a Business Collaboration, a Business Transaction, a Business Document Flow, and Choreography. Business messages and Business Signals are discussed throughout. A business message is typically associated with a Business Document Flow rather than a Business Signal.

3.4.1 Business Collaborations

A Business Collaboration is a set of Business Activities executing Business Transactions between business partners or collaborating parties. Each business partner plays one or more abstract partner roles in the Business Collaboration. The state of the Business Collaboration is logical between the parties interacting in a peer-to-peer rather than a controlled environment. The virtual state of the Business Collaboration lies with the involved partners. Peer-to-peer collaboration may involve business partners as well as distributed collaborating parties. For the latter, one example may be cross-organizational collaboration between parties involved in technical publishing where the nested, complex activities may be required to support an authoring process. Cross-organizational collaboration may occur in many organizations, such as those government departments and agencies enabling eGovernment. The relevance of and use of the business transaction patterns in such an environment is discussed in the book by Robert Glushko and Tim McGrath, Document Engineering - Analyzing and Designing Documents for Business Informatics and Web Services.[5]

The ebBP technical specification supports several levels of Business Collaborations. Business Collaborations can be specialized as Binary or Multiparty (Business) Collaborations.[6]

When a Business Collaboration is specialized, a Binary (Business) Collaboration involves two top-level or abstract partner roles only. For the purposes of this specification, these roles are sometimes called abstract partner roles. Multiparty (Business) collaborations involve more than two abstract partner roles. Business Collaborations are expressed as a set of Business Activities between these roles. Each abstract partner role occupies a specific role when associated with a Business Activity.

The Business Activity can be a Business Transaction Activity (i.e. the activity of conducting a single Business Transaction) or a Collaboration Activity (i.e. the activity of conducting another Business Collaboration such as a Binary (Business) Collaboration within another Binary (Business) Collaboration). An example of the former is the activity of “process purchase order”. An example of the latter is the activity of “negotiating a technical contract”. The example instances, found on the OASIS web site show how an ebBP definition could be used for CPA negotiation. In either case the activities can be choreographed relative to other activities as per below.

The ability of a Binary (Business) Collaboration to have activities that in effect are executing others is the key to recursive compositions and re-use of Business Collaborations.

In essence each Business Collaboration is a re-useable protocol between two or more agreeable parties that may assume and occupy different roles at various steps in the process.

Typically, a Business Transaction is defined once. However, the BT could appear many times as different Business Transaction Activities, where the roles change within the same Binary (Business) Collaboration, such as for an Offer and Counter Offer. As shown in the CPA example in the non-normative examples package, this is a known case in CPA negotiation. An activity, whether it is a Business Transaction Activity (BTA) or a Collaboration Activity represents the usage of a definition within another Business Collaboration. In the Business Transaction Activities, the abstract role in the Business Transaction becomes a specific role, where roles may change within the same Binary (Business) Collaboration. In that case, either abstract role in the Business Transaction MAY assume the initiating role in the BTA.

Business Collaboration between more than two abstract partner roles (i.e. Multiparty Collaboration) may be conducted in many presumed ways, including using coordination or as a community of peers. Functions to support Multiparty Collaboration may include status visibility, state alignment, identity, business constraints, etc. Business requirements are being gathered to gain more understanding of and define constructs for complementary functionality to support this type of Business Collaboration in addition to capabilities in this technical specification.

3.4.2 Business Transactions

A Business Transaction represents an atomic unit of work that may be associated with a trading arrangement between two business partners. The scope of the ebBP technical specification is to articulate more fully the Business Transactions, rather than primarily focusing on their relationship to trading arrangements between business partners. In the future, more requirements are anticipated to further express this relationship, such as from UN/CEFACT. Atomicity in the context of this technical specification is outlined in the glossary at the end of this document.

A Business Transaction is conducted between two parties playing opposite abstract roles in that transaction. Each party, as an abstract partner, assumes an abstract role in a Business Transaction. Those roles are always generic and labeled as Requesting and Responding roles. The specific roles (e.g. buyer, seller) MUST be specified at the Business Transaction Activity level, when the Business Transaction definition is used for a distinct purpose. At that point, the abstract partner assumes and occupies a specific role, as a role occupant. Only two role occupants may be active at one time in a BTA.

Like a Binary (Business) Collaboration, a Business Transaction is a re-useable protocol between two abstract roles (explicit generic Requesting and Responding Roles). The way it is re-used is by referencing it from a Binary (Business) Collaboration through the use of a BTA as per above. In a Business Transaction Activity the specific roles of the Binary (Business) Collaboration are assigned to the execution of the Business Transaction. As indicated in the previous section, a Business Collaboration may be composed within another Business Collaboration via a Collaboration Activity. Each abstract partner participates in the Business Collaboration and occupies different role (occupants) in the included Business Transactions. How the external role in a Business Collaboration maps to the roles defined within the enclosed Business Transactions is mapped to a series of role relationships. How this is accomplished using the Performs element and external role mapping is found later in Sections 3.4.5 (shows Multiparty interactions) and 3.4.10.1.

Unlike a Binary (Business) Collaboration, however, the Business Transaction is atomic; it cannot be decomposed into lower level message exchanges that could be reused independently of each other.

A Business Transaction is a very specialized and very constrained protocol used to achieve very precise and support enforceable transaction semantics and achieve state alignment when needed between both parties. The software component managing the Business Transaction, i.e. a BSI component, SHOULD enforce these semantics. For example, the BSI monitors the timers and requirements of the Business Collaboration. It is important to note that the BSI MAY interact with other software components that check the validity of business messages or documents or perform other monitoring or application functions. A Business Transaction MUST succeed or fail from both a technical and business protocol perspective. If it succeeds from both perspectives it MAY be designated as having shared intent between the two business partners, or otherwise govern their collaborative activity. As defined by the parties’ expectations, if it fails then it is null and void, and each partner MUST terminate and release any shared statement established by the transaction[7]. In addition, if it fails from protocol perspective, each party MUST synchronize their state to the state prior to the start of the transaction. For instance, a purchase order state should advance to “sent” when and only when the BSI reports a Protocol Success. In the case of a Business Failure, the state has already been “synchronized” and it is the duty of each application or service to take the proper actions. A Business Failure is any Failure that is identified by an application or service during the processing of the Business Document(s) and based on information not available in or part of the ebBP instance. For instance, a “reject purchase order” response document would be considered as a Business Failure. In this case, it is the role of the applications to mark the state of the purchase order appropriately. Success and failure, the conditions and guards defined, and their relationship to Business Document Flows and Business Signals is detailed later in Section 3 (particularly Section 3.6.3).

The Business Transaction is defined as an abstract super class. It is associated with the six concrete Business Transaction patterns defined in the UMM:

· Commercial Transaction

· Information Distribution

· Notification: Note, the Notification of Failure business transaction is based on the Notification pattern.

· Query Response

· Request Confirm

· Request Response

These patterns are the semantic guidance of the Business Transaction itself. A relationship exists between the format/requirements of the pattern and the semantics of each concrete Business Transaction pattern (that map to those in the UMM). Operational semantics and other criteria apply to these patterns. Where specified in a separate contract or agreement, any of these patterns may be intentional,[8] and provide the basis of any obligation to yield accurate information.

Agreements or other business requirements may guide or change the criteria surrounding any interaction between business partners, which correspondingly influences the technologies used (such as that defined in a BSI or MSI). In essence, the guidance could result in a profile of the criteria selections of the defined pattern of the involved parties. Where the agreements actually change the baseline assumptions of these patterns, this could result in a partner-specific pattern and a subsequent profile. This is discussed in further detail in Section 3.4.9.1.

3.4.3 Business Document Flows

A Business Transaction is realized as Business Document Flows between the Requesting and Responding parties performing roles. There is always a logical Requesting Business Document, and optionally a logical Responding Business Document, depending on the desired Business Transaction configuration: e.g. one-way notification (not Notification of Failure) or information vs. two-way conversation.

The actual Business Document definition MAY be achieved using the ebXML CCTS and other related specifications. This may also be achieved by some methodology external to ebXML such as OASIS Content Assembly Mechanism (CAM). The specific context, format or other business requirements may require different approaches to provide the schema definitions (XSD or DTD) used for message exchange and which an ebBP definition can logically reference.

3.4.4 Choreography

The Choreography of a Business Collaboration describes the ordering and transitions between Business Transactions or sub collaborations within a Business Collaboration. For example, in a UML tool this could be represented with a UML activity diagram. Actually, the choreography can be specified in the ebBP schema using activity diagram concepts such as: start state, completion state, activities, Forks, Joins, decisions, transitions between activities, and guards on the transitions. It can also be specified visually in other notations such as the BPMN. However, it is beyond the scope of this document to dictate or specify which notation is used to represent a Business Collaboration.

3.4.5 How to Design Business Collaborations and Business Transactions

This section describes the this specification by building a complete Multiparty (Business) Collaboration ebBP instance from the bottom up, as follows:

1. Specify a Business Transaction

2. Specify the Business Document Flow for a Business Transaction

3. Specify a Binary (Business) Collaboration re-using the Business Transaction

4. Specify a Choreography for the Binary (Business) Collaboration

5. Specify a higher level Binary (Business) Collaboration re-using the lower level Binary (Business) Collaboration

6. Specify a Multiparty (Business) Collaboration

Although this section, for purposes of introduction, discusses the specification of collaboration from the bottom up, the ebBP technical specification is intended for specifying collaborations from the top down, re-using existing lower level content as much as possible.

The constructs listed above support the specification of arbitrarily complex Multiparty Collaborations. However, an ebBP definition MAY be as simple as a single Binary (Business) Collaboration referencing a single Business Transaction as part of a single BTA. This involves steps 1-3 above. Note, the ebBP technical specification does not specify any Business Process modeling methodology nor does it require the use of such methodology. A business process specification may be modeled in the BPMN or Unified Modeling LanguageÔ (UMLÔ)[9] activity diagrams, for example.

The example shows a “drop ship”, which involves a customer, a retailer, a vendor, and a credit authority. The order is placed by the customer and fulfilled by the vendor. The credit authority makes sure that payments are made to appropriate creditors. In the scenario, the credit authority is only capable of supporting Web Services. The standard BPMN is used for the diagrams to give a pictorial representation of this Multiparty Collaboration. The BPMN (notation) provide businesses with the capability of defining and understanding their internal and external business procedures through a Business Process Diagram, which will give organizations the ability to communicate these procedures in a standard manner. BPMN is focused on business process modeling for business analysts, using key transaction, task, activity, and pool constructs known by such experts.

The use of this notation is non-normative and described in the referenced in the adjoining footnote.

The following figure represents the overall Multiparty Collaboration using BPMN[10]. A new notation construct, a Joint Activity, is under consideration (but not yet complete) by the BPMN team at the Object Management Group (OMG). Therefore, the diagrams herein have extended BPMN to integrate that anticipated construct. In addition, comments have been received on the BPMN v1.0 specification related to message and sequence flows, and underlying semantics, and may be subject to change. The use of such flows could also change given the inclusion of collaboration constructs and support their intended use in an ebBP process definition context.

In a high-level ebBP Business Process Diagram (BPMN terminology for this visual representation), many of the BPMN constructs are used including Pool, Gateway, Sequence Flow, Message Flow, Activity, and Data Object in addition to Joint Activity. For Business Collaboration, there may be other notation constructs or semantics recommended or required. As of the date of this technical specification, these characteristics indicative of Business Collaboration are being discussed between the two teams, and considered for integration in an incremental update to BPMN v1.0 or a future specification in OMG.

Figure 5: Representation of the “DropShip” Multiparty Collaboration with a BPMN diagram

All Binary (Business) Collaboration in the example feature only one BTA except two of them: Credit Charge and Product Fulfillment. They are represented on the following figure using the same convention.

Figure 6: Representation of the “CreditCharge” and “ProductFulfillment” Binary (Business) Collaborations

3.4.6 Packages, Includes and Specifications

3.4.6.1 Packages

All elements of this specification are defined within the context of a package. Packages may contain other packages, therefore defining a hierarchy of packages. A package supports the inclusion and substitution mechanisms in the ebBP schema. Packages can be included in and reused by multiple ebBP instances.

A package defines the namespace of the elements inside it. Two model elements, such as sub-packages, with the same name within the same package MUST NOT be allowed. Two packages cannot have the same name. Model element names may be qualified.

If a model element in package Order Entry needs to name something in a package called Billing, it MUST include this package to make its elements visible to its own model elements. Use of include requires that all model elements from the Billing package be fully qualified. So in order to designate the Invoice Business Document within the Order Entry.Process Purchase Order transaction, we need to refer to the Billing.Invoice document, assuming it is defined in the Business Transaction.Billing package.

The use of XInclude provides an ebBP definition with an assembly mechanism that points to a URL that specifies a location from where the specification can be retrieved. It MUST point to a an existing resource. More details on the use of XInclude may be found later in this section.

3.4.6.2 Specification element

A Specification element provides the type, location, target namespace and identifiers of the specified elements. If the logical Business Document uses different namespaces, each of which has a schema, any or all may be specified using a sequence of Specification elements. For example, the retail industry uses a logical Business Document and requires different parts be identifiable (i.e. multiple references to the content structure exist which may include multiple schemas and/or namespaces). The specificationVersion may be “2” while the actual (current) artifact document version is “2.0.4”.

It is relevant to note that the ebBP technical specification focuses on the logical Business Document not a wire format. The goal was to keep logical separation of functions between implementation and the processes described. The logical business document is a semantic document. It describes the semantic content and purpose of a physical document and also may include the semantic business objective. For example, a physical Purchase Order Response document may be mapped to two or more logical documents in ebBP, "AcceptPOResponse" / "RejectPOResponse" or "ShipImmediatePOResponse" / "HoldForReleasePOResponse". The logical business document drives the business process. This allows the flexibility to describe and use semantic information from a business perspective while remaining agnostic to what happens at transport level in order to move through a series of states given the transfer of a business document.

Business documents also convey states. The ebBP process definition can provide a semantic view of how the semantic document type, its state and key elements can be used to drive the business process. This logical view maintains the value of the business process and its underlying business collaboration states. In addition to use of variables on condition expressions that are semantic element declarations (see Section 3.4.11.1.1) that drive the process, an external document reference is available in the Specification element, called externalDocumentDefRef. An example of its use could be, a local government may have variability in how procurements occurs. Using the externalDocumentDefRef (in addition to other Specification detail), that entity may need to point to third-party information to provide additional detail to control the use of that business document. This functionality is particularly relevant for user communities interested in using such as Universal Business Language (UBL) , UBL SBS or high technology trading domains.

The logical business document also provides a DocumentSpecificationType that points to more information about that specification. This capability also may assist in providing a hint to a system, while also allowing an application, middleware or a service, to bound what it may be capable of processing. An ebBP implementation MAY use DocumentSpecificationType element to point to implementation specific details that it is capable of processing.

For example, several user communities are or anticipate using a small business UBL subset, the use of a hint could enable an iterative step to automate their processes and provide flexibility in the use of context or semantic conditions understood by those groups. In this scenario, the use of 'other' enumeration value for the DocumentSpecificationType allows the integration of a human decision into a process (alert). The message exchange at the transport level and as defined in the CPA, resolve down to physical Business Documents. In addition, by user community request, 'schematron' has been added as an enumeration value to assist in providing a pointer to validation capabilities.

3.4.6.3 Include elements

If needed, only package elements MAY be included in an ebBP instance document. One or more package elements (such as elements from other ebBP instances) MAY be included using the XInclude include element. A document referenced by an include element MUST be inserted before schema or DTD validation is attempted.

<ProcessSpecification

xmlns="http://docs.oasis-open.org/ebxml-bp/ebbp-2.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xi="http://www.w3.org/2001/XInclude"

name="PurchasingCluster" nameID="PC23"

uuid="urn:purchasingcluster" specificationVersion="2"

instanceVersion="1">

<xi:include href="signals-package-2.0.4.xml" parse="xml"

xpointer="element(/1/1)"/>

<Specification type="schema"

location="ubl-1-0-SBS-cs/xpaths/xml/XPath/Invoice-XPath.xml"

targetNamespace="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0"

name="Invoice" nameID="invoice32”

externalDocumentDefRef=”urn:oasis:names:tc:ubl:xpath:Invoice-1.0:sbs-1.0"/>

</BusinessDocument>

<BusinessDocument name="InvoiceResponse"

nameID="bd-invoiceResponse">

<Specification type="schema"

location="http://purchasingcluster.com/InvoiceResponse.xsd"

name="InvoiceResponse" nameID="invoice33"/>

</BusinessDocument>

<RequestingBusinessActivity name="ReqBA:SendInvoice"

nameID="debareq-invoice"

timeToAcknowledgeReceipt="PT6H"

timeToAcknowledgeAcceptance="PT12H">

<DocumentEnvelope name="DE:ProcessInvoice"

nameID="data-de-invoice" businessDocumentRef="bd-invoice"/>

</RequestingBusinessActivity>

<RespondingBusinessActivity name="ResBA:ReceiveInvoice"

nameID="debares-invoice">

<DocumentEnvelope name="DE:ProcessInvoiceResponse"

nameID="data-de-invoiceResponse"

businessDocumentRef="bd-invoiceResponse"/>

</RespondingBusinessActivity>

</DataExchange>

<RequestingBusinessActivity name="ReqBA:SendInvoice"

nameID="reqba-invoice"

timeToAcknowledgeReceipt="PT6H"

timeToAcknowledgeAcceptance="PT12H">

<DocumentEnvelope name="DE:ProcessInvoice"

nameID="bt-de-invoice" businessDocumentRef="bd-invoice"/>

<ReceiptAcknowledgement name="sira" nameID="sira1"

signalDefinitionRef="ra2"/>

<ReceiptAcknowledgementException name="sirae"

nameID="sirae1" signalDefinitionRef="rae2"/>

</RequestingBusinessActivity>

<RespondingBusinessActivity name="ResBA:ReceiveInvoice"

nameID="resba-invoice">

<DocumentEnvelope name="DE:ProcessInvoiceResponse"

nameID="bt-de-invoiceResponse"

businessDocumentRef="bd-invoiceResponse"/>

<ReceiptAcknowledgement name="sira" nameID="sira2"

signalDefinitionRef="ra2"/>

<ReceiptAcknowledgementException name="sirae"

nameID="sirae2" signalDefinitionRef="rae2"/>

</RespondingBusinessActivity>

</BusinessTransaction>

</ProcessSpecification>

In this example, Signals-package-2.0.4.xml is the target xml document that will be parsed as xml and whose first child Package element of the ProcessSpecification element will be inserted. In this example the XInclude reference will resolve the ra2 and rae2 signal references.

See the http://www.w3.org/2001/XInclude namespace. Implementers MUST ensure that attribute values of nameID are unique (i.e. no collisions occur). ebBP implementations MUST process the XInclude include element by making the appropriate insertions prior to schema or DTD validation is attempted. The XInclude mechanism replaces the include element in previous versions of ebXML BPSS.

If a package has a parent, the parentREF will enable inclusion all elements in the package’s hierarchy or tree. Then, an implementer MAY be capable of recreating a tree without relying on package names.

Arbitrary or invalid construction using XInclude is not recommended. In this technical specification, the effective use of XInclude SHOULD be restricted to inclusion of packages only (that may include other packages). This simple approach facilitates the use of this mechanism to support composition of ebBP definitions.

3.4.7 Versioning

The ebBP technical specification supports versioning of an ebBP instance with instanceVersion attribute of ProcessSpecification element. The instanceVersion attribute MAY be used to distinguish different revisions of a business process. The ebBP technical specification does not define specific format for the value of instanceVersion attribute. Authors, such as those within an industry, MAY choose arbitrary text of their convenience to recognize their assigned instanceVersion.

The instanceVersion attribute should be differentiated from the specificationVersion attribute, which is the major version identifier of ebBP technical specification of which that ebBP instance MUST conform. In this case, specificationVersion MUST always have value "2", if specified, for ebBP instances that conform to this major version of the technical specification. Two process models with different specification versions could in principle have the same instance version. The ebBP schema version MUST be defined by namespace (where minor variant versions within a namespace are handled by different URLs for specific schema location). The namespace URL always contains the most up-to-date schema. For example, the ebbp-2.0.4.xsd (ebBP schema document version for artifact name) [minor (“0”) and release (“2”)] resides in the v2.0 namespace (i.e. …ebbp-2.0 namespace and specificationVersion = 2) [major].

The attribute uuid MUST NOT be used for the purpose of versioning, so that even a change introduced by AttributeSubstitution (to Business Documents’ schemas, for example), would be marked by a new uuid. So while the same instance version could appear in two process documents with different schema namespaces, for example, they each would have different uuids. The uuid is not a guarantee that the version is the same. Take two examples, one that is more predictable. In the first case, the uuid is the same for different business process definitions. Therefore, they are the same version (ebBP schema and, where used, instance and specification version). However, in a second case: If the definitions exist in different repositories, each could have a different uuid. In implementation, tools (such as modeling tools) MAY use the uuid attribute value as a direct pointer to a particular ebBP instance within a namespace of a repository.

<ProcessSpecification xmlns="http://docs.oasis-open.org/ebxml-bp/ebbp-2.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xi="http://www.w3.org/2001/XInclude"

xsi:schemaLocation="http://docs.oasis-open.org/ebxml-bp/ebbp-2.0 http://docs.oasis-open.org/ebxml-bp/ebbp-2.0”

name="PurchasingCluster"

nameID="PC23"

uuid="urn:purchasingcluster"

specificationVersion="2"

instanceVersion="2.1" >

An industry may choose to use a specific instance version such as Australian Wheat Board v2.1. The specificationVersion for the technical specification resolves to 2 (version) while its document artifact name is 2.0.4 (version).

Further explanation related to the use of NameID for referencing is detailed later in Section 3.8.

3.4.8 Attribute Substitution Sets

There is a requirement for business process specifications that are more loosely coupled to technology and business details, such as specific document formats and structures and timing parameters. An industry MAY choose to specialize it for their domain context and definition. This can allow a Business Collaboration to be bound to many Business Document requirements and formats. Substitution sets support the capability to take a generic business process and specialize it for a specific use. For example, an ordering process may be very generic but a specific use of that process may require specific document capabilities that go beyond the generic.

A substitution set is placed in the more specific ebBP specification and MAY replace attribute values only. As such references to Business Documents definitions (abstract or not) within a Business Transaction definition MAY be replaced with other Business Document definition references. A Substitution Set is a container for one or more AttributeSubstitution elements. The entire SubstitutionSet specifies attribute values that should be used in place of some attribute values in an existing ebBP specification.

Where used, the attribute or document value SHOULD be used in place of some value in an existing ebBP specification. Attribute substitution MAY be used for document substitution.

3.4.9 Business Transaction and Business Document Flow

3.4.9.1 Key Semantics of a Business Transaction

As a unit of work in a trading arrangement between two business partners, a Business Transaction consists of a Requesting Business Activity, a Responding Business Activity, and one or two Document Flows between them. A Business Transaction may involve the exchange of one or more Business Signals that govern the use and meaning of acknowledgements.

Business signals acknowledging the Document Flow may be associated with each Document Flow.

Figure 7 presents an example of Document Flows and Business Signals within a Business Transaction. This Business Transaction has been represented in BPMN. As indicated for Figure 6, the BPMN v1.0 could be extended while changes to support Business Collaboration are considered by the BPMN team in the Object Management Group (OMG). In a Business Collaboration, several possible (expected) paths of business messages exist, and the semantics of Fork and Join are also important.

Changes are under discussion by OMG BPMN team. The joint activity previously referenced is being used in anticipation of those changes.

In addition, business messages have been represented by a thicker blue message flow, while signals are green message flows. These are allowed extensions in BPMN v1.0. Currently, business signals or messages are not differentiated in a standard way in this notation.

Figure 7: Possible Document Flows and signals and their sequence

The Requesting role performing the Requesting Business Activity and the Responding role performing the Responding Business Activity are abstract (placeholders). These roles become explicit and specific in context when the transaction is used within a BTA as part of a Business Collaboration. In the Business Transaction, the abstract roles are declared. However, there is no need to make these roles concrete such as buyer or seller. In particular some Business Transactions, for example “Cancel Purchase Order” MAY be used either way within the same Business Collaboration as two different Business Transaction Activities. In practice, roles may be implicit such as Initiator or Responder. To promote consistency and support role switching where applicable, these implicit roles of the abstract partners are explicitly declared and can be referenced in the BT. Role changes and role bindings are described in more detail in Section 3.

There is always a Request Document Flow. A Business Transaction definition specifies whether a Respond Business Document is required.

The Request Document Flow relates to the Business Transaction being implemented and may have a relationship with other Business Transactions (where applicable). For example, a Request Document Flow may be implicit or manual, or associated with a previous Business Transaction. A common example of a Request Document Flow that is a Notification Business Transaction (related to the Notification Pattern) is an Advance Ship Notice or Despatch (Dispatch) Advice. These are both requests. In this case, a previous Commercial Transaction may have been completed between two parties and one party desires to notify of shipment. That shipment may be logically considered an additional response to the original Business Transaction. However, the original Business Transaction and this Notification are separate. This and related cases are outlined in the appendices to this technical specification.

If defined within the parties’ expectations, a Business Transaction involving a response (to a request) may be associated with the formation of contracts and agreements.

A Business Action, an abstract element, is the holder of attributes that are common to both Requesting Business Activity and Responding Business Activity. This element cannot appear in ebBP instances. Irrespective of whether or not a Response Business Document is required (i.e. no DocumentEnvelope), a Responding Business Activity exists to support the mapping of the corresponding role and business action. Even when no Response Business Document is produced, there is a Responding Business Activity that occurs that receives and process the Request Business Document. Each activity has roles bound and linked to it.

A Business Transaction itself is abstract (i.e. the BusinessTransactionHead in the schema). In this version, eight overall patterns are available. There are six concrete Business Transactions patterns defined which are related to those defined by UMM and that map to Business Transactions. For this version, the ebBP technical specification has included these six concrete patterns, while retaining the original Business Transaction abstract pattern for conversions purposes only. Implementations are strongly encouraged to use the concrete Business Transactions when creating new ebBP instances. Implementations MAY use LegacyBusinessTransaction when converting instances in previous versions of ebXML BPSS.

In addition to the six concrete patterns referenced above and the LegacyBusinessTransaction, a Data Exchange pattern has also been defined to allow user communities to create a specialized pattern or extend the existing concrete ones. If a pattern is defined (outside of the concrete six ones), the pattern business semantics, underlying and surrounding protocol, state synchronization, or effects of extension are the responsibility of the defining parties. Extensibility of the concrete patterns is outside of the defined BT protocol, the Data Exchange element allows their redefinition. Outside of the syntactic parameters defined, this element allows parties to define their own operational and business semantics related to this pattern.

In addition, for v2.0.x versions, the existing pattern attribute has been retained. This pattern attribute SHOULD be used when the explicit (concrete) patterns are not used. Conversely, when a concrete pattern is used, the pattern attribute SHOULD NOT be used. The pattern name is extensible.

The six concrete patterns are summarized below. In addition, the customizable Data Exchange and historical Business Transaction (pattern) are also included for completeness.

· Commercial Transaction : For Commercial or Business Transaction, either element relates to the same Commercial Transaction BT pattern (to serve different communities to achieve a similar goal). Typically this pattern is a formal obligation between parties. Note, although specified as 'Commercial Transaction' in the UMM R10 transaction patterns, two separate elements were chose to reference back to it via the BusinessTransactionType in the ebBP v2.0.x schemas. This recognizes the use of the pattern in a broader user community and these changes were a result of community requests.

· Notification: Used for business notifications such as a Notification of Failure Business Transaction in line with a Commercial Transaction pattern. Represents a formal exchange between parties. Typically, in the case of NOF, used to render a Business Transaction as null and void. An Advance Ship Notice or Status Order are also business notifications.

· Information Distribution : Represents an informal information exchange between parties.

· Query / Response : Used by a Requester for an information query of which the responding party already has.

· Request / Confirm : Used where an initiating party requests confirmation about their status with respect to previous obligations or a Responder's business rules.

· Request / Response : Used when an initiating party requests information that a responding party already has and when the request for business information requires a complex interdependent set of results.

· Data Exchange : Allows a partner, industry or community to define a specific Business Transaction pattern not in the concrete set. The semantics used for data exchange are partner-specific.

· Legacy Business Transaction : Retained in v2.0.x technical specifications for conversion purposes only to enable the user community to migrate to the concrete patterns. This pattern is not recommended for use for the concrete Business Transaction patterns.

The patterns are applied to Business Transactions. In a Business Transaction, a Request may be manual, implicit or not apply, whereby the intent of the involved parties may be important. One such case is described in further detail in the appendices to this technical specification.

The Business Transaction patterns are described in further detail in the following matrices. Table 1 represents each pattern and their relationship to Business Signals and responses. The remaining matrices actually provide greater detail of the 6 concrete Business Transaction Patterns (excluding the partner-defined Data Exchange and LegacyBusinessTransaction conversion patterns available for use). These matrices provide relevant capabilities associated with the six concrete patterns, but do not enforce how trading partners use those capabilities. These matrices SHOULD be used. For example, the parties may select other quality of service related, operational semantics (such as isIntelligibleCheckRequired or retryCount). These are further described later in Section 3. In the succeeding tables, some usage recommendations are made such as the use of an Acceptance Acknowledgement Business Signal. The accompanying ebBP schema supports these recommendations. In some cases (i.e. where a capability is optional and other alternate capabilities may be chosen by the parties), the usage MAY to be specified by those parties. For example, isGuaranteedMessageDeliveryRequired has a default of 'false' although it is recommended to be ’true’ for most uses.

Note: Obligation herein is described as a responsibility to provide accordant information, which differs from residual obligation (obligation to a subsequent action).

Business Transaction Pattern	Concrete or Extensible	Response	Request Receipt Ack/ Exception	Request Acceptance Ack/ Exception	Response Receipt Ack/ Exception	Response Acceptance Ack/ Exception
Commercial Transaction : Business or Commercial Transaction *(see Note 1)*	Concrete	Yes	Yes	Optionally recommended	Yes	Optionally recommended
Notification	Concrete	No	Yes	Optional	N/A	N/A
Information Distribution	Concrete	No	Optional	No	N/A	N/A
Query / Response	Concrete	Yes	Optional	No	Optional	No
Request / Confirm	Concrete	Yes	Yes	No	Yes	No
Request / Response	Concrete	Yes	Optional	No	Optional	No
Data exchange	Extensibility pattern	Optional	Optional	Optional	By agreement	By agreement
Legacy Business Transaction *(Retained for conversion only. See below)*	Conversion use only	Yes	Yes	Yes	No	No

Table 1 Business Transaction Message Exchange Patterns

Note 1 : The Commercial Transaction or Business Transaction elements relate to the Commercial Transaction pattern via the BusinessTransactionType in the ebBP v2.0.x schemas. Both carry the same semantics and syntactic constructs, and operational criteria. Their differentiation and separation in the ebBP schema into a Commercial Transaction and Business Transaction allows similar usage by different communities.

Implementation Note: The Legacy Business Transaction may be used with a XSLT transform to start to migrate and upgrade to the ebBP v2.0.x schemas. Hints and a starting example (partial) are provided outside of this technical specification. Any transformation will add capabilities such as the Business Signals and criteria surrounding the use of the concrete BT patterns.

*Pattern/Criteria*	Short Description	Other Comments	Example Use Case
Commercial Transaction (Business Transaction Type for Commercial Transaction or Business Transaction)	Formal obligation between parties	Can relate to use of NOF. This construct has historically and commonly known as a business transaction with the formal pattern being named Commercial Transaction.	A buyer requests a product or service in a specific time delivered to a pre-determined location from a Seller. Accepting the obligation, the Seller agrees and commits to delivery to complete a business transaction. The parties may have a pre-existing agreement to exchange goods and payment.
Notification	A formal information exchange between parties.	NOF can apply to timeout on responding party's document or an issue with the received responding party's document (signature missing or invalid, erroneous, not authorized - maps back to TPA). It is recommended this be sent over an alternate communication channel. How and when the NOF is used is TPA specific. Provides further flexibility given decisions between the parties.	A requesting role that throws a business protocol exception terminates the transaction and then sends a notification revoking the offending business document request. The requesting role cannot send a business signal to the responding role to terminate the transaction. A responding role that throws a business protocol exception signals the exception back to the requesting role and then terminates the business transaction.
Information Distribution	An informal information exchange between parties		A Seller notifies its Buyers of the release of a new product line that become part of an product catalog. As each Buyer retains a copy of the product catalog, they may acknowledge receipt. Without non-repudiation, Information Distribution may be difficult to prove authorship and adherence.
Request-Response	A request and response where no residual obligation is created (for example, a request for price and availability). The request/response activity pattern shall be used for business contracts when an initiating partner requests information that a responding partner already has and when the request for business information requires a complex interdependent set of results.	Typically no residual obligation created. Requires some business processing before the results of a query are provided.	A Buyer asks a Seller in a request for the price and availability of a particular product. This request does not result in the responding party allocating product for future purchase. The Seller queries its inventory and other applications to provide a sufficient response by checking their Supply Chain Management and Inventory systems. The Seller has to calculate the current price based on availability, its Suppliers' details, etc. Most often, the Request-Response does not involve a simple Yes/No answer from the responding party.

Pattern/Criteria	Short Description	Other Comments	Example Use Case
Request-Confirm	Used for business contracts where an initiating partner requests confirmation about their status with respect to previous contracts or a responder's business rules.	Typically no residual obligation created.	A Buyer requests from a Seller if it is still authorized to sell certain product. The Buyer expects a confirmation response. A response does not equate to an obligation, although further action could subsequently occur. A previous contract may or may not have existed between the parties. The Seller confirms he is still authorized to sell the product. Typically, the Request-Confirm involves a simple Yes/No answer from the responding party.
Query Response	Used by a requester for an information query that responding partner already has.	This pattern should be used when the response meets the specified constraining criteria. If this involves a complex set of results, use request-response pattern. Use when no interdependency exists between the query results. Can use this pattern when querying business information and for specifying the structure of the response (without complex constraints).	A Buyer asks a Seller in a request for the price and availability of a particular product. This request does not result in the responding party allocating product for future purchase. The Seller maintains a online product catalog of products and can provide the Buyer a response without complex constraints or backend processing.
General Notes:
UMM R10, Chapter 9 specifies the RA and AA on the responder to the requester. Here experts have historically differed on the use of the signals on requester to the responder.	Note: More information may need to be derived from UMM R10, Chapter 8. In work.	Note: The Commercial Transaction pattern is not the legacy conversion Business Transaction pattern. The Commercial Transaction pattern in the UMM R10, Commercial Transaction is mapped to the ebBP v2.0.4 concrete pattern. That concrete pattern is typed and mapped to the ebBP Business Transaction Type that relates to (1) Commercial Transaction and (2) Business Transaction, that allows usage by different communities (commercial or not).
*Key:*	Mapping titles	Not applicable	Not allowed

Table 2 Concrete Business Transaction Pattern Descriptions and Examples

*Pattern/Criteria*	Receipt Ack/Exception (on request)	Accept Ack/Exception (on request)	Receipt Ack/Exception (on response)	Accept Ack/Exception (on response)	Response	NOF Possible
	Can include grammar, sequence and syntax validation.	Includes content validation	Can include grammar, sequence and syntax validation.	Includes content validation
Commercial Transaction (Business Transaction Type for Commercial Transaction or Business Transaction)	X	Optional but strongly recommended	X	Optional but strongly recommended	X (if accepted and if substantive)	X (if control failure)
		1. If negative AA, no response is sent by the responding party. 2. If positive AA, a business response is sent by the responding party. The AA and the business response are in the same business transaction (and BT activity). 3. Users are encouraged to review UN/ECE Recommendations 26 and 31 about business enforceability. AA allows state alignment to optimize processes accordingly. 4. The response may fulfill the AA and the response for the party commitments. An AA is not the response. 5. Substantial risk exists when it is not used for state alignment.		1. The responding party can issue an exception. The agreement may dictate the applicable conditions. 2. Users are encouraged to review UN/ECE Recommendations 26 and 31 about business enforceability. AA allows state alignment to optimize processes accordingly. 3. The response may fulfill the AA and the response for the party commitments. An AA is not the response. 4. Substantial risk exists when it is not used for state alignment.
						Business retry may also apply.

*Pattern/Criteria*	Receipt Ack/Exception (on request)	Accept Ack/Exception (on request)	Receipt Ack/Exception (on response)	Accept Ack/Exception (on response)	Response	NOF Possible
Notification	X	Optional				Pattern used for NOF.
		This is a business message, and therefore, because of the intentional nature, a n AA is optional.				An NOF may also be used in a business collaboration that includes multiple transactions. In that case, any of the patterns are used together. If a non-receipt occurs, for example, a NOF may result to set aside the Business Collaboration.
						Business retry may also apply.
Information Distribution	Optional					Not allowed
						Business retry may also apply.
Request-Response	Optional	Not allowed explicitly	Optional	Not allowed explicitly	X	Not allowed
						Business retry may also apply.
Request-Confirm	X	Not allowed explicitly	X	Not allowed explicitly	X	Not allowed
						Business retry may also apply.

*Pattern/Criteria*	Receipt Ack/Exception (on request)	Accept Ack/Exception (on request)	Receipt Ack/Exception (on response)	Accept Ack/Exception (on response)	Response	NOF Possible
Query Response	Optional	Not allowed explicitly	Optional	Not allowed explicitly	X	Not allowed explicitly
	General Notes:					Normally business retry may apply.
	UMM R10, Chapter 9 specifies the RA and AA on the responder to the requester. Here experts have historically differed on the use of the signals on requester to the responder.	Note: More information may need to be derived from UMM R10, Chapter 8. In work.	Note: The Commercial Transaction pattern is not the legacy conversion Business Transaction pattern. The Commercial Transaction pattern in the UMM R10, Commercial Transaction is mapped to the ebBP v2.0.4 concrete pattern. That concrete pattern is typed and mapped to the ebBP Business Transaction Type that relates to (1) Commercial Transaction and (2) Business Transaction, that allows usage by different communities (commercial or not).
	*Key:*	Mapping titles	Not applicable	Not allowed

Table 3 Concrete Business Transaction Pattern Operational Semantics (1 of 4)

*Pattern/Criteria*	Non-repudiation receipt (on request)	Non-repudiation of content and origin (on request)	Non-repudiation receipt (on response)	Non-repudiation of content and origin (on response)
Commercial Transaction (Business Transaction Type for Commercial Transaction or Business Transaction)	X	X	X	X
		Includes content and origin (responding role identity) validation.	Although it is possible one may consider non-repudiation could be optional for a receipt on a response, this is strongly recommended.	Includes content and origin (responding role identity) validation.
Notification	X	X
Information Distribution	Not allowed (no NR requirements exist)	Not allowed (no NR requirements exist)
Request-Response	Optional	Optional	Optional	Optional
	A receipt acknowledgment is allowed and therefore, non-repudiation of receipt may apply. By agreement, the parties may determine this is an implicit input to a future decision.	By agreement, the parties may determine this is an implicit input to a future decision.	A receipt acknowledgment is allowed and therefore, non-repudiation of receipt may apply. By agreement, the parties may determine this is an implicit input to a future decision.	By agreement, the parties may determine this is an implicit input to a future decision.
Request-Confirm	Optional	Optional	Optional	Optional
	Request-Confirm is a pattern where non-repudiation can be changed without changing semantics.	Requesting business document is allowed. Repudiation of content should therefore be optional but allowed.	Request-Confirm is a pattern where non-repudiation can be changed without changing semantics.	Responding business document is allowed. Repudiation of content should therefore be optional but allowed.

*Pattern/Criteria*	Non-repudiation receipt (on request)	Non-repudiation of content and origin (on request)	Non-repudiation receipt (on response)	Non-repudiation of content and origin (on response)
Query Response	Optional	Optional	Optional	Optional
	Requesting business document is allowed. Repudiation of receipt should therefore be optional but allowed.	Requesting business document is allowed. Repudiation of content should therefore be optional but allowed.	Responding business document is allowed. Repudiation of receipt should therefore be optional but allowed.	Responding business document is allowed. Repudiation of content should therefore be optional but allowed.
	General Notes:	UMM R10, Chapter 9 specifies the RA and AA on the responder to the requester. Here experts have historically differed on the use of the signals on requester to the responder.	Note: More information may need to be derived from UMM R10, Chapter 8. In work.	Note: The Commercial Transaction pattern is not the legacy conversion Business Transaction pattern. The Commercial Transaction pattern in the UMM R10, Commercial Transaction is mapped to the ebBP v2.0.4 concrete pattern. That concrete pattern is typed and mapped to the ebBP Business Transaction Type that relates to (1) Commercial Transaction and (2) Business Transaction, that allows usage by different communities (commercial or not).
	Key:	Mapping titles	Not applicable	Not allowed

Table 4 Concrete Business Transaction Pattern Operational Semantics (2 of 4)

*Pattern/Criteria*	TTP	Time to Acknowledge Receipt	Time to Acknowledge Acceptance	Formal or Informal	Has Legal Intent
Commercial Transaction (Business Transaction Type for Commercial Transaction or Business Transaction)	X	X	X	Formal	default="false"
					By agreement. Typically, this attribute is consistent between Notification and Commercial Transaction/Business Transaction (Commercial Transaction pattern). In general, this pattern meets legal enforceability reqts.
Notification	X	X	Optional	Formal	default="false"
					By agreement. Typically, this attribute is consistent between Notification and Commercial Transaction/Business Transaction (Commercial Transaction pattern). In general, this pattern meets legal enforceability reqts.
Information Distribution	X	Optional		By agreement	default="false"
					By agreement
Request-Response	X	Optional	Not allowed explicitly	By agreement	default="false"
					By agreement

*Pattern/Criteria*	TTP	Time to Acknowledge Receipt	Time to Acknowledge Acceptance	Formal or Informal	Has Legal Intent
Request-Confirm	X	X		By agreement	default="false"
					By agreement
Query Response	X	Optional	Not allowed explicitly	By agreement	default="false"
					By agreement
			General Notes:
			UMM R10, Chapter 9 specifies the RA and AA on the responder to the requester. Here experts have historically differed on the use of the signals on requester to the responder.	Note: More information may need to be derived from UMM R10, Chapter 8. In work.	Note: The Commercial Transaction pattern is not the legacy conversion Business Transaction pattern. The Commercial Transaction pattern in the UMM R10, Commercial Transaction is mapped to the ebBP v2.0.4 concrete pattern. That concrete pattern is typed and mapped to the ebBP Business Transaction Type that relates to (1) Commercial Transaction and (2) Business Transaction, that allows usage by different communities (commercial or not).

Table 5 Concrete Business Transaction Pattern Operational Semantics (3 of 4)

*Pattern/Criteria*	isGuaranteedMessageDeliveryRequired	documentSecurity (isConfidential, isTamperDetectable, isAuthenticated on Document Envelope)
Commercial Transaction (Business Transaction Type for Commercial Transaction or Business Transaction)	default = 'false'	X
	Strongly recommended to support state alignment.	If non-repudiation of content is required, the enumeration selected for each of these values should be other than 'none.' Typically, this occurs in situations where hasLegalIntent applies.
Notification	default = 'false'	X
	Strongly recommended to support state alignment.	If non-repudiation of content is required, the enumeration selected for each of these values should be other than 'none.' Typically, this occurs in situations where hasLegalIntent applies.
Information Distribution	default = 'false'	Optional
	Strongly recommended to support state alignment.
Request-Response	default = 'false'	Optional
	Strongly recommended to support state alignment.	By agreement of the parties. Non-repudiation of content suggests that the business document will be protected as specified for the Document Envelope. Typically, this occurs in situations where hasLegalIntent applies.
Request-Confirm	default = 'false'	Optional
	Strongly recommended to support state alignment.	By agreement of the parties. Non-repudiation of content suggests that the business document will be protected as specified for the Document Envelope. Typically, this occurs in situations where hasLegalIntent applies.

*Pattern/Criteria*	isGuaranteedMessageDeliveryRequired	documentSecurity (isConfidential, isTamperDetectable, isAuthenticated on Document Envelope)
Query Response	default = 'false'	Optional
	Strongly recommended to support state alignment.	By agreement of the parties. Non-repudiation of content suggests that the business document will be protected as specified for the Document Envelope. Typically, this occurs in situations where hasLegalIntent applies.
General Notes:	UMM R10, Chapter 9 specifies the RA and AA on the responder to the requester. Here experts have historically differed on the use of the signals on requester to the responder.	Note: More information may need to be derived from UMM R10, Chapter 8. In work.
Key:	Not allowed	Note: The Commercial Transaction pattern is not the legacy conversion Business Transaction pattern. The Commercial Transaction pattern in the UMM R10, Commercial Transaction is mapped to the ebBP v2.0.4 concrete pattern. That concrete pattern is typed and mapped to the ebBP Business Transaction Type that relates to (1) Commercial Transaction and (2) Business Transaction, that allows usage by different communities (commercial or not).
	Mapping titles	Not applicable

Table 6 Concrete Business Transaction Pattern Operational Semantics (4 of 4)

For the six concrete patterns and the LegacyBusinessTransaction (conversion only pattern) additional operational semantics may exist in the patterns matrices rather than being held in the ebBP schema. For example, manual or implicit actions by an involved party may be relevant in the ebBP process definition, particularly to provide state transition information in the Business Collaboration for monitoring. In the appendices to this technical specification, a brief description is provided about how the patterns may be used when manual or implicit actions exist. In future versions, more semantics may be defined and included in the ebBP technical specification and/or schema as business requirements are identified or user community feedback received.

3.4.9.2 Sample syntax

Here is a simple QueryResponse Business Transaction definition with just a Requesting and Response Document Flow:

</RequestingBusinessActivity>

<DocumentEnvelope name="Catalog Response" nameID="ID104" isPositiveResponse="true"

businessDocumentRef="IDs1001"/>

</RespondingBusinessActivity>

</QueryResponse>

3.4.9.3 Business Signals

The type of Business Transaction specifies whether a Receipt Acknowledgement and/or an Acceptance Acknowledgement signal is required. Business transaction protocol signals are independent from lower protocol and transport signals such as reliable messaging. The Business Signals are important for state alignment, and relate to the characteristics inherent in the BT patterns described earlier in Section 3. Business Signals and their relationship to success and failure are outlined in Section 3.6.3.

3.4.9.3.1 Receipt Acknowledgement Business Signal

The Receipt Acknowledgement Business Signal, if used, signals that a message (Request or Response) has been properly received by the BSI software component. The property isIntelligibleCheckRequired allows partners to agree that a Receipt Acknowledgement SHOULD confirm a message only if it is also legible. Legible means that it has passed structure/schema validity check. If specified, the content of the receipt and the legibility of a business message (if required) MUST be reviewed prior to the processing of the Requesting or Responding Business Document or the evaluation of condition expressions in the message's Business Documents or Document Envelope. Condition Expressions are expressions that evaluate to true or false. Condition Expressions are described in more detail in Section 3.4.11. This property recognizes that the receipt and the legibility check may be handled separately with the latter completed prior to the Receipt Acknowledgement being generated. This attribute indicates the document is parsable and reusable. In addition, it may be advised to indicate that some industries, particularly that have EDI historical experience, may vary on 'syntactic check'. An implementation MAY also equate 'syntactic check' to using parser to validate the XML.

3.4.9.3.2 Acceptance Acknowledgement Business Signal

The Acceptance Acknowledgement Business Signal, if used, signals that the message received (Request or Response) has been accepted for business processing and that processing is complete and successful by the receiving application, service or a receiving business application proxy. This is the case if the contents of the business message's Business Documents and Document Envelope have passed a business rule validity check. These business rules are not necessarily specified as part of the document schema or Business Collaboration. The state of each party is considered to be aligned when the receiving application (in general unknown to the other party) has signaled, via the BSI and an Acceptance Acknowledgement, that the Business Document has been successfully processed. Note that this acknowledgement is non-substantive, and simply indicate that the receiving party has reached a satisfactory state. If for any reason, the application could not process the Business Document, the sending party should be notified via a negative Acceptance Acknowledgement signal so that it can transition to a meaningful “internal” business state. For instance, a Purchase Order could not be considered in the “sent” state, unless the other party had sent the corresponding Acceptance Acknowledgement. The substantive response would come after the Business Signal indicating whether the order had been Accepted or Rejected. Positive Business Signals or exceptions are non-substantive in nature, i.e. they may contain business identification data relevant to a business acceptance of an obligation (See definition of obligation earlier in Section 3). A substantive business message actually includes a Business Document such as a purchase order acceptance.

3.4.9.3.3 Business Signal Criteria

Based on any agreement between the parties, the requesting party typically MAY recognize that the Business Document had been successfully received and processed. Where applicable and used, the logical sequence of the Receipt Acknowledgement, Acceptance Acknowledgement and Response are based on the timing expectations defined. For example, in implementation, if an Acceptance Acknowledgement is received prior to a Receipt Acknowledgement, the requesting party may wait (if no timeout), for the Receipt Acknowledgement because the two Business Signals are handled by different systems. Occurrence of Business Signals and their receipt are not dependent. Occurrence is summarized in Section 3.5.1.

Business protocol engines are expected to deal with the precedence of the receipt of Business Signals. Many eBusiness systems are completely asynchronous, whereby there is no way to guarantee that physical receipt will be sequenced. Logical receipt however is sequenced.

Failure to send either signal, when required (by specifying a timeout value in timeToAcknowledgeReceipt or timeToAcknowledgeAcceptance), SHOULD result in the transaction being null and void. A control Failure has occurred. The transaction will not reach any "Success" end state. A "Success" end state (Protocol or Business) is dependent on receipt of a Business Document satisfying the associated TimeToPerform. In order for a BTA instance to reach a “Success” state at run-time, the following things SHOULD be true:

· no timeout would have occurred (signals or response)

· no signal can have a negative content

· the response document sent to the requester MUST be marked as isPositiveResponse = ‘true’ in the ebBP instance that specifies the Business Collaboration in order to support Business Success

Conversely, if all signals are positive and sent and received on time, the transaction will be successful from a protocol perspective.

The isPositiveResponse attribute of a DocumentEnvelope is not part of the Business Transaction protocol and therefore does not impact the Protocol Success or Failure of a transaction (although it is relevant to Business Success and Failure). If the DocumentEnvelope received as a response is specified with the isPositiveResponse=false (at design time) the Business Transaction will end in a Business Failure state. The choreography of the Binary (Business) Collaboration MAY use this information to execute corresponding transitions or stop the collaboration altogether. Note that this attribute is optional and some Document Envelope MAY neither be positive or negative (consider for instance the case of a partial acceptance on a purchase order, where only a few line items are refused, or a back order response). In this case, the BTA is considered successful, again after it has reached a Protocol Success state.

For example in the case of a Decision (linking construct), isPositiveResponse is in effect within a Decision related to the DocumentEnvelope. This is evidence of the preference to evidence collaborative shareable) information (i.e. the DocumentEnvelope) to align state between the parties involved.

Condition guards on transitions are discussed in detail in Section 3.6.3.

It is important to note that the isPositiveResponse attribute such as other facilities in ebBP - condition guards on transitions, semantic variables, conditions expressions - are enabling mechanisms for the ebBP process definitions whereby the choreography, control flow, state transitions, logical business documents, and the expectations of the parties are clearly understood. It is their collective use that provides the capability to enable Business Collaborations.

A corresponding isPositiveSignal attribute occurs on each signal. Although consistent with the structure of the Document Envelope, this attribute on each signal type has a fixed value.

The isGuaranteedMessageDeliveryRequired refers to the underlying messaging service used to implement the Business Transaction protocol. The Business Transaction protocol is designed to achieve state alignment between both parties involved in the transaction and signals the sending party that Business Documents, a request or a response have been successfully processed by the receiving application, whatever it might be. However, to achieve this result, the Business Transaction protocol MUST be implemented on top of a reliable messaging service that provides guaranteed message delivery at the transport level. If the sending party was not guaranteed that its message or in particular signal reached the intended recipient, it could never be sure that the other party’s state is aligned with its own state. Since a signal structure is fixed there is no ambiguity about the BSI processing it and understanding its meaning provided it is known that it reached its destination, unlike a request or response which could have an invalid structure or content. In the case where the Business Transaction does not need to guarantee processing by the receiving application this condition MAY be relaxed and regular messaging services MAY be used.

Note, in order to guarantee the successful synchronization of state between two parties, reliable messaging MUST be used and the Business Transaction MUST be defined to use the request and response Acceptance Acknowledgement signals. When a Document Envelope exists, these signals are important to guarantee that the corresponding Business Documents were processed by the respective applications. Criteria surrounding the use of the Business Transaction patterns may include reliable messaging and use of the isGuaranteedMessageDelivery requirement (See Section 3.4.9.1). Any agreement between trading partners could specify that the certificate-based digest used by a message protocol could be captured and stored as the non-repudiation digest (making the message receipt function as a business protocol receipt). By default the Receipt Acknowledgement (and its associated on-repudiation attributes) are separate from the reliable messaging layer. In preceding technical specification versions, the guiding principles used were incomplete in describing the scope and operational details related to state synchronization. State synchronization may relate to the design and operational view of a business process specification like ebBP. In providing further concrete detail on the BT patterns, this technical specification concentrates on the operational view. Further business requirements may be identified from a design and modeling perspective that will affect these operationally focused patterns.

The difference between a Business Signal and a business message is that a signal has a fixed structure under the control of the infrastructure while a business message content may vary both at run-time and over time and is under the control of an application or service. ebBP technical specification specifies a schema for all signals of the Business Transaction protocol. However an extension mechanism is provided to support other schema definitions for Business Signals whereby user communities may define their own signal structure.

The Signal element is used to specify both ebBP and user defined signal schema references. The use of either is supported via the signal references in the ebBP and the Business Signal schema. The logical relationship between the ebBP, Business Signal and underlying messaging are visible via the schema constructs. In addition to this technical specification and its appendices a non-normative package of ebBP and signal instances is available on the OASIS web site.

3.4.9.4 Sample syntax

Here is a slightly more complex transaction with two Document Flows and all Business Signals.

The request requires both receipt and Acceptance Acknowledgement, the response requires only Receipt Acknowledgement. “P2D” is a W3C Schema syntax adopted from the ISO 8601 standard and means Period=2 Days. P3D means Period=3 Days, P5D means Period=5 Days. These periods are all measured from original sending of request.