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 1 - Generic Request/Response Transmission Tracking and Error Handling

Process Activities

Special Notes:            

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:

What other patterns?

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:

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     Narration

But it's too big to print! ... Due to the size of this model, you may want to print the model in parts by downloading and printing an image that is broken into parts or an image that is resized to fit on a page.  For some images you may need to adjust the page orientation or rotate the image.

Images:
Quadrant 1   Quadrant 2   Quadrant 3
  Quadrant 4
Smaller Print Version of Diagram

 


Narration   Activity Diagram

(incomplete)

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.