This chapter includes the following sections:
In your role as a developer, it is often impossible for you to anticipate all the database columns and UI fields your customers might need, or how each field should look as end user needs change. Flexfields enable customers to configure their applications to meet their business needs without having to perform custom programming.
The basic premise of a flexfield is to encapsulate all of the pieces of information related to a specific purpose, such as the components of a student's contact information, or the features of a product in inventory, or a key identifying a particular purchase by a particular person for a particular company on a particular date. A flexfield is a set of placeholder fields, called segments, that are associated with a business object. A segment captures a single atomic value, which is represented in the application database as a single column. In the application UI, a flexfield's segments can be presented as individual table columns, as separate fields, or as a concatenated string of values.
Those performing in the role of an implementor, either on behalf of the developer organization for a developer flexfield or on behalf of a customer for a customer flexfield, configure a flexfield by specifying the prompt, length, and data type of each flexfield segment. Configuration includes the specification of valid values for each segment, and the meaning of each value. Configuration also involves defining structure and context.
There are three types of flexfields, all of which enable implementors to configure application features without programming. These configurations are fully supported within Oracle Fusion Applications:
Descriptive: A descriptive flexfield gives customers the ability to extend a data model with additional attributes. A descriptive flexfield provides a fixed number of segments for a business object, which the customer can optionally use to add custom attributes to meet their business needs, define how the attributes are validated, and configure how the attributes are displayed.
Extensible: An extensible flexfield is similar to a descriptive flexfield, but with the following additional features:.
The number of configurable segments is not fixed. That is, the number of segments is extensible.
Attributes can be grouped into a context so they will always be presented together in the application user interface.
Hierarchical categories enable implementors to reuse contexts for similar entities.
Extensible flexfields support one-to-many relationships between the entity and the extended attribute rows.
Key: A key flexfield enables customers to use their own coding scheme or naming scheme to identify their business entities by giving implementors the ability to configure the business entities to be identified using flexible, multipart, intelligent key codes. Each element (segment) of the key may be individually meaningful, as well as the combination as a whole. For example, key flexfields might represent part numbers and account numbers. Key flexfields are never optional; customers must configure them for their Oracle Fusion applications to operate correctly.
To better understand flexfields and the differences among descriptive flexfields, extensible flexfields, and key flexfields, it is important to understand flexfield structures and contexts.
Structure: A flexfield structure is a specific configuration of segments. If you add or remove segments, or, in the case of key flexfields, you rearrange the order of segments in a flexfield, you produce a different structure. In some applications, different end users need to see individually tailored segment structures for the same flexfield; for example, the correctly formatted local postal address for customer service inquiries, which would change based on the user's locale.
A flexfield can display different segments and prompts for different end users based on a data condition in the application's data, such as the user's role or a value entered by the user. All types of flexfields allow for multiple structures. All the segments that you might need to use to create all the anticipated structures must be defined as part of the flexfield.
Context: Descriptive and extensible flexfield segments are context-sensitive — they are varied or made available in your application by implementors to reflect the needs of the customer for which the application is being configured.
Segments are made available to an application as groups of attributes called contexts. Each context is defined as part of a flexfield, and includes of a set of context-sensitive segments that stores a particular type of related information. The database columns on which segments are based can be reused in as many contexts as desired. For example, an implementor can define a Dimensions context, which uses three of the flexfield's database columns of type NUMBER for the height, width, and depth segments. The implementor can also define a Measurements context, which reuses those database columns for weight, volume, and density segments.
Note:
A descriptive flexfield segment that stores data that is applicable to all entities, regardless of context, is referred to as a global segment.
The following links provide more information within this book:
For more information about the role of implementor, see Participant Roles.
For more information about developer and customer flexfields, see Descriptive Flexfields and Extensible Flexfields.
Related Links
The following documents provide additional information related to subjects discussed in this section.
For information about flexfield configuration, see the section about defining flexfields in the Implementing Common Features guide for your product family.
For information about implementing your specific product family, do the following:
Access the Oracle Fusion Applications library.
See the Implementing Common Features guides for your product family.
Descriptive flexfields provide a way for customers to add custom attributes to business objects, to define how the attributes are validated, and to define display properties for the attributes. These attributes can be standalone attributes. That is, they do not necessarily need to have anything to do with each other and do not need to be treated as a combination. The segments of a descriptive flexfield that are made available to end users are exposed in the user interface as individual fields.
Descriptive flexfields are entirely optional; customers can choose to configure and expose them or not, as they wish. For example, one customer could configure the parts flexfield to store depth, height, and width, and another customer could configure the parts flexfield to store size and color. Some customers might not need any additional attributes.
You create a descriptive flexfield for one of two purposes:
For use by customer implementors — a customer flexfield.
In this case, you define and register the descriptive flexfield in your application database, but all configuration is accomplished by the implementor, including creating contexts, creating segments, and adding validation. End users see these additional attributes in the UI and can enter values for them. End users cannot modify the configuration; they can only enter values for attributes that are already configured.
To support functionality that you build into your application — a developer flexfield.
For this purpose, you define and register the descriptive flexfield, and then preconfigure (seed) the contexts and segments, value sets, and validation to satisfy a specific purpose. The descriptive flexfield becomes part of your application, and you can code references to its seeded configuration. You might also enable implementors to extend the developer flexfield, allowing them to configure it as they would a customer flexfield.
Even if implementors never change a flexfield after it has been configured, they can take advantage of useful flexfield features such as automatic segment validation, automatic segment cross-validation, multiple segment structures, and more.
An extensible flexfield is similar to a descriptive flexfield, but with the added ability for customers to add as many context-sensitive segments to a flexfield as they need. In addition, customers can associate more than one context with any particular row of data.
Extensible flexfields also enable implementors to configure contexts as either single row or multiple row. That is, either one set of the context's segments is stored for a business object instance, or multiple sets of the context's segments are stored for the instance. For example, a job position requires only one set of educational requirements, but can require more than one certificate or license.
Extensible flexfields also enable implementors to combine the contexts into groups known as pages, which serve to connect the contexts so they will always be presented together in the application user interface. Hierarchical categories can be defined for extensible flexfields, and implementors can associate any combination of contexts with a given category. For example, the Electronics and Computers category hierarchy might include a Home Entertainment category, which in turn might include an Audio category and a TV category, and so on. The Home Entertainment category might have contexts that specify voltage, dimensions, inputs and outputs. Contexts are reusable within a given extensible flexfield. For example, the dimensions context could be assigned to any category that needs to include dimensional information.
Just as with descriptive flexfields, you create a flexfield for one of two purposes:
For use by customer implementors — a customer flexfield.
To support functionality that you build into your application — a developer flexfield.
For more information about customer and developer flexfields, see Descriptive Flexfields.
Key flexfields are configurable multipart intelligent keys, where each element (segment) of the key may be individually meaningful, as well as the combination as a whole. For example, key flexfields might represent part numbers and account numbers.
A key flexfield is implemented in the user interface as a collection of fields that can be displayed in various UI formats. Key flexfields are never optional; customers must configure them for their Oracle Fusion applications to operate correctly.
The ability to individually tailor key flexfield structures to the end user can be essential. For example, Oracle General Ledger uses a key flexfield called the Accounting Flexfield to uniquely identify a general ledger account. It maintains the multiple accounting codes used throughout Oracle Fusion Applications, and provides different Accounting Flexfield structures for users of different sets of books. Oracle General Ledger determines which flexfield structure to use based on the value of a Set of Books user profile option.
This flexfield is preconfigured to include six segments: company code, cost center, account, product, product line, and subaccount, and valid values are defined for each segment, as well as cross-validation rules to describe valid segment combinations. However, customers might structure their general ledger account fields differently. By including the Accounting Flexfield, Oracle General Ledger can accommodate the needs of different customers. One customer can configure the Accounting Flexfield structure to include 6 segments, while another customer includes 12 segments, all without programming.
An end user enters a value into a flexfield segment while using an Oracle Fusion application. The flexfield validates each segment value against a set of valid values — a value set — which is usually predefined by the implementor. To validate a segment means that the flexfield compares the value that the end user enters into the segment against the values that comprise the value set that is assigned to that segment.
Flexfield segments are usually validated, and typically each segment in a given flexfield uses a different value set. A value set can be assigned to more than one segment and value sets can be shared among different flexfields. For most value sets, when you enter values into a flexfield segment, you can enter only values that already exist in the value set assigned to that segment.
When a business component is generated for a flexfield, the value set metadata is used in the creation of the view objects. Value sets (and their view objects) are owned by a module, which can be an application, a Logical Business Area (LBA), or a sub-LBA in the application taxonomy hierarchy.
For more information about the taxonomy hierarchy, see Working with the Application Taxonomy.
Related Links
The following document provides additional information related to subjects discussed in this section:
For information about value set configuration, see the Define Flexfields section in the Implementing Common Features guide.
For information about implementing your specific product family, do the following:
Access the Oracle Fusion Applications library.
See the Implementing Common Features guides for your product family.
Oracle Business Intelligence is a comprehensive collection of enterprise business intelligence functionality that provides the full range of business intelligence capabilities including interactive dashboards, proactive intelligence and alerts, enterprise and financial reporting, real-time predictive intelligence, and more.
A flexfield can be included in Oracle Business Intelligence by business-intelligence enabling the flexfield. However, because the polymorphic view objects that are used to model flexfields are not compatible with Oracle Business Intelligence, the flexfield must be flattened into a static form that Oracle Business Intelligence can work with. You accomplish this by slightly modifying the process when you register the flexfield and incorporate it into your application.
For more information, see the following sections in this book:
Responsibility for flexfield development activities is divided between owners and implementors. These are not formal development roles; they are used only in this documentation to clarify and group the flexfield development activities.
The owner is the developer (or development team) who determines that a particular flexfield is needed or would be useful within a particular Oracle Fusion application, and makes a flexfield of the appropriate design available. The owner then incorporates the flexfield into an application. With key flexfields, the owner can be either a producer or a consumer, or can assume both roles.
Producer: The flexfield producer is the developer who determines that a particular flexfield is needed or would be useful within a particular application, and makes available a flexfield of the appropriate design. With key flexfields, the producer's product owns the combinations table for that flexfield.
Consumer: A key flexfield consumer incorporates a flexfield into an application. The consumer typically stores a segment value or combination ID (CCID) on a product database table, and works with the structural and seed data and the business components that have been configured by the flexfield producer.
An implementor is an individual who sets up all or part of a flexfield-enabled application for deployment. Implementors typically work for or on behalf of customers to install, configure, or administer their applications. In the case of developer flexfields that have been created to support functionality that has been built into the application, the developer also assumes the role of implementor.
For more information about combinations tables for flexfields, see Creating the Combinations Table.
The process of developing a flexfield and incorporating it into an application differs for each type of flexfield. In general, the process comprises the following activities:
Define and register the flexfield metadata.
Create business components for the flexfield. For key flexfields, also create business components for the key flexfield combination filters.
For descriptive and key flexfields, link the flexfield business components to the application's business components.
Incorporate the flexfield into UI pages.
Define sample flexfield data and use it to test the flexfield.
Use the Tester role of the Create Flexfield Business Components wizard to create a model that you can use to test the flexfield.
Optionally, share the flexfield business components with other developers using an Oracle Application Development Framework (Oracle ADF) library.
After you have completed the flexfield development process and delivered the application, implementors can use the Manage Flexfields task flows to configure each flexfield. These task flows determine how the flexfield's segments will be populated, organized, and made available to end users within the application.
Note:
You must use the specified tools throughout the development lifecycle to create and update the flexfield metadata and product tables. Do not use database tools unless you are instructed to do so. If you use database tools instead of the specified tools, you risk destroying data integrity and you lose the ability to audit changes to the data.
Because Oracle Fusion Applications tables are interrelated, any changes that you make using the specified tools, such as building business components or UI forms, can update many tables at once. If you do not use the specified tools, you might not update all the necessary tables. In addition, most of these tools perform validation and change tracking.
If tables are not properly synchronized, you risk unpredictable results throughout Oracle Fusion Applications products.
For more information about creating business components for key flexfield combination filters, see Working with Code-Combination Filters for Key Flexfields.
Related Links
The following document provides additional information related to subjects discussed in this section:
For information about planning and implementing flexfield configuration, such as defining structures, contexts, attributes, labels, behavior, and associated value sets, see the Define Flexfields section in the Implementing Common Features guide.
For information about implementing your specific product family, do the following:
Access the Oracle Fusion Applications library.
See the Implementing Common Features guides for your product family.
Flexfield segments can appear in a user interface as either label/widget pairs or as table fields. After an extensible flexfield is configured, it appears in the UI as one or more regions. Configured descriptive and key flexfields may appear in the UI in either a form layout, a tabular layout, or in a form or table layout in a popup component:
Form layout: A typical label/prompt and either view-only data or a widget (text field, choice list, and so on) that allows an end user to enter values.
Tabular layout: A column of information in a table, where the label of the flexfield segment is the column header, and the values are within each cell of the column.
All segments of a single flexfield are grouped together by default. The layout of the form or table and the positions of the flexfield segments depend on where you place the flexfield on the page. Flexfields may also be presented in a separate section of the page, alone in a table, or on their own page.