Error Scenario Examples
Infrastructure Level Response 10001: Fatal-Error - Handling Specification Error
Infrastructure Level Response 10002: Fatal-Error - Infrastructure Response Value Processing Error
Infrastructure Level Response 10003: Fatal-Error - Business Level Response Value Processing Error
Infrastructure Level Response 10004: Fatal-Error - Message Definition Value Processing Error
Infrastructure Level Response 10005: Fatal-Error - Message Definition Version Value – Processing Error
Infrastructure Level Response 10007: Sender Reference Value - Processing Error
Infrastructure Level Response 10008: Handling Specification Business Rule Error
Infrastructure Level Response 10009: Fatal-Error - Unreadable Message Received
When a system receives a message which is totally unreadable due to it being corrupted or malformed, there is a default behaviour defined which systems should support. This behaviour for information unobtainable from the handling keys and header elements is listed below:
Issue - Unable to ascertain if a response has been requested.
Default Behaviour - A response must always be returned to the sender.
Issue - Unable to ascertain sender person or organisation.
Default Behaviour - Return a response to MESH mailbox original message was sent from and original sending system will have to deal with response the best it can.
Issue - Unable to ascertain whether original message was for action or only for information.
Default Behaviour - Assume for action and return response.
Issue - Unable to ascertain any other information
Default Behaviour - Return response as soon as possible once error is detected.
Issue - Unable to ascertain the identifier of the original message.
Default Behaviour - return the fixed string of “UNREADABLE-IN-ORIGINAL-MESSAGE”
Note: If only certain elements are missing or unreadable then the error codes associated with that key or element should be returned instead wherever possible.