Unlocking and locking risk firewalls
A risk firewall can be locked and unlocked to ensure that it does not process orders before an application is ready. The locking mechanism can also be helpful if it is necessary to stop risk firewall operation for some reason, for example:
There have been an excessive number of rejections.
An excessive number of orders have been placed.
There is a rogue trading algorithm.
The default behavior is that a risk firewall is created in a locked state. This is because there are a number of things that must be done before the risk firewall is ready to accept orders:
Risk firewall rule classes must be registered.
Risk firewall rule class instances must be added.
A risk firewall order receiver must be created. The order receiver handles orders that have been approved by the risk firewall.
After an application determines that the tasks listed above have been done, the application can call one of the following actions to unlock the risk firewall. These actions are available on a local risk firewall but not on a remotely connected risk firewall.
RiskFirewall.unlock() does not take any arguments nor does it return anything.
RiskFirewall.unlockCb() takes a single argument, which is a callback. Upon successfully unlocking the risk firewall, this callback is executed. Call this action when your application requires notification that the risk firewall has been unlocked.
If there are any pending rule class registrations or rule class instance additions, they are completed before the risk firewall is unlocked. If the risk firewall was processing orders when it was locked and there are queued orders then they are processed in the order in which they were received.
To lock a risk firewall, call the RiskFirewall.lock() action. This circuit-breaker style lock prevents all orders from being allowed through this risk firewall. For orders that are in the risk firewall, what happens depends on the setting of the risk firewall's rejection mode. With hard rejection mode, in-process orders are rejected. With soft rejection mode, in-process orders are queued until the risk firewall is unlocked or until manual intervention by a dealer. The lock() action is available on a local risk firewall and not on a remotely connected risk firewall.
To change the default lock state upon risk firewall creation, use the CONFIG_LOCKED_ON_CREATE risk firewall configuration parameter. This constant value (defined in com.apama.firewall.Consts) defines the name of the configuration parameter that indicates whether a risk firewall is created in a locked state. The default is that a risk firewall is created in a locked state. That is, an application must explicitly unlock a risk firewall. To change the setting of this parameter, use the CONFIG_LOCKED_ON_CREATE key and set it to the boolean value you need.
To find out whether a risk firewall is in a locked state, call the RiskFirewall.isLocked() action. This action returns true if the risk firewall is locked.