OASIS ebXML Messaging Services TC

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

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

    Posted 12-05-2001 20:43
    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