Rules Designer Setup
Rule Designer allows you to construct simple rules through an intuitive graphical interface and is available as part of Temenos Transact toolbox.
Below is the home screen for Temenos Transact toolbox.
Rules Designer GUI Elements
The Rule Designer main screen has the following tabs:
- Start Page – Gives access to the recently used rules and help contents.
- Designer – Displays the layout to design a rule.
The Rule Designer GUI consists of the following main areas:
Application Menu - Header Pane
The Header pane contains the name of the rule, a short description along with the icons to execute tasks against a rule.
Variables Pane
The Variables Pane contains various groups for writing the rule.
Script Pane
This pane allows you to define business rules. It provides syntax coloring and content assist functionality for defining a business rule.
Error and Description Pane
The error and description pane displays task specific error messages and additional information specific to business rule.
Rule Context Definition
Creating rule context is the first step when you design a business rule. Rule context are defined (one time definition) in the Temenos Transact application EB.CONTEXT. From a designer perspective, contexts are Temenos Transact applications or field names used in a rule definition.
Examples:
- A rule is defined to determine if a customer has been with a bank for longer than a specified period or was resident in a particular country, then the context will be based on Temenos Transact table CUSTOMER.
- A rule is defined to determine if an account had a balance higher than a particular amount or was a particular type of account, then the context will be based on ACCOUNT.
A context can be of the following types:
Simple Context
A simple EB.CONTEXT record holds only an ID. In the following example, the Primary Table field is linked to a context variable in Rules Designer and can access all the fields in the CUSTOMER table for evaluating rules.
Complex Context
When the details in a single table is insufficient to evaluate the rules, you need to use a complex EB.CONTEXT. The ID of any complex contexts should have a delimiter ‘*’. For example CUSTOMER*COMPLEX. There are two types of complex contexts:
Direct Complex Context
If you want to access data directly from more than one table, then you need to specify the tables that share a common ID in EB.CONTEXT. The Primary Table field should hold the table name that share a common ID and the Linked Table field should hold the context variable in Rules Designer. This way you can access the required fields in more than one table for evaluating rules.
Derived Complex Context
If the required information is not available from the specified tables, then you need to derive it. You can achieve this by using the following mechanisms:
j-descriptor
This mechanism uses the primary key of a table. You can achieve the required information by linking to other tables using their primary keys obtained from the previous record.
In the above screen capture,
- Data Label – This is a derived field used in Rules Designer for generating rules as any other field of a primary table. It holds the value of the LABEL.DESCRIPTION field in the DEPT.ACCT.OFFICER table. System then uses this value in the ACCOUNT.OFFICER field from the CUSTOMER table and reads the corresponding record in DEPT.ACCT.OFFICER to fetch the value of DELIVERY.POINT.
- SELECTION.PR – The value of this field is derived similar to j-descriptor.
Subroutine
You can retrieve complicated values using a subroutine.
The following fields are important for the Subroutine mechanism:
- DATA ROUTINE – Holds the routine.
- DATA.ARG.TAB – Holds the table name where the argument is a field.
- DATA ARGUMENT – Holds the field name of the table whose value is passed as an argument.
- MULTI.VALUE.ACT – Holds the returned argument, which is a multi-valued action.
In this topic