In QWFIX_J Order Manager, an order is represented by a FIXOrder object.
A FIXOrder is an abstract class. It has three derived classes, FIXRegularOrder, FIXCrossOrder or FIXListOrder.
FIXRegularOrder is the most commonly used, it represents either a single order or a multileg order ("New Order Single" or "New Order Multileg").
FIXCrossOrder represents a cross order. FIXListOrder represents a list order.
The type of the order can also be retrieved from FIXOrder.getFIXOrderType() property.
Creating and Sending Messages
A FIXRegularOrder is created when a "New Order Single" or "New Order Multileg" message is accepted. Alternatively, if GT order (gool till cancel or good till expire) is supported, a FIXRegularOrder may be created by accepting an execution report with "Restated" status.
Once a buy side creates a FIX message representing an order, it can send the order by calling FIXSessionOrderManager.addNewRegularOrder().
Once a FIXRegularOrder is sent or accepted, order modification messages ("Cancel Request" or "Replace Request") may be added by buy side application. (see createOrderCancelRequest(), createOrderReplaceRequest(), addOrderCancelRequest(), addOrderReplaceRequest()).
The sell side application can create and add execution reports to an order. (see FIXRegularOrder.addExecution()).
Event Model
QWFIX_J defines several listeners for FIXSessionOrderManager, FIXSessionOrderManagerBuySideListener, FIXSessionOrderManagerSellSideListener, FIXSessionOrderManagerCommonListener, FIXSessionOrderManagerExecutionListener, FIXSessionOrderManagerSimplifiedListener, and FIXSessionOrderManagerSessionRejectListener. As the names suggest, application can implement and register the listeners to get event notification.
For example, for sell side application, once a new order message is received, necessary checks will be made to the order message. If there is any potential problem with the order, for example, the "ClOrdID" is duplicated, the order will be automatically rejected. If the order is automatically rejected, the application code won't see the order at all.
User defined Visual Lambda rules are also applied during the check. If the Visual Lambda throws an "FIXOrderManagerOrderRejectException", the order will also be automatically rejected without the application code seeing the order.
If the order is not automatically rejected, a FIXSessionOrderManagerSellSideListener.newOrderReceived event is triggered. Note at this time, the order is still not accepted. Application still have chance to reject the order by throwing out a FIXOrderManagerOrderRejectException exception in the event handler.
If the order is still not rejected in FIXSessionOrderManagerSellSideListener.newOrderReceived event handler, the order will be accepted by the sell side. The sell side will create an order based on the order message. Then a FIXSessionOrderManagerCommonListener.orderAdded event will be triggered.
The same logic applies to the order cancel request and order replace request handling on both buy side and sell side. Please refer to the class reference for more details.
Handlers
Handler and listener are both defined as interfaces. The difference between a handler and a listener is that application can have multiple listeners but only one handler is allowed. Listeners can be "added" or "removed". But handler can only be "set". Setting a new handler will automatically remove the old handler.
QWFIX_J order manager defines several handlers. FIXSessionOrderManagerGTOrderHandler is used to identify GT orders. FIXOrderManagerAutoRejectHandler is used to generate automatically execution reject or cancel reject messages (application may need to implement its own handler for special OrderID or ExecID encodings).
The cross order will be automatically populated into two FIXRegularOrder instances. The list order will be populated into a list of FIXRegularOrder instances. Refer to the class reference documentation for more details.