Chapter 5 Building a Collaborative Business Process Model
You design a Business Transaction using a process with a <<BusinessTransaction>> stereotype.
The following extended attributes (accessible from the Extended Attributes tab of the process property sheet) apply to the Business Transaction process. The table shows what attributes are available for ebXML BPSS 1.01 or for ebXML BPSS 1.04 process language:
Name |
Internal code |
Description |
BPSS 1.01 | BPSS 1.04 |
|---|---|---|---|---|
| Requires guaranteed delivery | IsGuaranteedDeliveryRequired
(true | false) "false" |
Both partners must agree to use a transport that guarantees delivery | Yes | Yes |
| Pre conditions | preConditions | A description of a state external to this transaction that is required before this transaction can start | Yes | No |
| Post conditions | postConditions | A description of a state that does not exist before the execution of this transaction but will exist as a result of the execution of this transaction | Yes | No |
| Begins when | beginsWhen | A description of an event external to the collaboration/transaction that normally causes this collaboration/transaction to start | Yes | No |
| Ends when | endsWhen | A description of an event external to this collaboration/transaction that normally causes this collaboration/transaction to end | Yes | No |
| Requires secure transport | IsSecureTransportRequired | Both partners must agree to exchange business information using a secure Delivery Channel. The following security controls ensure that business document content is protected against unauthorized disclosure or modification and that business services are protected against unauthorized access. This is a point-to-point security requirement. Note that this requirement does not protect business information once it is off the network and inside an enterprise | No | Yes |
| Pattern | Pattern | The optional name of the pattern that this business transaction is based on | No | Yes |
The Business Transaction process is a composite process with a sub-diagram that designs the Business Signal exchanges between partners. This sub-diagram contains one Responding Business Activity (a process with <<RespondingBusinessActivity>> stereotype) and one Requesting Business Activity (a process with <<RequestingBusinessActivity>> stereotype):
The Signals are designed with flows between Requesting and Responding activities. The <<ReceiptAck>> and <<AcceptanceAck>> flow stereotypes allow the design of a Receipt Acknowledgment Signal and Acceptance Acknowledgment Signal. The Request Document and Response Document are also designed with flows with message formats that design the document format.
The following extended attributes (accessible from the Extended Attributes tab of the process property sheet) apply to both the Requesting and Responding Business Activity processes:
| Name | Internal code | Description |
|---|---|---|
| Requires authorization | IsAuthorizationRequired
(true | false) "false" |
If a partner role needs authorization to request a business action or to respond to a business action, then the sending partner role must sign the business document exchanged and the receiving partner role must validate this business control and approve the authorizer. A responding partner must signal an authorization exception if the sending partner role is not authorized to perform the business activity. A sending partner must send notification of failed authorization if a responding partner is not authorized to perform the responding business activity |
| Requires intelligible check | IsIntelligibleCheckRequired
(true | false) "false" |
Receiving partner role must check that a requesting document is not garbled (unreadable, unintelligible) before sending acknowledgement of receipt |
| Requires non repudiation
(true | false) "false" |
IsNonRepudiationRequired
(true | false) "false" |
If non-repudiation of origin and content is required, then the business activity must store the business document in its original form for the duration mutually agreed to in a trading partner agreement. A responding partner must signal a business control exception if the sending partner role has not properly delivered their business document. A requesting partner must send notification of failed business control if a responding partner has not properly delivered their business document |
| Requires non repudiation receipt | isNonRepudiationReceiptRequired
(true | false) "false" |
Both partners agree to mutually verify the receipt of a requesting business document and that the receipt must be non-reputable. A receiving partner must send notification of failed business control (possibly revoking a contractual offer) if a responding partner has not properly delivered its business document. Non-repudiation of receipt provides the following audit controls: Verify responding role identity (authenticate) – Verify the identity of the responding role (individual or organization) that received the requesting business document Verify content integrity – Verify the integrity of the original content of the business document request |
| Time to acknowledge acceptance | TimeToAcknowledgeAcceptance (specific to the Requesting Activity) | The time a receiving role has to acknowledge business acceptance of a business document |
| Time to acknowledge receipt | TimeToAcknowledgeReceipt | The time a receiving role has to acknowledge receipt of a business document |
| Number of retries | retryCount | Business level retries. For requesting business activity and available only for BPSS 1.04 |
A specific ebXML tool Palette allows you to directly create a Business Transaction composite process in the current diagram and initialize the composite process with the Requesting and Responding Activities. The following table summarizes the distinct flows that exist between the Requesting and the Responding Activity:
Flow |
Request Document | Response Document | Receipt on Response | Acceptance on Response | Receipt on Request |
|---|---|---|---|---|---|
| Without response | Yes | No | No | No | No |
| Default | Yes | Yes | No | No | No |
| With receipt on response | Yes | Yes | Yes | No | No |
| With receipt and acceptance on response | Yes | Yes | Yes | Yes | No |
| Full | Yes | Yes | Yes | Yes | Yes |
A Document Envelope conveys business information between the two roles in a Business Transaction. One Document Envelope conveys the request from the requesting role to the responding role, and another Document Envelope conveys the response (if any) from the responding role back to the requesting role. This concept is designed with a flow and a message format in the Business Process Model.
The following extended attributes (accessible from the Extended Attributes tab of the message format property sheet) apply to the Document Envelope:
| Name | Internal code | Description |
|---|---|---|
| DocTypeDocumentation | DocTypeDocumentation | Documentation of DocumentType |
| Is positive response | IsPositiveResponse | If TRUE the Document Envelope is intended as a positive response to the request. This parameter is only relevant on the response envelope |
| Is authenticated | isAuthenticated
(true | false) "false" |
There is a digital certificate associated with the document entity. This provides proof of the signatory identity |
| Is confidential | isConfidential
(true | false) "false" |
The information entity is encrypted so that unauthorized parties cannot view the information |
| Is tamper proof | isTamperProof
(true | false) "false" |
The information entity has an encrypted message digest that can be used to check if the message has been tampered with. This requires a digital signature (sender's digital certificate and encrypted message digest) associated with the document entity |
| Copyright (C) 2007. Sybase Inc. All rights reserved. |
| |