| Oracle® Fusion Applications Developer's Guide 11g Release 7 (11.1.7) Part Number E15524-08 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Developer's Guide 11g Release 7 (11.1.7) Part Number E15524-08 |
|
|
PDF · Mobi · ePub |
This chapter discusses how to use extensible flexfields to enable customers to add additional attributes to application business objects in Oracle Fusion Applications.
This chapter includes the following sections:
Section 23.2, "Overview of Integrating Extensible Flexfields in an Application"
Section 23.4, "Registering Extension Tables as Secured Objects"
Section 23.5, "Defining and Registering Extensible Flexfields"
Section 23.6, "Defining and Registering Extensible Flexfield Business Components"
Section 23.7, "Employing an Extensible Flexfield on a User Interface Page"
Section 23.8, "Incorporating Extensible Flexfields into a Search Form"
Section 23.10, "Customizing the Extensible Flexfield Modelers"
Section 23.12, "Making Extensible Flexfields Available to Web Services"
Section 23.13, "Accessing Information About Extensible Flexfield Business Components"
An extensible flexfield is similar to a descriptive flexfield in that it provides a customizable expansion space that implementors, such as Oracle Fusion Applications customers, can use to configure additional attributes (segments) without additional programming. As with descriptive flexfields, each segment is represented in the database as a single column. However, with extensible flexfields, the context values and context-sensitive segments are stored in an extension table.
Implementors can combine and arrange the segments into attribute groups that are tailored to a customer's specific needs. For example, they can group related segments so that they appear together on the page. An attribute group is referred to as a context. You can optionally set up an extensible flexfield to enable implementors to group contexts into categories.
To understand how implementors use contexts and categories to configure extensible flexfields to meet a customer's specific needs, see the "Flexfields Overview" section in the Oracle Fusion Applications Common Implementation Guide.
To learn more about flexfield basics and terms, including developer and implementor roles, segments, and contexts, see Chapter 21, "Getting Started with Flexfields." For more details about the differences between descriptive flexfields and extensible flexfields, see Section 23.1.2, "The Benefits of Extensible Flexfields."
Extensible flexfields include the following key artifacts:
Contexts (attribute groups)
Context-sensitive segments
Logical pages
Categories
Category hierarchies
Usages
An extensible flexfield context is a data grouping mechanism that implementors can use to arrange segments into meaningful groups. Each context is a group of attributes that is displayed in its own subregion of the user interface (UI) page at runtime. Implementors create and configure the contexts. After creating a context, an implementor must associate the context with the categories for which that group of attributes is relevant. For example, a Parts flexfield might have a Fax category and an All-in-One Printers category. A Fax context would be associated with both categories, while a Copy context would be relevant only to the All-in-One Printers category. You can learn about categories in Section 23.1.1.4, "About Categories."
Figure 23-1 shows the UI page for the Positions business object. The Positions flexfield is embedded in the Additional Position Details region on the page. This region contains the Educational Requirements, Certification and License Requirements, and Travel contexts for the Positions flexfield.
Figure 23-2 and Figure 23-3 show UI pages for the Parts business object. The developer has enabled multiple categories for the Parts flexfield, so the page displays the category to which the part shown belongs. In Figure 23-2, the part belongs to the All-in-One Printers category, and in Figure 23-2, the part belongs to the Fax category. In these pages, the Parts flexfield is embedded in the Additional Information region. For the All-in-One Printers category in Figure 23-2, the Additional Information region contains the Copy, Fax, and Scan contexts for the Parts flexfield, while on the Parts page for the Fax category in Figure 23-3, the region contains just the Fax context.
Note:
A flexfield region is empty until the implementor configures the extensible flexfield that is embedded in it.
Extensible flexfields allow implementors to configure contexts as either single row or multiple row. That is, either one set of segments is stored for a business object instance, or multiple sets of 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.
For single-row contexts, the segments appear as fields in a form. With multiple-row contexts, the segments appear as columns in a table, thus allowing end users to capture a list. In Figure 23-1, Educational Requirements and Travel are single-row contexts, so end users can specify only a single value for each context-sensitive segment, such as the percent of travel time required for the position. The Certification and License Requirements context is a multiple-row context, so end users can enter multiple rows, one for each certificate or license required for the position.
With extensible flexfields, every segment is a member of a context (attribute group). That is, every segments is a context-sensitive segment. Implementors define the contexts and their context-sensitive segments. Context-sensitive segments are the lowest-level data points that implementors can define for an extensible flexfield, and each segment is mapped to a column in an extension table. Just as with descriptive flexfields, the segments are rendered as ADF Faces rich client components, such as text box, text area, list of values (LOV) choice list, date picker, checkbox, and radio button group.
In Figure 23-1, the Educational Requirements context contains the High School, Bachelor, Master, J.D., M.D., and Ph.D. context-sensitive segments, and the Certification and License Requirements context contains the Type and Certificate/License context-sensitive segments.
Extensible flexfields enable implementors to define logical pages with which to group contexts for display purposes. Each page can contain one or more contexts along with their respective context-sensitive segments. There is no limit to the number of contexts on a logical page. The implementors associate the logical pages with categories on a flexfield usage basis. For information about usages, see Section 23.1.1.6, "About Usages (Data Levels)."
In the Parts UI page shown in Figure 23-2, an implementor has defined two logical pages for this category — Printers and All-in-One. The implementor defined the Printers logical page to contain all contexts related to the printing capabilities of the printer, and the All-in-One page to contain all contexts related to the other capabilities of the printer, such as the scanning, copying, and faxing capabilities
The Parts page that is shown in Figure 23-2 displays the list of logical pages for the category in the left-hand pane. End users view a logical page in the right-hand pane by selecting it from the list. In this figure, the end user has chosen to view the All-in-One logical page. The Printers logical page is shown in Figure 23-4.
Logical pages have several layout options. For example, in Figure 23-1, the developers chose to hide the entire left-hand section because their customers will add attributes to a single page that is known at the time of development. However, in Figure 23-4, developers chose to display the list of logical pages in the left-hand pane. For more information about layout options, see Section 23.7, "Employing an Extensible Flexfield on a User Interface Page."
Categories enable applications to dynamically display different sets of logical pages and contexts at runtime. In the simplest case, you create a single category for a flexfield, and the same extensible flexfield contexts and logical pages appear for every instance of the business object. In some cases, you might need the application to display different sets of logical pages and contexts depending on a runtime discriminator, such as an instance value. In these cases, you can create multiple categories for the flexfield, or you can provide application-specific logic that enables implementors to define their own categories.
The Positions flexfield in Figure 23-1 has a single category. The same flexfield segments appear in the Additional Position Details region regardless of which position is displayed. In this page, the developer has hidden the name of the category, because there is only one category.
In Figure 23-2 and Figure 23-3, the segments that the region displays depend on which category the part belongs to. In Figure 23-2, the part belongs to the All-in-One Printers category and the UI displays fields related to copying, faxing, and scanning. In Figure 23-3, the part belongs to the Fax category and the UI displays fields related to only faxing.
You can choose to support multiple categories for your flexfield. When you do so, the extensible flexfield respects any hierarchical relationship that is defined for the categories, whether created by developers or defined by implementors. Figure 23-5 shows an example of categories that are defined in a hierarchical fashion. In this example, the root category (the category that does not have parent categories) is Computers and Office. One of its child categories is Printers and Ink. The Printers and Ink category, in turn, has a Printers child category. The Printers category has two child categories — All-in-One Printers and Single Function Printers.
Each child category inherits the contexts and pages from its parent categories. For example, the Printers category contains the Print, Printer Functions, and Supported Operating Systems contexts. The All-in-One Printers category inherits these contexts from the Printers category. It also inherits all logical pages that are defined for its parent categories. Additional contexts can be assigned directly to the All-in-One-Printers category, such as Copy and Scan, which are relevant only to All-in-One printers.
When you create an extensible flexfield, you create one flexfield usage for each set of tables in the application that uses the flexfield. In the simplest case, you will have one flexfield usage. For example, in Figure 23-1, the Positions application requires a single Positions table with its associated extension tables to store the extensible flexfield values. Implementors simply associate their contexts with that one usage to make them available to the Positions application.
When you have several objects in the application that should be extended using the same extensible flexfield, you must create multiple usages for the flexfield. For example, in the case of an Items application, there might be different data levels, such as items and item revisions. In this case, you create one usage per data level. By defining separate usages for each set of tables, you enable your implementors to reuse the same extensible flexfield configuration for all data levels.
When deciding whether to use a descriptive flexfield or an extensible flexfield to extend a business object, consider the following features that you make available for implementors by using extensible flexfields:
Custom grouping: Extensible flexfields enable implementors to group segments into contexts (attribute groups), and each context is displayed in its own region on a page.
Multiple logical pages: When an implementor defines a large number of custom attributes, the implementor can choose to create several logical pages with which to display the attribute groupings. For example, Figure 23-2 and Figure 23-4 show different logical pages for the same part. In addition, the implementors can reuse these pages with different categories.
Hierarchical categories: Extensible flexfields can be configured to enable categories, which can be used to dynamically display different sets of logical pages and contexts based upon a runtime discriminator. The categories can be structured in a hierarchical manner and the children categories inherit all the contexts and logical pages that are configured for their parent categories.
Reusable attribute groups: When you enable multiple categories for an extensible flexfield, implementors can associate contexts with more than one category. When business object instances share common attributes, the implementors can put the common attributes in one context and reuse that context in all applicable categories, thus minimizing setup time. For example, in Figure 23-2 and Figure 23-3, the Fax context is associated with both the Fax category and the All-in-One Printers category.
Unlimited expansion space: While the number of segments that an implementor can define for a context is limited to the number of underlying flexfield extension columns, there is no limit to the number of contexts that an implementor can create for an extensible flexfield. Implementors can use the extension columns over and over in newly created contexts resulting in an unlimited number of custom attributes.
Custom lists: When implementors need to add custom lists to their business objects, they can create multiple-row contexts, which display the context's segments in a table, as shown in the Certification and License Requirements region in Figure 23-1.
Locale-specific values: You can optionally enable implementors to store different attribute values on a locale-by-locale basis. For example, an implementor could store and maintain the description of a part in English, Chinese, and French. The application displays and stores the value for the end user's locale.
For more information, see the "Translating Flexfield and Value Set Configurations" section in the Oracle Fusion Applications Extensibility Guide for Developers.
Access control. Implementors can define who can view and edit the attributes in a context.
Another advantage of using extensible flexfields is that you can create your own custom modeler classes for adding application-specific logic for generating ADF Business Components and UI task flows, as described in Section 23.10, "Customizing the Extensible Flexfield Modelers."
Unlike descriptive flexfields, which are mapped to extension columns in a product table, extensible flexfields are mapped to extension columns in extension tables that are separate from the product table. You create the extension tables at design time.
How Extensible Flexfields Are Modeled in Oracle Application Development Framework
Extensible flexfields are modeled as a collection of Oracle Application Development Framework (ADF) polymorphic view rows, as described in the "Working with Polymorphic View Rows" section in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
The category hierarchy translates into a hierarchy of view objects that are configured to support polymorphic view rows. The view objects have view links to associated context view objects. A CategoryCode attribute acts as the discriminator that determines which category view row type is used. At application runtime, the category in the base category view object row determines what pages and contexts are displayed. Given a collection of polymorphic view rows, each row can be a different type depending upon the category. An application module that holds the category view object is generated for each category.
Note:
Because flexfield view objects are modeled as polymorphic view objects, you can use extensible flexfield view objects in the same manner that you use any other polymorphic view objects, and they will behave in the same way.
The process of developing an extensible flexfield and integrating it in an application comprises several different activities, such as creating the extension tables, creating business components, and adding the flexfield to the appropriate application pages. This section identifies the major tasks for incorporating an extensible flexfield and points to the sections that provide the details for completing the tasks.
Before you begin:
Before you begin developing an extensible flexfield, you must first complete the following tasks:
Identify the business object and related product table for which you are implementing the extensible flexfield. For example, you might want to enable implementors to create custom attributes for the Parts business object, which corresponds to the FND_CRM_PARTS table.
Decide if you want customers to be able to store translated values for one or more segments. For example, for a Parts flexfield, customers might want to store translations for the attributes in the Catalog Information context so they can print the catalog in different languages.
Decide if you want to enable customers to store the information for a context at different levels (also referred to as flexfield usages). For example, implementors might choose to set up a context for a Parts flexfield that has both a part supplier level and a part level. The same context segments appear in both the supplier UI and the part UI, but the end user would enter different values. Take, for example, a lead-time segment. At the part level, the end user would supply the average lead time. At the supplier level, the end user would enter the actual lead time required for that supplier.
Decide if you need more than one set of artifacts generated for a flexfield usage. For example, you might need both private user interfaces that are based on updatable (entity-based) view objects and public user interfaces that are based on read-only view objects. When you have more than one set of artifacts, you will need to define multiple groups at the entity-usage level for the flexfield usage, such as a Private group and a Public group, when you register the flexfield's business components.
Determine whether you need to customize the generated model to add additional product-specific logic or customize the generated user interface, or both.
To complete the development tasks for an extensible flexfield:
Create a base extension table for each flexfield usage. If you want to enable customers to store translations on a locale-by-locale basis, create a translation extension table and a view of the translation extension table for each usage as well.
See Section 23.3, "Creating Extensible Flexfield Data Tables."
Register the extension tables as secured objects to enable implementors to specify view and edit privileges for each context's attributes.
See Section 23.4, "Registering Extension Tables as Secured Objects."
Create the flexfield metadata. In this step, you use PL/SQL procedures to register the flexfield and its usages, create a default context data element, and register the flexfield data columns and root category.
See Section 23.5, "Defining and Registering Extensible Flexfields."
Create and configure business components to support the extensible flexfield. In this step, you create an entity object and a view object from the base extension table, and, if they exist, the translation extension table and view. You then create the base category view object from the product table entity object (the table for which the flexfield is an extension). If you want to enable search capabilities, you create and register a declarative SQL-based view object for searching over the product table that the flexfield extends. Last, you register the flexfield's entity objects and view objects, and you run the Create Flexfield Business Components wizard.
See Section 23.6, "Defining and Registering Extensible Flexfield Business Components."
Add the extensible flexfield to the appropriate UI pages.
See Section 23.7, "Employing an Extensible Flexfield on a User Interface Page."
Load any necessary application seed data, such as error messages and lookup values.
Optionally, customize the generated model or the generated UI artifacts, or both.
See Section 23.10, "Customizing the Extensible Flexfield Modelers" and Section 23.10.2, "How to Customize the Runtime User Interface Modeler for Extensible Flexfields."
Test the flexfield.
After you have completed the extensible flexfield development process and delivered your application, implementors can use the Manage Extensible Flexfields task flow to define contexts, categories, and pages, and to configure the segments for each extensible 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 attributes, labels, behavior, and associated value sets, see the "Flexfields Overview" section in the Oracle Fusion Applications Common Implementation Guide.
Note:
An extensible flexfield is not displayed at runtime unless at least one context and context-sensitive segment has been configured and associated with a category.
To make the Manage Extensible Flexfields task flow available to application implementors, register it with Oracle Fusion Functional Setup Manager. For more information, see Section 26.8, "Integrating Flexfield Task Flows into Oracle Fusion Functional Setup Manager."
Before you can define an extensible flexfield, you must create one set of dedicated database tables for each of the flexfield's usages. Each set must be composed of at least a base extension table. If you want to enable customers to store translated values for the segments, the set must include a translation extension table and a view of the translation extension table.
At runtime, as end users enter attribute values for each context, the context and its segment (attribute) values are stored as a row in the base extension table if the context is not translatable, or, if the context is translatable, as rows in the translation extension table (one row per installed language). The translation extension view returns the rows in the current user locale. When an implementor creates a translatable context, the implementor can add only VARCHAR2 segments to the context.
An extensible flexfield must have at least one set of tables, which defines the primary usage. The implementors will expose only the extension columns that they require.
You must use the Database Schema Deployment Framework tools to create the tables and columns. Using these tools ensures that the table and its columns are registered in the Oracle Fusion Middleware Extensions for Applications (Applications Core) data dictionary. For more information, see Chapter 57, "Using the Database Schema Deployment Framework."
Note:
The steps in this section assume that the product table that the flexfield is extending already exists.
Each flexfield usage requires a base extension table. This table stores nontranslatable contexts and their segment values. The table name should have a suffix of _B to identify it as the base extension table. The name should have the _B suffix regardless of whether the extensible flexfield has a translation table.
Table 23-1 lists the columns that you must include in a base extension table. You can include additional columns, such as columns that are required by product teams or application standards. For space considerations, the table shows only the first and last attribute columns for each type.
Add as many attribute columns as you consider necessary. The attribute columns can be of type VARCHAR2, NUMBER, and TIMESTAMP. Do not set scale or precision for the NUMBER columns. There are no size requirements for the VARCHAR2 columns. To avoid compatibility and interoperability problems, name the columns ATTRIBUTE_type-and-number, such as ATTRIBUTE_CHAR1 for a VARCHAR2 column, ATTRIBUTE_NUMBER1 for a NUMBER column, and ATTRIBUTE_TIMESTAMP1 for a TIMESTAMP column.
For columns of type NUMBER, you can optionally add a column named ATTRIBUTE_NUMBERn_UOM to store the unit of measure.
The primary key of the base extension table must include the EFF_LINE_ID column, the CONTEXT_CODE column, the CATEGORY_CODE column, and the columns that match the primary key columns of the product table.
Table 23-1 Extensible Flexfield Base Extension Table (_B) Specification
| Column | Type | Nullable? |
|---|---|---|
|
EFF_LINE_ID |
|
No |
|
Primary key columns of the product table for which this extensible flexfield is being defined. |
Same as the column in the application. |
No |
|
CONTEXT_CODE |
|
No |
|
CATEGORY_CODE |
|
No |
|
CREATED_BY |
|
No |
|
CREATION_DATE |
|
No |
|
LAST_UPDATED_BY |
|
No |
|
LAST_UPDATE_DATE |
|
No |
|
LAST_UPDATE_LOGIN |
|
Yes |
|
ATTRIBUTE_CHAR1 |
|
Yes |
|
... |
||
|
ATTRIBUTE_CHAR40 |
|
Yes |
|
ATTRIBUTE_NUMBER1 |
|
Yes |
|
ATTRIBUTE_NUMBER1_UOM |
|
Yes |
|
.... |
||
|
ATTRIBUTE_NUMBER20 |
|
Yes |
|
ATTRIBUTE_NUMBER20_UOM |
|
Yes |
|
ATTRIBUTE_TIMESTAMP1 |
|
Yes |
|
... |
|
Yes |
|
ATTRIBUTE_TIMESTAMP10 |
|
Yes |
If you plan to allow customers to store translations for some contexts on a locale-by-locale basis, then you must also create a translation extension table and a single table translation view from that table. The translation extension table and the translation extension view are not required. However, if you do not provide these tables, the customers cannot store translations for their extensible flexfields as described in the "Translating Flexfield and Value Set Configurations" section in the Oracle Fusion Applications Extensibility Guide for Developers. For more information about multilanguage tables, see Section 9.2, "Using Multi-Language Support Features." For information about creating the view, see Section 23.3.3, "How to Create a Translation Extension View."
Note that unlike typical translation tables, the base extension table is completely separate from the translation extension table. All the segment values for a context go in either the base extension table or in the translation extension table. If a context is marked as translatable, all segment values are stored in the translation extension table. If a context is not marked as translatable all segment values are stored in the base extension table. This means that a translatable context cannot contain segments of non-translatable data types, such as numbers or dates.
Table 23-2 lists the required translation extension table columns. The required columns are similar to those in the base extension table, except that the attribute columns must be of type VARCHAR2 and you must include the LANGUAGE and SOURCE_LANG columns. For space considerations, the table shows only the first and last attribute columns. You can include additional columns, such as columns that are required by product teams or application standards.
The translation table name should have a suffix of _TL to identify it as a translation table.
The primary key of the translation extension table must include the EFF_LINE_ID column, the CONTEXT_CODE column, the CATEGORY_CODE column, the LANGUAGE column, and the columns that match the primary key columns of the product table.
Developers typically create the same number of VARCHAR2 type attribute columns in the translation extension table as exist in the base extension table, but you are not required to do so. Create as many VARCHAR2 type attribute columns as you think are necessary for a translatable context. To avoid compatibility and interoperability problems, name the columns ATTRIBUTE_CHARnumber, such as ATTRIBUTE_CHAR1, ATTRIBUTE_CHAR2, and so on. When setting the size of the VARCHAR2 columns in an extension translation table, consider that the columns might need to contain multibyte characters.
Table 23-2 Extensible Flexfield Translation Extension Table (_TL) Specification
| Column | Type | Nullable? |
|---|---|---|
|
EFF_LINE_ID |
|
No |
|
Primary key columns of the product table for which this extensible flexfield is being defined. |
Same as the column in the application. |
No |
|
CONTEXT_CODE |
|
No |
|
CATEGORY_CODE |
|
No |
|
CREATED_BY |
|
No |
|
CREATION_DATE |
|
No |
|
LAST_UPDATED_BY |
|
No |
|
LAST_UPDATE_DATE |
|
No |
|
LAST_UPDATE_LOGIN |
|
Yes |
|
SOURCE_LANG |
|
No |
|
LANGUAGE |
|
No |
|
ATTRIBUTE_CHAR1 |
|
Yes |
|
... |
|
Yes |
|
ATTRIBUTE_CHAR40 |
|
Yes |
Note:
To avoid compatibility and interoperability problems, format the column names as indicated.
If you create a translation extension table, you must also create a view from the translation extension table. To create the view, use a view definition statement that follows the format shown in Example 23-1. The name of the translation extension view should have a suffix of _VL.
Example 23-1 Format for Translation Extension View Definition
select ROWID ROW_ID, column list from translation extension table where LANGUAGE = userenv('LANG');
Example 23-2 shows a sample view definition.
You must register an extensible flexfield's extension tables as database resources to enable implementors to specify and manage access privileges for context attributes.
You can optionally preconfigure database resource actions and conditions (instance sets) that might be useful for the customers.
Note:
When an implementor uses Oracle Authorization Policy Manager to define security policies for an extensible flexfield, the implementor must manage the privileges for both the base extension table and the view of the translation extension table. If your application has a separate user interface for managing privileges, this user interface must manage the base extension tables and the views of the translation extension tables for all usages as separate secured objects.
You must register an extensible flexfield's base extension table as a secured object by creating a database resource for the table. If you create a translation extension table and view for an extensible flexfield, then you must register the view as a database resource as well. Use the Manage Database Security Policies task, which is accessed from the Setup and Maintenance work area of any Oracle Fusion Setup application, to create the database resources.
You can optionally create actions and conditions for the database resource. The preconfigured actions appear in the View Privileges and Edit Privileges dropdown lists for a context's usages in the Manage Extensible Flexfields task. Customers use these actions to restrict view and edit privileges.
To create a database resource:
In the Setup and Maintenance work area of any Oracle Fusion Setup application, go to the Manage Database Security Policies task.
From the Search Results region, select Actions > Create.
Create the database resource as described in the "Managing Oracle Fusion Applications Data Security Policies" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
WARNING:
When creating a database resource for the base extension table, then you must use the name of the table for the name of the database resource, such as ITEM_EFF_B. When creating a database resource for the view of the translation extension table, then you must use the name of the view for the name of the database resource, such as ITEM_EFF_VL. Otherwise, if an implementor creates actions for that database resource and sets the privileges for an extensible flexfield's context to those actions, the end users who have those privileges will get an oracle.jbo.JboException, such as Object is not registered with Data Security, when they access a page that contains the extensible flexfield context.
Ensure that the EFF_LINE_ID column is included in the primary key.
Optionally, create actions and conditions for the database resource.
After you create a set of dedicated tables for a flexfield's usage, use procedures from the FND_FLEX_DF_SETUP_APIS PL/SQL package to register the flexfield usage and define its metadata in seed tables.
You can learn about the FND_FLEX_DF_SETUP_APIS PL/SQL package by running the following command, which stores package documentation and usage examples in the <db_name>_<user_name>_FND_FLEX_DF_SETUP_APIS_<date>.plsqldoc file.
sqlplus <fusion_user>/<fusion_pwd>@<fusion_db> \ @/ORACLE/fusionapps/atgpf/applcore/db/sql/flex/fnd_flex_pkg_doc.sql \ FND_FLEX_DF_SETUP_APIS
The definition of an extensible flexfield usage includes the following information:
The logical name of the flexfield.
The name of the base extension table that contains the columns to be used as flexfield segments.
The names of the columns in the base extension table that are to be used as flexfield segments.
The identity of the flexfield context segment that will indicate how context-sensitive segments are used in each data row.
If the flexfield has a custom modeler, the name of the custom modeler in fnd_df_flexfields_b.ADFBC_MODELER. For information about custom modelers, see Section 23.10.1, "How to Customize the Runtime Business Component Modeler for Extensible Flexfields."
Flexfield usage information, including Oracle Metadata Services (MDS) root packages for usages — the name of the root package for all business components that model the flexfield. Each usage must have its own package name.
After the implementors configure the flexfield, the definition of an extensible flexfield also contains the following information:
A complete list of the ContextCode values that can appear in the flexfield context segment.
Information about the segments that are associated with the ContextCode values. Each ContextCode value is associated with its own set of these segments.
A complete list of the CategoryCode values that belong to the extensible flexfield, and the contexts that are associated with each category, page, and usage.
Validation rules that are associated with the segments. Each segment can have its own LOV or validation rules.
Use the FND_FLEX_DF_SETUP_APIS PL/SQL API package to register new extensible flexfield usages and to add the specified flexfield metadata to the following global configuration metadata:
FND_DF_FLEXFIELDS_B, FND_DF_FLEXFIELDS_TL
Add the extensible flexfield's code name to both tables.
FND_DF_FLEX_USAGES_B, FND_DF_FLEX_USAGES_TL
Add the extensible flexfield usages.
FND_DF_FLEX_USAGES_TL
Add the display names for the flexfield usages.
FND_DF_TABLE_USAGES
For each usage, add the product table name for which the flexfield is implemented and set the table type to BASE. Also, add the usage's base extension table name with a type of EXTENSION, and add the usage translation extension table name with a type of EXTENSION_TL. Set the table usage code to the flexfield's usage code.
If a consumer (of a flexfield) wants to support interface loading of extensible flexfield data, add entries for the BASE_INTERFACE, EXTENSION_INTERFACE, and EXTENSION_INTERFACE_TL table types.
FND_DF_SEGMENTS_B
Add one row for the extensible flexfield with CONTEXT_CODE set to "Context Data Element" and SEGMENT_CODE set to "Context Segment."
FND_FF_COLUMN_USAGES
For each usage, add an entry for each context-specific column in the EXTENSION and EXTENSION_TL tables. For example, add entries for all the ATTRIBUTE_CHARn columns, for all the ATTRIBUTE_NUMBERn columns, and so on.
FND_EF_CATEGORIES_B
An extensible flexfield requires at least one entry in this table. Add additional entries only if you are shipping your application with some categories already defined.
Note:
The CATEGORY_CODE and PARENT_CATEGORY_CODE values are used in the flexfield's element in the XML schema for web services. You can maximize the readability of the schema by naming the codes with a leading alphabetic character followed by alphanumeric characters. The use of spaces, underscores, multibyte characters, and leading numeric characters, which are all encoded in XML schemas, make the codes in the schema element difficult to read.
You can learn about the FND_FLEX_DF_SETUP_APIS PL/SQL package by running the following command, which stores package documentation and usage examples in the <db_name>_<user_name>_FND_FLEX_DF_SETUP_APIS_<date>.plsqldoc file.
sqlplus <fusion_user>/<fusion_pwd>@<fusion_db> \ @/ORACLE/fusionapps/atgpf/applcore/db/sql/flex/fnd_flex_pkg_doc.sql \ FND_FLEX_DF_SETUP_APIS
After you create the flexfield's business components, you must complete the registration process by adding entity details, as described in Section 23.5.1, "How to Register Extensible Flexfields." You must have at least one entity usage per base extension table. If you require parallel sets of extensible flexfield artifacts generated for different uses (for example, public view objects and private view objects), replicate the entity usage entries with a different group name. When the business components are generated for the flexfield, a separate set of components is generated for each group name.
To incorporate an extensible flexfield into your application, you must complete the following steps:
Create and configure extensible flexfield entity objects from the base extension table. If a translation extension table exists for the flexfield, create and configure extensible flexfield entity objects from the translation extension table and the translation table view.
Configure the EFF_LINE_ID attribute for each extensible flexfield entity object as a unique ID.
Create and configure flexfield view objects to support contexts, categories, and, optionally, searching.
Register the flexfield business components.
Run the Create Flexfield Business Components wizard.
Tip:
After completing these steps, you can regenerate the flexfield business components programmatically at runtime to update your extensible flexfield implementation without manual intervention.
For more information, see Section 26.7, "Regenerating Flexfield Business Components Programmatically."
Figure 23-6 shows the extensible flexfield business components for a product table. In this example, the flexfield is not translatable. The developer creates an entity object and view object from the base extension table to support contexts.
If the flexfield is translatable, the developer would also create an entity object and view object from the translation extension table and the translation extension view.
When an implementor deploys flexfield configurations, the deployment process creates the extended context entity objects, context view objects, category view objects, and category-to-context view links. Note that in this example, the C2 context is a member of two categories.
For each extensible flexfield usage, you must create entity objects from the base extension table. If you created a translation extension table and a translation extension view for a usage, you must create entity objects for them as well.
For more information about creating entity objects, see the "Creating a Business Domain Layer Using Entity Objects" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Note:
The packages in which these entity objects are created must not fall under the packages allocated for runtime-generated business components (which are specified in the adf-config.xml file and the flexfield usage metadata).
Before you begin:
Create one set of dedicated extension tables per usage, as described in Section 23.3.1, "How to Create a Base Extension Table."
Register the flexfield's usages as described in Section 23.5.1, "How to Register Extensible Flexfields."
Ensure that the Applications Core library has been added to the data model project, as described in Section 3.3, "Adding Necessary Libraries to Your Data Model Project."
Verify that at least one customization class is included in the adf-config.xml file. This serves to ensure correct application behavior. It does not matter which customization class you include.
For information about defining the customization layers, see the "Understanding Customization Layers" section in the Oracle Fusion Applications Extensibility Guide for Developers.
For each extensible flexfield usage, use the Create Entity Object wizard to create an entity object from the base extension table that is described in Table 23-1, but apply the changes described in the following procedure to support the extensible flexfield. For information about the Create Entity Object wizard, see the "How to Create Single Entity Objects Using the Create Entity Wizard" section in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
To create and configure an entity object from the base extension table:
On the Attributes page of the wizard, include only the following columns as attributes in your new entity object:
EFF_LINE_ID
OBJECT_VERSION_NUMBER
Primary key columns of the product table
CONTEXT_CODE
CATEGORY_CODE
CREATED_BY
CREATION_DATE
LAST_UPDATED_BY
LAST_UPDATE_DATE
LAST_UPDATE_LOGIN
On the Attribute Settings page, do the following:
Set the EFF_LINE_ID attribute to be a primary key.
Set the CONTEXT_CODE attribute to be a discriminator, with a default value of 0.
On the Java page, confirm that the objectnameBEOImpl entity object class to be generated extends the oracle.apps.fnd.applcore.oaext.model.OAEntityImpl class.
After creating the entity object, configure all of its attributes to be hidden.
On the UI Hints tab of the Property Inspector for each attribute, set the Display Hint property to Hide.
Create an alternate key for the flexfield.
When business components are generated from this entity object, this alternate key will be extended to include all multiple-row context segments that implementors designate as a unique key when they configure the flexfield.
Note:
If this alternate key does not exist for an extensible flexfield, implementors will not be able to mark a segment in a multiple-row context as a unique key.
In the Application Navigator, double-click the entity object.
In the overview editor, click the General tab.
In the Alternate Keys section, click the Add icon.
In the Define Alternate Key dialog, type EFF_ALT_KEY in the Alternate Key Name field.
Select the primary key columns of the product table that the extensible flexfield extends and move them to the Selected list.
Select the contextCode attribute, move it to the Selected list, and click OK.
If you created a translation extension table for the flexfield usage, as described in Table 23-2, use the Create Entity Object wizard to create an entity object from the translation extension table, but apply the changes described in the following procedure to support the extensible flexfield.
For more information about creating entity objects, see the "Creating a Business Domain Layer Using Entity Objects" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
To create and configure an entity object from the extensible flexfield translation extension table:
On the Attributes page of the wizard, include only the following columns as attributes in your new entity object:
EFF_LINE_ID
OBJECT_VERSION_NUMBER
Primary key columns of the product table
CONTEXT_CODE
CATEGORY_CODE
SOURCE_LANG
LANGUAGE
CREATED_BY
CREATION_DATE
LAST_UPDATED_BY
LAST_UPDATE_DATE
LAST_UPDATE_LOGIN
On the Attribute Settings page, do the following:
Set the EFF_LINE_ID attribute to be a primary key.
Set the CONTEXT_CODE attribute to be a discriminator, with a default value of 0.
On the Java page, confirm that the objectnameTlEOImpl entity object class to be generated extends the oracle.apps.fnd.applcore.oaext.model.OAEntityImpl class.
After creating the entity object, configure all of its attributes to be hidden.
On the UI Hints tab of the Property Inspector for each attribute, set the Display Hint property to Hide.
Configure all of the non-key attributes that are of type String to be translatable.
On the Applications tab of the Property Inspector for each non-key, String type attribute, set the OA Translatable property to True.
Create an alternate key for the flexfield.
When business components are generated from this entity object, this alternate key will be extended to include all multiple-row context segments that implementors designate as a unique key when they configure the flexfield.
Note:
If this alternate key does not exist for an extensible flexfield, implementors will not be able to mark a segment in a multiple-row context as a unique key.
In the Application Navigator, double-click the entity object.
In the overview editor, click the General tab.
In the Alternate Keys section, click the Add icon.
In the Define Alternate Key dialog, type EFF_ALT_KEY in the Alternate Key Name field.
Select the primary key of the product table that the extensible flexfield extends and move it to the Selected list.
Select the contextCode attribute, move it to the Selected list, and click OK.
If you created a translation extension table and view for the flexfield usage, use the standard wizard to create an entity object from the translation extension view that is described in Section 23.3.3, "How to Create a Translation Extension View," but apply the changes described in the following procedure to support the extensible flexfield.
To create and configure an entity object from the extensible flexfield translation extension view:
On the Attributes page of the wizard, include only the following columns as attributes in your new entity object:
EFF_LINE_ID
Primary key columns of the product table
CONTEXT_CODE
CATEGORY_CODE
On the Attribute Settings page, do the following:
Set the EFF_LINE_ID attribute to be a primary key.
Set the CONTEXT_CODE attribute to be a discriminator, with a default value of 0.
On the Java page, confirm that the objectnameVlEOImpl entity object class to be generated extends the oracle.apps.fnd.applcore.oaext.model.OAEntityImpl class.
After creating the entity object, configure all of its attributes to be hidden.
On the UI Hints tab of the Property Inspector for each attribute, set the Display Hint property to Hide.
On the Applications tab of the Property Inspector for the entity object General tab, set the OA Base Table property to the name of the view underlying this entity object.
After you create and configure entity objects from the base extension table, translation extension table, and view of the translation extension table as described in Section 23.6.1, "How to Create and Configure Extensible Flexfield Entity Objects," you must configure the EFF_LINE_ID attribute for each entity object as a unique ID.
The Unique ID Generator provides a way for your application to generate unique IDs for entity object attributes of type Long. The unique IDs generated are also of type Long, and meet certain required criteria for uniqueness across database instances.
Before you begin:
The application must have a a connection to the database that contains the Unique ID Generator table called S_ROW_ID. This is typically the ApplicationDB database.
To configure EFF_LINE_ID as a unique ID:
Configure a special default-value expression for EFF_LINE_ID that will invoke the Unique ID Generator when needed.
For more information, see Section 9.6, "Using Unique ID."
For each extensible flexfield usage, use the Create View Object wizard (not the Flexfield Business Components wizard) to create the following types of view objects:
To support contexts for the extensible flexfield, create one view object from the base extension table entity object and, if the flexfield has a translation extension table, one view object from the translation extension view entity object.
Note:
No view objects are required from the translation table entity object.
To support categories for the flexfield, create a view object from the product table entity object for which you are developing this extensible flexfield.
To support searching, create a declarative SQL-based view object.
For more information about creating view objects, see the "Defining SQL Queries Using View Objects" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework. For more information about declarative SQL-based view objects, see the "How to Create Declarative SQL View Objects" section in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Before you begin:
Create and configure entity objects from the base extension table, translation extension table, and view as described in Section 23.6.1, "How to Create and Configure Extensible Flexfield Entity Objects."
Configure the EFF_LINE_ID attribute as a unique ID as described in Section 23.6.2, "How to Configure the EFF_LINE_ID Attribute as a Unique ID."
To support contexts for an extensible flexfield usage, the usage must have a view object from its base extension table entity object. If you created a translation extension table for the usage, you must also create a view object from the translation extension view entity object.
To create and configure context view objects:
Use the Create View Object wizard to create the view objects from the base extension table entity object and, if you created a translation extension table for the usage, from the translation extension view entity object.
On the Java page for each view object, ensure that the view object classes to be generated extend base classes as follows:
vo_nameImpl extends EFFViewObjectImpl
vo_nameRowImpl extends EFFViewRowImpl
vo_nameDefImpl extends EFFViewDefImpl
These base classes are in the oracle.apps.fnd.applcore.oaext.model package.
To support categories for the flexfield, there must be a view object for the product table entity object for which you are developing the extensible flexfield.
To create and configure the base category view object:
Use the Create View Object wizard to create a view object from the product table for which you are implementing the extensible flexfield in the usual manner. For example, in Figure 23-2, the product table is the Parts table that stores the base attributes for the Parts entity, such as Part Number, Description, and Unit Cost.
This view object must include an attribute called CategoryCode, which is used to identify the category to which each row of data belongs. This attribute must be an entity-based attribute of type VARCHAR2 with a maximum of 80 characters.
Set the CategoryCode attribute to be a discriminator, with a default value of 0.
You must ensure that the correct category code is returned for this attribute at runtime.
To enable searching, you must create a declarative SQL-based view object for searching the product table for which you are implementing the extensible flexfield. You must include the same product table entity object that was used for the base category view object. For more information about the base category view object, Section 23.6.3.2, "Creating and Configuring the Base Category View Object."
For information about declarative SQL-based views objects, see the "How to Create Declarative SQL View Objects" section in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
To create a declarative SQL-based view object to enable searching:
In the Application Navigator, right-click the project in which you want to create the view object and choose New.
In the New Gallery, expand Business Tier, select ADF Business Components and then View Object, and click OK.
On the Name page, enter a package name and a view object name. Keep the default setting Updatable access through entity objects enabled to indicate that you want this view object to manage data with its base entity object. Click Next.
On the Entity Objects page, select the entity object that was used for the base category view object and move it to the Selected tree.
The view object can contain additional entity objects, but it must include the entity object that was used for the base category view object.
Click Next.
On the Attributes page, select all the attributes for which you want to enable search and move them to the Selected tree.
You must include the CategoryCode attribute and the primary key attributes.
Select the other attributes to include in the view criteria, move them to the Selected tree, and click Next.
Mark the CategoryCode attribute as a discriminator with a default value of -1.
On the Attribute Settings page, select CategoryCode from the Select Attribute dropdown list.
Select Discriminator.
In the Default Value field, type -1.
Note:
CategoryCode must be an entity object attribute. It cannot be a transient attribute.
Configure the attribute settings for the remaining attributes as required, and click Next.
On the Query page, select Declarative in the SQL Mode dropdown list if it is not already displayed. The wizard changes to declarative SQL mode.
On the Java page, select Generate View Object Class and select Generate View Object Definition Class.
Click Classes Extend.
In Object field in the Override Base Classes dialog, type oracle.apps.fnd.applcore.oaext.model.EFFCategoryViewObjectImpl.
The EFFCategoryViewObjectImpl class adds the additional WHERE clause that provides security.
In the Definition field, type oracle.apps.fnd.applcore.oaext.model.FlexfieldBaseViewDefImpl, and click OK.
Complete the steps.
Execute the following SQL statement to register the search view object. Replace search-view-object with the fully qualified name for the search view object. Replace product-table with the name of the product table that the flexfield extends.
UPDATE FND_DF_ADFBC_USAGES SET EFF_SEARCH_VIEW_OBJECT = 'search-view-object' WHERE TABLE_NAME='product-table' AND ENTITY_OBJECT='product-table-entity-object';
After you create extensible flexfield entity objects and view objects to support an extensible flexfield usage, you must complete the flexfield registration process by providing the names of the flexfield usage's entity object and view object. If you created a translation extension table for the flexfield usage, you must also register the entity object from the translation extension table.
You use procedures from the FND_FLEX_DF_SETUP_APIS PL/SQL package to register the flexfield usage's entity details. For information about using the procedures, see the package specification.
Before you begin:
Create and configure the extensible flexfield entity objects as described in Section 23.6.1, "How to Create and Configure Extensible Flexfield Entity Objects."
Create and configure the extensible flexfield view objects as described in Section 23.6.3, "How to Create and Configure Extensible Flexfield View Objects."
To register extensible flexfield entity details:
Add the flexfield metadata to the FND_DF_ADFBC_USAGES table as specified by the package specification.
For each table defined in the FND_DF_TABLE_USAGES table, specify the name of the entity object and view object. For the translation extension table, also specify the name of the entity object from the translation extension table.
If the consumers who are incorporating the flexfield into the application want to generate a different set of artifacts for both private and public groups, create an additional set of rows with a different extensible flexfield group name.
Figure 23-7 shows example entries for a flexfield usage. As described in Section 23.5.1, "How to Register Extensible Flexfields," the FND_DF_TABLE_USAGES table contains rows for the product table (USGA_BASE), the usage base extension table (USGA_EFF_B), and the usage translation extension table (USGA_EFF_TL). The FND_DF_ADFBC_USAGES table contains two entries for each entry in the FND_DF_TABLE_USAGES table — one for the Private group and one for the Public group. Each row names the entity object and the view object. The rows for the translation extension table also name the entity object from the translation extension table. Note that not all columns are shown.
Note:
In this example, the Public group is necessary because the product that is using the flexfield usage requires a parallel set of extensible flexfield artifacts generated for public view objects.
If the consumers wanted to support interface loading of extensible flexfield data, you would also add entries for the BASE_INTERFACE, EXTENSION_INTERFACE, and EXTENSION_INTERFACE_TL table types.
You use the Create Flexfield Business Components wizard to create the flexfield business components for an extensible flexfield's usage.
The business components that are generated will replace any existing components that are based on the same flexfield usage.
Before you begin:
Create the flexfield entity objects as described in Section 23.6.1, "How to Create and Configure Extensible Flexfield Entity Objects."
Configure the EFF_LINE_ID attribute for each entity object as a unique ID as described in Section 23.6.2, "How to Configure the EFF_LINE_ID Attribute as a Unique ID."
Create the flexfield view objects and the declarative SQL-based view object as described Section 23.6.3, "How to Create and Configure Extensible Flexfield View Objects."
Register the entity objects and view objects as described in Section 23.6.4, "How to Register Extensible Flexfield Entity Objects and View Objects."
Build your project to ensure that the entity objects are available in classes. The modeler relies on what is in your classes.
Ensure that you have added the Applications Core library to your project as described in Chapter 3, "Setting Up Your JDeveloper Application Workspace and Projects"
Ensure that at least one customization class is included in the adf-config.xml file. This inclusion serves to ensure correct application behavior. It does not matter which customization class you include.
For information about customization layers, see the "Understanding Customization Layers" section in the Oracle Fusion Applications Extensibility Guide for Developers.
To create extensible flexfield business components:
From the File menu, choose New.
In the New Gallery, expand Business Tier, select ADF Business Components, select Flexfield Business Components, and click OK.
In the Flexfield page of the Create Flexfield Components wizard, select Extensible from the Type dropdown list as shown in Figure 23-8.
In the Application field, specify the full name of the application to which your descriptive flexfield belongs.
You can browse for the name, and filter by ID, Short Name, or Name.
In the Code field, specify the code of the descriptive flexfield you want to use.
You can browse for and filter by Code.
In the Usage section, select the table row that contains your desired descriptive flexfield usage.
Click Next.
The Overview page displays the tasks that must be completed before the wizard can generate the business components, as shown in Figure 23-9. The wizard will complete the necessary tasks. Click Next.
Note:
If you created a declarative SQL-based view object as described in Section 23.6.3.3, "Creating a Declarative SQL-Based View Object to Enable Searching," then the wizard will create a stub search view object, which you can use to expose the extensible flexfield's attributes in a table and to incorporate the extensible flexfield in a search form. Make a note of the fully qualified path that is shown in on the Overview page for the stub search view object so that you can locate the view object and add it to an application module. If a path is not shown for the view object, then the declarative SQL-based view object was not registered in the FND_DF_ADFBC_USAGES table.
If the wizard needs to implement any uncompleted tasks from the Overview page, the wizard displays the automated code changes, as shown in Figure 23-10. Review the code and click Next.
On the Summary page, click Finish.
Note:
This wizard might fail with a "ClassNotFound" exception message. This indicates that one or more required libraries have not been automatically included in your project. You can resolve this issue by manually adding any missing libraries; then you can complete this procedure successfully.
Refresh the project to see the newly created flexfield business components in the Application Navigator. The components are in the package that you registered for the flexfield usage and are named using the registered prefix.
You can incorporate an extensible flexfield into an application with several UI variations:
As a single task flow for multiple contexts for a single usage in one of the following layouts:
Single page layout: A single task flow that presents a set of contexts associated with a specified logical page, which is identified before the UI page initializes. Figure 23-1 is an example of this variation.
Panel splitter layout: A list of the extensible flexfield logical pages for a single usage, combined with the contexts for the selected logical page, and integrated into a single task flow. Figure 23-2 is an example of this variation.
As a single task flow that presents a context, which is identified before the UI page initializes.
As a complete list of the usages and pages for a given extensible flexfield in one task flow, with contexts for the selected page in a separate task flow.
As columns in a table that displays the attributes for a specific category. The attributes from all the contexts that are associated with the category are displayed. The attributes are grouped in a column span and are labeled context:segment.
Notes:
If there is only one usage and only one logical page, use a single task flow that presents a set of contexts associated with a specified logical page, which is identified before the UI page initializes. Do not display a list of usages or pages on the left-hand side of the task flow.
If the extensible flexfield will never have more than one usage and will never have more than one logical page, and if you do not need any features that are unique to extensible flexfields as discussed in Section 23.1.2, "The Benefits of Extensible Flexfields," consider using a descriptive flexfield instead.
Unless you know that the extensible flexfield will contain only a small amount of information, do not embed the flexfield in the middle of a region that has other content.
For more information about task flows, see the "Creating a Task Flow" section in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Note:
When it is not clear what type of data will be configured for the extensible flexfield, name the containing region, such as a page or a dialog, "Additional Information" or "Additional Information: Object Name" for view-only data, and "Edit Additional Information" or "Edit Additional Information: Object Name" for data that can be edited. If the containing region is a tab, name the tab "Additional Information" or "Edit Additional Information," as appropriate. This convention ensures consistency across Oracle Fusion applications.
You can easily incorporate an extensible flexfield into the UI in one of the following layouts by dragging the view object for the flexfield-enabled object from the Data Controls panel and dropping it onto the page:
Single page layout: The extensible flexfield is incorporated as a single task flow that presents a set of contexts associated with a specified logical page and usage as shown in Figure 23-1.
Panel splitter layout: The extensible flexfield is incorporated as a list of the logical pages for a specified usage, combined with the contexts for the user-selected logical page, and integrated into a single task flow, as shown n Figure 23-2.
Before you begin:
Create and configure business components to support the extensible flexfield as described in Section 23.6, "Defining and Registering Extensible Flexfield Business Components."
Execute the following SQL query to obtain the name of the view object for the flexfield-enabled object:
SELECT VIEW_OBJECT FROM FND_DF_ADFBC_USAGES WHERE TABLE_NAME IN (SELECT TABLE_NAME FROM FND_DF_TABLE_USAGES TBL WHERE DESCRIPTIVE_FLEXFIELD_CODE = flexfield-code AND TBL.APPLICATION_ID = application-id AND TABLE_TYPE = 'BASE' AND FLEXFIELD_USAGE_CODE = flexfield-usage-code)
To add an extensible flexfield as a single flow for multiple contexts:
Open the page to which you want to add the extensible flexfield.
From the Data Controls panel, drag the view object for the flexfield-enabled object onto the page or Structure window.
When prompted, choose Applications and then choose Oracle Extensible Flexfield.
In the User Interface region in the Create Extensible Flexfield dialog, select Panel Splitter or Single Page, as shown in Section 23.7.1, "Create Extensible Flexfield Dialog"
Accept the default group code or change its value.
If you selected the single page layout, enter the page code for the logical page to be displayed at runtime.
Specify the usage code.
In the Object Keys region, specify the values to use for the category code and the primary keys.
Click Apply.
(Optional) Complete the following steps to modify the ReadOnly and _eff_param1 through _eff_param5 properties:
Right click in the page and choose Go to Page Definition.
In Executables section in the page definition, select taskFlow - ExtensibleFlexfieldRruntimeUI1 and click the Edit icon.
In the Input Parameters region in the Edit Task Flow Binding dialog, set ReadOnly to Y if the page should render all segments as read-only fields. Otherwise, set to N or leave the parameter value blank.
If you need to pass in custom parameters for UI customization, as described in Section 23.10.2, "How to Customize the Runtime User Interface Modeler for Extensible Flexfields," use the _eff_param1 through _eff_param5 parameters to specify the custom parameter values. For example, if you need to customize the page to display or not display certain segments based upon the user's location, you can use one of these parameters to provide the location as an input parameter.
If you have not done so already, complete the following substeps:
Open the Databindings.cpx file and add the following EFFRuntimeAM data control:
<BC4JDataControl id="EFFRuntimeAMDataControl"
Package="oracle.apps.fnd.applcore.flex.eff.
runtime.applicationModule"
FactoryClass="oracle.adf.model.bc4j.
DataControlFactoryImpl"
SupportsTransactions="true" SupportsFindMode="true"
SupportsRangesize="true" SupportsResetState="true"
SupportsSortCollection="true" Configuration=
"EFFRuntimeAM"
syncMode="Immediate"
xmlns="http://xmlns.oracle.com/adfm/datacontrol"/>
Add the following code to the Application tag at the top of the Databindings.cpx file to enable the application to find the page definitions for the generated UI artifacts:
PageMapClass="oracle.jbo.uicli.mom.DynamicPageMapImpl"
BasePageDefPackageName="pageDefs"
To expose the complete set of usages, logical pages, and associated contexts, build a UI page that includes a splitter with two task flows: one containing the list of extensible flexfield usages and their associated logical pages on the left, and the other containing the contexts associated with the selected logical page on the right.
To build the UI page:
Create a task flow for the extensible flexfield usages and a task flow for the associated contexts.
Create the left and right fragment pages.
Use the task flows in the UI page.
The UI page requires two task flows: one containing the list of extensible flexfield usages and their associated logical pages, and the other containing the contexts associated with the selected logical page.
Before you begin:
Create and configure business components to support the extensible flexfield as described in Section 23.6, "Defining and Registering Extensible Flexfield Business Components."
To create the two task flows:
Create a page-list task flow, for example, PageListTF.
Add the following parameter to the task flow:
Name: ContainerBean
Class: oracle.apps.fnd.applcore.flex.eff.runtime.EffCategoryPagesBean
Value: #{pageFlowScope.ContainerBean}
Create the context container task flow, for example, ContextPageTF.
Add a parameter that is the same as the one you added in Step 2 to the task flow.
Create a left fragment for the list of flexfield usages and a right fragment for contexts.
Before you begin:
Create the page-list task flow and context container task flow as described in Section 23.7.2.1, "Creating the Task Flows".
To create the fragments:
Create the left and right fragment pages PageListFrag.jsff and ContextPageFrag.jsff.
Add the EffCatPageListContainer seeded task flow from the ViewController FlexModeler-View library to the page list fragment using the following parameters:
_eff_application_id: Provide the FND_EF_UI_PAGES_B.APPLICATION_ID value; for example 10010.
_eff_descriptive_flexfield_code: Provide the FND_EF_UI_PAGES_B.DESCRIPTIVE_FLEXFIELD_CODE value; for example EGO_ITEM_EFF.
_eff_category_code: Provide the FND_EF_UI_PAGES_B.CATEGORY_CODE value; for example ELECTRONICS.
_eff_usage_code: Provide the FND_EF_UI_PAGES_B.FLEXFIELD_USAGE_CODE value; for example, EGO_ITEM_DL.
_eff_containerBean: Provide #{pageFlowScope.ContainerBean}.
Add the EffContextsPageContainer seeded task flow from the ViewController FlexModeler-View library to the context page fragment using the following parameters:
_eff_application_id: Provide #{pageFlowScope._eff_application_id}.
_eff_descriptive_flexfield_code: Provide #{pageFlowScope._eff_descriptive_flexfield_code}.
_eff_category_code: Provide #{pageFlowScope._eff_category_code}.
_eff_usage_code: Provide #{pageFlowScope._eff_usage_code}.
_eff_page_code: Provide #{pageFlowScope._eff_page_code}.
_eff_containerBean: Provide #{pageFlowScope.ContainerBean}.
_eff_category_pk1: (optional) Provide the value for the category's first primary key column, if applicable. For example, if the first primary key column is INVENTORY_ITEM_ID, and its value is 149, provide 149.
_eff_category_pk2 - (optional) Provide the value for the category's second primary key column, if applicable. For example, if the second primary key column is ORGANIZATION_ID, and its value is 204, provide 204.
_eff_category_pk3 through pk5: Provide the value for that primary key column, if applicable.
Drag and drop the page list fragment onto the page-list task flow.
Drag and drop the context page fragment onto the context task flow.
Use the task flows that you just created in Section 23.7.2.1, "Creating the Task Flows" to add the usages, logical pages, and associated context lists to the page.
Before you begin:
Create the page-list task flow and context container task flow as described in Section 23.7.2.1, "Creating the Task Flows."
Create the left and right fragment pages PageListFrag.jsff and ContextPageFrag.jsff as described in Section 23.7.2.2, "Creating the Fragments."
To use the task flows in the page:
Open the page and add the splitter.
Add the page-list and context page task flows to the left and right facets of the splitter.
Enter the value of pageFlowScope.EffCategoryPagesBean for the ContainerBean parameter to the task flows.
If you have not done so already, complete the following substeps:
Open the Databindings.cpx file and add the following EFFRuntimeAM data control:
<BC4JDataControl id="EFFRuntimeAMDataControl"
Package="oracle.apps.fnd.applcore.flex.eff.
runtime.applicationModule"
FactoryClass="oracle.adf.model.bc4j.
DataControlFactoryImpl"
SupportsTransactions="true" SupportsFindMode="true"
SupportsRangesize="true" SupportsResetState="true"
SupportsSortCollection="true" Configuration=
"EFFRuntimeAM"
syncMode="Immediate"
xmlns="http://xmlns.oracle.com/adfm/datacontrol"/>
Add the following code to the Application tag at the top of the Databindings.cpx file to enable the application to find the page definitions for the generated UI artifacts:
PageMapClass="oracle.jbo.uicli.mom.DynamicPageMapImpl"
BasePageDefPackageName="pageDefs"
Build an application page with a single task flow as a dynamic region on the right, and containing the context that was passed. This variation does not present an extensible flexfield usage or page-list task flow in the user interface.
Before you begin:
Create and configure business components to support the extensible flexfield as described in Section 23.6, "Defining and Registering Extensible Flexfield Business Components."
To expose the extensible flexfield context:
Create a task flow for Pages List, for example, PageListTF.xml.
Add a managed bean called EffCategoryPagesBean to this task flow. It should have a class of pageFlowScope.EffCategoryPagesBean and a scope of pageFlow.
Create a fragment, for example PageListFrag.jsff, and drag and drop the EffCatPageListContainer task flow from the ViewController FlexModeler-View library on the fragment.
Add the following parameters:
_eff_application_id: Provide #{pageFlowScope._eff_application_id}.
_eff_descriptive_flexfield_code: Provide #{pageFlowScope._eff_descriptive_flexfield_code}.
_eff_category_code: Provide #{pageFlowScope._eff_category_code}.
_eff_usage_code: Provide #{pageFlowScope._eff_usage_code}.
_eff_page_code: Provide #{pageFlowScope._eff_page_code}.
_eff_containerBean: Provide #{pageFlowScope.EffCategoryPagesBean}.
Place the task flow on any page on which you want the page list to appear.
Create a task flow, for example, ContextsTF.xml.
Add an empty fragment to this task flow, for example, ContextsFrag.jsff.
Access the page on which you would like your contexts to appear. This could possibly be the same page as in Step 5, but is likely the second facet of a splitter.
Drag and drop ContextsTF.xml as a dynamic region onto this page at the correct location.
When prompted for a backing bean, enter a new bean name, class, and package, for example, ContextsRenderingBean.java, and allow it to remain as a backing bean.
Open the Java file and add the following code, replacing the value for taskFlowId with the appropriate string:
public class ContextsRenderingBean {
private String taskFlowId =
"/WEB-INF/oracle/apps/fnd/applcore/flex/eff/runtime/ui/test/flow/ContextsTF.xml#ContextsTF";
private String newTaskFlowId =null;
private boolean refreshRegion = false;
public ContextsRenderingBean () {
}
public TaskFlowId getDynamicTaskFlowId() {
return TaskFlowId.parse(taskFlowId);
}
public boolean getRefreshRegion() {
refreshRegion = false;
newTaskFlowId = (String) ADFContext.getCurrent().getSessionScope().
get("_eff_context_tf_id");
if (newTaskFlowId != null && taskFlowId.compareTo(newTaskFlowId) != 0 ) {
taskFlowId = newTaskFlowId;
refreshRegion = true;
}
return refreshRegion;
}
}
Open the page definition for the launch page and scroll to the location of the dynamic region binding.
Add the following refresh condition setting to the taskFlow tag:
RefreshCondition="#{backingBeanScope.ContextsRenderingBean.refreshRegion}"
This setting provides the callback and the conditions for the refresh of the contexts region.
When you run the page and click the page link, the callback to refreshRegion will look up the ID for the contexts task flow and enable a refresh condition of the dynamic region.
If you have not done so already, complete the following substeps:
Open the Databindings.cpx file and add the following EFFRuntimeAM data control:
<BC4JDataControl id="EFFRuntimeAMDataControl"
Package="oracle.apps.fnd.applcore.flex.eff.
runtime.applicationModule"
FactoryClass="oracle.adf.model.bc4j.
DataControlFactoryImpl"
SupportsTransactions="true" SupportsFindMode="true"
SupportsRangesize="true" SupportsResetState="true"
SupportsSortCollection="true" Configuration=
"EFFRuntimeAM"
syncMode="Immediate"
xmlns="http://xmlns.oracle.com/adfm/datacontrol"/>
Add the following code to the Application tag at the top of the Databindings.cpx file to enable the application to find the page definitions for the generated UI artifacts:
PageMapClass="oracle.jbo.uicli.mom.DynamicPageMapImpl"
BasePageDefPackageName="pageDefs"
You can expose extensible flexfield attributes as columns in a table that displays attributes for a specific category. The attributes from all the contexts that are associated with the selected category are displayed. The attributes are grouped in a column span and are labeled context:segment.
Before you begin:
If you have not done so already, add the stub search view object that was created when you ran the Create Flexfields Business Components wizard to an application module. The stub search view object is in the view folder in the package that you registered for the extensible flexfield usage in the FND_DF_ADFBC_USAGES table.
Note:
The Create Flexfields Business Components wizard creates the stub search view object based on the flexfield's declarative SQL-based view object that was registered for the flexfield usage. If no declarative SQL-based view object was registered, then a stub search view object will not exist. You must create and register the SQL-based view object as described in Section 23.6.3.3, "Creating a Declarative SQL-Based View Object to Enable Searching" and then run the Create Flexfield Business Components wizard as described in Section 23.6.5, "How to Create Business Components For an Extensible Flexfield's Usage."
To expose category attributes in a table:
Open the page to which you want to add the table with extensible flexfield flexfield columns.
Drag the stub search view object and drop it on the page.
When prompted, select Applications > Table.
Rearrange the columns and select table options as required. If you choose the filtering option, the table will be a filtered table.
Right-click in the page and choose Go to Page Definition.
In the source editor for the page definition, remove the AttrNames tag and its nested tags from the nodeDefinition tag in the tree tag. The tags shown in bold in Example 23-5 are examples of the tags to remove.
Example 23-3 AttrNames Tag to Remove from the Page Definition
<tree
IterBinding="j_ExtendedDeclarativePublic1Iterator"
id="j_ExtendedDeclarativePublic1">
<nodeDefinition
DefName="oracle.apps.fnd.applcore.flex.eff.test.genjbo.base.model.view.
j_ExtendedDeclarativePublicVO" Name="j_ExtendedDeclarativePublic10">
<AttrNames>
<Item Value="Description"/>
<Item Value="ItemType"/>
<Item Value="Name"/>
<Item Value="CategoryCode"/>
</AttrNames>
</nodeDefinition>
</tree>
Write down the value for IterBinding.
In the source editor for the search page, add the following <af:column> tag to the <af:table> tag. Change iter-binding to the IterBinding value for the tree tag in the page definition. This is the value that you noted in Step 7.
<af:column headerText="header-text"> <fnd:extensibleFlexfieldColumn value="#{bindings.iter-binding}" readOnly="true"/> </af:column>
Open the source code in which you will call the executeQuery method for the view object.
Add a call to the EFFSearchUtil.prepareEFFDeclarativeVOForCategory method followed by a call to the view object's executeQuery method.
The prepareEFFDeclarativeVOForCategory method prepares the declarative view object with all the attributes that pertain to the specified category.
Example 23-4 shows the API for the prepareEFFDeclarativeVOForCategory method.
Example 23-4 prepareEFFDeclarativeVOForCategory API
@param effDeclarativeViewObject : The view object instance on which the table has been built. This should be an instance of j_ExtendedDeclarative<group>VO @param categoryCode : The category for which to render the table. public static void prepareEFFDeclarativeVOForCategory( ViewObjectImpl effDeclarativeViewObject, String categoryCode )
After the call to the executeQuery method, call the DescriptiveFlexfield.updateFlexColumns method with the table component object as the argument.
This method refreshes the table to add the flexfield columns for the category.
You can include extensible flexfield view object attributes as search criteria in a query search form. The search form will include an Add Fields button, which displays a list of the flexfield view object attributes. End users can select which attributes of the flexfield view object to use as search criteria.
You incorporate an extensible flexfield into a query search form by dropping a view criteria component from the Data Controls panel onto the page.
Before you begin:
If you have not done so already, add the stub search view object that was created when you ran the Create Flexfields Business Components wizard to an application module. The stub search view object is in the view folder in the package that you registered for the extensible flexfield usage in the FND_DF_ADFBC_USAGES table.
Note:
The Create Flexfields Business Components wizard creates the stub search view object based on the flexfield's declarative SQL-based view object that was registered for the flexfield usage. If no declarative SQL-based view object was registered, then a stub search view object will not exist. You must create and register the SQL-based view object as described in Section 23.6.3.3, "Creating a Declarative SQL-Based View Object to Enable Searching" and then run the Create Flexfield Business Components wizard as described in Section 23.6.5, "How to Create Business Components For an Extensible Flexfield's Usage."
If the desired view criteria for the stub search view object does not exist, create it. The view criteria must contain the flexfield's CategoryCode attribute. The operator for the CategoryCode attribute must be set to Equals.
To incorporate an extensible flexfield into a search form:
Open the search page to which you want to add the extensible flexfield.
From the Data Controls panel, expand the stub search view object, expand Named Criteria, and drag the desired view criteria onto the page or Structure window.
Use the stub search view object to create a results panel and a query panel as described in the "Creating Query Search Forms" section in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Right-click in the page and choose Go to Page Definition.
In the source editor for the page definition, remove the AttrNames tag and its nested tags from the nodeDefinition tag in the tree tag. The tags shown in bold in Example 23-5 are examples of the tags to remove.
Example 23-5 AttrNames Tag to Remove from the Page Definition
<tree
IterBinding="j_ExtendedDeclarativePublic1Iterator"
id="j_ExtendedDeclarativePublic1">
<nodeDefinition
DefName="oracle.apps.fnd.applcore.flex.eff.test.genjbo.base.model.view.
j_ExtendedDeclarativePublicVO" Name="j_ExtendedDeclarativePublic10">
<AttrNames>
<Item Value="Description"/>
<Item Value="ItemType"/>
<Item Value="Name"/>
<Item Value="CategoryCode"/>
</AttrNames>
</nodeDefinition>
</tree>
Write down the value for IterBinding.
In the Structure window for the search page, select the af:query component.
In the Property Inspector, expand Behavior and set the QueryListener property to FlexEFFSearchUtilBean.effQueryListener.
In the source editor for the search page, add the following <af:column> tag to the <af:table> tag. Change iter-binding to the IterBinding value for the tree tag in the page definition. This is the value that you noted in Step 6.
<af:column headerText="header-text"> <fnd:extensibleFlexfieldColumn value="#{bindings.iter-binding}" readOnly="true"/> </af:column>
Any implementation of flexfields in Oracle Fusion Applications typically requires application seed data, which is the essential data that enables flexfields to work properly in applications. Flexfield seed data can be uploaded and extracted using Seed Data Loader.
After you complete the registration process described in Section 23.5.1, "How to Register Extensible Flexfields," your flexfield seed data consists of the information that you registered for your flexfield, such as the tables and columns reserved for your flexfield. For a customer flexfield, the seed data contains only this registration data.
If your flexfield is a developer flexfield, you also serve as the implementor. In addition to the registration data, your flexfield seed data might include contexts, segments, and value sets that you have defined for your flexfield. You can use the Oracle Fusion Middleware Extensions for Applications (Applications Core) Setup application, as described in Section 26.5, "Deploying Flexfields in a Standalone WebLogic Server Environment," to configure a flexfield. For information about how to define contexts, segments, and value sets, see the "Flexfields Overview" section in the Oracle Fusion Applications Common Implementation Guide.
For information about extracting and loading seed data, see Chapter 56, "Initializing Oracle Fusion Application Data Using the Seed Data Loader."
You can customize the modelers that generate the extensible flexfield business component and UI artifacts to add additional product-specific logic. For example, you might want the modeler to set a specific JavaServer Pages (JSP) Expression Language (EL) expression on a generated segment's ReadOnly property.
To extend the runtime business component modeler for extensible flexfields, override the EFFBCModelerFactory.getCustomEFFBCModeler method, shown in Example 23-6, in the custom runtime business component modeler factory for extensible flexfields.
Example 23-6 getCustomEFFBCModeler Method
/**
* Implementing teams need to override this method and provide the
* custom BC Modeler here (for example, PIMBCModeler).
* @param namespace the name space
* @param flexDef the flexfield def
* @param entityUsage the entity usage
* @param writer the modeler writer
* @param conf the configuration
* @param categoryDef the category def
* @param categoryContextDef the category context def
* @param categoryCode the category code
* @param contextCode the context code
* @param appShortName the application short name
* @param flexCode the flexfield code
* @param connUrl the connection url
* @param isInterface the interface flag
* @return the custom EFF BC Modeler instance.
*/
protected EFFBCModeler getCustomEFFBCModeler(FlexfieldNamespace namespace,
FlexfieldDef flexDef,
FlexfieldEntityUsage entityUsage,
BCModelerWriter writer,
Map<BCModeler.Option, Object> conf,
CategoryDef categoryDef,
CategoryContextDef categoryContextDef,
String categoryCode,
String contextCode,
String appShortName,
String flexCode,
String connUrl,
boolean isInterface)
{
return new EFFBCModeler(namespace, flexDef, entityUsage, writer, conf,
categoryDef, categoryContextDef, categoryCode,
contextCode, appShortName, flexCode, connUrl,
isInterface);
}
An example of the PIMBCModelerFactory.java override for this method is shown in Example 23-7.
Example 23-7 PIMBCModelerFactory.java Override
protected EFFBCModeler getCustomEFFBCModeler(FlexfieldNamespace namespace,
FlexfieldDef flexDef,
FlexfieldEntityUsage entityUsage,
BCModelerWriter writer,
Map<BCModeler.Option, Object> conf,
CategoryDef categoryDef,
CategoryContextDef categoryContextDef,
String categoryCode,
String contextCode,
String appShortName,
String flexCode,
String connUrl,
boolean isInterface)
{
return new PIMBCModeler(namespace, flexDef, entityUsage, writer, conf,
categoryDef, categoryContextDef, categoryCode,
contextCode, appShortName, flexCode, connUrl,
isInterface);
}
If the UI artifacts that are generated for an extensible flexfield business component do not fulfill application requirements, you can create wrapper implementation classes for the framework's customizer interfaces. These wrapper implementation classes enable some control over the XML code that the modeler generates for the UI artifacts just before it persists the generated task flows and JavaServer Faces (JSF) page fragments. The implementation classes are in the oracle.apps.fnd.applcore.flex.uimodeler.customizers package.
To customize an extensible flexfield business component's generated UI artifacts:
Create wrapper classes for the default customizer implementation classes.
Create a wrapper of the metadata provider implementation class.
Register the metadata provider wrapper class in the metadata for the flexfield's business component.
Extend the default customizer implementation classes from the oracle.apps.fnd.applcore.flex.uimodeler.customizers package to customize the following UI artifacts:
Context JSF fragment
Segment components in the generated context task flow
Page links in the generated links task flow
Page task flow
Search task flow
To customize the JSF page fragment for a single row context, create a wrapper class for the SingleRowContextRegionCustomizerImpl implementation class and override the customizeGeneratedSingleRowContextFragment method.
To customize the JSF page fragment for a multiple row context, create a wrapper class for the MultiRowContextRegionCustomizerImpl implementation class and override the customizeGeneratedMultiRowContextFragment method.
To customize which segment components in the generated context task flow will be read-only for single and multirow contexts, create a wrapper class for the ContextComponentsCustomizerImpl implementation class and override the getAtributeComponentReadonlyELExpression method. This method returns the value of the readOnly property for a given segment component in the context task flow, as shown in Example 23-8.
Example 23-8 Sample getAtributeComponentReadonlyELExpression Method
public String getAtributeComponentReadonlyELExpression(
Transaction tx, ViewDef contextViewDef) {
String returnData = null;
ViewDefImpl contextViewDefImpl = (ViewDefImpl) contextViewDef;
if(contextViewDefImpl.getName().toUpperCase().indexOf("RESOLUTION") >0 ) {
returnData = "#{pageFlowScope.EFF_PARAM5=='Y'}";
}
return returnData;
}
To customize which page links in a generated links task flow will be rendered, create a wrapper class for the PageListCustomizerImpl implementation class and override the getPageLinkRenderedProperty method. This method returns the value of the rendered property for a page link.
To customize which context task flows will be rendered in a page task flow, create a wrapper class for the ContainerPageCustomizerImpl implementation class and override the getContextTFRenderedELExpression method. This method returns the value of the region tag for a context task flow.
If implementors have defined a view privilege on a context, then the application checks if the context is present in either the base or translation extension table before verifying whether the end user has view privileges for the context. By default, the application uses the primary keys of the product table plus the context code and category code to search for a matching row in the extension tables. If your application uses a different method for associating extension table rows with product table rows, you must override the prepareSqlQueryForMatchingEffLineId method in the oracle.apps.fnd.applcore.flex.eff.runtime.EffCategoryPagesBean.java class to return the search query that is to be used to find a matching row. This method takes the security object, the context code, the category code, and the category row as input parameters and it returns the query in String form.
To customize the search task flow, create a wrapper class for the SearchRegionCustomizerImpl implementation class. Table 23-3 shows the ways in which you can customize the search task flow and the methods to override to perform the customizations.
Table 23-3 Methods to Override to Customize the Search Task Flow
| Customization | Method to Override | Notes |
|---|---|---|
|
Set the list of actions required in the search results table. |
|
Use the |
|
Set the managed bean for the generated task flow. |
|
The manage bean must extend |
|
Alter properties in the product table component for search results. |
|
This method returns a hashmap of name-value pairs of the properties to be set. |
|
Alter properties in the ADF Table that is in the product table component for search results. |
|
This method returns a hashmap of name-value pairs of the properties to be set, as shown in Example 23-9. |
|
Customize the query panel properties. |
|
This method returns a hashmap of name-value pairs of the properties. |
|
Get a handle to the document object model (DOM) object of the generated search region and its |
|
Use DOM objects to customize generated artifacts only if there is no other way to perform for the customization. |
|
Customize the |
|
This method returns a JSP EL expression. |
|
Customize the properties on the search results table column for an |
|
This method returns a hashmap of name-value pairs of the properties. |
|
Set the task flow data control scope to shared. |
|
The task flow can be generated with either a |
|
Add custom toolbar components. |
|
Use the |
|
Set the default search criteria on the search page as it is loaded. |
|
NA. |
|
Customize the generated search task flow XML. |
|
This method returns a handle to the DOM object for the generated task flow XML. You should use DOM objects to customize generated artifacts only if there is no other way to perform the customization. |
Example 23-9 Sample getADFTablePropertiesMap Method
public HashMap getADFTablePropertiesMap()
{
HashMap propertiesMap = new HashMap(10);
propertiesMap.put("filterVisible","false");
propertiesMap.put("columnStretching","column:description");
propertiesMap.put("inlineStyle","width:100%;");
return propertiesMap;
}
If you have created customizer wrapper classes for a flexfield business component, you must create a wrapper of the default UIModelerMetadataProviderImpl implementation class for that business component. This class is in the oracle.apps.fnd.applcore.flex.uimodeler package.
Override the appropriate methods in the following list to return the names of the custom wrapper classes. For example, if you created a custom wrapper class to customize the search task flow, you would override the getSearchRegionCustomizerClassName method, as shown in Example 23-10. Override only the methods that correspond to the classes for which you have created custom wrappers. In the case of a SearchRegionCustomizerImpl custom wrapper, the method that you override depends on whether the wrapper customizes the interface search UI or the regular search UI. If the wrapper customizes the interface search UI, override the getInterfaceSearchRegionCustomizer method. Otherwise, override the getSearchRegionCustomizerClassName method.
getContextComponentCustomizerClassName
getContainerPageCustomizerClassName
getPageListCustomizerClassName
getSearchRegionCustomizerClassName
getInterfaceSearchRegionCustomizer
getSingleRowContextRegionCustomizerClassName
getMultiRowContextRegionCustomizerClassName
For the user interface modeler to use your custom wrapper classes at runtime, you must register the metadata provider class. To register the class, set the ADFUI_MODELER column for the business component's row in the FND_DF_FLEXFIELDS_B table to the name of the UIMetadataProviderImpl implementation class that you created for the business component.
You can test specified flexfields from JDeveloper using the Run with Flexfields dialog or the Debug with Flexfields dialog. You can also test the flexfields by running the application from an Integrated WebLogic Server instance. For more information, see Section 26.4, "Testing Flexfields."
You can make extensible flexfields available to web service clients and enable the clients to perform create, read, update, and delete (CRUD) operations on the flexfield data rows.
To make web service access available for an extensible flexfield, associate the flexfield usage's stub search view object with the service-backed view object for the product table that the extensible flexfield extends. Then add a SERVICE_PROCESS_CHILDREN property to the view link and create service data object (SDO) classes for the service-backed view object.
The stub search view object serves as a placeholder for resolving build time dependencies. When the flexfield is deployed, the flexfield modelers generate a view object with the same name in the MDS repository, and generates the view object's XML schema definition (XSD). Because of the name space configuration, the generated view object and XSD are picked up instead of the view object that is shipped with the application. The XSD that is generated for the stub search view object includes references to the XSD definitions for the child categories and contexts that the implementor defines at runtime. At runtime, the application uses view object polymorphism to obtain the category and context view objects that extend from the stub search view object.
Before you begin:
Ensure that a stub search view object exists for the flexfield usage. The stub search view object is in the view folder in the package that you registered for the extensible flexfield usage in the FND_DF_ADFBC_USAGES table. The name of the stub search view object begins with j_ and ends with the name of the usage's view object. You can use the following SQL statement to determine the package name and view object name for the flexfield usage.
SELECT PACKAGE_NAME, VIEW_OBJECT FROM FND_DF_ADFBC_USAGES WHERE TABLE_NAME IN (SELECT TABLE_NAME FROM FND_DF_TABLE_USAGES TBL WHERE DESCRIPTIVE_FLEXFIELD_CODE = flexfield-code AND TBL.APPLICATION_ID = application-id AND TABLE_TYPE = 'BASE' AND FLEXFIELD_USAGE_CODE = flexfield-usage-code)
Note:
The Create Flexfields Business Components wizard creates the stub search view object based on the flexfield's declarative SQL-based view object that was registered for the flexfield usage. If no declarative SQL-based view object was registered, then a stub search view object will not exist. You must create and register the SQL-based view object as described in Section 23.6.3.3, "Creating a Declarative SQL-Based View Object to Enable Searching" and then run the Create Flexfield Business Components wizard as described in Section 23.6.5, "How to Create Business Components For an Extensible Flexfield's Usage."
A service-backed view object must exist for the product table that the flexfield extends, as described in the "Creating View Objects Backed by SDO Services" section in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
To expose an extensible flexfield as a web service:
Create a view link as described in the "How to Create a Master-Detail Hierarchy for Entity-Based View Objects" section in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
On the View Objects page, in the Select Source Attribute tree expand the service-based view object in the desired package. In the Select Destination Attribute tree expand the stub search view object.
For entity-based view objects, notice that in addition to the view object attributes, relevant associations also appear in the list.
Select the primary key and CategoryCode attributes in both Source and Destination trees. Then click Add to add the association to the table that is below the trees.
Click Finish.
In the Application Navigator, double-click the view link that you just created.
In the overview editor, expand the Custom Properties section and add a SERVICE_PROCESS_CHILDREN property set to true, if one does not already exist.
Open the service-based view object.
In the overview editor click the Java navigation tab.
In the Java Classes section, click the Edit icon to generate and configure Java implementation classes.
In the Select Java Options dialog, select Generate Service Data Object Class and click OK.
The consumers of an extensible flexfield might need to programmatically access an extensible flexfield, for instance, to further process the data that has been entered for an extensible flexfield, to add additional validation, or to perform change control. The oracle.apps.fnd.applcore.flex.runtime.util.common.ExtensibleFlexfieldUtil package provides methods for obtaining the handles to the artifacts that are generated in a customer's instance.
Use the methods in oracle.apps.fnd.applcore.flex.runtime.util.common.ExtensibleFlexfieldUtil to get the names of the following Java business objects (JBOs) that are generated for an extensible flexfield:
Context entity object: Use getContextEoName, which is shown in Example 23-11.
Context view object: Use getContextVoName, which is shown in Example 23-12.
Context entity association between base and extension entity objects: Use getCategoryContextAssocName, which is shown in Example 23-13.
Context entity/view object attribute for a given segment code: Use getContextAttributeName, which is shown in Example 23-14.
Categories: Use the various methods shown in Example 23-15.
Search view object attributes: Use getSearchVoAttributeNames, which is shown in Example 23-16.
Example 23-11 Method to Get EFF Context Entity Object Name
/**
* @param appId - application id
* @param flexCode - flexfield code (e.g. EGO_ITEM_UDA)
* @param flexUsageCode - flexfield usage code (e.g. EGO_ITEM_DL)
* @param txn - DB transaction
* @param contextCode - context code (e.g Voltage)
* @param tableType - table type (e.g. EXTENSION)
* @param effGroup - eff grouping entity name (public / private)
* @return
*/
public static String getContextEoName(Long appId, String flexCode,
String flexUsageCode,
DBTransaction txn,
String contextCode,
String tableType,
String effGroup)
Example 23-12 Method to Get EFF Context View Object Name
/**
* @param appId - application id
* @param flexCode - flexfield code (e.g. EGO_ITEM_UDA)
* @param flexUsageCode - flexfield usage code (e.g. EGO_ITEM_DL)
* @param txn - DB transaction
* @param contextCode - context code (e.g Voltage)
* @param tableType - table type (e.g. EXTENSION)
* @param effGroup - eff grouping entity name (public / private)
* @return
*/
public static String getContextVoName(Long appId, String flexCode,
String flexUsageCode,
DBTransaction txn,
String contextCode,
String tableType,
String effGroup)
Example 23-13 Method to Get Name for EFF Context Entity Association Between Base and Extension Entity Objects
/**
* @param appId - application id
* @param flexCode - flexfield code (e.g. EGO_ITEM_UDA)
* @param flexUsageCode - flexfield usage code (e.g. EGO_ITEM_DL)
* @param txn - DB transaction
* @param contextCode - context code (e.g Voltage)
* @param tableType - table type (e.g. EXTENSION)
* @param effGroup - eff grouping entity name (public / private)
* @return
*/
public static String getCategoryContextAssocName(Long appId, String flexCode,
String flexUsageCode,
DBTransaction txn,
String contextCode,
String tableType,
String effGroup)
Example 23-14 Method to Get Attribute Name for EFF Context Entity/View Object Given Segment Code (FND_DF_SEGMENTS_VL.SEGMENT_CODE)
/** * Get the attribute name for the EFF context view * object / entity object given the segment code. * @param segmentCode - segment code for attribute name. * @return attribute name */ public static String getContextAttributeName(String segmentCode)
Example 23-15 EFF Category Methods
public static String getCategoryAmNameForWebServices() public static String getCategoryAmNameForDataEntry() public static String getCategoryAmNameForInterfaceGeneric() public static String getCategoryAmNameForInterfaceCategory() public static String getCategoryAmNameForSearchGeneric() public static String getCategoryAmNameForSearchCategory() public static String getCategoryVoNameForDataEntry() public static String getCategoryVoNameForWebServices() public static String getCategoryVoNameForInterfaceGeneric() public static String getCategoryVoNameForInterfaceCategory() public static String getCategoryContextViewLinkNameForInterfaceGeneric() public static String getCategoryContextViewLinkNameForInterfaceCategory() public static String getCategoryContextViewLinkNameForSearchCategory() public static String getCategoryContextViewLinkNameForSearchGeneric() public static String getCategoryContextViewLinkNameForWebService() public static String getCategoryContextViewLinkNameForDataEntry() public static void useServiceProvider() public static String getCategoryVoNameForSearchCategory() public static String getCategoryVoNameForSearchGeneric()
Example 23-16 Method to Get Hash Map of View Object Attribute Names for EFF Search View Object
/**
* Get a map of segment codes to search view object attribute names
* @param flexUsageCode - flexfield usage code (e.g. EGO_ITEM_DL)
* @param contextCode - context code (e.g Voltage)
* @param segmentCodeList - segment codes for the map.
* @return map of attribute names with key of segment codes
*/
public static HashMap<String, String> getSearchVoAttributeNames(
String flexUsageCode,
String contextCode,
ArrayList<String> segmentCodeList)
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|