FIX engine is associated with a scheduler. The scheduler does not have to be the same as the schedulers of the sessions.
Since QWFIX 1.5.X, the concept of session end point was introduced.
In FIX engine editor, nagivate to "FIX Sessions" -> "EndPoints" tab. CLick the "Add" button as shown below.
Multiple end points can be added. Each end point can be modified later on using the GUI tool. For "Acceptor" sessions, the TCP address is usually a special address "0.0.0.0" which mean "any address". For initiator, the address should be the host name of actual IP of the acceptor.
Note: The end point has to be set up before the sessions can be added.
FIX engine can manage more than one FIX sessions. In the FIX engine editor window, navigate to "FIX Sessions" -> "Sessions" tab to activate engine session editor panel.
Click the "Add Session" button to add a FIX session to the engine.
A dialog will pop up with a list of existing FIX sessions in repository.
Choose a FIX session to add, along with a corresponding end point. Then click "OK" button. The session will be added to the engine.
In FIX engine editor, all sessions are displayed in a list view. Select a session in the list view, the detail configuration of that session will be displayed in the lower panel of the page. Any changes user made to that panel will be reflected to the selected session.
Starting from QWFIX 1.5, users are able to fine tune the performance of a FIX session by specifying the thread priorities of the encoding and decoding threads.
For example, user can give "Highest" priorities to a session if that session is used for high frequency trading where latency should be kept as low as possible.
Those two priorities are automatically set to "Normal" for pre 1.5 settings in order to keep backward compatibility.
Before QWFIX 1.5, there is no concept of session end point. The TCP settings and session direction are directly associated with the engine session settings.
The QWFIX system is always designed with backward compatibility in mind. The runtime can correctly parse the configurations of pre 1.5 versions. The end points will be automatically created and added with the name of "Initiator0", "Initiator1", ... and "Acceptor0", "Acceptor1", ..., etc. Users can modify the names of the end points later on using the Enterprise Manager GUI tool.
Custom Visual Lambda modules can be assigned to a FIX session to provide customized message handling.
Incoming Handlers
Incoming handlers can further verify the incoming FIX messages. It should raise a "FIXSessionRejectException" if the validation process fails. The message will be rejected by sending back a session level reject FIX message.
Incoming message handler should not try to modify the incoming message. Any attempt to modify the message will result in the message being rejected (because the modification attempt will trigger an exception).
Outgoing Handler
Outgoing handler should not be used for verification purpose, because the developer of QWFIX enabled application should be responsible for the validity of outgoing messages anyway.
Outgoing handler can be used to further modify the FIX message before the message is being sent out. For example, system administrator can use a outgoing handler to set some certain fields in outgoing FIX message. One example in the default repository to a module that set the "SenderSubID" of the outgoing messages.
Note: Both incoming and outgoing handlers only applies to application messages. Administrative messages such as "Heartbeat" or "ResendRequest" will not trigger the handlers.
Logon Handler
Logon handler only applies to the logon messages. It should be used for authentication purpose only. Starting from FIX 4.3, two fields, "Username" and "Password" are added to the logon FIX message. Logon handlers can be used to set or verify those parameters.