Re: [ebxml-dev] renamed thread: State Alignment

[Karsten Riemer <Karsten.Riemer@Sun.COM>]

I think Mike is right, there are really two levels of state alignment that
needs to take place.  ebXML has made a great contribution to the
partner-to-partner (a.k.a. b2b) alignment.  Internally, clearly each partner
has its own set of state management issues. Mapping between the two may for a
while be 'manual', but that does not detract from ebXML's accomplishments in
partner-to-partner alignment.  (I took the liberty to rename this thread to
more appropriately reflect its content)

-karsten


>Bob,
>
>Thanks for your observations, but I think you missed my point.  I am *not* 
>"confusing the states of an external business deal with the internal states 
>of the private internal business apps."  That is precisely my point.  They 
>*aren't* the same. However, if you're going to execute the BPSS you have to 
>track it's states, and the only place you can really go for the states by 
>trying to correlate them with the states available in the application.
>
>Furthermore, when the BPSS and BP worksheet examples have things like:
>
>"Constraints - The invoice shall only be sent after confirmed 
>shipment.  The invoice shall reflect the confirmed shipment."
>"Guard Condition - ThreeWayMatach(Invoice).State=VALID"
>"Preconditions - Valid Sales Order, Valid Vendor Relation"
>
>You're telling me that you aren't expecting a BPSS-enabled application  to 
>pay attention to this type of stuff?  If they are supposed to, where are 
>the standard semantics for any of these values?  If we're not expecting the 
>application to pay attention to them, what's the point of forcing them into 
>a machine-processable XML document?
>
>Cheers,
>
>Mike
>
>
>At 04:14 PM 6/25/02 -0500, bhaugen wrote:
>>Mr. Rawlins and all,
>>
>>I think you are confusing the states of an external
>>business deal with the internal states of the private
>>internal business apps.
>>
>>They are not the same.
>>
>>The business states that need to be synchronized
>>must be simple and agreed-upon by both trading
>>partners in a business transaction.
>>
>>They only refer to the milestones in a deal where
>>the parties would shake hands and say "I agree"
>>if they were sitting across a table.
>>
>>For example, in an offer-acceptance transaction
>>(such as a purchase order), the end states that
>>are interesting might include whether the offer
>>was accepted or rejected.
>>
>>These agreements on the state of the deal
>>happen one way or another in trad EDI, too.
>>Just slightly differently.
>>
>>There is a lot of confused discussion in many
>>circles right now about Web "transactions".
>>Most of the confusion comes from thinking
>>of them as database or internal workflow
>>transactions.  They get much easier if
>>you think of them as normal external
>>business deal handshakes.
>>
>>-Bob Haugen
>>
>>----- Original Message -----
>>From: Michael C. Rawlins <mike@rawlinsecconsulting.com>
>>To: Jean-Jacques Dubray <jjd@eigner.com>; 'Assaf Arkin'
>><arkin@intalio.com>; <ebxml-dev@lists.ebxml.org>
>>Cc: 'Ismael Ghalimi' <ghalimi@intalio.com>
>>Sent: Tuesday, June 25, 2002 4:04 PM
>>Subject: RE: [ebxml-dev] BPSS and WSCI
>>
>>
>> > Jean-Jacques put this very nicely:
>> >
>> > At 04:07 AM 6/25/02 -0400, Jean-Jacques Dubray wrote:
>> >
>> > ><JJ> The fundamental achievement of BPSS is the state synchronization
>> > >between two (business) parties, whether this is part of a
>>"commitment"
>> > >or a more casual message interchange. In any B2B message exchange
>>(even
>> > >between a travel agent and an airline) this is mandatory. Imagine the
>> > >cost of getting periodically out of synch with your business
>>partners?
>> > >
>> >
>> > While I agree with these statements, I must also note that they also
>>point
>> > out one of the more formidable problems that application vendors will
>>have
>> > in supporting the BPSS.  Every application already has it's own state
>> > machine.  These state machines are usually organized around the point
>>of
>> > view of internal business processes (for example, many systems won't
>>let
>> > you invoice without an order, or invoice without first indating that
>>the
>> > ordered goods have been shipped).   Implementing a BPSS will require
>>one to
>> > map the states of these existing machines onto those specified in the
>> > BPSS.  So, added to the burden of mapping application data to UIDs (or
>>EDI
>> > data elements in our current world), vendors and/or end users have to
>>map
>> > application states to BPSS process states.  That's fine so long as the
>>BPSS
>> > states are uniform (like a defined dictionary of states), but if they
>>are
>> > different then life gets very complicated (much more so than just
>> > supporting both X12 and EDIFACT invoices).  In addition, if the BPSS
>> > specifies a state that can't be easily matched to an internal
>>application
>> > state, then either application modifications are required in order to
>> > support the state or the user is forced to intervene and handle that
>>state
>> > "out-of-band" as a manual exception.
>> >
>> > And about getting "out of synch" with your business partners - I'm
>>sure
>> > that there are a few people who have this problem and for them I'm
>>sure
>> > that it is a big problem.  However, most application systems I've
>>worked
>> > with that support e-Business in any serious fashion are already
>>configured
>> > to avoid this type of thing.  I don't see it as a major concern for
>>most users.
>> >
>> > This leads me to the conclusion that while the BPSS and the UMM upon
>>which
>> > it is based may be valuable tools for documenting and agreeing on
>>business
>> > processes (for those who find ROI in using them), I see little utility
>>for
>> > them in the near future for actually automating the execution of
>>business
>> > processes.
>> >
>> > Mike (OK - so I still see the glass half empty ;^) )
>> >
>> >
>> > >Michael C. Rawlins, Rawlins EC Consulting
>> >
>> > www.rawlinsecconsulting.com
>> >
>> >
>> > ----------------------------------------------------------------
>> > The ebxml-dev list is sponsored by OASIS.
>> > To subscribe or unsubscribe from this elist use the subscription
>> > manager: <http://lists.ebxml.org/ob/adm.pl>
>
>---------------------------------------------------------------
>Michael C. Rawlins, Rawlins EC Consulting
>www.rawlinsecconsulting.com
>
>
>----------------------------------------------------------------
>The ebxml-dev list is sponsored by OASIS.
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.ebxml.org/ob/adm.pl>