| Oracle® Fusion Applications Developer's Guide 11g Release 1 (11.1.3) Part Number E15524-03 |
|
|
View PDF |
| Oracle® Fusion Applications Developer's Guide 11g Release 1 (11.1.3) Part Number E15524-03 |
|
|
View PDF |
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 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.
Implementors 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. See Section 22.2, "Participant Roles" for the definition of the implementor role.
There are three types of flexfields, all of which enable implementors to configure application features without programming, and these configurations are fully supported within Oracle Fusion Applications:
Descriptive: Descriptive flexfields give customers the ability to extend the data model with additional attributes. A descriptive flexfield provides a set amount 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. For more information, see Section 22.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 into contexts so they will always be presented together in the application user interface.
Hierarchical categories enable you to reuse contexts for similar entities.
Extensible flexfields support one-to-many relationships between the entity and the extended attribute rows.
For more information, see Section 22.1.2, "Extensible Flexfields."
Key: Key flexfields enable customers to use their own coding scheme or naming scheme customers to identify their business entities by giving implementors the ability to configure 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 22.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 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.
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 implementors 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 implementor can define a Dimensions context, which might consist of segments that represent height, width and depth. The implementor can also define a Measurements context, which 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 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 don't necessarily need to have anything to do with each other and do not need to be 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 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, 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 implementors to extend the flexfield at your discretion, 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.
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 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 for can be defined for extensible flexfields, and implementors 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 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 sub-account, and valid values are defined for each segment, as well as cross validation rules to describe valid segment combinations. However, companies might structure their general ledger account fields differently. By including the Accounting Flexfield, Oracle 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 an Oracle Fusion application. The flexfield validates each segment 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 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 business components are 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 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 implementor configures the flexfields.
For more information, see Section 23.12, "Preparing Descriptive Flexfield Business Components for Oracle Business Intelligence" and Section 25.4.3, "How to Prepare Key Flexfield Business Components for Oracle Business Intelligence".
Responsibility for flexfield development activities is allocated 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 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 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.
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 (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. 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 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.
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 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.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
