Re: [tamie] uc3 ubl-ish LTS diagram as discussed at Seoul Korea conference

["Stephen Green" <stephen.green@documentengineeringservices.com>]

In response to Dale's questions about UBL ordering process(es):

According to the UBL 2.0 spec

"Figure 8. Ordering Process"
http://docs.oasis-open.org/ubl/os-UBL-2.0/art/UBL-2.0-OrderingProcess.jpg

the ordering can complete for in several ways which (although it is, IMO,
ambiguous in the diagram, which isn't supposed to limit how UBL is used *)
depend on which document is used to respond to the order.
If an OrderResponse is the document sent in response then there are three ways
to complete:
1. if the OrderResponse is sent without any modification then the order can be
completed by Buyer doing nothing (except of course sending signals where
appropriate e.g. with ebXML)
2. if the OrderResponse is sent with modification then there are two ways to
complete the process
2a. Buyer send an OrderCancellation
2b. Buyer send an OrderChange
I note (and again it isn't all that clear, IMO) that an order
rejection by the Seller
is typically (I say typically because the process isn't 'dictated' by
UBL as such *)
performed using the OrderResponseSimple. I'm not sure it *can* be done using
the OrderResponse document schema without customizing the schema.

What isn't clear from the diagram is how the different responses relate to the
different paths to completion. (I might want to comment on this to the UBL TC
as they approach UBL 2.1).


* to quote the UBL 2.0 spec
Section 4: UBL 2.0 Context of Use
http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html#CONTEXT
"The processes described in this section, and the business rules
associated with them, define a context for the use of UBL 2.0 business
documents. They are normative insofar as they provide semantics for
the UBL document schemas, but they should not be construed as limiting
the application of those schemas."

I'm not sure we are on safe ground using UBL as reference material for
the use case #3
since the use case is about processes and UBL 1.0 and 2.0 do not
specify any limits on
processes which use UBL documents/schemas. If we were to define condition guards
we could do so in terms of UBL schema/XPaths but that might be as far
as is appropriate
for UBL as a Standard. Maybe there is a UBL profile which gives us
what we want - maybe
NES http://www.nesubl.eu/, OIO
http://www.oioubl.info/classes/en/index.html, or CEN's BII.
But do we really want to go that far. We could stick to the process
paths I describe above
(but define/clarify them ourselves in the details) or make up our own.

Best regards

Steve

2008/12/29 Moberg Dale <dmoberg@axway.com>:
>
>
> Preliminary Discussion.
>
>
>
> The events monitored following the transition to the PurchaseOrderRequest
> state are primarily for a message that is either a
>
>
>
> PurchaseOrderConfirmation
>
> PurchaseOrderDecline (or Rejection)
>
> PurchaseOrderChange.
>
>
>
> (There is only one of these 3 messages sent or else a signal (NOF)
> indicating technical unrecoverable failure for the process instance.)
>
>
>
> The transition then would be to the ASN state if the PurchaseOrder
> Confirmation is received (to Despatch Advice in UBL?)
>
>
>
> If either of the other events is received, the first transition is to send a
> Notification that Cancels the original PO Request.
>
> Then if a Decline was received, the transition is to Stop (it would be to
> the Failure flavor of Stop in ebBP)
>
> If a PO Seller Side change request was received, then the Cancellation would
> be followed by a transition to a new
>
> PO request when  the POChange Request was accepted by the original Buyer.
>
>
>
> But I am uncertain what happens when the Buyer Declines to accept the
> Seller's proposed PO Change request. I suppose a Cancel would be sent. That
> means the logical label on the Transition to Failure should be
> "PurchaseOrderRequestDecline or BusinessFailure" How the Seller is notified
> of the rejection of the
>
> PO Change Request is not clear to me from our discussion of UBL supported
> processes.
>
>
>
> So we probably need to add  discussion on this point so that we can clarify
> this use case.
>
>
>
>
>
> I will create an ebBP 2.0 instance for this case once we resolve the above
> issues and reach consensus on UBL supported process.
>
>
>
> It should also be possible to supply BPMN 2.0 diagrams for this use case
> within the next few months when the choreography and public process
> visualizations are settled.
>
>
>
> It would be nice to have a WS- BPEL and/or a WS-CDL instance eventually
> also.
>
>
>
>



-- 
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice