richard-churchman
5f6bbe45f7
Major bug fixes relating to the Redis implementation in Reprocessing and Search Key Cache were identified and fixed as part of the rekeying development. Included functionality to stop the Exhaustive training. Fixed the Unsupervised learning functionality in Exhaustive Training. Embedded the Mock Data CSV data into a class to make it compatible with Docker without needing to modify the Dockerfile (i.e, build). Included a new table that stores training data to enhance support capabilities for Exhaustive. Reintroduced and validated the Multitenancy functionality. Postgres is now fully deprecated in place of Redis for cache, and all implementations of the Interfaces for Postgres have been removed. No migrations exist to support this deprecation, and Postgres as a cache is now wholly unsupported. Removed the Indexing background thread, as Redis does not require it, given that it is a key-value pair database. Created a RedisCommandFlag Environment Variable to support Fire and Forget write to Redis in Invocation. Implemented functionality to Export, Peek and Download configuration environments using a secure, encrypted scheme. Created a permission to access the functionality via the user interface. Extensive database-based logging is included to provide for a comprehensive audit. Created functionality to Import the encrypted Export file inside a database transaction to ensure consistency. As Docker is now the primary deployment model, log4net instantiation has been moved to an approach that primarily uses programmatic instantiation of the ConsoleLogger and RollingFileAppender given Environment Variables. Implemented functionality to support remote \ mounted Log4Net XML Serialisation files for more advanced log4net configurations. Reintroduced access to counters via the user interface and created a permission. Took the opportunity to implement ReSharper linter suggestions. Disabled the Lock button across the whole application, with that functionality being reserved for future use. It is intended that locking happens programmatically on the basis of dependencies in future commits. Fixed several significant end-use bugs which became apparent during testing of the refactored code relating to case management and visualisations. Fixed certain other minor bugs that came up during testing. Brought documentation up to date for this commit. Brought the Docker Compose file up to date for this commit. Removed Redundant Environment Variables for this commit. Made the README file less verbose and unnecessary.
4.3 KiB
layout, title, nav_order, parent, grand_parent
| layout | title | nav_order | parent | grand_parent |
|---|---|---|---|---|
| default | Gateway Rules | 7 | Models | Configuration |
🚀Speed up implementation with hands-on, face-to-face training from the developer.
Gateway Rules
Gateway Rules are pre-filtering and sampling to reduce the transaction volume eligible for the processing by more intensive functions that perhaps follow.
Transactions will only proceed to the subsequent steps in model processing in the event that Gateway Rule matches. Upon a Gateway Rule matching, it can also be tested against a random sample, as a means to reduce the volume further. The page is available by navigating through the menu as Models >> References >> Gateway Rules:
The page exists to create Gateway Rules, which are VB.net code fragments, to be compiled into the engine during synchronisation. Gateway Rules accept data objects and tests the code fragment for equality, expecting a return of True on match, or otherwise False. The Builder and Coder the following data:
| Value | Description |
|---|---|
| Payload | The fields created in the Request XPath page, Inline Functions and Inline Scripts (if allocated). |
To add a new Gateway rule, click on the Model in the tree towards the left hand side:
The parameters for the Gateway Rule are described as follows:
| Value | Description | Example |
|---|---|---|
| Gateway Sample | A percentage value, between 0% and 100%, representing the sample that should be allowed through to subsequent processing. The sample will only be taken in the event that the Rule returns as true. For example, if the Gateway Sample is set to 20%, it would imply that only 20% of the matching transactions will be passed through for subsequent processing. | 100% |
| Max Response Elevation | Upon a Gateway Rule Matching, the Maximum Response Elevation is set such to provide some risk management to the magnitude of the Response Elevation. For example, if the Response Elevation is used to instruct a bid, the open-boundedness could be cause for alarm. This value is the largest response elevation that may be responded, with any values exceeding this value being truncated to this value. Keep in mind that there are similar limits at the model level also. | 10 |
Complete the form as above parameters and with an example rule that ensures that the AmountUSD is greater than 0:
Click the Add button to create the Gateway Rule:
Synchronise the model via Entity >> Synchronisation.
Gateway Rules exist to marshal a transaction or event for subsequent processing, and only on match, to the following processing steps:
- Sanctions.
- TTL Counters.
- Abstraction Rules.
- Abstraction Deviation.
- Abstraction Calculation.
- Adaptation.
- Activation Rules.
It follows that none of the aforementioned functions will be processed except in the event of a match on the Gateway Rule. Henceforth, to validate the Gateway Rule, it is necessary to deploy one of the aforementioned functions.