Legacy Issue Number: 9364
Comment to BPMN FTF:
- Currently there is no standard way to differentiate a business
message from a business signal, which have fundamental different
During the ebBP-BPMN discussions last week, I was asked to summarize what business signals are and how they function. There has been some initial discussion on the email@example.com list re: signals in general. I'd like to make a necessary distinction about the similarities and differences.
- What is a business signal? 
o "Business signals have a specific business purpose and are
separate from lower protocol and transport signals. One or
more Business Signals can be exchanged as part of a Business
Transaction to ensure state alignment between both parties.
Evaluation of business signals enable the state of a
Business Collaboration to be explicitly calculated at run
time. The ebBP technical specification provides both the
structure and choreography of Business Signals, including
allowing for user defined signals....
A Business Signal is computable. This provides the
collaborating parties with a mutual understanding of the
business activity. This function allows the parties to know
if their expectations in a Business Transaction are
realized. This is state alignment, and is important in order
for the ebBP specification to have commercial viability. The
ebBP specification provides the ability to conduct intended
transactions if that is the intent of the collaborating
- Where does the business signal fit in eBusiness and business
o State alignment: (almost quoting from our specification for
specifics) The process of exchanging signals and state
changes of a Business Transaction enables state alignment
between the parties involved. If the standard signals are
used, the structures of ebXML Business Signals are
‘universal’ and do not vary from transaction to transaction.
Business signal schema can be found at:
(detailed schema documentation also exists on this public
page). The ebBP technical specification provides both the
structure and choreography of Business Signals. The ebXML
Message Service Specification (and other evolving
technologies) 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.
o Part of process definition: Defined in the BT pattern and
bounded by partner expectations. Map back to business
transaction activity. Map back to service and action context
for agreement (such as CPP/A).
o Transition and determination of several types of successes
and failures: Condition guards exist on transition in
process steps and activities. Business signals are integral
here. In ebBP and in business collaboration, there is
protocol and business success whereby one supports the
(See Section 3.6.3)
- What happens if you don't model these signals?
o In configuration: Business and messaging signals are
explicitly modeled in configuration.
o In understanding the partner agreement: The partners may
mutually expect these be used and therefore set criteria
associated with the progress and outcomes of the business
process (and its activities).
o In managing state transitions: See previous comment.
o In seeking to generate computable artifacts: Without the
definition of such signals, the artifacts either have to be
defined out of band or in a potentially proprietary way. We
allow user-defined signals, although they are still related,
included and part of the business process.
- Links to the business process 
o Standard signals: Defined structure and semantics related to
the pattern, activity and transitions
o User defined signals: Allowed pointers to user-defined structure
o BT patterns
+ Template: See patterns matrices in the specification
(sections 3.4.9 and 184.108.40.206) that specify how these
signals infer content validation, succesful syntactic
validation and also allow the business process to
proceed (or not).
+ Profile: Partners identify their expectations using
the patterns and the selectable criteria to support
not only the business messages received but the
business signals that support them.
o Relevance to model
+ Business Transactions and the Business Service View
[4. See Chapter 9].
+ Business significance
- Involves timing parameters, implication to
business partner expectations, etc. Several
important criteria are defined around the use of
the business signals. [4. See Chapter 8. State
notations and their relevance to partner
expectations are found in Chapter 9.]
You can see how signals are used in the process definitions found on our public web site at: (ePV, Netherlands example) http://www.oasis-open.org/committees/document.php?document_id=16436&wg_abbrev=ebxml-bp
- Properties such as line width or color could be used but can't be
seen if printed on black and white.
- Properties such as message and (add) signal could be used. The
latter would have to be added. There would also possibly need to
be a way to differentiate whether or not business signals were
used as the implementation and runtime results may differ given
that assumption (different semantics).
- In order to maintain the focus of generation of software
artifacts, business signals should be considered for modeling in a
standard way (preferred to a tool specific option).
Additional note: We have seen tools that actually use the properties of messages to delineate a signal (such as a stereotype).
- Business signals differ from underlying messaging infrastructure
acknowledgements. Several communities including UK Bristol
government and ePV have indicated the value of the use of business
signals. Supports monitoring framework as well.
Two partners agree to engage in a Commercial Transaction pattern and use the BT from the pattern. A BTA is developed in a Business Collaboration to support these expectations. The partners will use reliable messaging and they use the business signals. An intelligibility (syntactic) check is made on the business message before the Receipt Acknowledgement business signal is sent, and successful business processing is required on the business document before an Acceptance Acknowledgement business signal is generated. Both carry timing expectations with them (in support of the BTA). For example, an Order Management system would validate a business document meets the partner expectations before initiating a sales order and sending a Response from a Purchase Order Request. Prior to the Response being sent these signals are used. They also allow the partners to optimize where required. The Buyer (Requesting Role) can understand that the Request was received and then whether or not it was successfully business processed (i.e. alleviating the potential need to query another Seller). Let's assume the Purchase Order doesn't muster in validation processing, then a Negative Acceptance Acknowledgement is sent. The Buyer (Requesting Role) may have an early indication and then can send a Cancel Transaction. Both parties are able to react more quickly to current conditions. In addition the business signals give clear indication of state alignment (the parties have a shared understanding of their condition and state of the business expectations).
Example business signals found at: http://www.oasis-open.org/committees/download.php/16652/ebxmlbp-v2.0.2-cd-ExampleSignals.txt
 From our FAQ found at: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/16540/ebBPv2.FAQ.html
 Not transport level or HTTP acknowledgements.
 Business signals defined in Section 220.127.116.11 at: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/ (in technical specification)
 This reference was provided on the public bpmn@omg list late last week - N090 UNCEFACT Modeling Methodolgy R10 . The business signals occur in the Business Service View (which is different than a transport level component), see: http://www.ifs.univie.ac.at/untmg/ (UMM_N090R10_2001-11_01.zip) - See chapters 8-9.
- Currently there is no standard way to differentiate a business
Reported: BPMN 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
Disposition: Resolved — BPMN 1.1
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred
Updated: Fri, 6 Mar 2015 20:57 GMT