Apama 10.3 | Apama Capital Markets Foundation Documentation | Capital Markets Foundation | Order Management | Risk firewall | Implementing custom risk firewall rule classes | Introduction to custom rule class implementation
 
Introduction to custom rule class implementation
A com.apama.firewall.RuleClass object defines the following default actions. As with default rule classes, the risk firewall calls these actions on your custom rule class as needed.
*addRuleInstance() — Adds an instance of your custom rule class.
*modifyRuleInstance() — Modifies an instance of your custom rule class.
*removeRuleInstance() — Removes an instance of your custom rule class.
*evaluateRuleClassQuery() — Queries the global state of your custom rule class.
*evaluateRuleInstanceQuery() — Queries each added instance of your custom rule class.
*processRuleClassUpdate - Processes an order update against the global state of the rule class.
*processRuleInstanceUpdate() — Processes an order update once for each added instance of your custom rule class.
*getRuleInstanceState() — Obtains information/state for an instance of your custom rule class.
*getRuleClassState() — Obtains information/state for your custom rule class.
*getRuleClassName() — Obtains the name of your custom rule class.
*getRuleClassDescription() — Obtains the description of your custom rule class.
*getSchema() — Obtains the configuration schema for your custom rule class.
At a minimum, a custom rule class must override either
evaluateRuleClassQuery()
or
evaluateRuleInstanceQuery() and addRuleInstance()
If you override only evaluateRuleClassQuery() then you can use your rule class to check all OMS events that are passed into the risk firewall. This can be useful if you want to sanity check (global state check) every order for some specific criteria. However, you will not be able to add any rule class instances. If you choose to implement all of the actions then your rule class can perform a sanity check on every order and also evaluate every order against any rule class instances that have been added.
The addRuleInstance(), modifyRuleInstance() and removeRuleInstance() actions each provide two callbacks. One callback indicates to the risk firewall that the operation was successful. The other callback indicates an error. This lets you implement these operations in an asynchronous way. After your custom rule class has completed the operation, it must execute one of the callbacks.
If there is an error while adding, modifying, or removing a custom rule class instance, your implementation should create a com.apama.utils.Error object that contains useful, human-readable, details about the error. This error object provides an errorType parameter, which is always one of
*FAILED_TO_ADD_RULE_INSTANCE
*FAILED_TO_MODIFY_RULE_INSTANCE
*FAILED_TO_REMOVE_RULE_INSTANCE
These constants are defined in com.apama.firewall.ErrorConstants. If an error callback has been set on the risk firewall then the error type lets the caller programmatically identify the cause of the error. However, if your custom rule class implementation provides another value for errorType, it is stored in the Error object's parameters as ERROR_SUBTYPE.
The risk firewall RuleClass interface stores instance configurations internally. However, if your custom rule class maintains any internal (or live) state information then your custom rule class must also cache and (if necessary) persist this state information. An application's custom rule class implementation can use the CMF Configuration Service to persist/recover any internal state information. See Configuration Service.
The risk firewall uses the CMFs Configuration Store to store custom rule class instance configurations. This enables queries by other parts of the application from any context. Also, DataViews are automatically published for risk firewall RuleClass instance tables. You can use these DataViews to publish risk firewall RuleClass information and instances to a user interface.
When the risk firewall needs to evaluate a query against a custom rule class implementation, it will first attempt to call the evaluateRuleClassQuery() action. If the query passed against this action, the success callback action allows the application to specify whether the evaluateRuleInstanceQuery() action will be called for each individual custom rule class instance.
If required, the evaluateRuleInstanceQuery() action will be called for each custom rule class instance that was added, and will provide both the instance Id and the configuration that was defined for this instance, as well as the QueryRequest object. As the configuration parameters for the RuleClass instances are stored internally to the risk firewall, this means that your RuleClass implementation does not have to cache information about its instances unless it needs to (either because of efficiency or any other reason).
Execution of evaluateRuleClassQuery() or evaluateRuleInstanceQuery() results in approval or rejection of an order. Execution of ProcessRuleClassUpdate() and ProcessRuleInstanceUpdate() cannot reject the order update.

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.