Extendable Lookup Advanced Topics

This section provides some addition technical information about extendable lookup attributes

Defining Additional Attributes

The product provides a few different ways to define additional values for an extendable lookup. Some of the methods are only relevant for base delivered lookup values as they may impact whether or not an implementation can update the values.

The following table highlights the options available and some summary information about what the option provides.

Option Brief Description Extendable Lookup Value Searchable by this Attribute? Base Delivered Value Modifiable?
Element mapped to BO_​DATA_​AREA The element is mapped to a CLOB field that allows for base delivered values to be modified. No Yes
Element mapped to BASE_​BO_​DATA_​AREA The element is mapped to a CLOB field that does not allow for base delivered values to be modified. No No
Flattened characteristic The element is defined using the flattened characteristic mechanism. Yes No

The following points highlight information from the table above:

  • The decision of defining an additional attribute using a CLOB mapping or a flattened characteristic will depend on whether the functionality expects that the lookup value is known when the attribute is needed (in which case a CLOB mapping is appropriate) or if the functionality expects to determine the lookup value based on the attribute (in which case, a flattened characteristic is appropriate).

  • When the base product defines an extendable lookup with additional attributes and intends to provide base extendable lookup values, it needs to determine whether or not implementations may update the additional attribute or not.

    • If no and the value is mapped to a CLOB, it will map the value to the BASE_​BO_​DATA_​AREA column. This means that implementations will receive an owner mismatch error when attempting to change the value. In addition, upgrading to a new release will replace the value with the base value.

    • If yes and the value is mapped to a CLOB, it will map the value to the BO_​DATA_​AREA column. This means that implementations will be able to change the value for a base owned record. In addition, upgrading to a new release will not make any changes to the value.

    • For values mapped to a characteristic, the product does not support an implementation changing the value of a base delivered record. If the product would like to support an implementation overriding this type of value, the business object will need to be designed with a corresponding "override" element (also a flattened characteristic), similar to how the product supplies an Override Description field to support an implementation overriding the base product delivered description for a base value. This element will not be delivered with any value and will allow an implementation to populate that value.

      Note: Note that in this situation, the product functionality that uses this value must cater for the override value.

  • All of this detail is only relevant for base provided extendable lookup values. If an implementation adds custom values for a base supplied extendable lookup, all the additional attributes may be populated as appropriate.

  • If an implementation defines a custom extendable lookup business object and wants to define an additional attribute using a CLOB, it doesn't matter which CLOB column is used. Both BO_​DATA_​AREA and BASE_​BO_​DATA_​AREA provide the same functionality for custom business objects.

Capturing a Password

If an extendable lookup includes configuration of a password for some functionality, the system supports automatic encryption of the password value if the schema maps the password to a characteristic using the characteristic type F1-PWD.