Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The Rules Processing System API consists of a set of hierarchical classes defined in the TSENTRY tpriNtRt C/C++ library.  See the tpriRps library documentation for more details about these classes.

Rules Manager Process

Expand
titleOverview

In general, a rules manager process runs periodically (i.e. every 5 seconds) in the background on the host control system.  It is responsible for the following tasks:

  • Monitor rules configuration files for changes to any rule definitions.

  • Monitor each rule to determine if it is time to evaluate the criteria and, if the criteria are satisfied, perform the specified output actions.

  • Write operating data to the rules configuration file so that processing of rules can continue seamlessly across any system restarts.

  • Perform diagnostic tests for debugging rules on a development system.

  • Log all activity to the NtRtMgr console.

A manager process is not provided with TSENTRY.  Custom implementations of a rules processing system can either use the default tpriRpsProcessor class to create a rules processor object or they can extend the tpriRpsProcessor class to customize the rules processor object.  All that is required then within the manager process is to create and initialize the tpriRpsProcessor or tpriRpsProcessor‑derived object and then periodically call the ProcessRules() member function to perform rules processing.

Expand
titleConfiguration

A rules manager process is configured by a single file containing the list of rules defined in the system.  This single file contains all information about all defined rules and is fully maintained by the process itself.  That is, the manager process periodically re-writes this file with the latest configuration and status information as the rules are processed; for instance, every time a rule is evaluated the NextEvalTime parameter for that rule must be updated, since the next time that the rule should be evaluated has changed.  Because this file contains all of the latest configuration information, when the rules system is stopped and restarted it can easily restore itself to the exact configuration it was in before shutdown.

Requests for various operations on the system, such as to activate or deactivate a rule, are sequenced into the manager using command files.  A command file directory is specified during rules processor initialization, and this directory is periodically monitored for any files with specific file extensions.  The defined extensions are:

File Extension

Description

.rpsAdd

Add a new rule to the system.

.rpsDel

Remove an existing rule from the system.

.rpsVerify

Verify an existing rule.

This directory is typically exposed via a network share so that Rules Processing System HMI screens can write command files to this directory.  Both the share permissions and the underlying NTFS file permissions for this directory must allow read and write access to the local tpriHmi user on the host system for access by the user interface.

In addition, the rules processing system periodically copies the current configuration file to this command file directory so that it can be shared with the HMI.  The HMI therefore periodically checks this directory for updated configuration files so that it can update its display of the current rules status.

Rules Processing System User Interface

Expand
titleOverview

In general, the user interface for a rules processing system is responsible for the following tasks:

Provide graphical user interface to allow users to create new rules, modify existing rules, and activate and deactivate rules on the host.

Provide feedback to the user about the current status of rules running on the host.

A complete user interface is not provided with TSENTRY; however, TSENTRY does provide an HMI object, TPRI.RpsEditor, that can be used to build a customized HMI for a Rules Processing System.