The following documents may also be of interest:

Rules are structured as a hierarchy of simple tables, which can cross-reference one another to implement complex rules. Within the tables, the conditions and outcomes that describe logic can be entered.

The following screenshots show two sample rules that might be applied during the checkin process at an airline's checkin counter. The first rule, named ItemCheck, determines whether an item can be checked in (the IsLegal column in the top right of the screenshot), and if so, whether any surcharge applies (the Surcharge column). The rule table looks like this:

The ItemCheck rule table is very simple: it consults the SizeLimits rule to determine if the item is too large, then returns the result. This relationship between the rules is shown in the Flow Diagram view, in the lower half of the screenshot. The ItemCheck can easily be extended to apply other checks in the same way as SizeLimits, such as weight restrictions or aircraft load factors.

The SizeLimits rule inspects the dimensions of the luggage and the class of passenger:

The SizeLimits rule table is evaluated from top to bottom, and the results (on the right) are determined by the first matching line.

By linking simple rule tables together, complex rules can be represented and managed easily.

The TPAC Rules Editor allows rule maintainers to add references to rule lines, rule tables and sets of rule tables. These can include:

Using this mechanism, the source of each rule can be made clear, and any additional notes can be added as plain text. By maintaining this coupling between rule logic and documentation, it is easy both to keep rules in sync and to verify that the rules are in sync.

The TPAC Rules Editor provides a built-in test environment, allowing users to try out rules as they are being built. The user can specify any number of test cases, each of which provides input data for the test and the expected outcomes. The rules can then be applied, and actual results are compared with expected results.

Tests can be saved as test plans, which can be used to ensure that rule changes don't unintentionally cause other rules to break.

The test plan below shows five test cases for the ItemCheck rule:

In this example, two test cases have failed, which indicates that either the rules or the test cases need some attention.

TPAC Rules is designed to allow what-if scenario modelling, so that changes to rules or reference data can be made in a non-production environment to assess the impact of those changes.

A common usage of this capability is to model changes to crew rules during enterprise bargaining, and passed to crewing optimisation software to model the impact on staff levels, pay costs and operational capacity.

The way this typically works is to clone the production repository and make changes. Applications that use TPAC Rules, such as optimisers, or equipment management systems can then be directed to use the non-production repository as their source of rules. The Revision History feature can be used at any to see what has changed since the clone from production, and the Merge feature allows the changes to be merged back into production if desired.

This modelling capability possible due to TPAC Rules repositories being entirely self-contained, which allows applications to retrieve all rule information from one central location. Any reference data that is owned by external systems but required by the rules is internalised into the rule repository.

For every change that is made to rule repositories, the TPAC Rules Repository Server stores:

This information can be queried from the TPAC Rules Editor to find the change history of any rule table, set of rule tables or the whole repository.

Multiple users can view and edit the same rule repository, then use the TPAC Rules Editor's merge facility to combine any changes.

During a merge, all changes are summarised with details of who made the change. Each change may be applied, and if any conflicts occur (such as two edits to the same cell in a rule table), the user can decide which change to apply, and what other edits may be required as a result. Any tests that may have been broken can be repaired, and the TPAC Rules editor automatically analyses the repository for any logical errors.

The TPAC Rules Repository Server can manage multiple rule repositories, and provides the facility to clone (or branch) repositories, work on them, then merge any changes back in to the parent repository.

As an example, a rule maintainer in the crewing department might create a clone of the PRODUCTION rule repository in January, in order to begin working on some crewing rule changes. During February, a rule maintainer in the Operations department might modify some equipment loading rules in the PRODUCTION repository. In March, the crewing rule changes are done. Using the TPAC Rules Editor's merge facility, the changes to the crewing rules can be incorporated into the PRODUCTION repository, and any conflicts with the changed equipment loading rules can be detected and resolved.

Although that example describes rule maintainers making changes directly to the PRODUCTION repository, it is more common to set up a STAGE or DEVELOPMENT repository to which all rule changes are made. Then, one authorised party can verify that all changes are correct before migrating the changes to the PRODUCTION repository. The TPAC Rules security model enables this practice to be enforced.

The following diagram describes the architecture of the TPAC Rules component. It shows:

Three APIs are available for application integration. This range of APIs allows the TPAC Rules rule engine to be integrated with front-end applications for local validation, server software for back-end rule application, and backend software such as optimisers.

The choice of API to use for integration with an application will largely be determined by the language in which the application is written.

Please contact Constraint Technologies for further information about the TPAC Rules Rule Engine APIs.