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.1 KiB
layout, title, nav_order, parent, grand_parent
| layout | title | nav_order | parent | grand_parent |
|---|---|---|---|---|
| default | Creating Case Entry With Defer Activation Rule | 10 | Case Management | Configuration |
🚀Speed up implementation with hands-on, face-to-face training from the developer.
Creating Case Entry With Defer Activation Rule
When a case is created as a consequence of an Activation Rule match it would be placed into the case workflow, and assuming it is not already open pending closure, in will be in an open status. In the event that the case record is already in existence, and not in closed status, a case record will not be created.
Cases can be newly created either as an Open status, or a Suspend Bypass status.
The Suspend Bypass status is used to create a case which is not intended to receive attention and only exists to ensure that no other case can be created for a case key and case key in the cases workflow. An example of where a Suspend Bypass might be useful is in an audit use case, where a sample of a very large population is adequate, as it may not be necessary to review each customer or client. By using a Suspend Bypass status, on case creation, a random sample of case creation can be allocated to Open, with the remainder being allocated to Suspend Bypass. The Suspend Bypass will denote that the case has been sampled out and disallow any other case being created until a closed status is set for that case record.
Suspend Bypass status is subject to the diary automation functionality, and in concert with a diary date, will automatically lapse, moving from a Suspend Bypass Status to a Closed Status on a given date and time.
Revisit the Volume1DayUSDForIPOver100 Activation Rules and select the Activation Rule Create Case for the purposes of editing:
Scroll down to the configuration section that deals with case creation:
Locate the Bypass switch under Cases:
Toggle the Bypass switch to true to expose further options:
The case creation closed status is controlled by the Suspend Bypass sample slider which will evaluate against a random digit on case creation:
For example, suppose the suspend bypass sample is set at 50%, hence the slider set as follows:
This would have the effect of sending half of the cases to an Open status and half the cases to a Suspend Bypass status. The diary date is important so that the case management system knows when to move any Suspend Bypass status to a closed status (which will allow for the reopening of a case):
Scroll down the page and click update to create a version of the Activation Rule:
Synchronise the model via Entity >> Synchronisation and repeat the HTTP POST to endpoint https://localhost:5001/api/invoke/EntityAnalysisModel/90c425fd-101a-420b-91d1-cb7a24a969cc for response as follows, noting change of AccountId to Test2:
Repeat, changing AccountId to Test2, Test3, Test4, Test5, etc. Note the createCasePayload element in the response by way of indication of Bypass having taken place:
In the above example, there is no Bypass, henceforth the case will be in an Open status.
Given the Bypass Sampling is at 50%, it would be expected that roughly half of the newly created cases will be allocated an Open status, and half of the newly created cases will be allocated a Suspend Bypass status:
As opposed cases where filter updated to target Suspend Bypass:
Given that it is common that filters target only open cases, notwithstanding the existence of a case record (which has the effect of disallowing further creation) it is practically removed from view until such time as the case moved automatically to a Closed status.