Re: [ebxml-dev] BPSS execution engine

[Sacha Schlegel <sschlegel@cyclonecommerce.com>]

Hi Derrick, Steve, others

I apologize for having confused the useage of Acceptance Acknowledgement 
business signal and thank you for making me review my interpretation of the 
business signals!

A way around this means that I have to explicitly model the collaborative 
business process in such a way, that there is a substantive "business 
document" flowing back which indicates that a business request will be 
fulfilled or not ... because the simple Acceptance Acknowledgement business 
signal is non-substantive and does not assure me that the request will be 
fulfilled how I expect it to be fulfilled.

Regards

Sacha

Below text of the ebBP 2.0 draft 12, section 1.9 on Acceptance Acknowledgement 
and Receipt Acknowledgement :

Receipt Acknowledgement Business Signal
-----------------------------------------------------------
The Receipt Acknowledgement Business Signal, if used, signals that a message 
(Request or Response) has been properly received by the ebXML BSI software 
component.  

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 Acknowledgment. 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 an 
business acceptance of an obligation. A substantive business message actually 
includes a business document such as a purchase order acceptance.

On Friday 08 July 2005 03:33 am, derrick.evans@bt.com wrote:
> All,
> It is interesting to see the various interpretations placed on business
> signals as defined in BPSS. So,  just to add to the confusion I will throw
> my view into the ring.
>
> 1)	ebXML message acknowledgement - Your message was delivered
> 2)	BPSS receipt acknowledgement - Your message is in sequence and valid in
> dictionary terms for the transaction/collaboration 3)	BPSS acceptance
> acknowledgement - Your message is acceptable to the system of record (in
> effect a non-substantive acceptance) having passed any system rules that
> allow the Requesting business document to be recorded on the target system.
> 4)	Responding business document - what I actually intend to do about your
> request.
>
> Regards
> Derrick Evans
>
> -----Original Message-----
> From: Gerald Ebner [mailto:gebner@ihg.net]
> Sent: Friday, July 08, 2005 11:27 AM
> To: ebxml-dev@lists.ebxml.org
> Cc: Sacha Schlegel
> Subject: Re: [ebxml-dev] BPSS execution engine
>
> Sacha,
>
> thanks for the detailed answer.
> Very interesting your comment regarding the AcceptanceAcknoweldgement
> business signal: I always considered the meaning of this signal as
> "document is valid and will be processed", e.g. checking that the sender is
> known, the that sequence of exchanged documents still make sense, etc. This
> tasks would not require functionality of the backend application nor any
> user intervention. My idea was that the seller tells the buyer in a
> separate document (e.g. UBL OrderResponse and OrderResponseSimple) if he is
> willing to fulfil the order.
>
> regards
> Gerald
>
> Sacha Schlegel escribió:
> >Hi Gerald
> >
> >Welcome to the ebXML world, a framework for business to business
> >electronic commerce.
> >
> >Having studied the CPA formation process and the CPA negotiation [1] I
> >had similar questions concerning a "BPSS engine". When you look at the
> >Charter of the ebXML BP TC homepage [2] you will see one or two
> >sentences along the lines of  "The TC may identify bindings to support
> >the business process instance and ultimately the run-time execution.".
> >This means that a BPSS instance is not per se neccessarly executable.
> >Well this does not stop you from interpreting a BPSS instance. Another
> >possible use case is to not execute a BPSS but to monitor events
> >(emitted by the collaborative software, integration software, backend
> >software, others) and try to map the events to the BPSS to figure out
> > whether a BPSS is correctly followed or not.
> >
> >What is important to realize, as you may have already, is that a BPSS
> >engine could, but must not (you cannot require that your trading
> >partner must use such an engine, or they may use a different
> >implementation than you use), run at each party. Then it is important
> >that these engines (or interpreters) are synchronized. Personally I
> >think more work has to be done for multiparty collaboration in relation
> >with forks, joins, and "Begins when" and "ends when" constructs. Some
> > people probably are doing research in this area.
> >
> >On a separate note, of interest is when you combine the collaborative
> >aspect of b2b (eg the ebXML BP) and potential private aspects. Often
> >this will result in linking, or making sense of the collaborative
> >business processes and the private business processes.
> >
> >In that direction, if you follow ebXML business processes and select
> >the commercial business transaction for example you are required to
> >exchange further business related information. One example is the
> >"AcceptanceAcknowledgement" business signal. This business signal
> >indicates, that the backend application has accepted whatever was sent
> >in the actual message. Eg it is the OK that your message will be
> >processed by the backend application, eg the backend application will
> >process your purchase order. I assume in a business world, once you get
> >an AcceptanceAcknowledgement business signal of a trading partner, you
> >do know that you do not have to place the same order at another trading
> >partner. But then, if a partner sent you the AcceptanceAcknoweldgement
> >business signal and in the end the partner will NOT deliver, or process
> >your request,  the idea is that you have a some legal means. For
> >example you could define Service Level Agreements in your contracts
> >based on this business signal. For example whenever your trading
> >partner sends you the AcceptanceAcknowledgement signal then it HAS to
> > deliver otherwise he is breaking the agreement and penalties can result.
> >
> >An interesting case because this activity, to send the
> >AcceptanceAcknowledgement signal involves the two worlds, the public
> >collaborative world (collaborative business process) and the private
> >world (private business processes).  This will require some smart
> >integration solutions or even better your backend applications can make
> >use of this additional collaborative business information.
> >
> >A typical question is: Who is responsible for this business signal? The
> >backend application or the collaboration system? The backend
> >application can be a very dumb system which has no sense at all of such a
> > business signal. Further, you better make sure you generate this business
> > signal only if you are sure you can process, fullfill the expectation the
> > business signal is used for :)
> >
> >Regards
> >
> >Sacha
> >
> >[1] http://www.schlegel.li/ebXML/index.html
> >[2] http://www.oasis-open.org/committees/ebxml-bp/charter.php
> >
> >On Tuesday 28 June 2005 07:05 am, Gerald Ebner wrote:
> >>Dear ebXML Dev,
> >>
> >>first of all: I'm an ebXML newcomer, actualy going through the specs
> >>and forums, and thinking about an architecture for the B2B system to be
> >> built. My question: I found promising (reference) implementation of the
> >> ebXML registry and messaging services, but nothing that covers the
> >> concept of
> >>- "business process/BPSS execution engine"
> >>- "choreography engine"
> >>- "ebXML execution framework"
> >>i.e.a  run-time execution instance enforcing the BPSS business
> >>collaboration protocol (I just found /ebSOA, /but that sounds like a
> >>future approach).
> >>
> >>How would one typically implement the choreography?
> >>- Hand code the BPSS engine?
> >>- Transform the BPSS to BPEL?  How?
> >>
> >>thanks in advance
> >>Gerald Ebner