Thanks
Arvola !! You have saved me from writing an email. I absolutely concur with what
you say ... you can have one "service" supporting multiple different
business transactions. If we do this it also means that we can have one
conversation involving multiple different business transactions, e.g. a 3A4
(Create Purchase Order) followed by a 3A8 (Change Purchase Order) where the
change purchase order was for the order created by the create purchase
order.
Another use case is where you can have the same service
used in multiple different collaborations for example consider the following two
collaborations:
Example 1, Invoice Payment:
1. BT1 - Present Invoice
2. BT2 - Make Payment
Example 2, Pay Refund:
1. BT1 - Request Refund
2. BT2 - Make Payment
Both
of these involve making a payment which, in Business Transaction terms, would be
carried out the same way.
Where
I think it gets really critical to separate the two is when you want to route
messages. If Party, Service and Action are always the same, irrespective of the
business process in which they are being used then you can use these three
fields for routing purposes in a consistent way.
On
reflection this I think is one of the issues I have with always requiring a CPA
as defined in the CPA/CPP spec as you can actually quite reasonably do routing
in two different ways:
look
up the CPA from the CPA ID and route the message to the endpoint
identified, or
look
up the Party, Service and Action in a table to identify where to send the
message to.
The
former allows you to vary the endpoint very flexibly and alter where you send a
message to depending on the business process you are in, the latter allows you
to have simpler rules but with less flexibility.
I
think both use cases are valid ... and required ..
David
-----Original Message-----
From: Arvola Chan
[mailto:]
Sent: Thursday, July 19, 2001 9:04
AM
To: Martin W Sachs; David Fischer
Cc: Burdett, David;
ebXML Msg; Pete Wenzel
Subject: Re: PIP IDs
Marty,
Up to now, RosettaNet PIPs are either
request-response (two-actions) or notification (one-action) style business
processes. Earlier versions of PIP 3A4 are an exception in the sense
that PIP 3A4 covers Create Purchase Order (request-response), Change
Purchase Order (request-response) and Cancel Purchase Order (request-response)
interactions. Recently, PIP 3A4 has been split into 3A4 (Create Purchase
Order), 3A8 (Change Purchase Order), and 3A9 (Cancel Purchase Order) in order
to achieve some degree of uniformity across PIPs (I believe). Therefore, I
think it is reasonable to equate existing RosettaNet PIPs with BPSS
Business Transactions.
In the RosettaNet message header, there are
separate elements to identify the PIP ID, the PIP action and the Service.
Multiple PIPs may be implemented by the same service, e.g., there may be a
Buyer service implementing PIPs 3A4, 3A8, 3A9 from the buyer perspective, and
a Seller service implementing the same PIPs from the seller
perspective.
I don't think we should equate PIP ID with
Service and action with "the particular business transaction within the PIP".
Otherwise, we will not be able to capture the role information, e.g., the
ability to distinguish a Buyer Service from a Seller Service, and a request
action from a response action.
From the RosettaNet point of view, it will be
desirable if we can have distinct Service, PIP (equivalently BPSS Business
Transaction), and action elements in the message header. Alternatively, we can
use the Service element to capture role information (e.g., Buyer vs Seller),
and use the Action element to capture the PIP ID. Whether we are dealing with
a request action or a response action will have to be inferred from the
Service element.
Regards,
-Arvola
Arvola Chan ()
TIBCO Software (on loan to
RosettaNet)
+1-650-846-5046 (US-Pacific)
----- Original Message -----
From: "Martin W Sachs" <>
To: "David Fischer" <>
Cc: "Burdett, David" <>;
"ebXML Msg" <>
Sent: Thursday, July 19, 2001 8:07
AM
Subject: Re: PIP IDs
In my opinion it makes more sense for Service to point to
the PIP ID and
action to point to the particular business transaction
within the PIP. In
other words one execution of a PIP is a
conversation. I believe that some
of the PIPs include multiple
business
transactions.
Regards,
Marty
*************************************************************************************
Martin
W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts,
NY 10598
914-784-7287; IBM tie line 863-7287
Notes address:
Martin W Sachs/Watson/IBM
Internet address: mwsachs @
us.ibm.com
*************************************************************************************
David
Fischer <> on
07/19/2001 10:45:54 AM
To: "Burdett, David" <>
cc: ebXML Msg <>
Subject: PIP IDs
David, in the F2F you
mentioned the need for a new element to contain
industry specific business
process identifiers such as a RosettaNet PIP
identifier. Could this be done
with Service/Action where the Service would
be something like RNet and the
Action something like PIP3A1
(Request
Quote)?
<eb:Service>urn:services:RNet</eb:Service>
<eb:Action>PIP3A1</eb:Action>
Regards,
David
Fischer
Drummond
Group.
------------------------------------------------------------------
To
unsubscribe from this elist send a message with the single
word
"unsubscribe" in the body to:
