Apama 10.3 | Apama Capital Markets Foundation Documentation | Capital Markets Foundation | Order Management | Risk firewall | Implementing custom risk firewall rule classes | How a risk firewall queries rule classes
 
How a risk firewall queries rule classes
The following background information may be helpful for implementing custom rule classes. Keep in mind that for a risk firewall to approve an order, that order must comply with at least one instance of each rule class that is registered with that risk firewall. If a custom rule class does not require instances to be added, then approval of an order requires that the order comply with the custom rule class itself.
When a risk firewall receives an order it creates a com.apama.firewall.QueryRequest object, which contains a request Id, a request type (new, amend, or cancel), and a com.apama.oms.OrderState object. The risk firewall sends the query request to rule classes and their instances and receives a com.apama.firewall.QueryResponse object back.
The risk firewall first sends the query to the registered rule classes according to any priority ordering that has been set. If more than one rule class has the same priority, the query goes to those rule classes in the order in which they were registered. If no priority ordering has been set, then the query goes to the registered rule classes in the order in which they were registered. The risk firewall queries the rule class implementation before querying any rule class instances. This allows validation against any global, state information, and it can also allow your custom rule implementation to iterate over its own instances.
If the rule class query is successful then the risk firewall begins to query each instance of each rule class.
By default, if a rule class instance returns a failure in the query response object, then no further query requests are sent to the other instances for that rule class, or any other rule classes that have not been queried. As the mechanism is asynchronous, there may be outstanding queries being calculated. These will be ignored when they return. On a failed query response, the associated OMS event is rejected.
This early termination mechanism is configurable, so that it can be disabled if responses from all registered rule classes are required. However, this has a performance impact as the response is pended until all registered rule classes and their instances have been queried.
An application can set one or more callbacks with the risk firewall by using the RiskFirewall.addQueryResponseCallback() action to monitor query requests. A query response callback provides a com.apama.firewall.CombinedQueryResponse object that contains the set of query responses from all of the queried rule classes. This might be a subset of those registered depending on the query and the failure mode in operation. In a query response callback, the application cannot override the response that has been returned from the risk firewall. The application can, for example, use the information provided in the query response to determine whether the failure is critical enough to prevent further orders from being processed by the risk firewall, or to simply monitor orders being processed (such as an auditing system).
The risk firewall uses a configurable timeout, set by the CONFIG_TIMEOUT_DURATION configuration parameter, on all the query requests. This ensures that the state of an order is not blocked by unresponsive rule classes. If the timeout period is reached (the default setting is 5 seconds), the default behavior is that the order will be rejected as a result of the request timing out.
On receipt of the query response objects, the risk firewall determines whether the query result was pass or fail, and takes the appropriate action. For a failed query result, the appropriate action is determined by the rejection mode that the risk firewall is using. See Configuring risk firewall behavior for rejected orders.

Copyright © 2013-2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.