Communicating an unsolicited mass order cancellation

, ,
1

Imported from previous forum

2

Hi All
I am currently looking at the best way to communicate the following scenario:

  1. We have a matching system that runs on different servers due to load balancing. Although this is completely technical info, the clients who are connecting to us are aware of which server ID their order is sitting on via the ApplID(1180) field in the EXRs they get.

  2. In a case where trading becomes unable in one of these servers (due to some sort of a hardware/sotware crash), we expire the orders in the server (this is an automatic action). This generates an EXR for each of the orders notifying the customers about the expiration. Nothing controversial here.

  3. In some of the cases, we cannot send the EXR. This is because a process downstream of the matching system has crashed, the matching system it self has crashed or the entire server has crashed. Even in this case, the business functionality is the same, the clients should assume that their orders are now expired.

Is there anyway we can notify the clients that their orders are expired in a situation like #3? The gateways are capable of detecting that a particular server crashed/unavailable and can also generate a message by themselves to notify the clients of the failure. However I am unable to find a fitting message for this purpose. I guess I am looking for something like a “mass order cancel notification” or a “system status notification”.

3

I would suggest TradingSessionStatus (35=h). Otherwise there are OrderMassCancelReport (35=r), OrderMassActionReport (35=BZ) and News (35=B). But these last ones are not fully satisfactory…

Hi All
I am currently looking at the best way to communicate the following scenario:

  1. We have a matching system that runs on different servers due to load balancing. Although this is completely technical info, the clients who are connecting to us are aware of which server ID their order is sitting on via the ApplID(1180) field in the EXRs they get.

  2. In a case where trading becomes unable in one of these servers (due to some sort of a hardware/sotware crash), we expire the orders in the server (this is an automatic action). This generates an EXR for each of the orders notifying the customers about the expiration. Nothing controversial here.

  3. In some of the cases, we cannot send the EXR. This is because a process downstream of the matching system has crashed, the matching system it self has crashed or the entire server has crashed. Even in this case, the business functionality is the same, the clients should assume that their orders are now expired.

Is there anyway we can notify the clients that their orders are expired in a situation like #3? The gateways are capable of detecting that a particular server crashed/unavailable and can also generate a message by themselves to notify the clients of the failure. However I am unable to find a fitting message for this purpose. I guess I am looking for something like a “mass order cancel notification” or a “system status notification”.

4

Hi Xavier
Thank you for bringing TradingSessionStatus (h) to notice. My original take was to choose between OrderMassCancelReprot(r) or OrderMassActionReport(BZ),but TradingSesionStatus(h) also seems to communicate the fact that the application is unavailable.

Will bounce the idea off my colleagues and will keep the thread open just in case.

I would suggest TradingSessionStatus (35=h). Otherwise there are OrderMassCancelReport (35=r), OrderMassActionReport (35=BZ) and News (35=B). But these last ones are not fully satisfactory…

Hi All
I am currently looking at the best way to communicate the following scenario:

  1. We have a matching system that runs on different servers due to load balancing. Although this is completely technical info, the clients who are connecting to us are aware of which server ID their order is sitting on via the ApplID(1180) field in the EXRs they get.

  2. In a case where trading becomes unable in one of these servers (due to some sort of a hardware/sotware crash), we expire the orders in the server (this is an automatic action). This generates an EXR for each of the orders notifying the customers about the expiration. Nothing controversial here.

  3. In some of the cases, we cannot send the EXR. This is because a process downstream of the matching system has crashed, the matching system it self has crashed or the entire server has crashed. Even in this case, the business functionality is the same, the clients should assume that their orders are now expired.

Is there anyway we can notify the clients that their orders are expired in a situation like #3? The gateways are capable of detecting that a particular server crashed/unavailable and can also generate a message by themselves to notify the clients of the failure. However I am unable to find a fitting message for this purpose. I guess I am looking for something like a “mass order cancel notification” or a “system status notification”.

5

I would concur with Xavier that TradingSessionStatus is a good approach but I wanted to add one more specific option. OrderMassActionReport would require you to have a functional filter (e.g. all orders for product XYZ). You only have a technical filter, i.e. a server/partition that went down which you represent with ApplID. TradingSessionStatus has the ApplicationSequenceControl block which carries the ApplID. You would need to combine it with a specific TradSesEvent (1368) value to distinguish it from normal application level status messages that can be recovered through ApplicationMessageRequest. In your case it sounds as if ApplID will have to restart sequencing after the failure. The alternative to TradingSessionStatus is to use ApplicationMessageReport with ApplReportType (1426) = 0 (Reset) with ApplNewSeqNum (1399) set to 1. Your rules of engagement could describe that this represents a failure of the given ApplID and all orders previously handled by it have now implicitly been cancelled.
Regards,
Hanno.

Hi Xavier
Thank you for bringing TradingSessionStatus (h) to notice. My original take was to choose between OrderMassCancelReprot(r) or OrderMassActionReport(BZ),but TradingSesionStatus(h) also seems to communicate the fact that the application is unavailable.

Will bounce the idea off my colleagues and will keep the thread open just in case.

I would suggest TradingSessionStatus (35=h). Otherwise there are OrderMassCancelReport (35=r), OrderMassActionReport (35=BZ) and News (35=B). But these last ones are not fully satisfactory…

Hi All
I am currently looking at the best way to communicate the following scenario:

  1. We have a matching system that runs on different servers due to load balancing. Although this is completely technical info, the clients who are connecting to us are aware of which server ID their order is sitting on via the ApplID(1180) field in the EXRs they get.

  2. In a case where trading becomes unable in one of these servers (due to some sort of a hardware/sotware crash), we expire the orders in the server (this is an automatic action). This generates an EXR for each of the orders notifying the customers about the expiration. Nothing controversial here.

  3. In some of the cases, we cannot send the EXR. This is because a process downstream of the matching system has crashed, the matching system it self has crashed or the entire server has crashed. Even in this case, the business functionality is the same, the clients should assume that their orders are now expired.

Is there anyway we can notify the clients that their orders are expired in a situation like #3? The gateways are capable of detecting that a particular server crashed/unavailable and can also generate a message by themselves to notify the clients of the failure. However I am unable to find a fitting message for this purpose. I guess I am looking for something like a “mass order cancel notification” or a “system status notification”.