Previous Page TOC Index Next Page

2.12.2 Application (level 7) processing rules, deferred processing two phase reply (original acknowledgment mode only)

(This section remains in the specification only for reasons of providing backward compatibility: it is to be used only with the original acknowledgment protocol. For the original acknowledgment protocol, it creates a generic form of an asynchronous application level acknowledgment, the MCF message).

The application processing rules for deferred processing are described here. In this mode the responding system sends an acknowledgment to the initiating system that means the message has been placed in some type of secure environment (e.g., disk storage), and the receiving system commits to processing it within a reasonable amount of time, if a) the message contains the necessary information, and b) nothing causes the message’s request for action to be canceled before the responding system processes the request.

Note: Neither of these two conditions is completely checked at the time of the first acknowledgment. They are both checked at the time of processing.

The receipt of the first delayed acknowledgment by the initiating system means that the responding system has taken responsibility for the subsequent processing of the message. This also implies that the initiating system no longer needs to keep the particular message in its current form to send out later. For example, if the sending system were maintaining a queue of outgoing messages, the particular message could be deleted from the output queue at this point.

The receipt of the second delayed acknowledgment message informs the initiating application of either: a) the application’s successful processing of the initial message, or b) an error that prevented its processing. If the receiving application needs to return detailed change of status information, an application-specific message will be used. An example of the latter is the General Order message (ORM) described in Chapter 4.

The general delayed acknowledgment protocol is implemented on a site-specific and application-specific basis as needed. At a particular site, for a given transaction type the choices are:

a) do not allow deferred acknowledgements

b) all messages will have a deferred acknowledgment

c) only exceptional cases (errors) will receive the deferred acknowledgment

In overview the processing for options b) and c) proceeds as follows:

Initiator receives message from sending application and sends it to the responding system.

The responding system receives the message from the initiating system and

a) partially validates it syntactically and against the detailed rules described in Section 2.12.1, "Original and enhanced processing rules". This validation need not be complete but should be sufficient to determine the application that will ultimately respond to the message. If this validation fails, a reject message is constructed by the protocol software and returned to the initiator.

b) (if the message passes this validation) stores it and constructs a response message that simply acknowledges receipt. MSA-5-delayed acknowledgment type then has a value of D.

c) subsequently passes the message to the application, which:

1) creates a response message, or

2) creates an error message, or

3) creates a reject message

d) The protocol software sends the response, error, or reject message to the initiating system as an unsolicited update with no value present in MSA-5-delayed acknowledgment type.

The protocol software of the initiating system responds to the response, error, or reject message with simple acknowledgment and passes it to the initiating application.

The details follow.

2.12.2.1 Initiation

The rules for creating the initial message are exactly as defined in Section 2.12.1, "Original and enhanced processing rules," for the original acknowledgment rules.

2.12.2.2 Response

The processing in the responding system follows this pattern:

a) the protocol software accepts the message and validates it against at least the following criteria:

1) the value in MSH-9-message type is one that is acceptable to the receiver

2) the value in MSH-12-version ID is acceptable to the receiver

3) the value in MSH-11-processing ID is appropriate for the application process handling the message

If any of these edits fail, the protocol software rejects the message. That is, it creates an ACK message with AR in MSA-1-acknowledgment code.

b) If the message passes the edits, the protocol software stores it and a generates a response message of type ACK with a value of AA in MSA-1-acknowledgment code and D in MSA-5-delayed acknowledgment type.

c) Subsequently the protocol software passes the message to the application, which performs one of these functions:

1) processes the message successfully, generating the functional response message (message type MCF) with a value of AA in MSA-1-acknowledgment code.

- OR -

2) creates an error response, providing error information in functional segments to be included in the response message, which has a value of AE in MSA-1-acknowledgment code.

- OR -

3) fails to process (rejects) the message for reasons unrelated to its content or format (system down, internal error, etc.) For most such problems it is likely that the responding system will be able to accept the same message at a later time. The implementors must decide on an application-specific basis whether the message should be automatically sent again. The MSA segment of the response message contains a value of AR in MSA-1-acknowledgment code.

d) the application passes the message to the protocol software, which constructs a message of type MCF with F in MSA-5-delayed acknowledgment type.

e) the protocol software passes the message to the initiating system as an unsolicited update

f) the protocol software in the initiating system passes the response message to the initiating application and generates a simple ACK message. No value is present in MSA-5-delayed acknowledgment type.

All other values are put in the MSA segment as described in Section 2.12.1, "Original and enhanced processing rules."

Previous Page TOC Index Next Page