- ebXML Business Process Analysis Participants
- Introduction
- Goal and Objectives
- Business Collaboration Overview
- Business Process and Information Modeling
- The Analysis Process
- Relationship Between Business Process and Core Components
- Analysis Aids: Worksheets and Tools
- References
- Disclaimer
- Contact Information
- Appendix A Context Category—Meta Model Cross-reference
5 Business Collaboration Overview
5.1 ebXML electronic business collaboration
The strength of the ebXML technical architecture is that it provides a framework for electronic business collaboration. The architecture enables businesses to work together to specify business process, discover each other, negotiate collaboration agreements, and execute business processes. The significant activities implementing and executing this ebXML electronic business collaboration are shown in Figure 5.1-1.
FIGURE 5.1-1 ebXML Business Collaboration Process
The overall process starts with Process Definition, utilizing Business Process and Business Document Analysis and logically progresses to Partner Discovery, Partner Sign-Up, Electronic Plug-in, Process Execution, Process Management, Process Evolution.
Process Definition: Utilizing Business Process and Business Document Analysis, an enterprise determines and defines which processes will be necessary for electronic commerce. In some cases, a community of trading partnersfor example AIAG1 or RosettaNet2may define the business processes to be used in the community. These business processes are defined according to a well known model and described in agreed upon formats.
Partner Discovery: Enterprises identify potential electronic trading partners through a search of company profiles held in ebXML compliant registries.
Partner Sign-up: Trading partners then negotiate agreements that will serve as the terms and conditions of their collaboration.
Electronic Plug-in: The trading partners then configure their electronic interfaces and business services according to their agreements.
Process Execution: Businesses exchange documents and complete commercial transactions in accordance with their agreements and carry out the agreed upon business processes.
Process Management: The business processes defined in the Process Definition phase and agreed to in the Partner Sign-Up phase are monitored for compliance with trading partner agreements and successful execution.
Process Evolution: Participants in the electronic marketplace will evaluate their existing processes, improve them through process re-engineering, and create new processes to meet the needs of the market.
The following table shows the relationship between ebXML Project Teams, significant ebXML documents, and the activities in Figure 5.1-1:
Activity Document |
ebXML Project Team |
ebXML Document |
Process Definition |
Business Process, CC/BP Analysis sub-team, Registry |
UN/CEFACT Modeling Methodology3, ebXML Business Process Specification Schema , Business Process and Business Document Analysis Overview, ebXML Business Process Analysis Worksheets and Guidelines, ebXML Catalog of Business Processes, ebXML The role of context in the re-usability of Core Components and Business Processes, and ebXML specification for the application of XML based assembly and context rules, ebXML Registry Services, ebXML Registry Information Model |
Partner Discovery |
Technical Architecture, Trading Partner, Registry |
ebXML Technical Architecture Specification, Collaboration-Protocol Profile and Agreement Specification, ebXML Registry Services, ebXML Registry Information Model. |
Partner Sign-up |
Trading Partner, Technical Architecture |
Collaboration-Protocol Profile and Agreement Specification, and Business Collaboration Patterns. |
Electronic Plug-in |
Technical Architecture, Trading Partner |
Collaboration-Protocol Profile and Agreement Specification, ebXML Technical Architecture Specification, Information TechnologiesOpen-EDI Reference Model [ISO14662E], Transport, Routing and Packaging Message Services |
Process Execution |
Trading Partner, Technical Architecture, Transport, Routing and Packaging (TRP) |
Collaboration-Protocol Profile and Agreement Specification, ebXML Technical Architecture Specification, Information TechnologiesOpen-EDI Reference Model [ISO14662E], Transport, Routing and Packaging Message Services |
Process Management |
None |
Information TechnologiesOpen-EDI Reference Model [ISO14662E] (Section Open-EDI Support Infrastructure)4, Transport, Routing and Packaging Message Services, |
Process Evolution |
None |
Nonenot in scope of ebXML. |
5.2 Economic elements in business processes
The most common ebXML business collaborations will be resource exchanges between companies: buying and selling products and services. The most common collaboration pattern for these exchanges will probably be order-fulfillment-payment. The ebXML Meta Model provides Economic Modeling Elements for specifying these collaborations in business and economic terms rather than in technical terms. The Economic Elements include:
Economic Contracts: ranging from simple orders to long-term component contracts
Economic Resources: including products, services, and cash
Economic Events: including product or service deliveries, and payments
Partner Types: including the parties and roles authorized to commit and exchange resources in business collaborations
Using these elements, it will be possible to determine in a business collaboration:
When an Economic Contract is formed
When an Economic Event SHOULD be recognized
When an Economic Resource or a claim to a resource SHOULD be recognized in accordance with generally accepted accounting principles (GAAP)
Whether or not a delivery fulfills a commitment
What events MAY follow if a delivery does not fulfill an order
When an exchange is complete from a business point of view
Many other aspects of typical business relationships
Using the ebXML Economic Modeling Elements, these typical business collaboration patterns can be designed once and re-used in many situations5. Figure 5.2-1 provides an overview of the REA economic elements in a typical product- oriented Order-Fulfillment Business Process.
FIGURE 5.2-1 Overview of the REA economic elements in a typical product-oriented Order-Fulfillment Business Process.
The above concepts and relationships are specified in the UMM, but there is no programmatic support for them in the first version of the ebXML Business Process Specification Schema [BPSS]. They could, however, be implemented in business collaboration management software based on the UMM Meta Model.
The Business Process is composed of several Business Collaborations, taken directly from the Catalog of Common Business Processes [CCBP] and other business libraries.
Query Product Information receives Product Master or Catalog information about the products that can be ordered. In REA, products are Economic Resource Types.
Distribute Inventory Report receives information about products that are currently available. This purpose could also be accomplished through a Query Availability process. In REA, inventory is an Economic Resource. Each inventory element is typed by a Product Master (Economic Resource Type).
Create Order forms a Purchase Order (an Economic Contract) composed of Line Items (Economic Commitments). Each Line Item reserves the committed quantity of the ordered product type, due at the committed date and time.
Notify of Shipment results in a Shipment (an Economic Event) which SHOULD fulfill one or more of the Purchase Order Line Items.
Process Payment results in a Payment (an Economic Event) which pays for the Shipment (the REA "duality" relationship).
When all of the Line Items have been fulfilled, and all the Shipments have been paid, the Business Process is complete. The contract terms in this simple example specified "pay on receipt". Otherwise the business process might have another step, e.g. Process Invoice.
If something goes wrong, and the shipments do not fulfill the commitments, and the payments do not compensate for the shipments, or some economic event is late or otherwise incorrect, the problem can be expressed using the REA concepts and relationships explained above.
5.3 ebXML design time and run time reference model
In order to put Business Process and Business Information Analysis on its proper context, it is useful to consider the ebXML Technical Architecture. ebXML Technical Architecture is comprised of two basic components: Design Time and Run Time. Business Process and Business Information Analysis is a part of Design Time component. The Design Time component deals with the procedures for creating an application of the ebXML infrastructure, as well as the actual discovery and enablement of ebXML-related resources required for business transactions to take place. Business Process and Business Information Analysis is one way accomplishing the Design Time component of the Technical Architecture.
The Run Time component covers the execution of an ebXML scenario with the actual associated ebXML transactions.
The Design Time and Run Time components of the ebXML Technical Architecture are found in.
The Design Time artifacts enable the Run Time systems to execute the agreed business processes. Business processes and business documents are defined during the Business Process and Business Information Analysis activity. Core Components and Domain Components are the reusable information building blocks used to specify document content and structure. They can be identified and defined using the ebXML Methodology for the Discovery and Analysis of Core Components. The Business Process Specifications for the defined Business Processes and Business Documents are stored and registered in Business Libraries which contain catalogs of Business Processes and Business Information Objects (document components). These catalogs reside in ebXML compliant registries/repositories.
FIGURE 5.3-1 ebXML Design Time and Runtime Reference Model
The business process modeling results in an ebXML Business Process Specification, which MAY be referenced in the Collaboration Protocol Profiles (CPPs), of businesses and form the basis for Collaboration Protocol Agreements (CPAs) established between business parties. Ultimately, the business processes specified in the CPAs drive the business service interfaces to execute those processes and send the REQUIRED documents.