Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
 Generic Models Index | Supporting Documentation | Downloads | FAQs |
Generic Model 2 - Generic Three-Party Request/Response Serial Interactions

Special Notes:             

Process Activities

Many three-party interactions are really serial two-party interactions, e.g. Partner A interacts with Partner B, and Partner B interacts with Partner C.  As use of 3rd parties has grown and as use of electronic commerce has grown, it has been argued that business models for multi-party, collaborative processes are needed.  Many processes involving agents, intermediaries, or service providers, such as distributors and contract manufacturers, are 3-party models conceptually, but in reality, the interactions are a series of 2-party interactions.  The technology for supporting true "collaborative" processes is still emerging. 

Overcoming the obstacles encountered in the three-party serial interactions is important for preparing the way for the next-generation of collaborative process and enablement tools. 

The main difference between the two-party interactions and the three-party serial interactions is the need for one party to include references to a third party.  For example, a buyer placing an order to a supplier to have parts drop-shipped to a contract manufacturer needs to report the contract manufacturer's address, purchase order number and part number, in addition to the buyer's own address, purchase order number and part number.  Many legacy ERP systems were designed based on assumptions about two-party interactions, and had no way to store or enter information about a 3rd party involved in a transaction.  Likewise, the supplier needs to capture and store information about the third party, and include it on documents such as packing slips. Again, the early obstacle was that many legacy systems had no way to process data about a 3rd party.

The other assumption that should be challenged in multi-party interactions is timing (a/k/a time to perform).  For example, a specification for a business process may specify that a response to a request should be returned within a certain amount of time.  The value set is often based on two-party interactions.  In a 3-party interaction, Partner A may send a request which means that Partner B has to send a request to Partner C, and get back a response in order to respond to Partner A.  In that interaction, the process may need to allow Partner B a longer time to respond than would be needed in a strictly two-party interaction.

The following diagram shows a generic three-party request/response serial interaction.  The request document could be a Request-for-Quote, a Purchase Order, a Forecast, etc.  The diagram illustrates that some of the activities between the End-Customer and the Agent or Service Provider may be dependent upon the results of interactions between the Agent or Service Provider and the Supplier.


Activity Diagram     Narration

 


Narrative (see also Graphic):

Step Description
A. At start state A, the primary requesting party and Agent, Intermediary or Service Provider have a pre-established relationship.  The primary requesting party is ready to make a request.
1. The primary requesting party generates and sends a Request Document to the Agent, Intermediary or Service Provider.
2. The Agent, Intermediary or Service Provider processes the Request Document.
3. If the Agent, Intermediary or Service Provider can respond immediately, it generates and sends a Response to the Request Document (Response Document), with the status set to either "Accept" or "Reject."
4. The primary requesting party processes the Response Document.
B. At end state B, the primary requesting party has received an Response Document with a status of "Accept" or "Reject".  If the status is "Accept", the primary requesting party can continue with the next step in the business scenario.  If the status is "Reject," the process ends.
C. Start state C indicates that a follow-on Response Document should be generated if the the Response Document indicated a status of 'pending'.
5. If the Agent, Intermediary or Service Provider cannot respond immediately, and especially, when the it needs a a quote from the secondary responding party before responding to the primary requesting party, the Agent, Intermediary or Service Provider generates and sends an Response Document with the status set to "Pending."
6. The primary requesting party processes the Response Document.
D. At end state D, the Agent, Intermediary or Service Provider has sent a response that indicates that the status is "pending".  The primary requesting party should not continue on to the next step in the business scenario.  The primary requesting party should expect to see a follow-up response from the Agent, Intermediary or Service Provider within an agreed, configurable amount of time.  The amount of time may be specified the Trading Partner Agreement.  The primary requesting party may launch an exception notice if the Agent, Intermediary or Service Provider's follow-on response is not received within the agreed, configurable period of time.
7. The Agent, Intermediary or Service Provider generates and sends a Request for Quote (Request Document) to the secondary responding party.
8. The secondary responding party processes the Request Document.
9. The secondary responding party responds to the Request Document.  The secondary responding party will send a status of either "Accept," "Reject," or "Pending."
10. The Agent, Intermediary or Service Provider processes the Response Document.
E. At end state E, the Secondary Responding Party has sent a response that indicates that the status is "pending".  The Agent, Intermediary or Service Provider should not continue on to the next step in the business scenario.  It should expect to see a follow-up response from the Secondary Responding Party within an agreed, configurable amount of time.  The amount of time may be specified the Trading Partner Agreement.  The Agent, Intermediary or Service Provider may launch an exception notice if the Secondary Responding Party's follow-on response is not received within the agreed, configurable period of time.
F. Start state F indicates that a follow-on Response Document should be generated if the the Response Document indicated a status of 'pending'.
11. The Agent, Intermediary or Service Provider responds to the primary requesting party's Request Document.  The secondary responding party will send a status of either "Accept," "Reject," or "Pending."
G. At end state G, the primary requesting party has received an Response Document with a status of "Accept" or "Reject".  If the status is "Accept", the primary requesting party can continue with the next step in the business scenario.  If the status is "Reject," the process ends.
H. At end state H, the Agent, Intermediary or Service Provider has sent a response that indicates that the status is "pending".  The primary requesting party should not continue on to the next step in the business scenario.  The primary requesting party should expect to see a follow-up response from the Agent, Intermediary or Service Provider within an agreed, configurable amount of time.  The amount of time may be specified the Trading Partner Agreement.  The primary requesting party may launch an exception notice if the Agent, Intermediary or Service Provider's follow-on response is not received within the agreed, configurable period of time.
I. Start state I indicates that a follow-on Response Document should be generated if the the Response Document indicated a status of 'pending'.

 

Last updated 06 January 2003