If upgrading from or have had exposure to some very early versions, here are some of the highlights that were introduced in version 5.
The following are a list of major new features since version 4.0
The user interface has been given a complete makeover to improve usability.
Before a configuration is deployed to the server it is now checked for file reference integrity to avoid deployment mistakes.
Entire repositories can now be packaged up for distribution between consoles and can be progressively backed up.
Targeted logs can now be added that will continue to monitor a user, IP Address, Device ID or some other provided identifier and log test data whenever that identifier is present. This data can be used for forensic analysis or to monitor specific data points (such as which browser type users are using).
Flight recorder data can be easily graphed and visualized.
A very flexible case manager that integrates fully with the Flight Recorder technology has been added. It provides customizable workflow and event management abilities.
The ability to trace up to 20 transactions through the rules engine has been added. This allows for a precise text view of how a rule set executes with any given transaction.
Rules are now available to help protect against XSS, CSRF, XPATH, IFRAME and SQL Injection attacks.
A license key is now supplied for each installation to determine the licensor and the features licensed.
A new rules class loader has been introduced to load classes from the product home folder instead of the application path. This includes all third party JAR files so that conflict resolution between application level JAR files and rules JAR files are no longer required.
The basic application level rules engine (JAR) now loads a minimum of classes to allow as many features as possible to be delivered via extensions. Extensions can now be changed/added without the requirement of the web application being restarted, even after code has already been loaded.
The connection between the console and the rules engine can now be encrypted for better security.
Logged events are now more consistently time stamped and include a severity determination to help with diagnostics.
The version control utility now covers all elements of repositories (including data) for consistency.
Please see the rules reference for a complete listing of rules and the version in which they have been added. More than 30 new rules have been added since version 4.0.
The console and demo server are now able to obtain a list of updates that can be downloaded and applied on demand. Updates include sample applications, extensions and sample repositories. What can be download will depend on the license held.
In previous versions of the rules engine it was possible to have a very high performance rule set with substantial console output create a race condition where the administration console output would be challenged to keep up with the flood of data. As of version 5, this condition results in the console dropping packets instead of trying to obtain a perfect list. This helps maintain the high performance and memory consumption of the rules engine.
It is now possible to nominate rule sets that will only be executed once on either startup or shutdown. This allows rules to sign in to a service, add timing code, perform cleanup and perform other tasks that may be needed to encapsulate the main rule set.
The rules engine now features global variables that can be used to communicate information between separate transactions (for example credentials and timing information).
The rules engine can now be configured to a specific event count to determine if the engine is looping. This allows the ability to ensure that very large XML files with substantial processing can be executed without a potential loop being detected.
Rule sets can now be set to be executed at a regular interval. This allows for background services to be created.
This feature allows for the creation of content (html, xml, images) directly within the console and for this content to be served up directly from within the rules engine. The content is an effective overlay of the web server content the rules engine is protecting.
The console now allows for the direct editing of HTML documents being served up by the content delivery mechanism. Further editors for other content is planned.
Content delivered by the rules engine can now be managed with dedicated rule sets without the need for file readers and dedicated HTTP responses.
The rules engine will make dynamic performance optimization decisions based on the content of the variables being used and the scope within which they are being used. This optimization can result in substantial performance gains, especially with larger variables (such as entire HTML pages).
In addition to the support in previous versions for simply banning variable names from ever being entered into the rules engine, it is now also possible to allow banned variables to appear as MD5 hashes or PCI compliant masked credit card numbers (First 6 and last 4 digits visible).
It is now possible to set variables internally as objects from within rules. This can be done both locally and globally. Objects that are set this way must be read as objects as well, also from within rules. If they are read using the normal access rules (such as Get Variable) a string representation (toString) will be returned. It is the responsibility of the programmer writing custom rules to exploit these features and to ensure the stored Objects can be released from memory and that they clear up any resources used. For more information, see the VariableAttributeObject and RulesEngine JavaDoc.
The console now contains status messages, such as when the rules engine was loaded, started, stopped and unloaded. This is especially useful to understand at what point the startup and shutdown rule sets are invoked.
It is now much easier to control and manipulate the content of HTTP requests going to the actual application (including overriding user supplied parameters) and equally it has been made much easier to modify the application response before it is returned to the end user.
The following is a list of new environments supported since version 4.0.
A new Linux based appliance provides easy support for all non-Java environments.
Array parameters provided in web requests are now correctly available to the rules engine.
The popular Struts framework has the ability to create variable names that essentially look like function calls and have previously been hard to access as the rules engine would interpret them as strings.
Test data can now be downloaded in XLS format, can be modified and uploaded as an XLS file, which in turn will be automatically converted to a .TST file (the new extension for test data files).
Large server clusters (anything from 10+ servers running the same rule set) can now be managed by a cluster of OctopusV8 consoles. Rule sets from a single master console can be automatically propagated to any number of slave consoles for further propagation to target servers. Each slave cluster can have their rules engines started and stopped as a single unit.
For rules engines and consoles that must access the internet via an internal web proxy, NTLM authentication (for Microsoft ISA servers) has been added. Additionally, rules that previously exposed the proxy settings for an external web request, now obtain their proxy information from the server settings instead.
Keyed arrays can now be created and used within a rule set. Arrays are stored as JSON objects and can be manipulated with general purpose rules. Rules for conversion between arrays and CSV formats have been added and keyed arrays are now used for HTTP header manipulation.