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
The process for handling transmission exceptions and application integration exceptions is generally the same for all types of documents. There are some differences for different patterns of interaction.Request/response pattern where a request message is sent and a response message is expected. Request/response may be handled in one of these ways:

Request and Response messages are independent from the gateway's point of view
- The requesting party's gateway expects a Receipt Acknowledgment from the responding partner's gateway, tracks this and reports exceptions.
- The requesting partner's gateway does not know whether or not a response message is expected and so does not track this.
- The requesting party's back-end application expects a response message, tracks this, and reports exceptions
Request and Response messages are linked in a business process specification such as a RosettaNet PIP or OAGI BOD.
- The requesting partner's gateway expects a Receipt Acknowledgment from the responding partner's gateway, tracks this and reports exceptions.
- The requesting partner's gateway also expects a response message, tracks this, and reports exceptions.
- You may end up with duplicate notifications - backend still has to track if some messages are manual or if using a standard that doesn't put control in the gateway. Harder for business user to override because no access to gateway.

What other patterns?

WSDL:
- One way
- Request-response
- Solicit-response (try to find where WSDL says what this is)
- Notification (what's difference between one-way and notification?)
UMM (see Karsten article in ebxml bp folder):
- Commercial transaction
- Request/confirm
- Query/response
- Request/response
- Notification
- Information distribution

Every transmission from one application to another is a potential point-of-failure, and every atomic processing activity in an application is a potential point of failure.

Application-to-Application
When a file is sent from one application to another, regardless of whether the applications are on separate computers or on the same computer, the following types of failures may occur:

Transmission failure - the file is not successfully transferred, intact, to the specified destination
Syntax error - the file contains bad syntax an cannot be processed
Compliance error - the file is not compliant with a specification
- In particular, a file may not be compliant to a specified standard and version
Application failure - the file does not pass the applications edits; the file does not conform to the recipient's business rules

When a file is sent from one trading partner's computer to another trading partner's computer, via a point-to-point connection or via a third party service provider, the receiving gateway should send back a business signal called a Receipt Acknowledgment in order to indicate that the sent document was received. Most Receipt Acknowledgments indicate success - successful receipt and successful validation. A Receipt Acknowledgment is also sent of the document was received but failed validation. A Receipt Acknowledgment does not report other failures that may occur. The received document may fail in such a way that a Receipt Acknowledgment cannot be generated. Likewise, a sent document may fail mapping/translation after a Receipt Acknowledgment has been sent, or the document may fail the receiving application's edits. The Receipt Acknowledgment itself may fail validation at the recipient's gateway (the sender of the original document that is the subject of the Receipt Acknowledgment).

Most standards provide for automated exception notices that can be used to report the failures that the Receipt Acknowledgment does not cover. However, adding automated exception notices to the processing increases the number of possible points of failure, because now the exception notices themselves may fail transmission, compliance checking or application edits. It is therefore recommended that when business signals (such as Receipt Acknowledgments) fail, or when exception notices fail, the resolution should be handled manually - via telephone or non-structured e-mail - in order to avoid getting into an unending loop of sending exception notices to report failures of exception notices or business signals.

Activity Diagram

Click here to view a larger image.

Narration

Step	Description
This represents a typical method for transmission tracking and error handling. Specifics for different standards vary.
A.	At start state A, the requesting party and the responding party have a pre-established relationship. The requesting party is ready to send a request.
1.	The requesting partner generates a request message. It is assumed that the back-end application used has its own transmission tracking and error handling logic.
2.	The back-end application sends the request message to the gateway. Generally, an intranet or other internal network is used for the routing.
3.	If the send fails, the back-end application should generate an exception notice or other error message. This is done internally and should not impact the trading partner.
B.	At end state B, the outbound request message has failed and the process ends. The problem will have to be resolved and then the process re-started.
4.	If the send is successful, the requesting party's gateway receives the request message.
5.	The back-end application may be generating a proprietary format or a standard format. The gateway translates the request message from the format generated by the back-end application to the format expected by the recipient. This could be any of several content standards, including X12, EDIFACT, RosettaNet XML, OAGIS XML, etc.
6.	If the translation fails, the requesting party's gateway should generate an exception notice or other error message. This is done internally and should not impact the trading partner. Whether or not the exception gets sent to the back-end application depends on the organization's support model. In this example, the exception notice is not sent to the back-end application because front-line support is handled by gateway personnel.
C.	At end state C, the translation or the transmission has failed. The problem needs to be corrected and the process restarted.
7.	If the translation is successful, the gateway envelopes the message according to what transport and routing method will be used.
8.	The message is transmitted. The two most common communications methods used are Value-Added Networks and internet communications.
9.	The requesting partner's gateway will monitor the status of the message to see if a Receipt Acknowledgment has been received from the responding party's gateway.
10.	If the send is successful, the responding party's gateway receives the request message.
11.	The responding party's gateway runs a validation process to see if the request message is in compliance with the chosen standard.
12.	If the validation generates a fatal error - an error that makes it impossible for the gateway software to generate a Receipt Acknowledgment, the responding party's gateway may generate and send an exception notice. While many standards recommend this approach, it is more common to deal with this type of error manually. Note that error checking for the send is not included on the diagram, but the process is the same as for any other sent message. See steps 8 and 9 above.
13.	The requesting party's gateway processes the exception notice. If the exception notice fails, the resolution should be handled manually.
D.	At end state D, an exception has been processed, and the process ends. The problem needs to be corrected and the process restarted.
14.	If the Receipt Acknowledgment is overdue and no exception notice has been received (manually or electronically), the requesting party's gateway may generate and send an exception notice to the responding party. Note that error checking for the send is not included on the diagram, but the process is the same as for any other sent message. See steps 8 and 9 above.
15.	The responding party's gateway processes the exception notice. If the exception notice fails, the resolution should be handled manually.
E.	At end state E, an exception has been processed, and the process ends. The problem needs to be corrected and the process restarted.
16.	If the validation step ends normally (no fatal error), the responding partner's gateway sends a Receipt Acknowledgment to the requesting partner's gateway. Note that error checking for the send is not included on the diagram, but the process is the same as for any other sent message. See steps 8 and 9 above.
17.	The requesting party's gateway processes the Receipt Acknowledgment.
F.	At end state F, the Receipt Acknowledgment has been processed, and indicates that the request message passed validation.
18.	If the receipt acknowledgment indicates that the requesting message failed validation, the requesting party's gateway generates and sends an exception notice to its back-end application. Whether or not the exception gets sent to the back-end application depends on the organization's support model. In this example, the exception notice is sent to the back-end application because front-line support is handled by back-end application support personnel. Note that error checking for the send is not included on the diagram, but the process is the same as for any other sent message. See steps 8 and 9 above.
19.	The requesting party's back-end application processes the exception notice. If the exception notice fails, the resolution should be handled manually.