Clarification on the usage of BusinessMessageReject (35=j) to reject Admin message ( e.g Resend Request)

Imported from previous forum

Hi All,

Is it a recommended practice to use the BusinessRejectMessage (35=j) to reject a client’s Resend Request (35=5) when the application is busy to process the resend request (possibly with a reason ‘Application Busy’)?

As per FIX definition for BusinessRejectMessage, its stated that 35=j can be used to reject Application level messages but doesnt explicitly mention the applicability on Admin messages.

“The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means.”

Thanks,
Hiran

Hi Hiran,

the ResendReject is a session level message, i.e. it is NOT an application level message. BusinessRejectMessage does not explicitly mention the applicability on Admin [session level] messages because it is NOT applicable.

If the ResendRequest cannot be honored, e.g. is ill-formed in terms of the syntax then the session level Reject message is the correct response.

You say “when the application is busy to process the resend request”. This should never be the case as the session layer is responsible to process such requests. The application layer only takes care of application resend requests as part of Application Sequencing, a concept introduced with FIX 5.0.

Regards,
Hanno.

PS: Reposted due to wrong user used.

On a side note it is interesting to note that there is no session level reject in FIXP

Aditya, with respect to your side note, the FIXP spec deals explicitly with this case.

For a RetransmitRequest that the requester should have known was invalid with certainty, the sender should terminate the session. Terminate message with ReRequestInProgress code should be sent if it sees a premature retransmit request.

Yes agreed, I meant that there is no FIXP equivalent of 35=3 in FIXT.

FIXP should not be seen or analyzed as a high speed version of FIXT. It is the third standard session layer within the FIX Family of Standards with a focus on high performance. The previous (and still active) session layers focus more on convenience and are hence more “verbose”. A comparison between FIX4 (session layer for FIX 4.x versions) and FIXT is thus more appropriate. FIXT is different from FIX4 in that it introduced transport independence.