| Oracle® Fusion Applications Developer's Guide 11g Release 1 (11.1.1.5) Part Number E15524-01 |
|
|
View PDF |
| Oracle® Fusion Applications Developer's Guide 11g Release 1 (11.1.1.5) Part Number E15524-01 |
|
|
View PDF |
This chapter discusses how to incorporate extensible flexfields into your application so they can access data that is represented by different organizations using different combinations of fields, and how to customize the presentation of that information to application users in a way that is most appropriate for their organizations.
This chapter includes the following sections:
Section 23.3, "Defining and Registering Extensible Flexfields"
Section 23.4, "Defining Extensible Flexfield Business Components"
Section 23.5, "Registering Extensible Flexfield Entity Details"
Section 23.6, "Employing Extensible Flexfields on an Application Page"
Section 23.8, "Accessing Information About Extensible Flexfield Business Components"
Section 23.9, "Customizing the Extensible Flexfield Runtime Business Component Modeler"
An extensible flexfield is similar to a descriptive flexfield in that it provides a customizable expansion space that customers can use to configure additional attributes (segments). 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 a child table. Individuals with the role of implementer combine and arrange the segments into different structures, based on contexts, that are tailored for the customers' specific needs. For more information about segments, structures, contexts, and participant roles, see Chapter 21, "Getting Started with Flexfields."
Extensible flexfields provide the added ability for customers to add as many context-sensitive segments to a flexfield as they need.
The process of developing an extensible flexfield and incorporating it into an application comprises several different activities, such as creating the flexfield tables, creating business components, and adding the flexfield to the appropriate application pages.
To complete the development tasks for an extensible flexfield:
Create a set of dedicated tables to contain the flexfield data. You create one set for each usage.
See Section 23.2, "Creating Extensible Flexfield Data Tables."
Register the flexfield usages.
See Section 23.3, "Defining and Registering Extensible Flexfields."
Create and configure business components to support the extensible flexfield.
See Section 23.4, "Defining Extensible Flexfield Business Components."
Register the flexfield's entity details.
See Section 23.5, "Registering Extensible Flexfield Entity Details."
Add the extensible flexfield to the appropriate application pages.
See Section 23.6, "Employing Extensible Flexfields on an Application Page."
Load any necessary application seed data, such as error messages and lookup values.
After implementing a flexfield, you can define seed or test value sets for the flexfield, and you can create a model that you can use to test it. For more information, see Section 25.1.2, "How to Test Flexfields".
Once you have completed the extensible flexfield development process and delivered your application, implementers 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 "Using Flexfields for Custom Attributes" chapter in the Oracle Fusion Applications Extensibility Guide.
To make the Manage Extensible Flexfields task flow available to application implementers, you register it with Oracle Fusion Functional Setup Manager. For more information, see Section 25.5, "Integrating Flexfield Task Flows into Oracle Fusion Functional Setup Manager".
Similar to a descriptive flexfield, an extensible flexfield is a logical grouping of attributes (segments) that are mapped to a set of extension columns, which are shipped as part of Oracle Fusion Applications tables. Unlike descriptive flexfields, these extension columns are part of extension tables, separate from the base application table.
The columns that are to be used for the flexfield segments are created at design time, but the mapping of segments to columns, how the segments are organized and associated, and which segments appear together on an application page, are determined by implementers working on behalf of the application owner. Implementers use three essential features — contexts, categories, and pages — to achieve this result. Consequently, much of the usefulness of an extensible flexfield derives from the decisions that are made during application installation and configuration. As you develop an application with extensible flexfields, you should anticipate the ways in which these features are likely to be combined.
As with descriptive flexfields, extensible flexfield segments are context-sensitive and segments are made available to an application as groups of attributes called contexts. However, with an extensible flexfield, a context can be defined as single row or multi row. Single row contexts are the same as descriptive flexfield contexts. A multi row context enables you to associate multiple sets of values with the same object instance. For example, for a BOOK table, you could create a multi row context named chapters that contains a chapter segment and a number of pages segment. Multiple chapters can then be associated with each book in the BOOK table.
Implementers can associate any combination of contexts with a given category. A category is a grouping of related data items that can be considered to belong together.
A category hierarchy logically organizes a set of categories. For example, the Electronics and Computers category hierarchy might include a Computer category and a Home Entertainment category, which in turn might include an Audio category and a TV category, and so on.
A new category can be added to an extensible flexfield as a child or a sibling of an existing category. The hierarchy can be as simple or as complex as desired, with any combination of zero or more sibling categories and zero or more child categories. If no category is defined, the data items are grouped under a single predefined default category.
Each category has associated contexts that store relevant information about a data item in that category. For example, a Home Entertainment product has contexts that specify Voltage, Dimensions, Inputs and Outputs. Contexts are reusable within a given extensible flexfield; the Dimensions context can be assigned to any category that needs to include dimensional information.
If a hierarchy includes child categories, each child category inherits the contexts from its parent category; for example, the Home Entertainment category inherits Voltage and Dimensions from the Electronics and Computers category.
Each extensible flexfield is associated with a particular category hierarchy. You can think of category hierarchies as the defining framework for extensible flexfields and their contexts. A category hierarchy specifies which contexts are valid for each category.
An extensible flexfield can include multiple contexts which are defined by implementers to support a given category. These contexts can be suitable for a variety of different purposes, but within a particular category, some contexts might be considered to be related to, or dependent on, each other. Implementers can combine these contexts into groups known as pages, which serve to connect the contexts so they will always be presented together in the application user interface.
For example, the Home Entertainment category might have an Electrical Specifications page that contains the Voltage, Inputs and Outputs contexts, and a Physical Specifications page that contains the Dimensions and Form Factor contexts.
As with descriptive flexfields, you can define multiple usages for an extensible flexfield, which enables several application tables to share the same flexfield. For example, a flexfield for shipping options can be used by both a Supplier table and a Buyer table. In addition, extensible flexfields give implementers the flexibility to associate a context with one, some, or all of the flexfield's usages. Thus, with the shipping information example, an implementer can associate a warehouse context with the Supplier usage, a delivery location context with the Buyer usage, and a ship-via context with all usages.
Extensible flexfields let you satisfy different groups of users without having to reprogram your application by generating application pages based entirely on the extensible flexfield structure and configuration as determined by the application implementer or administrator. These also enable context-sensitive fields that appear only when needed. In essence, an extensible flexfield enables the automatic creation of pages based on its segments for the purposes of input (data modification) or searching (data querying).
One of the elements of the extensible flexfield framework is the user interface modeler. At runtime, the user interface modeler engine reads the metadata that the application implementer has defined by configuring categories, contexts, and flexfield pages, and builds application pages based on the categories and their associated contexts. The pages have data bindings to the business components that the business component modeler produces.
The flexfield segments are presented as a set of fields on the page, much like the fields of the core application. Each application page corresponds to one extensible flexfield category, with a separate region of the page for each associated context.
For example, suppose you have a retail application that keeps track of customers. Your customers form would normally include fields such as Name, Address, State, Customer Number, and so on. However, your page might not include extra fields to keep track of customer clothing size and color preferences, or regular salesperson, since these are attributes of the customer entity that depend on how your users use your application. If your retail application is used for a tool company, a field for clothing size would be undesirable. Even if you initially provide all the fields that your users need, they might later identify even more customer attributes that they want to keep track of. You can add an extensible flexfield to your application so it has the desired expansion space. They can also take advantage of the fact that extensible flexfields are entirely context sensitive, where the information your application stores depends on other values your users enter in other parts of the application.
You could use an extensible flexfield in a fixed assets application that you build to allow further description of a fixed asset. You could let the structure of your assets flexfield depend on the value of an asset type field. For example, if asset type were "desk", your extensible flexfield could prompt for style, size and wood type. If asset type were "computer", your extensible flexfield could prompt for CPU chip and memory size.
An extensible flexfield describes an application entity, with the runtime ability to expand the database that implementers can use to define the data structure that appears in the application.
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. In a polymorphic collection, each view row can have its own set of attributes, and all rows have at least one common attribute, the discriminator. The discriminator determines which view row type should be used. Given a collection of polymorphic view rows, each row can be a different type.
The attribute sets associated with the discriminator are predefined. In fact, the Oracle Application Development Framework enables each view row to have its own view definition. When a polymorphic collection is created, the framework selects a view definition for the row to be added based on the value of the discriminator attribute.
Flexfields use a context switching mechanism similar to that of polymorphic view objects. A flexfield polymorphic view object is created based on the extensible flexfield definition produced by the implementer, then a view link is created to connect the product view object to the flexfield view object. The view object is then used to add the flexfield to an application page.
For more information about polymorphic view rows, see the "Working with Polymorphic View Rows" section in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
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.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 a base table, a translation table, and a view of the translation table. You must have at least one set of tables, which defines the master usage. The implementing organization exposes only the flexfield attribute columns that it requires.
Use the Database Schema Deployment Framework tools to create, for each usage of the extensible flexfield, a base table, a translation table, and a view of the translation table. For more information about using the framework tools, see Chapter 56, "Using the Database Schema Deployment Framework."
The base table columns are listed in Table 23-1, the translation table columns are listed in Table 23-2, and the view columns are listed in Table 23-3.
Note:
To avoid any compatibility and interoperability problems, you should format the column names as indicated.The number of attribute columns of each type as shown in Table 23-1 is not mandatory. You can increase or decrease the quantities as you see fit to accommodate the purpose of the flexfield. The number of columns shown in the specifications should be adequate for most implementations.
Table 23-1 Extensible Flexfield Base Table (_B) Specification
| Column | Type | Nullable? |
|---|---|---|
|
|
|
No |
|
|
|
No |
|
Primary key columns of the application table for which this extensible flexfield is being defined. |
Same as the column in the application. |
No |
|
|
|
No |
|
|
|
No |
|
|
|
No |
|
|
|
No |
|
|
|
No |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
There should be one VARCHAR2 type attribute column in the translation table for each corresponding attribute column, such as ATTRIBUTE_CHAR1, in the base table.
Table 23-2 Extensible Flexfield Translation Table (_TL) Specification
| Column | Type | Nullable? |
|---|---|---|
|
|
|
No |
|
|
|
No |
|
Primary key columns of the application table for which this extensible flexfield is being defined. |
Same as the column in the application. |
No |
|
|
|
No |
|
|
|
No |
|
|
|
No |
|
|
|
No |
|
|
|
No |
|
|
|
Yes |
|
|
|
No |
|
|
|
No |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
The view should contain the same set of VARCHAR2 type attribute columns as the translation table.
Table 23-3 Extensible Flexfield View (_VL) Specification
| Column | Type | Nullable? |
|---|---|---|
|
|
|
No |
|
Primary key columns of the application table for which this extensible flexfield is being defined. |
Same as the column in the application. |
No |
|
|
|
No |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
After you create a set of dedicated tables for a flexfield's usage, you use procedures from the FND_FLEX_DF_SETUP_APIS PL/SQL package to register the flexfield usage and define its metadata in seed tables.
The definition of an extensible flexfield usage includes the following information:
The logical name of the flexfield.
The name of the database table containing the columns to be used as flexfield segments.
The names of the database table columns 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.
The name of the custom modeler in fnd_df_flexfields_b.ADFBC_MODELER.
Flexfield usage information, including Oracle Metadata Service (MDS) root packages for usages — the name of the root package for all business components that model the flexfield. Each usage can have its own package name.
After the implementers 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 (if any) belonging to the extensible flexfield, and the contexts associated with each category, page and usage.
Validation rules associated with the segments. Each segment (global or context-sensitive) can have its own LOV or validation rules.
You 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 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 application base table name for which the flexfield is implemented and set the table type to BASE. Also add the usage base table name with a type of EXTENSION, and add the usage translation table name with a type of EXTENSION_TL. Set the table usage code to the flexfield's usage code.
If the consumers want to support interface loading of extensible flexfield data, also 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 forth.
FND_EF_CATEGORIES_B
An exensible flexfield requires at least one entry in this table. Add additional entries only if you are shipping your application with some categories already defined.
After you create the flexfield's business components, you complete the registration process by adding entity details, as described in Section 23.5.1, "How to Register Extensible Flexfield Entity Details."
For more information, refer to the package specification.
To incorporate an extensible flexfield into your application, you must define and configure entity objects, view objects, and an application module for each set of database tables that are defined for each flexfield usage.
To define an extensible flexfield business component:
Create and configure extensible flexfield entity objects over the base table, the translation table, and the 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 searching.
Configure an application module for each extensible field usage.
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 25.4, "Regenerating Flexfield Business Components Programmatically."
For each extensible flexfield usage, you must create entity objects over the base table, the translation table, and the view.
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
adf-config.xml and the flexfield metadata).Before you begin:
Create one set of dedicated flexfield tables per usage, as described in Section 23.2.1, "How to Create Extensible Flexfield Database Tables."
Register the flexfield's usages as described in Section 23.3.1, "How to Register Extensible Flexfields."
Ensure that the Applications Core library has been added to the data model project.
Verify that at least one customization class is included in adf-config.xml. 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 each extensible flexfield usage, use the standard wizard to create an entity object over the base table that is described in Table 23-1, but apply the changes described in the following procedure to support the extensible flexfield.
To create and configure an entity object over the extensible flexfield base 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 application table
CONTEXT_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 unique 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 oracle.apps.fnd.applcore.oaext.model.OAEntityImpl.
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.
For each extensible flexfield usage, use the standard wizard to create an entity object over the translation table that is described in Table 23-2, but apply the changes described in the following procedure to support the extensible flexfield.
To create and configure an entity object over the extensible flexfield translation 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 application table
CONTEXT_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 unique 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 oracle.apps.fnd.applcore.oaext.model.OAEntityImpl.
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 not of type String to be translatable.
On the Applications tab of the Property Inspector for each non-key, non-String type attribute, set the OA Translatable property to True.
For each extensible flexfield usage, use the standard wizard to create an entity object over the view that is described in Table 23-3, but apply the changes described in the following procedure to support the extensible flexfield.
To create and configure an entity object over the extensible flexfield 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 application table
CONTEXT_CODE
On the Attribute Settings page, do the following:
Set the EFF_LINE_ID attribute to be a unique 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 oracle.apps.fnd.applcore.oaext.model.OAEntityImpl.
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.
For all of your extensible flexfield entity objects, you must configure the EFF_LINE_ID attribute as a unique ID.
The Unique ID Generator provides a way for your application to generate unique IDs for entity object attributes of type BigDecimal. The unique IDs generated are also of type BigDecimal, and meet certain required criteria for uniqueness across database instances.
Before you Begin:
Create and configure entity objects over the base table, translation table, and view as described in Section 23.4.1, "How to Create and Configure Extensible Flexfield Entity Objects."
To configure EFF_LINE_ID as a unique ID:
Create a connection to the database that contains the Unique ID Generator table called S_ROW_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 standard 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 over the flexfield base table entity object and one view object over the flexfield view entity object.
Note:
No view objects are required over the translation table entity object.To support categories for the flexfield, create a view object over the application base table entity object for which you are developing this extensible flexfield.
To support searching, create declarative view objects.
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.
Before you begin:
Create and configure entity objects over the base table, translation table, and view as described in Section 23.4.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.4.2, "How to Configure the EFF_LINE_ID Attribute as a Unique ID."
To support contexts for an extensible field usage, the usage must have a view object over its base table entity object and a view object over its view entity object.
To create and configure the context view objects:
Create the view objects over the extensible flexfield base table entity object and view entity object in the normal manner.
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 over the application base table entity object for which you are developing the extensible flexfield.
To create and configure the category view object:
Create the view object over the application base table for which you are implementing the extensible flexfield in the normal manner.
This view object must include an attribute called CategoryCode, which will be used to identify the category to which each row of data belongs. This attribute can be entity-based, SQL-derived, or a transient attribute.
Set the CategoryCode attribute to be a discriminator, with a default value of 0.
If the implementing organization will define any categories for this flexfield, you must ensure that the correct category code is returned for this attribute at runtime.
Implement the following interface on the Java tab of the view object definition:
oracle.apps.fnd.applcore.oaext.model.EFFCategoryViewObjectInterface
Create a method called queryCategoryRowByPrimaryKey that will take in up to five primary key values and return the correct row of the product view object as demonstrated in Example 23-1.
For this example, the view object has a view criteria defined called getItemByKey, and bind parameters defined for two primary key attributes, called OrganizationIdBind and InventoryItemIdBind.
Example 23-1 Query Category Row Method
public Row queryCategoryRowByPrimaryKey(
String pk1, String pk2, String pk3,
String pk4, String pk5)
{
Long invId = new Long (pk1);
Long orgId = new Long (pk2);
setWhereClauseParams(null);
applyViewCriteria(null);
ViewCriteria vc = getViewCriteria("getItemByKey");
setNamedWhereClauseParam("OrganizationIdBind", orgId);
setNamedWhereClauseParam("InventoryItemIdBind", invId);
applyViewCriteria(vc);
executeQuery();
Row r = null;
if(hasNext())
{
r = next();
setCurrentRow(r);
}
return r;
}
This method queries the correct category row based on up to five primary key values passed into the method.
To enable searching, there must be a declarative view object for searching over the application base table for which you are implementing the extensible flexfield.
To create declarative view objects for searching:
Create the declarative view object in the normal manner.
On the Java page, confirm that the objectnameVOImpl view object class to be generated extends the following class:
oracle.apps.fnd.applcore.oaext.model.EFFCategoryViewObjectImpl
The EFFCategoryViewObjectImpl class adds the additional WHERE clause that provides security.
To enable application pages that contain a flexfield usage to display the flexfield's segments, you must configure an application module to support that flexfield usage.
You can use the application module that you have already created for your application, or you can use the standard wizard to create a new application module dedicated to your extensible flexfield.
To the application module's Java client interface, add a method called createDetailRowIfNotExist, as shown in Example 23-2.
Example 23-2 Java Source for createDetailRowIfNotExist Method
public void createDetailRowIfNotExist(
String categoryAMInstName, String categoryViewUsageName,
String contextViewLinkAccName, String category_pk1,
String category_pk2, String category_pk3,
String category_pk4, String category_pk5)
{
EffCategoryAMImpl effAM = (EffCategoryAMImpl)
findApplicationModule(categoryAMInstName);
effAM.createDetailRowIfNotExist(
categoryViewUsageName, contextViewLinkAccName,
category_pk1, category_pk2, category_pk3,
category_pk4, category_pk5);
}
At implementation, the extensible flexfield runtime business component modeler creates a personalization on this application module, and generates an application module instance for each category that the implementer defines.
To complete the registration process, you provide the names of the flexfield's entity object and view object, as well as the name of the entity object over the translation table.
You use procedures from the FND_FLEX_DF_SETUP_APIS PL/SQL package to register the flexfield entity details. For information about using the procedures, refer to the package specification.
Before you begin:
Create one set of dedicated flexfield tables per usage, as described in Section 23.2.1, "How to Create Extensible Flexfield Database Tables."
Register the flexfield's usages as described in Section 23.3.1, "How to Register Extensible Flexfields."
Create and configure business components to support the extensible flexfield as described in Section 23.4, "Defining Extensible Flexfield Business Components."
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 FND_DF_TABLE_USAGES, specify the name of the entity object and view object. For the translation table, also specify the name of the entity object over the translation table.
If the consumers 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-1 shows example entries for a flexfield usage. As described in Section 23.3.1, "How to Register Extensible Flexfields," the FND_DF_TABLE_USAGES table contains rows for the application base table (USGA_BASE), the usage base table (USGA_EFF_B), and the usage translation 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 usage translation table also name the entity object over the translation table. Note that not all columns are shown.
Note:
In this example, the Public group is necessary because the consuming product 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 can incorporate an extensible flexfield into an application with several user interface variations:
As a list of the extensible flexfield pages for a single usage, combined with the contexts for the selected page, and integrated into a single task flow.
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 a single task flow that presents a set of contexts associated with a specified extensible flexfield page, which will be identified before the application page initializes.
As a single task flow that presents a context, which will be identified before the application page initializes.
Note:
When it is not clear what type of data will be seeded 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 editable data. 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 incorporate an extensible flexfield into an application as a list of the extensible flexfield pages for a single usage, combined with the contexts for the selected page, and integrated into a single task flow.
To expose the pages and contexts that are associated with one extensible flexfield usage:
Create a task flow for the single extensible flexfield usage, which includes an application page fragment with a splitter that contains the list of the usage's extensible flexfield pages on the left, and the contexts associated with the selected flexfield page on the right.
Add the task flow to the page.
Render the page.
Create a task flow to be added to the page that will display the page lists and contexts.
Before you begin:
Create and configure business components to support the extensible flexfield as described in Section 23.4, "Defining Extensible Flexfield Business Components."
Register the entity details as described in Section 23.5.1, "How to Register Extensible Flexfield Entity Details."
To create the task flow:
Create a task flow with a default view activity pointing to a fragment.
Add an EffCategoryPagesBean managed bean with the class oracle.apps.fnd.applcore.flex.eff.runtime.EffCategoryPagesBean to the task flow. The scope should be pageFlow.
Open the fragment and drag and drop a splitter control.
On the first facet, drag and drop the EffCatPageListContainer seeded task flow from the ViewController FlexModeler-View library.
Add 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.EffCategoryPagesBean}
Do the same for the Context Container Page 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.EffCategoryPagesBean}
_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
Add the task flow for the extensible flexfield usage to the page that will display the page lists and contexts.
Before you begin:
Create the task flow for the extensible usage as described in Section 23.6.1.1, "Creating a Task Flow for a Single Extensible Flexfield Usage."
To add the task flow to the page:
Open the JSPX page that will display the page lists and contexts.
Drop the task flow on the page.
Render the page to view the user interface.
Before you begin:
Add the task flow for the extensible usage to the page as described in Section 23.6.1.2, "Adding the Task Flow to the Page."
Obtain the flexfield usage's package name from the FND_DF_ADFBC_USAGES.PACKAGE_NAME column.
To render the page:
Open the Databindings.cpx file for the project that is consuming the generated extensible flexfield task flows and add the 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"/>
Complete the following steps to mark the flexfield usage's package directory as a flexfield model package:
Create an inf directory in the flexfield usage's package directory. For example, if the usage's package is oracle.apps.fnd.applcore.crmdemo.flex, then create the /oracle/apps/fnd/applcore/crmdemo/flex/inf directory.
To identify the package directory as a flexfield model package, create a file named FlexfieldPkgInf.xml in the package's inf directory and add the following contents to the file.
<?xml version="1.0" encoding="UTF-8" ?> <flexfield-inf/>
Note:
Ensure that this directory only contains the automatically generated flexfield MDS files and theinf directory with the FlexfieldPkgInf.xml file. When you deploy the application, the ANT script that is run by the deployment process will add the required name spaces for the identified package directory to the adf-config file, as shown in the following example.
<namespace path="/persdef" metadata-store-usage="mdsRepos"/> <namespace path="/oracle/apps/scm/productCatalogManagement/items/protectedModel/itemRevisionEff"metadata-store-usage="mdsRepos"/> <namespace path="oracle/apps/scm/productCatalogManagement/"items/protectedModel/itemsEffmetadata-store-usage="mdsRepos"/>
Complete the following steps to identify the flexfield user interface packages:
Either create a WAR deployment profile in the project that is named FlexfieldViewController and that contains flexfield user interface packages, or reference the flexfield user interface packages through a library JAR file. Do not include this deployment profile in the application EAR file. This is just a marker profile.
Find the flexfield user interface package directory under the ViewController/public_html directory and add an inf subdirectory to the flexfield user interface package directory.
To identify the package directory as a flexfield user interface package, create a file named FlexfieldViewPkgInf.xml in the package's inf directory and add the following contents to the file.
<?xml version="1.0" encoding="UTF-8" ?> <flexfield-inf/>
Note:
The package directory will be added to theadf-config file and thus only should contain the automatically generated flexfield MDS files and the inf directory with this file.
Do not repeat these steps for the corresponding pageDefs packages under Application Sources. Those packages are added automatically when the flexfield is deployed.
Add the following snippet to the Application tag at the top of Databindings.cpx in order for the application to find the page definitions for the generated user interface artifacts:
PageMapClass="oracle.jbo.uicli.mom.DynamicPageMapImpl"
BasePageDefPackageName="pageDefs"
Deploy and run your application to render the page.
To expose the complete set of usages, pages, and associated contexts, build an application page comprised of a splitter with two task flows: one containing the list of extensible flexfield usages and their associated flexfield pages on the left, and the other containing the contexts associated with the selected flexfield page on the right.
To build the application 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 page.
The page requires two task flows: one containing the list of extensible flexfield usages and their associated flexfield pages, and the other containing the contexts associated with the selected flexfield page.
Before you begin:
Create and configure business components to support the extensible flexfield as described in Section 23.4, "Defining Extensible Flexfield Business Components."
Register the flexfield's entity details as described in Section 23.5.1, "How to Register Extensible Flexfield Entity Details."
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 to the task flow similar to the one in Step 2.
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.6.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 Flex-View library to the page list fragment using the parameters listed in Section 23.6.1.1, "Creating a Task Flow for a Single Extensible Flexfield Usage," with the exception that the value for _eff_containerBean should be pageFlowScope.ContainerBean instead of pageFlowScope.EffCategoryPagesBean.
Add the EffContextsPageContainer seeded task flow from the ViewController Flex-View library to the context page fragment using the parameters described in Section 23.6.1.1, "Creating a Task Flow for a Single Extensible Flexfield Usage," with the exception that the value for _eff_containerBean should be pageFlowScope.ContainerBean instead of pageFlowScope.EffCategoryPagesBean.
Drag and drop the page list fragment to the page-list task flow and the context page fragment in the context task flow.
Use the task flows that you just created in Section 23.6.1.1, "Creating a Task Flow for a Single Extensible Flexfield Usage" to add the usage and context lists to the page.
Before you begin:
Create the page list task flow and context container task flow as described in Section 23.6.2.1, "Creating the Task Flows."
Create the left and right fragment pages PageListFrag.jsff and ContextPageFrag.jsff as described in Section 23.6.2.2, "Creating the Fragments."
To use the task flows in the page:
Open the page and add the splitter.
Add the pageList and ContextPage 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.
Follow the steps listed in Section 23.6.1.3, "Rendering the Page" to view the user interface.
You can incorporate an extensible flexfield into an application as a single task flow that presents a set of contexts associated with a specified extensible flexfield page, which will be identified before the application page initializes.
To expose one extensible flexfield page and its contexts, build an application page including a splitter with a single task flow as a dynamic region on the right, containing the contexts associated with a selected flexfield page. This variation does not present an extensible flexfield usage or page list task flow in the user interface.
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.4, "Defining Extensible Flexfield Business Components."
Provide the seed metadata necessary to support the extensible flexfield in the appropriate global tables as described in Section 23.5.1, "How to Register Extensible Flexfield Entity Details."
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 put the EffCatPageListContainer on the fragment using the parameters described in previous sections.
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 4 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 snippet, 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 provides the call back and the conditions for the refresh of the contexts region.
Follow the steps listed in Section 23.6.1.3, "Rendering the Page" to view the user interface.
When you run the page and click on the page link, the call back to refreshRegion will look up the contexts task flow ID and enable a refresh of the dynamic region.
Any implementation of flexfields in Oracle Fusion Applications typically requires application seed data, which is the essential data to enable 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.3.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 the role of the implementer. In addition to the registration data, your flexfield seed data might include contexts, segments, and value sets that you have defined for your flexfield.
For information about extracting and loading seed data, see Chapter 55, "Initializing Oracle Fusion Application Data Using the Seed Data Loader".
The consumers of an extensible flexfield might need to programmatically access an extensible flexfield, such as 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.
You can use the APIs in oracle.apps.fnd.applcore.flex.runtime.util.common.ExtensibleFlexfieldUtil to get the names of the following generated extensible flexfield Java business objects (JBOs):
Context entity object: Use getContextEoName, which is shown in Example 23-3.
Context view object: Use getContextVoName, which is shown in Example 23-4.
Context entity association between base and extension entity objects: Use getCategoryContextAssocName, which is shown in Example 23-5.
Context entity/view object attribute for a given segment code: Use getContextAttributeName, which is shown in Example 23-6.
Categories: Use the various APIs shown in Example 23-7.
Search view object attributes: Use getSearchVoAttributeNames, which is shown in Example 23-8.
Example 23-3 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-4 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-5 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-6 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-7 EFF Category APIs
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-8 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)
Teams can customize the extensible flexfields base business component modeler and user interface modeler to add additional product-specific logic.
To extend the extensible flexfield runtime business component modeler, override the EFFBCModelerFactory.getCustomEFFBCModeler method, shown in Example 23-9, in the custom extensible flexfield runtime business component modeler factory.
Example 23-9 getCustomEFFBCModeler Method
/**
* Implementing teams need to override this method and provide the
* custom BC Modeler here (e.g. 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-10.
Example 23-10 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);
}
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|