Flexfield Segment Properties
Independent of the value set assigned to a segment, segments may have properties that affect how they're displayed and how they function.
The following aspects are important in understanding
-
Display properties
-
Properties related to segment values
-
Properties related to search
-
Range validation segments
-
Rule validation of segment values
-
Naming conventions
Display Properties
The following table summarizes display properties.
Property |
Description |
---|---|
Enabled |
Whether the segment can be used. |
Sequence |
The order the segment appears in relation to the other configured segments. |
Prompt |
The string to be used for the segment's label in the user interface. |
Display type |
The type of field in which to display the segment. |
Selected and deselected values |
If the display type is check box, the actual values to save. For example, Y and N or 0 and 1. |
Display size |
The character width of the field. |
Display height |
The height of the field as measured in visible number of lines when the display type is a text area. |
Read only |
Whether the field should display as read-only, not editable text. |
Description help text |
The field-level description help text to display for the field. Use description help text to display a field-level description that expands on or clarifies the prompt provided for the field. If description help text is specified, a Help icon button is displayed next to the field in the application. The description help text is displayed when the user hovers over the Help icon button. |
Instruction help text |
The field-level instruction help text to display for the field. Use instruction help text to provide directions on using the field. If instruction help text is specified, it's appears in an in-field help note window when users move the cursor over the field. |
Properties Related to Search
Extensible flexfield segments can be marked as selectively required in search using the indexed property. The indexed property requires users to enter a value before conducting a search on the attribute represented by the indexed segment. A database administrator must create an index on the segment column representing the indexed attribute.
Range Validation of Segments
Range validation enables you to enforce an arithmetic inequality between two segments of a flexfield. For example, a product must be ordered before it can be shipped. Therefore, the order date must be on or before the ship date. Also, the order date segment value must be less than or equal to the ship date segment value. You can use range validation to ensure this relationship.
The conditions for range validation are as follows:
-
Segments must be configured for range validation in pairs, one with the low value and one with the high value.
-
Both segments must be of the same data type.
-
Both segments must be parts of the same structure in a key flexfield or parts of the same context in a descriptive flexfield or extensible flexfield.
-
The low value segment must have a sequence number that's lesser than that of the high value segment.
-
Non-range validated segments can exist between a range validated pair, but range validated pairs can't overlap or be nested.
You can configure as many range validated pairs as you want within the same flexfield. Your application automatically detects and applies range validation to the segment pairs that you define, in sequence order. It must detect a low value segment first, and the next range validated segment that it detects must be a high value segment. These two segments are assumed to be a matching pair. The low value and the high value can be equal.
Rule Validation of Segment Values
Validation rules on descriptive and extensible flexfield segments determine how an attribute is validated. The value entered for an attribute on a business object must match a specified format or be restricted to a list of values. You can use a value set or a Groovy validator to specify the validation rules.
Value set validation is required for global segments and context-sensitive segments, and optional for context segments. In the case of context segments, the application may validate a value instead of the value set validating the value against the context segment. However the application entered values must match exactly the valid context segment values. If the context segment values are a superset or subset of the input values, you must assign a table-validated value set or independent value set to validate context values.
You can also use Groovy validation to set additional restrictions or requirements for what values are allowed for certain attributes of business objects. This is useful when you need to use the same value set to validate multiple segments, but the exact validation requirement changes with each case. These validators can be defined at the global segment level, or at the context level, based on your business needs. They have a validator code, validation expression, error message, and description. After adding a new validator, click the Groovy Expression Builder icon to open the expression builder window where you define your validation expression. Groovy validation is done when a user tries to save their values to an attribute that has a Groovy validator. If the value for this attribute fails validation against the Groovy expression, the text defined in the Error Message column is displayed as an error message.
When you configure a descriptive flexfield segment, you can specify a constant to use for setting the initial value. The initial value can be an available parameter. For every planned segment, list the constant value or parameter, if any, to use for the initial value.
Naming Conventions
Enter a unique code, name, and description for the segment. These properties are for internal use and not displayed to end users. You can't change the code after the segment is created.
The Application Programming Interface (API) name is a name for the segment that isn't exposed to users. The API name is used to identify the segment in various integration points including web services, rules, and business intelligence. Use alphanumeric characters only with a leading character. For example, enter a code consisting of the characters A-Z, a-z, 0-9 with a non-numeric leading character. The use of spaces, underscores, multi-byte characters, and leading numeric characters isn't permitted. You can't change the API name after the segment has been created.