Working with Subconfiguration in Advisor

Use subconfiguration to create a master pageset that is comprised of many separate pagesets. Subconfiguration allows for a pageset to be created once and reused in many places within the application. Using subconfiguration allows you to:

• Provide conditional messaging information

• Separate data into smaller size pagesets

• Provide users with simultaneous multiple configurations

Example of Subconfiguration in Advisor Applications

In the following example, there are three complete pagesets, including data and UI:

• Computer

  The computer pageset has selections for processor speed and hard-drive size.

• PCI-1

  The PCI-1 pageset allows the user to configure Ethernet cards.

• PCI-2

  The PCI-2 pageset allows the user to configure SCSI cards.

To link these pagesets together in a subconfigured mode, use the following procedure.

To create a subconfiguration

1. Create pagesets complete with data and UI.

2. Determine which pageset is the PARENT, for example Computer.

3. Determine which pagesets are the CHILDREN, for example PCI-1 and PCI-2.

4. Create a Feature table in the PARENT pageset, for example PCI_CARD.

5. Inside the Feature table, create a column called CHILD.

   CHILD is a reserved name.

6. In the CHILD column, enter the name of the CHILD pagesets, for example PCI-1 and PCI-2. The following table shows the complete data to enter into the Feature table.

   CODE	DESC	CHILD	DEFAULT
   0	None	null	DEFAULT
   PCI-1	Ethernet Card	PCI-1
   PCI-2	SCSI Card	PCI-2

   
   

7. In the Inputs page for the Computer pageset, create a BuildWidget UI control that calls its values from the PCI_CARD Feature table. For information on BuildWidget, see Siebel Advisor API Reference.

   When the user selects Ethernet card, the PCI-1 pageset is instantiated as the CHILD. If the user changes their mind and selects SCSI card, the PCI-2 pageset is instantiated and replaces the PCI-1 pageset Feature table values with PCI-2 values.

8. To link the pagesets, you can either:

   • Use the Subconfiguration and Optional Subconfiguration links in the BuildTarget API. For more information about using these links, see the Pageset Functions chapter in Siebel Advisor API Reference.

   • Use references to Feature tables.

About Referencing Feature Tables in Subconfigured Data Models

To reference a pageset in a subconfigured data model, you can reference the Feature table that has the CHILD column that instantiates the pageset. In the example above, you would use PCI_CARD:FEATURE_TABLE_NAME.COLUMN_NAME to reference any of the Feature tables in the PCI-1 or PCI-2 pagesets.

Example 12-1 Referencing a Pageset in a Subconfigured Data Model

This example uses a subconfigured data model where RACK is the name of the top level, SERVER1 is the next level, and SOFTWARE is the third level.

From the Rack Pageset

• To reference variables within SERVER1, use SERVER1:TABLE_NAME.COLUMN_NAME

• To reference variables within SOFTWARE, use SERVER1:SOFTWARE:TABLE_NAME.COLUMN_NAME

From the SERVER1 Pageset

• To reference variables within the RACK, use TOP:TABLE_NAME.COLUMN_NAME

  or PARENT:TABLE_NAME.COLUMN_NAME

• To reference variables within SOFTWARE, use SOFTWARE:TABLE_NAME.COLUMN_NAME

From the SOFTWARE Pageset

• To reference variable within the RACK, use TOP:TABLE_NAME.COLUMN_NAME

  or PARENT:PARENT:TABLE_NAME.COLUMN_NAME

• To reference variables within SERVER1, use TOP:SERVER1:TABLE_NAME.COLUMN_NAME

  or PARENT:TABLE_NAME.COLUMN_NAME

About Setting Defaults in Subconfigured Data Models

In a Subconfiguration data model, defaults are defined in the following places:

• An external pageset

• The DYNDEF column of a Feature table that instantiates a CHILD

• The Feature tables within Advisor

In an External Pageset

Each of the Feature tables that need to get defaulted in the Subconfiguration data model must be explicitly referenced (including the TOP items). Using the example above with RACK, SERVER1, and SOFTWARE, the syntax would be as follows:

FTN = FEATURE_TABLE_NAME
CV = CODE VALUE
TOP:FTN=CV,TOP:SERVER1:FTN=CV,TOP:SERVER1:SOFTWARE:FTN=CV

In the DYNDEF Column

You can set defaults in the DYNDEF column of a Feature table that instantiates a CHILD. See Table 12-1 for sample values.

Table 12-1 PCI_CARD

Code	Desc	Child	Dyndef	Default
0	None	null		DEFAULT
PCI1	Ethernet Card	PCI-1	SPEED=4
PCI2	SCSI Card	PCI-2	SIZE=2

DYNDEF, like CHILD, is a reserved column name for Feature tables. In this column, you can specify which defaults load into the CHILD. A CHILD pageset only gets defaulted once. The use case is when the user selects the Ethernet Card, opens the PCI-1 pageset and changes SPEED from 4 to 3. Now the user changes the PCI_CARD UI control to SCSI Card, then back to Ethernet Card. Which value should SPEED have? The engine retains the user's selection, and therefore does not default the pageset in any way.

The same pageset can get defaulted different ways depending on how you instantiate the CHILD. If the computer example had two PCI Card slots, you could use the data as shown in Table 12-2 and Table 12-3:

Table 12-2 PCI_CARD1

Code	Desc	Child	Dyndef	Default
0	None	null		DEFAULT
PCI1	Ethernet Card	PCI-1	SPEED=4
PCI2	SCSI Card	PCI-2	SIZE=2

Table 12-3 PCI_CARD2

Code	Desc	Child	Dyndef	Default
0	None	null		DEFAULT
PCI1	Ethernet Card	PCI-1	SPEED=2
PCI2	SCSI Card	PCI-2	SIZE=1

About Accessing Model Variables

Having stored your data in different places within the same user session, it is important to understand which variables are accessible at which points.

In Configuration Tables

When creating Configuration tables, you can use any Feature table within the pageset as well as any Feature tables in the CHILD and below. This is the way to enforce different rules on the same CHILD pageset depending on where it gets instantiated.

If you are using a CHILD variable as an input column in a Configuration table in the PARENT, be aware of the row matching algorithm. If the CHILD is not instantiated (which it is not upon initial load of the PARENT pageset), the value of the input column variable is null. If you do not account for this, you could have some trouble getting a valid match in your Configuration table. Using range values like (=*) or (!=3,4) matches even if the input column variable is null. If you want to make sure the CHILD is not instantiated, you could type the word ”null” into the cell of the Configuration table to try to get a match.

In OL_CONDITIONS and Cell Functions

OL_CONDITIONS and Cell Functions provide access to any variable on any pageset. Be careful with this operation, because the order of execution in Siebel Tools can have significant impact on your cell functions. As with any operation in the pagesets, make sure that the variables you are setting and the variables you are calculating are getting performed in a clear, predictable order based on the engine's order of execution. A cell function in a CHILD pageset that references an output variable in the PARENT does not work. The cell function calculates before the output variable is set, causing the application to be out of sync.

Performance Considerations for Subconfigured Data Models

When designing an Advisor subconfigured data model, use the following guidelines for optimum performance:

• To increase the speed of initial load, start the system with as few children instantiated as possible.

• To increase the speed of click to click time, limit the UI control selections to only instantiate one CHILD at a time.

Duplicate Configuration Column Names in Subconfigured Data Models

If two Configuration column names have the same name, the latter column name in the evaluation cycle overwrites the value from the first column. In case analysis, you can use this method to evaluate one subtable or another based on input values. Since only one of the tables is evaluated, each of the options should have the same outputs, and you need to duplicate column names. Only one of the columns is evaluated for any particular set of selections.