OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [ebBP] 3/28/2004: WI-45- Transactions via other channels [RSD]


Discussion|OASIS.ebBP.WI45-Transactions via other channels;
Topic|;
Point|Summary review.

mm1@
For this work item, I think we have found at least part of a solution 
and I would like to see if this can be generically handled in the BT/BTA.

Work Item 45 - Transactions performed on other channels
Description: The state of one partners system gets legitimately out of 
sync.  For example a customer places an order via the phone, when it 
should normally go through a gateway.  The customer system does not then 
reflect the order.  In this case, a transaction needs to be enacted that 
get the systems back in sync. This will enable the BPSS to be more 
effective in the transactional environment.

Presented BT Use Case: Need to: 1) Allow the send of the response even 
though the request was out of band, 2) Any party can enact a BTA, or 3) 
Allow request to be sent after response.

Potential requirements:

    * Provide mechnaism to align partners when an action occurs by other
      means.
          o The solution cannot be a delegated submission, because a
            notification is required to align state when a business
            message occurs out of band. the solution cannot be a
            business signal because the business document and message
            are required.
          o Provide visibility to application systems of gateway events.
          o Provide a flag to acknowledge the out-of-band process.
    * Allow for the specification that a BTA could be initiated by
      either party.

Recommendations:

    * Provide a 'reversible' flag be added in the business transaction
      element. We can specify this kind of flow at the state level using
      the fork and join and subcollaboration (Kulvantunyou, 27 Nov 2003).
    * Provide a flag to allow for the out-of-band message to occur.
    * Maintain default behavior as defined.
    * Assume no acceptance would be required [Tell].

Open discussion items:

    * How will this affect ebMS.
    * Determine if an acceptance is required.
    * If a flag is used, are there any business side effects for
      acceptance and conditions?

One proposed option was to use the BSI where each party could update its 
collaboration state via an internal system by notifying the BSI. One 
party could be in charge  of updating the BSI where the BSI notifies the 
other party, or the external system could be brought into an 
end-to-end-collaboration definition (as a web service) [Dubray 25 Nov 2003].

***Martin, can you indicate what this would look like in the schema and 
provide to the team?
Everyone, if there are other requirements or side effects that have not 
been acknowledged, please advise.**
*@mm1



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]