In this chapter we will demonstrate an example of using Visual Lambda in QWFIX system.
In QWFIX system, the FIX session can take a list of Visual lambda module as session filters for incoming FIX messages. A session filter takes a "FIXMessage" as input parameter. The session filter has no return type. Session fileters can not modify the incoming either. The only session filters can do is to reject the incoming message by raising an exception. If a FIX message is rejected, a "Rejct" message will be sent to other party. The application that implements the high level business logics will not see the rejected FIX message.
QWFIX system provides several pre-defined Visual Lambda signatures. User can choose a pre-defined signature when creating a module, in the module dialog as shown below. Once a module chooses a pre-defined signature, user can not modify the signature in the Visual Lambda editor.
For more information about signatures, see "Type, Module and Signature".
Suppose we have a FIX session working as a sell side to take equity orders. The business rules require that only market orders will be accepted.
The clients of this session have been informed of that rule. And the business logics have been implemented in high level application code under the assumption that only market orders will be transmitted to that session.
However, we are not living in a perfect world. And we can't really guarantee that our clients won't make mistakes. What if a limit order is sent by our clients by mistake? Because our own code has already made assumption that only market orders will be received, if we accidentally received a limit order, will it break our application?
In order to make sure application won't receive an order with invalid order type, a session message filter can be define to reject invalid messages in session level, so that application code won't have a chance to see problemtic messages.
In the following example we will demonstrate how to create a message filter described above.
Note: In this example, we perform two checks. First we check if the message type is "NewOrderSingle". Secondly we check if the "OrdType" field is "Limit". If both conditions check, we will raise an exception to tell the engine reject the order.
1. Create a new Visual Lambda Module
We name the module "Session_RejectLimitOrderMessage". Please make sure signature "FIXSession_MessageFilter" is used in new module dialog (First check "From signature").
Right click the root node to add the action of the module. We can specify a simple "Case" action for this module.
"Case" expression takes two operands, "Condition" and "Action". Note the operands can only be added in order. We have to add the "Condition" before we specify "Action".
Because we need to check both the "MsgType" and "OrdType", we add a Boolean "And" expression as the condition.
"And" expression can take two or more operands, named "Oprand 0", "Oprand 1" and so on and so forth.
Note the operands can only be added in order. We need to add "Oprand 0" first.
The first operand of "And" expression is a Boolean to check if the "MsgType" equals to "NewOrderSingle". So we add a "== Equal [String]" expression to perform equality check on two strings.
Now we add the left operand of "==" expression as a "FIX Message Operations" to get "MsgType" of the message.
"get_MsgType" takes one operand, which is a message. We add the input parameter "message" to it. (The screen shot is not shown).
Now we can specify the second operand ("Oprand 1") of "== Equal [String]", which should be a constant string value of the the MsgType of "NewOrderSingle". Instead of using directly using the constant, QWFIX offers an alternative to use a name. Just choose "[FIX] MessageTypes".
A dialog will pop up. Choose "NewOrderSingle [D]" from "FIX44" schema. Then click "OK".
Now we can use a more user friendly name "FIXMessageType(FIX44.NewOrderSingle)" to represent the constant value of "D".
Now we can add a second operand to the "And" expression. It should be a Boolean expression to compare the "OrdType" field of the message. Note in FIX schema, "OrdType" field has a type of "char". So we need to choose "== Equal [char]" from the pop up menu.
The left side of the comparison should be the content of the field in the message. We can use "GetCharValue" expression from "FIX Message Operations" to get it.
"GetCharValue" takes 3 operands, "message", "tag" and "defaultValue". Note because the FIX message may not contain the field specified by "tag", a default value must be supplied as the return value in such case.
Again, we can use a name instead of constant value to represent "tag", as shown below. We choose "FieldTags" when adding the value for "tag", which is of "int" type.
Specify the tag name of "OrdType" from "FIX44". Note user can search the names from the text boxes in the dialog. Then click "OK". Now we can use "FIX44.OrdType" to represent the constant value of "40".
After finished the left side operand of the comparison, we need to specify the right side (Oprand 1).
Again we can use the names to represent the field valid value in FIX schemas, as shown below.
Pickup the value of FIX44 -> OrdType -> Limit.
The condition is completed. Now we can specify the "Action". Choose "FIXSessionRejectException" as shown below.
Below is a screen shot of the finished module.
