FpML Issues Tracker

654: MessageRejected requires observable completion

March 17, 2008

closed

Minor

Always

Architecture

Admin

andrew

Summary

The MessageRejected process requires an observable completion to be valid with the FpML Business Process Architecture Design Assumptions.

Section 3.1.2 states: "All business process definitions must have an observable completion. The set of messages defining a business process needs to be complete. In addition, timeouts must be defined if necessary."

Today, a MessageRejected may be received at any point. I propose two techniques that could make MessageRejected observable. Either technique or both techniques may be used, or an alternative technique may be substituted.

Technique 1: Add a MessageAccepted message for each message that could have a MessageRejected. This is effectively adding in a lower level protocol, exactly as FIX and SWIFT do. Receipt of either MessageAccepted or MessageRejected would constitute observable completion.

Technique 2: Add a timeout to responding with a MessageRejected. For example if the timeout is 1 hour, and the transport characteristics as per the FpML Bulk Transport Mode, then we would add the Messaging Sending Window duration to the Bounded Communication Delay duration, double it for the return trip and add that to the timeout. So ((30s + 15m) x 2) + 1h = 1h31m. If a MessageRejected was not received in this period then you would have observable completion.

IMHO - it is simpler to sort out the distinction between the messaging layer and the business layer, like SWIFT and FpML, and use a MessageRejected (Technique 1). OMGEO CTM uses a Message "Valid" for the same purpose.

Notes:

  • andrew

    03/17/08 12:43 pm

    The current confusion arises because the current processes were designed using guaranteed delivery over a message queuing transport as an assumption. As such they mix request/response messages with the occaisional notification.

    I suggest in future all processes should (in general) be designed using one style or the other (although this potentially creates problems for processes like confirmation in which there is a asynchronous notification in the reverse direction at a later stage) and that the message framework be adjusted to differentiate between responses and exceptions (of which MessageRejected is one).

    Some of the business process will need additional response messages where currently the the request is not acknowledged directly. More analysis is needed to see of a generic MessageAccepted is applicable or whether a business process specific response should be added (e.g. to pass back business data).

    I think its dangerous to pre-judge the correct solution before this analysis has been completed.

  • matthewdr

    04/14/08 10:01 am

    There was extensive discussion of this issue at the AWG meeting of Thursday 10th April 2008.

    The typical scenario this is designed to avoid is the scenario where a MessageRejected is sent a long time (days or months), after a message was sent. To give the sender of a message certainty there needs to be an observable completion to prevent the sender of a Message having to wait a long time to guarantee eh won’t receive a MessageRejected. At the moment there is the risk that at any time in the future a message may be rejected.

    The consensus of the meeting was that in addition to MessageRejected there were other observable completions of sending a message. The total possible set of options to a message were agreed as:
    1. MessageRejected (explicit completion)
    2. MessageAccepted (explicity completion)
    3. A subsequent business message in the business process (implicit completion)
    4. Timeout, such as P1D (implicit completion)

    Any subset of those 4 techniques may be defined as being used for each business process. Which techniques are available are defined in the business process.

  • matthewdr

    04/14/08 10:05 am

    We need proposals to vote upon. Based on the discussion at the meeting I propose:

    1. Message Accepted is a possible response everywhere Message Rejected is a possible response.
    2. An FpML-wide default timeout on sending a Message Rejected of P1D. This may be overridden in a business process definition.
    3. Any subsequent business message within the same business process that refers to a message is treated as implicitly accepting it.

  • mgratacos

    11/12/19 7:30 am

    AWG Meeting 2019-11-07

    • Participants agreed that this was solved in version 5.
    • We don’t have implementations questioning this nor a more complete example of a scenario where the current message set fails.
    • Agreement to close the issue and reopen if more concrete example is provided using version 5.
  • Leave an update

    You must be logged in to post an update.