RE: Transition question (executing Business Transaction several t imes)

["Hayes, Brian" <Brian.Hayes@Commerceone.com>]

[I applogize for the long email.  I was planning to answer JJ's questions a
little more directly and then serendipty got the best of me.]

At first glance, I also thought that this rule appeared to be undesirable:
	- A transition cannot enter and exit the same state

Example...
	In the bpWS (Business Process Analysis Worksheets & Guidelines)
example (Appendix C), there is a collaboration activity diagram that
violates this rule.  See section C.3.4, BC-6.4-Create-Vendor-Purchase-Order,
Figure 12-13 , <<BusinessCollaborationProtocol>> CreateVendorPurchaseOrder.
In the model, the Retailer repeats the CreateVendorPurchaseOrder business
transaction activity until a vendor accepts the order or the Retailer
reaches the end of its list of vendors. 

However...
	I think there is something wrong with the
BC-6.4-Create-Vendor-Purchase-Order model:  The model is specifing internal
processing and state of the Retailer. The model describes the Retailer
iterating through its list of vendors.  Business process specifications are
about the public process between the parties and not (at least typically)
about a party's internal processing.  So, in the model, the
CreateVendorPurchaseOrder transaction's transition unto self should be a
transition to FAILURE. In making this fix, the Retailer can still initiate a
sequence of Create Vendor Purchase Order collaborations -- there are no
guards to prevent it from doing so.

Change Order and BPSS Multiparty Collaborations...
	Based on the process described by JJ below (and one's I've seen
described), there are two scenarios:
	1.	Buyer initiated change order
	2.	Seller initiated change order
It looks like there is a common transaction here called "Change Order."
Further analysis might show that there are two partner types: Buyer and
Seller.  And there are atleast two roles: InventoryBuyer, CustomerService.
Transaction-level modeling for the scenarios leads me to believe that there
are two transactions:
	1.   Buyer Initiated Change Order (initiating party/role:
Buyer/InventoryBuyer; responding party/role: Seller:CustomerService)
	2.   Seller Initiated Change Order (initiating party/role:
Seller:CustomerService; responding party/role: Buyer/InventoryBuyer)
	Given the differences in the roles, there are two transactions.

	[Perhaps it would be better to substitue "InventoryBuyer" with
"InventoryManager."  But I have no idea if in the Seller Initiated Change
Order if the Seller's customer service agent or the Seller's inventory
manager initiates the change order.  I would need to ask a domain expert.
The point of doing this substitution is to see if there can be just one
transaction.]
	[Note on seller initiated change order:  In the limited analysis
that I have participated in, seller initiated change order could be modeled
as a buyer initiated change order.  I believe the seller usually calls the
buyer to inform the buyer of the seller's desire to change the order.  The
seller might do this, say, to substitute parts.  When the buyer gives the
verbal okay, that can be considered a buyer initiated change order.  And,
it's even e-business since the phone system is an electronic system :^)]

	The ebBPSS states that "Binary Collaborations are between two roles
only" [ebBPSS, line 489].  Therefore, to model this collaboration using the
BPSS, we need to use the BPSS Multiparty Collaboration construct.

A transition cannot enter and exit the same state...
	Okay, so lets just focus on one transaction, Buyer Initiated Change
Order, and model the possibility of executing it several times.  First, one
would think that the Multiparty Collaborations choreography that one could
specify that the Buyer Initiated Change Order transaction could be initiated
multiple times.  It is not clear to me how one would choreograph
BinaryCollaborations in a Multiparty Collaborations (I'll need to analyze
the ebBPSS some more).
	Alternatively, I believe you can Transition from a
BusinessTransactionActivity to a CollaborationActivity.  I could imagine the
following transitions:
	+ Start to Business Transaction "Buyer Initiated Change Order"
	+ Business Transaction "Buyer Initiated Change Order" to Binary
Collaboration "Buyer Initiated Change Order"
	+ Business Transaction "Buyer Initiated Change Order" to Success
	+ Business Transaction "Buyer Initiated Change Order" to Failure
	+ Binary Collaboration "Buyer Initiated Change Order" to Success
	+ Binary Collaboration "Buyer Initiated Change Order" to Failure
Naturally, you would need to use BPSS elements Start, Success, Failure,
Transition, BusinessTransactionActivity, and CollaborationActivity to do
this.
	Thus, I believe the rule can stand; although, it would be
interesting to know what the motiviation for the rule is.  What does it say
in the UMM Metamodel?


/Brian Hayes


-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjdubray@exceloncorp.com]
Sent: Sunday, August 05, 2001 4:06 AM
To: Karsten Riemer - Sun IR Development; ebxml-bp@lists.ebxml.org
Subject: Transition question


Hi:

I have a question about business transactions that may be executed several
times. The very common example is a change purchase order BT. Once an order
has been placed, there are many industries which would allow the buyer (or
the seller) to change the PO any number of time.

How do you set up the transitions to do that? My first instinct would have
been to set up a transition from and to thesame business transaction but I
came across this Wellformedness Rule:
- A transition cannot enter and exit the same state

Does that mean I cannot have a "from" and "to" which is identical (because
actually what I am tryng to model is a transition which exit and enter the
same state)?

In which case, how do you specify this essential business pattern?

JJ-