CompTIA EIDX - Generic Model

sitemap

EIDX Home

About EIDX

Benefits of Membership

Business Process

	Current Projects
	Clickable Business Models
	Business Model Navigational Help
	Business Model Development Methodology
	Business Model Legends

Education

Guidelines & Standards

LOGIN

PASSWORD

remember my login

forgot my password

EIDX Generic Business Model
Generic Request/Response Transmission Tracking and Error Handling
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 (PO) number and part number, in addition to the buyer's own address, PO 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. 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 three-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 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 PO, 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

Click here to view a larger image

Narrative

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.'