Siebel Interactive Designer Administration Guide > Working with Interactive Designer Configuration Tables >

The Configuration Matching Process

When users of Interactive Designer applications make a feature selection in one of the input UI controls in an application, the engine searches through the configuration data of the pageset to determine whether the feature selection represents, in combination with all the other feature selections, a valid product configuration.

The engine searches through product configuration information in the following order:

1. The engine runs through the Configuration Data area of the MAIN Configuration table, comparing user selections in the application to the feature codes defined in input columns of configuration rows.

   In all Configuration tables, the matching process evaluates DATA rows before evaluating EXCEPTION rows. The current input UI control selections are compared against valid configurations before they are compared against invalid configurations.

   Additionally, because Configuration table cells are read from left to right, when you create configuration rows you must place cells in the order in which you want them evaluated. The RULE column, for instance, should always be the last column on the right, so that all feature codes are evaluated before the exception message appears.

   The MAIN Configuration table ultimately defines all valid feature configurations. If the engine finds a matching configuration row in the DATA Row Types of the MAIN table, the configuration is valid. If not, the configuration is invalid.

   While searching Configuration Data in the MAIN Configuration table, the engine may refer to subtables that contain more configuration definitions for the pageset. In order for a configuration row in the MAIN Configuration table to be a valid match, all the subtables it points to must also contain matches.

2. If the engine finds a match from among the input columns in the MAIN Configuration table (a row in which all the input columns contain feature codes that match the feature selections in the application) it checks the rest of the configuration row for any subtable columns.

   If the engine does not find a subtable column, the configuration is considered valid and the configuration matching process ends. If the engine does find a subtable column in the row, it pauses and evaluates the configuration rows defined in the subtable that the subtable column references.

   As with feature codes, when you create configuration rows you must place subtable columns in the order, from left to right, in which you want the Configuration subtables they represent to be evaluated.

   If the Configuration subtable contains subtable columns that point to further subtables (sub-subtables), the engine pauses and evaluates the configuration rows defined in the sub-subtables. The engine then returns to the original subtable and continues evaluating from the point at which it paused.

   If the engine does not find a valid configuration that matches the current input UI control selections, then it evaluates exception data in the subtable. The engine then returns to the Configuration table from which it came and evaluates the data in that table.

3. If the engine does not find a configuration that matches the current input UI control selections in the valid configurations defined in the MAIN Configuration table, or in any of the valid or invalid configurations defined in Configuration subtables, it compares the user-selected configuration to the invalid configurations (exception data).

   When the engine reaches a matching row in the EXCEPTION Row Types, it displays the text in the associated output RULE column as an exception message in the application.

4. The engine checks to see if the pageset includes a Configuration table named OL_CONDITIONS. If not, the configuration matching process is complete. Otherwise, the engine continues on to evaluate the OL_CONDITIONS Configuration table.

   An OL_CONDITIONS Configuration table is not required in any pageset, and each pageset can contain only one OL_CONDITIONS table.

   The application engine recognizes the name OL_CONDITIONS and begins the configuration matching process in this Configuration table, if one is found. An OL_CONDITIONS Configuration table exists only to evaluate the current input UI control selections in the application against JavaScript-defined conditions.

   The OL_CONDITIONS table must contain only two columns: an input column named TEST, and a output RULE column. The cells in each row of the TEST column contain a JavaScript expression that returns true or false. The RULE column for each row contains the exception message that appears if the TEST expression returns true.

   Each row in the OL_CONDITIONS table is evaluated in order of SEQUENCE number, from smallest to greatest, against the current user-selected configuration.

   If all of the TEST expressions in the OL_CONDITIONS table return false, the engine considers the user-selected configuration valid and ends the configuration matching process. If a TEST expression returns true, the exception message defined in the associated RULE column appears in the application.

   For more information on the OL_CONDITIONS Configuration table, see Creating Javascript Conditional Statements for Interactive Designer Applications.