RE: [ebxml-msg] Short Lived Conversation Ids: Comments on the 1.0 9about ConversationId

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

I was hoping to read all the email on this thread before I responded, but
after I read the 10 or so for Nov 30th, I'm giving up.  I have a bit of
practical experience in e-commerce with things like conversation id's; but,
I won't claim to be an expert.

In any case, due to the nature of the business information being
communicated in business transactions, I am fairly confident we will find
that conversation id's will be short lived.  "Short" can mean either a few
number of transactions (perhaps over a long period of time) and/or a small
number of transactions over a small time period.  You may already
intuitively understand this if you understand how economic commitments,
resources, and agreements relate to content of business messages.

Here's the example: Buyer A sends five purchase orders to Seller B. There
will be five different conversation ids.  In the simple case, if Buyer A
wants to change one of the orders, the Buyer sends a change order and the
conversation id of the change order message is set to the coversation id of
the message containing the corresponding purchase order.  Now, along comes
the ASN(s) and eventually the invoice(s). It is natural to think that the
ASN and invoice is in the same conversation as some purchase order.
Furthermore, some of us will want to model the ASN and Invoice into the same
business process as create order and change order transactions.  However, it
is very common for ASN to carry information for multiple purchase orders and
for invoices to invoice multiple purchase orders.  So, what conversation id
do I put on the invoice's message where the invoice references two or more
purchase orders?

I propose that the message spec recommends that a conversation id be limited
to a single instance of a business transaction. Applications are quite adept
at relating business documents that cross multiple business transactions and
mulitple business processes (if you are interested in this, I recommend you
look into the eBTWG efforts).  Applications don't need a conversation id to
do this and, based on my understanding from the field, many legacy
applications will not be able to support conversation ids.

/Brian Hayes