Re: [ebxml-bp] Manual Operations in BPSS"

[Duane Nickull <dnickull@adobe.com>]

Comments inline:

martin.me.roberts@bt.com wrote:

>How do you know what state your BPSS is in?
>
[DN] I will answer this from our architectural vision.  Your BPSS is a 
map to a complete set of possible paths though a business process.  This 
includes a marker for each signal (transaction)  that will be sent 
between the parties of a process.  When each transaction is sent, sent 
and received or sent and failed, there is both an "initializing" state 
and a "advanced to" state.

Both parties must know where to start.  We'll arbitrarily call that 
point "State 0" for the sake of this email.  From State 0, a party that 
assumes one of the roles is possibly the only one that can send the next 
message.  When that party sends a message, the BP execution engine must 
initiate a Conversation ID that will be referencable from each and every 
transaction that takes place within this specific business process. 
 Conversation ID is the primary key for tracking the state of any 
business process.  

Let's say for arguments sake, the first transaction is called "foo" and 
it can only be entered from a state of State 0. The BP instance is 
referenced via a CPA instance document.  That CPA instance document has 
a set of signals and values that are affixed to those signals and how 
they must be treated.  It specifies that when Foo is sent, each party 
MUST keep a complete copy of  foo in their persistent message store for 
XXX amount of time.  Let's say this value is 7 days.

When A sends B the foo transaction, each has a copy of it inside their 
persistent message store.  If either wants to calculate the state of the 
transaction, they use the Conversation ID as the primary key to do so. 
 They talk to the messaging layer via the API and say (in effect) please 
give me the information I need for all messages with a conversation ID 
of XXX.   By combining that set of information with the roadmap of the 
process, state can be calculated.  They should also be able tell what 
the next "allowable" steps are in the process.  From the given state, 
they can go a number of next steps.    For instance, if it is deduced 
that the state is "PO sent and Accepted", then the next messages that 
are allowable may be either the purchased sending in a "Change Order 
Request" or the Seller Role sending in a "shipping advice" notification 
to the Buyer, at which time a change order request may no longer be 
acceptable as a next step.

For sake of argument, let's say that A has sent B the Foo transaction 
and then A's system crashes.  When A bring his system back up, he must 
be able to calculate the last known state by accessing all messages from 
the persistent message store.  This creates an implementation Best 
practice that the persistent message store should ensure that messages 
are safe from corruption.  If B has tried to send the reply or response 
back to the foo message when A's system is down, B will fail.  When A is 
back up, if the time to perform has not expired, B may still send the 
foo response message back.  If it has expired, then both parties must 
roll back the entire process to where they agreed it should go.  This 
creates a requirement that any BP script must be abel to express that.

The complexity of the state alignment is more complicated than it at 
first appears.  In the example above, there is the potential for a state 
misalignment based on missing a transport level acknowledgment and a 
business level ack coming back first.. If the system that receives the 
foo message sends back a business level acknowledgment, that should take 
precedence over any other signals, including a transport layer ack in my 
opinion.

The entire ebXML stack is a synergistic approach with the largest 
benefit being realized when the stack is complete.  Using the ebXML MS 
by itself does not solve many business problems but is capable of the 
functionality needed for complicated state alignment required to 
constrain complex processes over time.  SOAP does not provide this 
capability.  

It may be beneficial to create some formal documentation around this 
subject.  I had started preparing a 4 hour tutorial talk for XML Europe 
2004 on this very subject however it was rejected.  Perhaps this work 
should be illustrated to make it easier to understand?

Duane
They send the first message

>
>For us in BT we have used forks and joins with names to indicate states.
>This means that we could exchange with our partner through an out of
>band collaboration, where each of our collaborations is.  The customer
>could also send us that information.  Depending on who gets there first
>we could replay any transactions or agree to leap to a named state.
>
>Very simple but effective.  No replay required but you now have two
>gateways/systems stacks aligned.
>
>What do you think?
>
>Martin Roberts 
>xml designer, 
>BT Exact
>e-mail: martin.me.roberts@bt.com 
>tel: +44(0) 1473 609785  clickdial
>fax: +44(0) 1473 609834
>Intranet Site :http://twiki.btlabs.bt.co.uk/twiki
>
>
>  
>

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com