|Oracle® Fusion Applications Developer's Guide
11g Release 1 (11.1.2)
Part Number E15524-02
|PDF · Mobi · ePub|
This chapter discusses the basics of using flexfields to enable customers to add custom attributes to business objects in their Oracle Fusion applications.
This chapter includes the following sections:
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 development.
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 an "expandable" data field that is divided into segments. 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.
Customers 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. The concepts of structure and context are defined later in this section. For information about flexfield configuration, see the "Using Flexfields for Custom Attributes" chapter in the Oracle Fusion Applications Extensibility Guide.
There are three types of flexfields, all of which enable implementers to configure application features without programming, and these configurations are fully supported within Oracle Fusion Applications:
Descriptive — 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. Descriptive flexfields give customers the ability to extend the data model with additional attributes. A descriptive flexfield provides a set amount of segments for an entity, 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. For more information, see Section 21.1.1, "Descriptive Flexfields."
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 so they will always be presented together in the application user interface.
Hierarchical categories enable entities to inherit the segments that are configured for their parents.
Extensible flexfields support one-to-many relationships between the entity and the extended attribute rows.
For more information, see Section 21.1.2, "Extensible Flexfields."
Key — It can be difficult to anticipate what type of coding scheme or naming scheme customers might need to identify their business entities. Key flexfields give implementers and administrators the ability to configure their business entities to be identified using flexible, multi-part, "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 can be implemented to represent part numbers and account numbers. Key flexfields are never optional; customers must configure them for the product to operate correctly.
For more information, see Section 21.1.3, "Key Flexfields."
To better understand flexfields and the differences between 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 rearrange the order of segments in a flexfield, you produce a different structure. In some applications, different 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.
Your flexfield can display different segments and prompts for different end users based on a data condition in your application 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.
Contexts — Descriptive and extensible flexfield segments are context-sensitive — they are varied or made available in your application by implementers and administrators to reflect the needs of the organization 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 is comprised of a set of context-sensitive segments that store 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 implementer can define a Dimensions context which might consist of segments that represent height, width and depth. The implementer can also define a Measurements context that contains segments that reuse the same underlying height, width and depth columns, and which also includes segments for weight, volume and density.
Note:Segments that are always available, regardless of context, are often referred to as global segments.
Descriptive flexfields provide a way for customers to add custom attributes to entities, to define how the attributes are validated, and display properties for the attributes. These attributes are generally standalone; they don't necessarily have anything to do with each other and are not treated together as a combination. The segments of a descriptive flexfield that are made available to end users are exposed in the UI as individual fields.
Descriptive flexfields are entirely optional; customers can choose to configure and expose them or not, as they wish. For example, one company could configure the parts flexfield to store depth, height, and width, and another company could configure the parts flexfield to store size and color. Some companies might not need any additional attributes.
You create a descriptive flexfield for one of two purposes:
For use by customer implementers and administrators — a customer flexfield.
In this case you define and register the descriptive flexfield in your application database, but all configuration is accomplished by the application implementer or administrator, 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, then create contexts and segments, and define 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 implementers and administrators to extend the flexfield at your discretion, allowing them to configure it like a customer flexfield.
Even if administrators never change a flexfield once 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.
Another feature of extensible flexfields is that you can have more than one context associated with any particular row of data, and a row can have multiple occurrences of the same context. That is, extensible flexfields support a one-to-many relationship between the entity and its extended attribute rows.
Extensible flexfields also enable implementers 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 for can be defined for extensible flexfields, and implementers 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 product 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.
Key flexfields are configurable multi-part "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 can be implemented to represent part numbers and account numbers.
A key flexfield is implemented in the UI as a collection of fields that can be displayed in various UI formats. Key flexfields are never optional; customers must configure them for the product to operate correctly.
The ability to individually tailor key flexfield structures to the 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. General Ledger determines which flexfield structure to use based on the value of a Set of Books user profile option.
Oracle has configured this flexfield to include six segments: company code, cost center, account, product, product line, and sub-account. Oracle has also defined valid values for each segment, as well as cross validation rules to describe valid segment combinations. However, other companies might structure their general ledger account fields differently. By including the Accounting Flexfield, General Ledger can accommodate the needs of different organizations. One company can configure the Accounting Flexfield structure to include six segments, while another company includes twelve segments, all without programming.
An end user enters a value into a flexfield segment while using your application. The flexfield validates each segment against a set of valid values — a value set — which is usually predefined by the application implementer or administrator. To "validate a segment" means that the flexfield compares the value that the user enters into the segment against the values that comprise the value set which 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, 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.
Value set metadata is mined and used by the business component modeler to create expert mode 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 information about value set configuration, see the "Using Flexfields for Custom Attributes" chapter in the Oracle Fusion Applications Extensibility Guide. For more information about the taxonomy hierarchy, see Appendix A, "Working with the Application Taxonomy".
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.
Flexfields can be included in Oracle Business Intelligence. However, because the polymorphic view objects used to model flexfields are not compatible with Oracle Business Intelligence, the flexfields 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 flexfields and incorporate them into your application, and when the application implementer or administrator configures the flexfields.
For more information, see Section 22.12, "Preparing Descriptive Flexfield Business Components for Oracle Business Intelligence" and Section 23.4.3, "How to Prepare Key Flexfield Business Components for Oracle Business Intelligence".
Responsibility for flexfield development activities is allocated between owners and implementers. These are not formal development roles; they are used only in this documentation to clarify and group the flexfield development activities.
The flexfield 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 segment values or combination IDs (CCID) on a transaction table, and works with the structural and seed data and the business components that have been configured by the flexfield producer.
A flexfield implementer is an individual who sets up all or part of a flexfield-enabled application for deployment. Implementers 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 plays the role of implementer.
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 in a seed database.
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 your application's business components.
Incorporate the flexfield into application pages.
Define sample flexfield data and use it to test the flexfield.
Use the tester mode of the flexfield business components wizard to create a model that you can use to test the flexfield.
Optionally, share your flexfield business components with other developers using an ADF library.
Once you have completed the flexfield development process and delivered your application, implementers can use the Manage Flexfields task flows 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. For information about planning and implementing flexfield configuration, such as defining structures, contexts, attributes, labels, behavior, and associated value sets, see the "Using Flexfields for Custom Attributes" chapter in the Oracle Fusion Applications Extensibility Guide.
Note:You must use the specified tools throughout the development lifecycle to create and update the flexfield metadata and application 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.
Flexfields consist of label/widget pairs or table fields. Once configured, extensible flexfields appear in the UI as regions, and 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 widget (text field, choice list, and so on) that allows a 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 the developer places 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.