| 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 describes how to create searchable objects in Oracle Fusion Applications.
This chapter includes the following sections:
Searchable objects are sets of data that make view objects available for full text search. They are used in an abstract way for exposing business data to search engines. For example, a purchase order as a searchable object would be defined as a set of searchable properties and its relationship to other searchable objects. Business data can be both structured and unstructured, such as data residing in a database, file attachments (including images), and documents.
The abstraction allows searchable objects to be bound to different contexts at runtime and to be described and used within that context. Since the binding information describes how a searchable object behaves in a given context, it is sometimes called search metadata.
To create searchable object, you must perform the following tasks:
Define the searchable objects and searchable attributes
(Optional) Enable the capability to crawl searchable objects with file attachments. For more information, see Section 31.2, "Enabling Search on Fusion File Attachments".
(Optional) Enable the capability to crawl searchable objects with Oracle WebCenter tags. For more information, see Section 31.3, "Enabling Search on WebCenter Tags".
Secure the searchable objects
Configure the search features
Configure the custom properties for the searchable objects
Oracle Enterprise Crawl and Search Framework is used to integrate search functionality in Oracle Fusion Applications by defining searchable objects and its attributes. Defining the searchable objects enables the corresponding view objects and its attributes for search and creates the necessary metadata for ECSF. The ECSF metadata can be packaged into an application archive and subsequently be used by ECSF runtime to deploy data sources into Oracle Secure Enterprise Search (Oracle SES) to perform crawling and index operations. All artifacts (for example, Java archive files, Oracle Application Development Framework objects, and so on), on which the view objects depend, must be packaged in the enterprise archive (EAR) file in order to make the searchable objects usable during runtime for both crawl and query.
Note:
You can also package ECSF metadata into metadata archive (MAR) files.Consider the following when you define searchable objects and searchable attributes:
Rather than reuse or functionally overload view objects designed for other purposes, construct view objects (parent and children) for search purposes (that is, only include attributes you intend to search).
Exclude locator objects (LOB) from searchable objects unless you intend to search LOB contents.
Restrict the use of multilevel view objects to 5 levels to avoid causing severe feed performance degradation.
Co-locate all servers (for example, ECSF, Oracle SES, database, and so on) and follow standard performance, scalability, and reliability network performance guidelines to minimize network latency between servers.
Feed throughput is directly proportional to the amount of data that is pulled from the database to be indexed.
Be selective with the searchable objects to ensure that only a limited portion of data from the primary table is crawled to maximize crawling and indexing performance.
Attachments (Oracle Content Management or LOBs) require record by record processing, and every record requires one additional network round-trip.
Store attributes only when necessary. Attributes stored in Oracle SES should be for only the following purposes:
Faceted navigation
Advanced search
Search result actions
Primary keys
If the value of an attribute needs to be searchable, place it in the body of the searchable object.
Use common attributes across Oracle Fusion Applications. Stored attributes common to all the searchable objects must share the same name and data type. For information about preventing conflicts, see Section 27.2.10, "What You May Need to Know about Preventing Search Attribute Naming Conflicts".
Use the default security plug-in (oracle.ecsf.impl.DefaultSearchPlugin) as much as possible. Use of the default security plug-in ensures that the searchable objects are secured properly.
Set the data type for stored attributes correctly and avoid conflicting attribute names.
Determine the appropriate incremental crawl approach for your searchable object. Initial crawl refers to the first time data is crawled and indexed into a search engine. During initial crawl, all data intended to be crawled is sent to the search engine. All subsequent crawls are incremental crawls. During incremental crawls, only data that has been added or modified since the last crawl are sent to the search engine for indexing.
ECSF supports two mechanisms to identify newly added or modified data. You must choose and implement at least one of the following mechanisms:
Configuring the Crawl Date Column searchable attribute property. For information, see Section 27.2.6.1, "Making View Object Attributes Searchable".
Raising change events. For information, see Section 31.7, "Raising Change Events Synchronously".
If neither mechanism is implemented, the data that has been added or modified since the initial crawl will not be indexed, and therefore will not be searchable.
To define searchable objects and searchable attributes, use the Search navigation tab of the overview editor in Oracle JDeveloper to complete the following tasks:
Make view objects searchable.
Make view object attributes searchable.
Note:
You must choose the Oracle Fusion Applications Customization role when you launch JDeveloper.You can also switch to the Oracle Fusion Applications Customization role from within JDeveloper by selecting Tools > Preferences > Roles from the main menu and restarting JDeveloper.
Before you begin:
Before you can define searchable objects, you must be familiar with the following:
Oracle JDeveloper and Oracle Application Development Framework technology, and understand how to build applications using entity objects, view objects, and view links. For information, see Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
How view objects are used in ECSF. For more information, see the "Managing Search with Oracle Enterprise Crawl and Search Framework" chapter in the Oracle Fusion Applications Administrator's Guide.
How to use Groovy expressions when defining search metadata. For information, see Section 27.2.1, "How to Use Groovy Expressions in ECSF".
ECSF indexes data based on a view object, which represents the top level view object to crawl. Many business objects are hierarchical, and ECSF leverages Oracle Application Development Framework's (Oracle ADF) methods of describing such hierarchies by using view links. ECSF supports multiple levels of a view hierarchy. By defining additional view objects and linking the top level view object to the additional view objects through a view link, parent, child, grandchild, and so on relationships are formed. Once a view link is set, you can reference data in those successive objects for indexing by using Groovy, a Java-like scripting language that is dynamically compiled and evaluated at runtime.
Note:
When you design your view object for search, make sure that you configure view links to generate only the Destination Accessor and not the Source Accessor.When querying for root records during crawl time, ECSF also traverses the view link accessors to query child view objects. ECSF follows the parent view link accessors until it reaches the limit for the number of view accessor levels to be crawled. The default limit is set to 5 levels. If a parent view object has a view link accessor to its child view object, and the child view object also has a view link accessor pointing back to the parent view object, then the code cycles. It is not necessary to index the data in both parent and child view objects. When creating a view link object in Oracle JDeveloper, generate the view link accessors in either end of the view link. Only generate the view link accessor in the parent view object and not in the child view object.
When defining search metadata, Groovy expressions are used to reference the attributes of view objects and the attributes of their child, grandchild, and so on view objects so that the attribute (string) values can be added into the ECSF index. You are required to enter Groovy expressions for fields such as Title, Body, and Keyword.
You can also use Groovy expressions to localize ECSF. For information, see Section 31.9, "Localizing ECSF Artifacts".
Groovy expressions can reference view object attributes (voAttrName) as variables. For example, you can enter the following Groovy expression in the Title field:
"Purchase Order " + RowId + " created for " + Customer + " on " + CreatedDate
Note:
View object attribute names are case sensitive.If the value for RowId is "1234", the value for Customer is "ABC Inc", and the value for CreatedDate is "1/1/2007", then a search would return the title value:
Purchase Order 1234 created for ABC Inc on 1/1/2007
The ECSF runtime code parses, then evaluates the expressions in the context of a view object, and returns the title with values for the variables.
Note:
To reference a stored view object attribute whose alias corresponds with an Oracle SES default search attribute (for example,
Language), you must make sure to change the alias of the view object attribute to something other than any name of the Oracle SES default search attributes (for example, use alias Lang, instead of Language). Changing the alias prevents conflicts between Oracle SES and ECSF stored view object attributes. Alternatively, you can create view object transient attributes and reference them in the expressions. For more information, see Section 27.2.9, "What You May Need to Know about Preventing Conflicts with Oracle SES Default Search Attributes".Groovy expressions can also reference child view object attributes (viewLinkAccessorName.voAttrName) as variables by using the view link accessor names to access child attributes.
For example, you can enter the following Groovy expression in the Title field:
"Product Codes: " + ProductsView.ProdCode
Note:
View object attribute names are case sensitive.If the view object represented by the ProductsView view link accessor contains one record, and the value of its ProdCode attribute is 1XYZ, then a search would return the title value:
Product Codes: 1XYZ
If a child view object referenced by an expression contains more than one record, then the values of all the child records are concatenated together. For example, if the ProductsView view link accessor contains three records, and the values of its ProdCode attribute are 1XYZ, 2ABC, and 3STU, then a search would return the title value:
Product Codes: 1XYZ 2ABC 3STU.
The view link accessor name for a child view object is available on the view link that points to the child view object. The name of the view link accessor is the Destination value. In Figure 27-1, which shows the accessors information on the Relationship navigation tab of the view link editor, the name of the view link accessor is ZipLov.
You can also find the name of view link accessors in the <ViewLinkAccessor> tags of the XML source mode of the view object.
Alternatively, you can use the curdoc keyword to access the current document, as shown in Example 27-1.
Example 27-1 Using curdoc to Access Child Documents and Their Attributes
s = "";
if (curdoc.getChildDocs("ProductsView") != null)
{
for (d in curdoc.getChildDocs("ProductsView"))
{
s = s + d.attributes.ProdCode + " ";
}
};
"Product Codes: " + s;
The curdoc keyword is used to access child documents and their attributes.
Groovy expressions can also reference view object attributes (viewLinkAccessorName.voAttrName, viewLinkAccessorName.viewLinkAccessorName.voAttrName, and so on) in searchable objects with a multilevel structure.
By default, the view link depth is set to 5. To index fewer or more than five levels of data in the view hierarchy, you must set the oracle.ecsf.max.links.depth property in system properties to the desired value. Figure 27-2 illustrates a searchable object with a 5 level structure.
The figure shows a representation of the PurchaseOrder searchable object with 5 levels.
Using Groovy expressions in the search metadata, you can access attributes in PO Line Detail, Line Item Product, and Product Doc. For example, you can enter the following Groovy expression in the Title field:
POLine.LineDetail.AttributeX + POLine.LineDetail.LineProduct.AttributeY + POLine.LineDetail.LineProduct.ProductDoc.AttributeZ
If a grandchild view object referenced by an expression contains more than one record, then the values of all the grandchild records are concatenated together. For example, if you reference view object attributes with viewLinkAccessorName.viewLinkAccessorName.voAttrName, the result of the expression POLine.LineDetail.AttributeX is the concatenation of all AttributeX values for the LineDetail of all POLines of the current PurchaseOrder.
When writing Groovy expressions, it can be useful to generate strings that contain formatted versions of view object attribute values. For example, you may want to generate formatted strings such as "01/30/07" or "Jan 30, 2007" for an attribute value of type java.sql.Date.
To format attribute values you must first determine the Java data types. The data types of view object attributes can vary. For example, some attributes may return simple strings, while others may return java.sql.Date, java.sql.Timestamp, or numbers like java.lang.Long.
One way to determine the types is to write a test Groovy expression that displays the type names. For example, if the view object has an attribute called Hiredate, then you can use the Groovy expression, as shown in Example 27-2, in the Body field.
Example 27-2 Sample Groovy Expression to Determine Attribute's Java Data Type
'Hiredate type: ' + (Hiredate != null ? Hiredate.getClass().getName() : 'null');
The class name of the Hiredate attribute's value is displayed and can be viewed in the Data Feed:
Hiredate type: java.sql.Date.
Once you determine the Java data type of a view object attribute, you can apply standard Java formatting techniques to format its value. Example 27-3 shows a sample Groovy expression for formatting a date.
Example 27-3 Sample Groovy Expression for Formatting Dates
fmt = new java.text.SimpleDateFormat('MM/dd/yyyy'); // create a date formatter (standard java class)
'Hire date: ' + fmt.format(Hiredate);
The Groovy expression evaluates to:
Hire date: 01/30/2007
To format a number attribute named Qty of data type java.lang.Long using comma separators, write a Groovy expression, such as the one shown in Example 27-4.
Example 27-4 Sample Groovy Expression for Formatting Numbers
fmt = new java.text.DecimalFormat('#,###,###');
'Quantity: ' + fmt.format(Qty);
The Groovy expression evaluates to:
Quantity: 2,450
The Groovy expressions are compiled and evaluated at runtime to display the desired string value in the crawl data feeds.
Use the Search page of the overview editor in JDeveloper, as shown in Figure 27-3, to set search property values for view objects.
Note:
The Search page is not editable if the view object or existing searchable object is read-only.Make view objects searchable by setting search property values for them.
Caution:
Do not modify the Oracle Fusion Applications Help searchable object named
TopicSearchPVO.To set search property values for view objects:
In the overview editor, select the Search navigation tab.
Complete the Primary Table field by doing one of the following:
If the view object is based on an entity object, then select a value from the Primary Table dropdown menu.
If the view object is not based on an entity object, then enter the schema, table name, and table alias for the primary table. Use the format DATABASE_SCHEMA.TABLENAME TABLE_ALIAS_NAME (for example, fusion.Emp Employee).
You can either type directly in the text box or use the Select Primary Table dialog. For more information, see Section 27.2.3.2, "Using the Select Primary Table Dialog".
Note:
The table alias name you enter must match the table alias name used in the view object's SQL statement. You can view the SQL statement by selecting the view object's Query tab.In the Title field, enter a Groovy expression to be evaluated to a string for the desired title of the search result. For more information, see Section 27.2.1, "How to Use Groovy Expressions in ECSF".
The Title field allows for multiple lines of text.
You can also click the Edit icon to open the Edit Expression Editor, where you can enter Groovy expressions for the desired title of the search result. Click OK to save.
Note:
Do not include attributes of type Character Large Object (CLOB) or Binary Large Object (BLOB) in the Groovy expressions for the Title, Body, and Keywords fields, or you will receive an error. All columns with type CLOB or BLOB in a view object or its child view objects are processed as Oracle SES attachments.In the Body field, enter Groovy expressions to provide additional information on the search results. This appears below the title. For more information, see Section 27.2.1, "How to Use Groovy Expressions in ECSF".
You can also click the Edit icon to open the Edit Expression Editor, where you can enter Groovy expressions for the desired title of the search result. Click OK to save.
In the Keywords field, enter the keywords in the form of Groovy expressions. For more information, see Section 27.2.1, "How to Use Groovy Expressions in ECSF".
You can also click the Edit icon to open the Edit Expression Editor, where you can enter Groovy expressions for the desired title of the search result. Click OK to save.
The values of the keywords are evaluated at crawl time using Groovy, and sent to Oracle SES as part of the document for indexing. Once indexed, the values of the keywords are searchable for the document with which they are associated.
Select the desired view object attribute from the Language Attribute dropdown menu to specify the language of this view object record. If the object has no language attribute, leave it blank.
Note:
Currently, ECSF provides a way for you to specify whether an attribute is a language field. ECSF will assume that the value of this field for each instance is the language for this instance. ECSF initially supports the Oracle Fusion Applications language code. If no language field is specified for a given searchable object, ECSF uses the language preference of the crawler user.Complete the Search PlugIn field by using the Search PlugIn dialog. For more information, see Section 27.2.3.3, "Using the Search PlugIn Dialog".
Save the view object.
Note:
In order to save the changes made to the Primary Table, Title, Body, and Keywords fields, you must move the focus from those attributes (that is, click outside each field as you complete them).Note:
If the view object is open in JDeveloper when you update the corresponding searchable object file (view_object_name_ECSF.xml), you must close and reopen the view object to view the updates.Use the Select Primary Table dialog to specify the primary table for the searchable object if the view object is not based on an entity object.
To use the Select Primary Table dialog
From the Search navigation tab, click the Edit icon next to the Primary Table field.
The Select Primary Table dialog appears, as shown in Figure 27-4.
Select the desired schema from the Database Schema dropdown menu.
With the Tables checkbox selected in the Object Type field, click Query to list the available tables.
Select the desired table name from the list under Available Objects.
Type an alias for the primary table in the Table Alias field.
Note:
The table alias entered must match the table alias used in the view object's SQL statement. You can view the SQL statement by selecting the view object's Query tab.Click OK.
Note:
You must select a primary table from the Available Objects list in order to save.ECSF provides an extension model to allow you to extend ECSF functionality. Implement a search extension to implement any number of the following Java interfaces to extend or customize ECSF functionality:
oracle.ecsf.Securable, used to implement a security extension.
oracle.ecsf.PreIndexProcessor, used to customize or manipulate data before it is sent to the search engine for indexing, such as for enabling advanced search on child objects (that is, attribute filtering).
oracle.ecsf.PostQueryProcessor, used to customize results before search results are returned.
Use the Search PlugIn dialog to specify the extension you wish to use for the searchable object.
Note:
If you do not specify a search extension for your searchable object, then the default security extension is used. The default security extension requires you to identify a secure attribute. For information, see Section 27.2.6.1, "Making View Object Attributes Searchable".Note:
If the search extension is in the Oracle WebLogic Server shared library, then the ECSF library (
ecsf.jar) must be present in the shared library in order for ECSF to load the interface.To use the Search PlugIn dialog:
From the Search navigation tab, click the Edit icon next to the Search PlugIn field.
The Search PlugIn dialog appears, as shown in Figure 27-5.
In the PlugIn Class Name field, enter the name of the custom Java class that implements the methods to determine security and resolve the URL.
Note:
If there is no plug-in defined in the searchable object, and you are not using a custom security extension, then this value is null and by default is set to
oracle.ecsf.impl.DefaultSearchPlugin which is used at runtime.If desired, enter a parameter name in the Parameter Name field and its corresponding value in the Value field, then click Add.
To update an existing parameter, select the desired parameter in the table, change its value, then click Update.
To delete an existing parameter, select the desired parameter in the table and click Delete.
Click OK to save.
JDeveloper captures the search metadata for each view object and writes it to an external XML file (searchable object) for consumption by the runtime component. Each searchable object corresponds to a view object. The file naming convention is view_object_name_ECSF.xml, and the file is created in the same location as its corresponding view object.
Note:
Manually deleting an ECSF file removes the search functionality from the corresponding view object.Caution:
Do not manually modify the contents of theview_object_name_ECSF.xml file. If you manually modify the search metadata in the XML file, the changes appear in the editor window when it is closed and reopened in JDeveloper, but metadata changes are not validated. Instead, use the Search navigation tab of the overview editor in JDeveloper to modify the search metadata.ECSF metadata can be packaged into an EAR file or a MAR file for consumption during crawl time and query time.
The searchable object reflects any change in the search metadata only after you save the view object. Until then, the changes are in memory. When you save the view object, the search metadata is saved to the searchable object. If there is no existing searchable object corresponding to the view object, then a new searchable object is created and stored in the same location as the view object.
In addition, if you rename or delete a view object with a corresponding searchable object, then the searchable object is likewise renamed or removed from the project.
Making view object attributes searchable creates the necessary metadata for:
Advanced search
Faceted navigation
Security
Search result actions
Note:
The more attributes you make searchable, the larger the index becomes, which slows the performance of the queries.Use the Search page of the overview editor in JDeveloper, shown in Figure 27-6, to set property values for view object attributes.
Using the Search page, you can perform the following tasks on view object attributes:
Make view object attributes searchable.
Modify searchable attributes.
Delete searchable attributes.
Make view object attributes searchable by setting search property values for them.
To set search property values for view object attributes:
In the overview editor, select the Search navigation tab.
Click the Add icon in the Searchable Attributes table header to open the Searchable Attribute Properties dialog, shown in Figure 27-7.
Select the desired view object attribute from the Attribute Name dropdown menu.
Complete the remaining fields to define the property set for the searchable attribute. For information about the searchable attribute properties, see Table 27-1.
Note:
Before creating new stored attributes, check the list of Oracle SES attribute names and types to avoid conflicts. See Oracle Fusion Applications Reference for Oracle SES Attributes.Table 27-1 Searchable Attribute Properties
| Property | Description |
|---|---|
|
Stored |
Select this checkbox to store the view object attribute in Oracle SES as a separate custom search attribute. The view object attribute's Alias property will be used as the name of the custom search attribute. The Alias property can be updated and renamed to avoid name and type conflicts. See Section 27.2.10, "What You May Need to Know about Preventing Search Attribute Naming Conflicts." Attributes stored in Oracle SES are used for Advanced Search, Actionable Results, and Faceted Navigation. For more information, see Section 27.4.1, "How to Define Search Result Actions"and Section 27.4.4, "How to Implement Faceted Navigation". Selecting this checkbox enables the Weight field. |
|
Secure Attribute |
Select this checkbox to use the attribute's value to secure the document at crawl time and to determine which users can access the indexed object at query time. |
|
Crawl Date Column |
Select this checkbox to enable the crawler to detect changes to the searchable object based on the date column. You must be able to reference the Crawl Date Column in a SQL predicate for ECSF to detect added or changed data. During incremental crawls, scheduled using either the Fusion Applications Control for ECSF or ECSF Command Line Administration Utility, only objects that have been modified since the last crawl are sent to Oracle SES. If Crawl Date Column is specified for multiple searchable attributes, then all the date columns are used in the SQL query to retrieve data that has been modified since the last crawl. The SQL query uses the OR condition to get the incremental set of data. For example, if the Crawl Date Column checkbox is selected for Select * from EMP where (CREATED_DATE between LAST_CRAWL_TIME and CURRENT_TIME) or (LAST_UPDATE_DATE between LAST_CRAWL_TIME and CURRENT_TIME) |
|
Weight |
This field is enabled only when you select the Stored checkbox. Enter a value 1 to 10 (low to high), or select from the dropdown menu, to attach a weight to the stored attribute. Weights affect the ranking of the search results. If the weight is set to 1, the stored attribute gets no boost. If the weight is set to 2 or 3, the stored attribute gets very low boost (added to custom attribute Headline2). If the weight is set to 4 or 5, the stored attribute gets low boost (added to custom attribute Headline1).If the weight is set to 6 or higher, the stored attribute gets high boost (added to custom attribute Reference Text). |
Note:
Only stored and secured view object attributes are available for advanced search (that is, the Stored and Secure Attribute checkboxes are selected).Click OK.
Save the view object.
Note:
If the view object is open in JDeveloper when you update the corresponding searchable object file (
view_object_name_ECSF.xml), you must close and reopen the view object to view the updates.Modify a searchable attribute by editing the search property values for the view object attribute.
To edit search property values for view object attributes:
In the overview editor, select the Search navigation tab.
Expand the Searchable Attributes table header to expose the table of searchable attributes.
Select the searchable attribute you want to modify. This highlights the entire row.
Click the Edit icon in the Searchable Attributes table header to open the Searchable Attribute Properties dialog, shown in Figure 27-7.
The attribute you selected on the Search navigation tab is displayed in the Attribute Name field.
Select or deselect the checkboxes to modify the property set for the searchable attribute. For information about the searchable attribute properties, see Table 27-1.
Click OK.
Save the view object.
Deleting the searchable attributes removes the search metadata for the view object attribute.
To delete searchable attributes:
In the overview editor, select the Search navigation tab.
Expand the Searchable Attributes table header to expose the table of searchable attributes.
Select the searchable attribute you want to remove. This highlights the entire row.
Click the Delete (red X) icon in the Searchable Attributes table header.
The attribute you selected on the Search navigation tab is removed from the table of searchable attributes.
Save the view object.
JDeveloper captures the search metadata for each view object, including its attributes, and writes it to an external XML file (searchable object) for consumption by the runtime component. Each searchable object corresponds to a view object and includes the view object attributes. The file naming convention is view_object_name_ECSF.xml, and the file is created in the same location as its corresponding view object.
During crawl time, the ECSF runtime server uses the view attributes that are annotated for search to construct documents for indexing.
Caution:
Do not manually modify the contents of theview_object_name_ECSF.xml file. If you manually modify the search metadata in the XML file, the changes appear in the editor window when it is closed and reopened in JDeveloper, but metadata changes are not validated. Instead, use the Search navigation tab of the overview editor in JDeveloper to modify the search metadata.ECSF implicitly adds the following attributes to Oracle SES indexes:
ECSF_SO_NAME. This attribute stores the fully qualified searchable object name that corresponds to the searchable object on which the Oracle SES data source is based.
ECSF_TAGS. This attribute is created if Oracle WebCenter tags are associated with the searchable object. For information, see Section 31.3, "Enabling Search on WebCenter Tags".
DEFAULT_ACL_KEY. ECSF uses this attribute to store access control list (ACL) keys for the document.
The searchable object reflects any change in the search metadata only after you save the view object. Until then, the changes are in memory. When you save the view object, the search metadata is saved to the searchable object. If there is no existing searchable object corresponding to the view object, then a new searchable object is created and stored in the same location as the view object.
In addition, if you rename or delete a view object with a corresponding searchable object, then the searchable object is likewise renamed or removed from the project.
Note:
Manually deleting an attribute that has a corresponding search attribute from a view object causes unexpected search results.Oracle SES supports system-defined default search attributes that may conflict with ECSF stored view object attributes. For example, for Purchase Order 123 you define a stored view object attribute with the alias Language and value US. However, Oracle SES contains a default search attribute also named Language, but it has en as its value. When you reference the view object attribute in a Groovy expression, such as when you define a search result action of URL type where target="http://example.com/q=dj&lang="+Language, you expect the search result action to display as http://example.com/q=dj&lang=US.
However, the search result action displays as http://example.com/q=dj&lang=en because the Oracle SES default search attribute value overrides the value of the ECSF stored view object attribute of the same name.
Note:
The attribute conflict does not consider case. For example, a conflict still occurs if the stored view object attribute's alias isLANGUAGE (all caps) and the Oracle SES default search attribute name is Language.Following are the Oracle SES default search attributes:
Author
Description
Headline1
Headline2
Headline3
Host
Infosource
Infosource Path
Keywords
Language
LastModifiedDate
Mimetype
Reference Text
Subject
Title
Url
Urldepth
Author, LastModifiedDate, and Subject are the exceptions, and can be used to enhance usability of the Oracle SES UI and to decrease the number of custom attributes in Oracle SES.
To prevent a conflict between Oracle SES default search attributes and ECSF stored view object attributes, you can either change the alias of the stored view object attribute to something other than any name of the Oracle SES default search attributes, or you can create a view object transient attribute and set it as a stored attribute, then reference the transient attribute in the expressions.
To resolve the conflict in the given example, you can change the alias value of the Language view object attribute from Language (default) to Lang. The view object attribute alias is used to retrieve the value of the view object attribute in expressions.
Alternatively, you can resolve the conflict by creating a view object transient attribute, such as one named Lang, and use it in the expressions (for example, target="http://example.com/q=dj&lang="+Lang). By default, when the values of transient attributes are sent to Oracle SES, ECSF assigns the transient attribute a unique alias. When their values return as part of query results, they won't conflict with any default search attributes in Oracle SES. When expressions containing transient attributes are evaluated, ECSF converts the transient attribute names to the aliases and retrieves the data correctly.
Because Oracle SES only supports facets on attributes of type STRING, if a facet is defined on a non-string attribute ECSF automatically converts the stored attribute type to a string before sending the attribute to Oracle SES.
However, a conflict may occur when a stored attribute of the same name is generated for a view object with no facets. Searchable attributes in Oracle SES are unique across the entire instance, so if multiple searchable objects contain the same attribute name of different types, then only the attribute (regardless of type) of the first searchable object crawled is used by Oracle SES. Take the following example:
You create a view object oracle.apps.crm.cutomer360.CustomerPVO with a set of attributes and types that are based on the underlying tables that use the Oracle ADF standard UI. The view object attribute contains the following information stored as Oracle ADF metadata:
| Attribute Name | Attribute Alias | Attribute Type |
|---|---|---|
Name |
NAME |
VARCHAR2 |
OrganizationId |
ORGANIZATION_ID |
NUMBER |
Description |
DESCRIPTION |
VARCHAR2 |
You use the Search Designer to annotate a subset of these attributes (Name and OrganizationId) to store in Oracle SES for search purposes.
When Oracle SES crawls oracle.apps.crm.cutomer360.CustomerPVO, ECSF sends a document for each customer in the table. Each document contains the following attribute details:
| Attribute Alias | Attribute Type |
|---|---|
NAME |
VARCHAR2 |
ORGANIZATION_ID |
NUMBER |
In Oracle SES, NAME and ORGANIZATION_ID are created as customer attributes with the respective types. Due to the global nature of custom attributes in Oracle SES, if an attribute of the same name already exists, no new attribute is created even if its type is different. Values for the attributes with conflicting name and type pairs are not stored in Oracle SES.
The issue surfaces when ORGANIZATION_ID is used as a facet (to enable users to narrow down the results per organization tree). ECSF implements a logic that detects if an attribute is used for a facet or not. If it is used for a facet, ECSF automatically changes the attribute type from NUMBER to VARCHAR2 because Oracle SES does not support facets on attributes with type NUMBER. This causes a conflict with the already existing ORGANIZATION_ID stored attribute of type NUMBER.
To prevent this conflict and allow Oracle SES to index both attributes, you must change the alias of the stored attribute that is used for facets. Navigate to the JDeveloper ADF view object attribute editor and update the Alias property value, as shown in Figure 27-8. For example, in the view object attribute editor, change the Alias value from PARTY_ID to PARTY_ID_FACET.
Before creating new stored attributes, check the list of Oracle SES attribute names and types to avoid conflicts. See Oracle Fusion Applications Reference for Oracle SES Attributes.
ECSF determines if a user has access to a search category depending on whether or not the user has permission to access the searchable objects in the category. Search categories, also called search groups, are the logical collections of searchable objects that facilitate group search on related items. Search categories are directly used for querying. If all of the searchable objects in a search category are not accessible to the user, then that category does not appear in the user's category list. In this case, ECSF runtime does not return that category when SearchCtrl.getSearchGroups() is called. However, if any one of the searchable objects in a search category is accessible to the user, then that category does appear in the user's category list.
To secure searchable objects:
Set permissions for searchable objects
Create the security realm
Create the application policy store
Set permissions for searchable objects by using the Search PlugIn dialog to enter the permissions parameters. For information, see Section 27.2.3.3, "Using the Search PlugIn Dialog".
To set permissions for searchable objects:
In the PlugIn Class Name field, enter the name of the custom Java class that implements the methods to determine security. If you are not using a custom security extension, enter oracle.ecsf.impl.DefaultSearchPlugin.
Add the following parameter names and values, and click Add for each name and value pair:
Parameter Name: FUNCTION_PERMISSION_NAME
Value: PURCHASE_ORDER_VIEW_DETAILS
Parameter Name: FUNCTION_PERMISSION_ACTION
Value: view
Parameter Name: FUNCTION_PERMISSION_CLASS
Value: RegionPermission
Note:
The value of
FUNCTION_PERMISSION_NAME and FUNCTION_PERMISSION_ACTION must be the same as the value of the permission name and action in the jazn-data.xml file.Click OK.
The parameters are used to validate permissions in the ECSF security classes. Searchable objects with no permissions set are accessible by all users.
The user in the security realm is deployed to the Oracle WebLogic Server security realm. Add a jazn.com realm to jazn-data.xml.
To add a security realm:
Expand Application Resources > Descriptors > META-INF, and open the jazn-data.xml file.
Select Identity Store, and click New to add a new realm. Name it jazn.com.
Navigate to jazn.com > Users, and click Add to add a user with the following information:
Name: scott
Credentials: weblogic
The jazn-data.xml file is updated with the security realm, as shown in Example 27-5.
Example 27-5 jazn.com Security Realm
<jazn-realm default="jazn.com">
<realm>
<name>jazn.com</name>
<users>
<user>
<name>scott</name>
<credentials>{903}O/XvB3XDx97MYp4sUSWwT3Q5KPLIEciA</credentials>
</user>
</users>
</realm>
</jazn-realm>
The user Scott is associated to the jazn.com security realm.
Save.
The policy store is used to determined which users have access to which objects. Add an application policy store to jazn-data.xml.
To add an application policy store:
Expand Application Resources > Descriptors > META-INF, and open the jazn-data.xml file.
Select Application Policy Store, and click New to add a new policy store. Enter TestPermission for the display name.
Select Application Roles, and click Add to add a new role. Name it admin.
Select Application Roles, and shuttle the user scott from the Available section to the Selected section.
Select Application Policies, and click New to add a new policy. Enter View Orders for the display name.
Select the View Orders application policy, go to the Principals tab, and click Add to add a principal with the following information:
Name: admin
Class: oracle.security.jps.service.policystore.ApplicationRole
Type: role
Leave the Realm Name field blank.
Go to the Permissions tab, and click Add to add a permission with the following information:
Name: PURCHASE_ORDER_VIEW_DETAILS
Class: oracle.adf.share.security.authorization.RegionPermission
Actions: view
The jazn-data.xml file is updated with the application policy store, as shown in Example 27-6.
Example 27-6 Application Policy Store
<policy-store>
<applications>
<application>
<name>TestPermission</name>
<app-roles>
<app-role>
<name>admin</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<name>scott</name>
<class>oracle.security.jps.internal.core.principals.JpsXmlUserImpl</class>
</member>
</members>
</app-role>
</app-roles>
<jazn-policy>
<grant>
<grantee>
<display-name>
View Orders
</display-name>
<principals>
<principal>
<type>
role
</type>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>admin</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.share.security.authorization.RegionPermission</class>
<name>PURCHASE_ORDER_VIEW_DETAILS</name>
<actions>view</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
The application policy store includes the values that you specified.
In addition to basic and advanced search, ECSF allows you to further improve the search experience with the Actionable Results and Faceted Navigation search features, which you must configure.
Note:
No configuration is required for integrating Saved Search functionality.To configure search features, you can complete the following tasks:
Define search result actions.
Implement faceted navigation.
Associating actions with the searchable objects and exposing the action links in the search results allows Oracle Fusion Applications users to run specific actions on a given search result. You can either define actions as URLs so the user can then either go to a specific web page related to the search result, or define actions as references to ADF task flow definitions so the user can then launch a specific task on the search result. For more information, see Section 14.2.3, "How to Add Dynamic Main Area and Regional Area Task Flows to a Page". Figure 27-9 illustrates an example of the results of a filtered search.
Clicking the title (default action URL) opens the Sonoma - Elites page. An additional action link allows the user to e-mail the owner.
You can perform the following tasks to define search result actions:
Add search result actions.
Modify search result actions.
Delete search result actions.
Use the Search navigation tab of the overview editor in JDeveloper, shown in Figure 27-3, to define actions for search results.
To define search result actions for Oracle Fusion Applications Search, you must complete additional configuration tasks. For information, see Section 14.15.6, "How to Use the Actionable Results API with Oracle Fusion Applications Search".
During runtime, the Access URL allows Oracle SES and the end user to access the applications from the Query page. The Access URL contains the view object name, the row's primary keys, and the action name, the values of which are used to look up the action definition, query for the record, evaluate action parameters, and construct target URLs. The Access URL also points to the Redirect Service.
The Redirect Service is used for resolving URLs and redirecting users to the resolved URL. Invoking the Redirect Service improves performance when attributes referenced in the action definition not stored in the index.
The redirect logic includes the following steps following a request:
Use the view object name and action name to look up the action definition.
Use the primary key values to query for the row in the database.
Attribute values are obtained from search attributes. If an action refers to unstored attributes, primary keys are used to obtain their values during redirect.
Construct an indexable document from the row.
Resolve the URL.
For task action type:
Look up the task and construct a TaskFlowID.
Look up the task parameters, if there are any.
For each task parameter, evaluate the parameter value by passing the field and value map and the expression into an evaluator, add it to the resolved parameters list, then construct the URL using the same ControllerContext.getTaskFlowURL API.
For URL action type:
Evaluate the parameterized URL by passing the field/value map and the expression into an evaluator.
Redirect the user to the resolved URL.
Add search result actions to associate actions to searchable objects. The action links you define display with the search results.
To add search result actions:
In the overview editor, select the Search navigation tab.
Click the Add icon in the Search Result Actions table header to open the Search Result Actions dialog, shown in Figure 27-10.
In the Name field, enter a name for the action.
Note:
No two actions can share the same name. This comparison is case insensitive.From the Action Type dropdown menu, select Task (default) to specify a task to be performed on the search result or select URL to specify a web page.
Note:
Only bounded task flows can be launched through the URL mechanism.Perform one of the following:
If you chose URL for Action Type in Step 4, then in the Action Target field, define the action by entering a Groovy expression that generates the URL that is invoked when the user clicks the action.
For URLs that point to an external site, you must configure the target expression to generate a fully qualified URL, which includes both the protocol (such as http://) and the host name (for example, example.com).
For internal link URLs that point to pages on the same application from which the search is performed, configure the target expression to generate a relative URL (for example, "/EmployeeDetailPage?empId=" + EmpId). Relative URLs are invoked relative to the current host name and port number. This allows for the action to succeed on any application server on which the search is running.
You can also click the Edit icon next to the Action Target field to use the Edit Expression Editor dialog for entering the Groovy expression. For more information, see Section 27.2.1, "How to Use Groovy Expressions in ECSF".
The URL must be no longer than 32,000 in length. You can reference only stored attributes. For example, you can enter "http://www.example.com/search?hl=en&q=" + SRCompanyZip.
Caution:
Using unstored attributes results in an exception at query time when the action is resolved. Also, do not refer to child documents when defining the action definition.If you chose Task for Action Type in Step 4, then leave the Action Target field blank. However, you must define the TaskName and TaskFile properties in the Action definition. For information, see Section 27.4.1.4, "Defining Properties for Bounded Task Flows".
In the Title field, enter a Groovy expression to be evaluated to a string for the desired display title of the action as you would like it to appear on the Search Results page. For more information, see Section 27.2.1, "How to Use Groovy Expressions in ECSF".
You can also click the Edit icon next to the Title field to use the Edit Expression Editor dialog for entering a Groovy expression.
Select the Default Action checkbox to make this action the default action to be performed on the search results.
Note:
You can set only one action as the default action.For tasks, enter a parameter name in the Parameter Name field and its corresponding value in the Value field, then click Add.
Enter parameter values as Groovy expressions. You can use only stored attributes (for example, SRNumber) as parameters.
Note:
Using unstored attributes results in an exception at query time when the action is resolved. Also, do not refer to child documents when defining the action definition.You can also click the Edit icon next to the Value field to use the Edit Expression Editor dialog for entering a Groovy expression.
Minimally, the TaskName and TaskFile parameters must be provided. The value of the TaskName parameter is a Groovy expression that returns the name of the task (that is, a name surrounded by double quotation marks). The value of the TaskFile parameter is a Groovy expression that returns the name of the task definition file. Values of other parameters are Groovy expressions that return the desired value. These parameters are passed into the task. For more information, see Section 27.2.1, "How to Use Groovy Expressions in ECSF".
To update an existing parameter, select the desired parameter in the table, change its value, then click Update.
To delete an existing parameter, select the desired parameter in the table and click Delete.
Click OK.
To create additional search result actions, repeat Steps 2 to 11.
Save the view object.
For bounded task flows, you must define the TaskName and TaskFile properties in the Action definition of the searchable object file (view_object_name_ECSF.xml). The task definition file, containing the value for TaskName, is usually located in the WEB-INF folder.
Edit the TaskFile parameter to point to the bounded task flow task definition XML file, located in the WEB-INF folder. For example, \WEB-INF\filename.
To define the TaskName and TaskFile properties:
Locate the task definition file and note its location and filename, for example, \WEB-INF\task-flow-definition.xml.
Open the task definition file, locate the <task-flow-definition> element, for example, <task-flow-definition id='task-flow-definition'> and note the value of the id attribute.
Open the searchable object file and locate the TaskFile parameter, then edit the value to reflect the location and filename of the task definition file, for example, \WEB-INF\task-flow-definition.xml.
Locate the TaskName parameter and edit the value to reflect the id attribute value of the <task-flow-definition> element of the task definition file, for example, 'task-flow-definition'.
Save the searchable object file.
You can modify search result actions as needed to change the action links that display with the search results.
To modify search result actions:
In the overview editor, select the Search navigation tab.
Expand the Search Result Actions table header to expose the table of actions.
Select the action you want to modify. This highlights the entire row.
Click the Edit icon in the Search Result Actions table header to open the Search Result Actions dialog, shown in Figure 27-10.
The information of the action you selected is displayed.
Make the necessary changes to the desired fields. For more information about the fields, see Section 27.4.1.3, "Adding Search Result Actions".
Note:
You must recrawl the data if you reference a new attribute that is marked as stored.Click OK.
Save the view object.
You can delete search result actions to remove action links that display with the search results.
To delete search result actions:
In the overview editor, select the Search navigation tab.
Expand the Search Result Actions table header to expose the table of actions.
Select the action you want to delete. This highlights the entire row.
Click the Delete (red X) icon in the Search Result Actions table header.
The action you selected on the Search navigation tab is removed from the table of actions.
Save the view object.
JDeveloper captures the search metadata for each view object, including the search result actions you define, and writes it to an external XML file (searchable object) for consumption by the runtime component. Each searchable object corresponds to a view object and includes the search result actions. The file naming convention is view_object_name_ECSF.xml, and the file is created in the same location as its corresponding view object.
Caution:
Do not manually modify the contents of the
view_object_name_ECSF.xml file. If you manually modify the search metadata in the XML file, the changes appear in the editor window when it is closed and reopened in JDeveloper, but metadata changes are not validated. Instead, use the Search page of the overview editor in JDeveloper to modify the search metadata.The search result actions you define during design time is parsed at runtime and appear in a table on the search results page.
The Name, Action Type, Action Target, and Title fields are required fields. You must input values for all three fields in order to save the action.
Facets are used to filter search results by attribute. A facet must point to an attribute that contains a list of values (LOV) definition. The LOV defines a way to get a list of values that make up the potential values for the attribute and can be used to filter results. To implement faceted navigation, you must perform the following tasks:
Create a searchable object and set it up for facets:
Create a view object (base object) and identify the attributes you want to bind to facets.
Create a view object (LOV object) for each of the attributes you identified in Step 1a to get a list of available values for the attributes.
Create a view accessor on the base object for each LOV object to be used as a facet, and assign each LOV object to its corresponding attribute.
Define the facet hierarchy. Since the faceted navigation path is hierarchical, you must form the structure so that the LOV objects form one facet definition. For each LOV object to be used as child, create a bind variable and view criteria.
While defining the facet hierarchy, you can constrain the LOV object by the stored attribute.
Create the facets.
To better illustrate the process of defining LOVs for facets, consider the following scenario: You want to create facet relationships for the EmpView base object. EmpView contains two stored attributes, StateID and CityID, on which you want to create facets. "City" is the child facet of "State." The values shown in the "City" facet is constrained by the value selected for "State." This scenario is used in the tasks listed in this section.
You can also configure stored transient attributes on the view object to define:
Facets that support number or date ranges.
Facets based on the values of multiple attributes.
For more information, see the "Working with List of Values (LOV) in View Object Attributes" section in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
Defining LOVs for stored view object attributes creates facet relationships for the base object and its stored attributes. The following procedure uses the example of the EmpView base object and its two stored attributes, StateID and CityID.
To define list of values for stored view object attributes:
Define a view object (StatesView) to represent a list of values for a view attribute (StateID).
Define a view accessor for StatesView (StatesView1) on EmpView.
The view accessor lets you obtain the full list of possible values from the row set of the parent view object.
Note:
When you design your view object for search, make sure that you configure view links to generate only the Destination Accessor and not the Source Accessor.In the Edit Attribute dialog for the stored attribute (StateID), select List of Values and select Enable List of Values.
Create a mapping from a child attribute to the stored attribute.
Values from the child attribute are used to filter the parent view object.
Specify which attribute on the view object contains the display value.
In the Attribute Editor, select List of Values and select Edit List UI Hints.
In the List UI Hints dialog, add a child attribute to display. The first attribute value is used as the display value.
Repeat Steps 1 to 5 to define a view object (CitiesView) to represent the stored attribute that is defined as the child facet.
Constraining the CitiesView object by StateID makes sure that only the cities of the selected state are returned. Configure the CitiesView1 view accessor on EmpView so that the view criteria on CitiesView is applied when the user queries using CitiesView1. Based on the view criteria, only cities where its parent StateId is equal to the value of EmpView.StateId (that is, the currently selected state) is returned.
To constrain CitiesView by State:
Define a bind variable on CitiesView (StId).
Create a named view criteria (CitiesViewCriteria) on CitiesView.
On the View Criteria page of the View Criteria Editor dialog, click the Add Item button.
In the Criteria Items panel, define the criteria as follows:
Attribute: ParStateId
Operator: equal to
Operand: Bind Variable
Parameter: StId
Usage: Required
Click the Edit button to edit the view accessor (CitiesView1) for CitiesView on EmpView.
In the Edit View Accessor dialog, select the view criteria (CitiesViewCriteria) in the Available list and click the Move icon to add it to the Selected list, as shown in Figure 27-11.
Map the StId bind variable on CitiesView to the StateId attribute of EmpView.
Ensure that the row-level bind values exist.
Faceted navigation allows Oracle Fusion Applications users to narrow their search results by setting filters, based on a set of predefined facets. For example, users can narrow their search results first by country, then by state, and then by city.
Search facets follow a tree structure. The root facet appears above the tree control, followed by child facets. All facets contain a name and an attribute, and can contain a child facet.
Note:
If you require both custom SQL query and facets for a view object, you must create the view object with the Updateable object through entity objects option and select Expert for Query Mode on the Query page.You can define facets by creating search facets, modifying search facets, deleting root search facets, and deleting child search facets. Use the Search navigation tab of the overview editor in JDeveloper, shown in Figure 27-3, to define facets for faceted navigation.
You can create search facets to specify the root facet, facet name, an attribute, and child facets. Use the Facets dialog to add search facets.
Before you begin:
Define LOVs for stored view object attributes. For information, see Section 27.4.4.1, "Defining Lists of Values".
To add search facets:
In the overview editor, select the Search navigation tab.
Click the Add icon in the Facets table header to open the Facets dialog, shown in Figure 27-12.
In the Facet field, enter a valid facet name for the root facet.
Note:
No two facets can share the same name at the searchable object level. This comparison is case insensitive.Click the icon next to the Facet Display Name field to open and use the Select Text Resource dialog for selecting a text resource from an existing resource bundle, or for creating and selecting a new text resource. For more information, see Section 27.4.4.4, "Using the Select Text Resource Dialog to Select a Matching Text Resource" or Section 27.4.4.5, "Using the Select Text Resource Dialog to Create and Select a New Text Resource".
Note:
If no facet display name is specified, the label text of the view attribute corresponding to the facet is used as the display name. If there is no label text, then the view attribute name is used as the display name.You can use resource bundles to localize ECSF. For information, see Section 31.9, "Localizing ECSF Artifacts".
From the Attribute Name dropdown menu, select a searchable attribute for the root facet.
Note:
The Attribute Name dropdown menu lists only the searchable attributes whose
isStored property is set to true. For information, see Section 27.2.6.1, "Making View Object Attributes Searchable".
No two facets can share the same attribute at the searchable object level.
To add a child facet, click Add Facet.
The new child facet is inserted below the selected facet in the tree structure. Any existing child facets are moved below it to the next level down in the structure.
Enter a name for the child facet in the Facet field.
Note:
No two facets can share the same name. This comparison is case insensitive.Select an attribute for the child facet from the Attribute Name dropdown menu.
Note:
No two facets can share the same attribute.Repeat Steps 5-7 to add more child facets.
Click OK.
Save the view object.
Use the Select Text Resource dialog to select a text resource from an existing resource bundle.
To select a matching text resource:
From the Facets dialog, click the icon next to the Facet Display Name field to open the Select Text Resource dialog.
Select a resource bundle from the Resource Bundle dropdown menu.
Note:
If there is no resource bundle associated with the view object, then an external resource bundle is created in the application. Save the new resource bundle externally.Enter values in the Display Value, Key, and Description fields to narrow down the list of matching text resources.
Select the desired text resource in the Matching Text Resources table.
Click Select. Click the Clear Selection button to clear your selection.
Use the Select Text Resource dialog to create and select a new text resource.
To create and select a new text resource:
From the Facets dialog, click the icon next to the Facet Display Name field to open the Select Text Resource dialog.
Select a resource bundle from the Resource Bundle dropdown menu.
Note:
If there is no resource bundle associated with the view object, then an external resource bundle is created in the application. Save the new resource bundle externally.In the Display Value field, enter a string or any type of object to associate with the key in the page's resource bundle.
In the Key field, enter a string to uniquely identify a locale-specific object in the resource bundle.
In the Description field, enter a description of any length for the key and value pair.
Click Save and Select.
You can modify existing search facets by changing the values of the facet attribute fields, adding child facets, or deleting child facets. Use the Facets dialog to modify search facets.
To modify search facets:
In the overview editor, select the Search navigation tab.
Expand the Facets table header to expose the table of root facets.
Select the root facet you want to modify. This highlights the entire row.
Click the Edit icon in the Facets table header to open the Facets dialog, shown in Figure 27-12.
In the tree structure, select the facet you want to modify.
Make your desired changes:
Change the values of the Facet Attributes fields. For more information about the fields, see Section 27.4.4.3, "Creating Search Facets".
Add child facets. For more information, see Section 27.4.4.3, "Creating Search Facets".
Delete child facets. For more information, see Section 27.4.4.8, "Deleting Child Search Facets".
Click OK.
Save the view object.
You can delete root search facets to remove them from the table on the Search navigation tab.
To delete root search facets:
In the overview editor, select the Search navigation tab.
Expand the Facets table header to expose the table of root facets.
Select the root facet you want to remove. This highlights the entire row.
Click the Delete (red X) icon in the Facets table header.
The root facet you selected on the Search navigation tab is removed from the table of root facets.
Save the view object.
You can delete child search facets to remove them from the facet tree.
To delete child search facets:
In the overview editor, select the Search navigation tab.
Expand the Facets table header to expose the table of root facets.
Select the root facet you want to modify. This highlights the entire row.
Click the Edit icon in the Facets table header to open the Facets dialog, shown in Figure 27-12.
In the tree structure, select the facet you want to delete.
Click Delete.
Click Yes, when prompted with "Are you sure you want to delete the facets?"
The facet you selected is removed from the tree.
Click OK.
Save the view object.
You can define facets to support ranges for numbers and dates.
To define facets that support ranges
Configure on the view object a transient attribute that summarizes the numeric or date attribute value into a range code. For example, create a transient attribute named AmountRange that contains the following Groovy expression for the number attribute:
if (Amount > 0 && Amount < 100) 'Range1'; else if (Amount >= 100 && Amount < 200) 'Range2'; else 'Range3';
For a date attribute, you can create a transient attribute named HireDate that contains the following Groovy expression:
if (Hiredate.getYear() >= 80 && Hiredate.getYear() < 90) '80s'; else if (Hiredate.getYear() >= 91 && Hiredate.getYear() < 100) '90s'; else '2000s';
Define a static LOV with the range codes and display values.
Associate the LOV to the transient attribute.
Create a facet with the transient attribute in the facet definition.
You can define facets that are based on the values of multiple attributes. For example, Project Status=Active if Status is not Closed AND Start Date is after Today.
To define facets that support ranges
Configure on the view object a transient attribute to classify a record into some code. For example, create a transient attribute named Status that contains the following Groovy expression for the number attribute:
if (Status == 'Active' && Closed != null) 'Active'; else 'Inactive';
Define a static LOV with the codes and display values.
Associate the LOV to the transient attribute.
Create a facet with the transient attribute in the facet definition.
JDeveloper captures the search metadata for each view object, including the search facets you define, and writes it to an external XML file (searchable object) for consumption by the runtime component. Each searchable object corresponds to a view object and includes the search facets. The file naming convention is view_object_name_ECSF.xml, and the file is created in the same location as its corresponding view object.
At runtime, the search interfaces provided by ECSF allow users to iterate through facets and further filter the query by selecting facet values.
Caution:
Do not manually modify the contents of theview_object_name_ECSF.xml file. If you manually modify the search metadata in the XML file, the changes appear in the editor window when it is closed and reopened in JDeveloper, but metadata changes are not validated. Instead, use the Search navigation tab of the overview editor in JDeveloper to modify the search metadata.Facets can only be defined on attributes in the parent or top-level view object because only attributes on the parent or top level view object can be created as index attributes in the underlying Oracle SES index. For example, if you want to create an "address" facet consisting of the following tree, Country > State > City > Zip Code, all four attributes (country, state, city, zip code) must be view object attributes in the parent or top level view object. Attributes that are used for facets must exist on the parent view object, not on a child view object linked to the parent through a view link. If any of the information is in a child attribute, then the attribute must be joined into the parent view object.
Since facets can filter against only a single search category, faceted navigation is not supported with federated search.
You can configure custom properties for searchable objects to modify default runtime behavior or to make searchable object public.
The following custom properties can be set for searchable objects through the overview editor to modify default runtime behavior:
oracle.ecsf.crawl.batch.size
oracle.ecsf.crawl.datafeed.size
oracle.ecsf.max.links.depth
oracle.ecsf.split.mode
oracle.ecsf.split.threshold
These properties, described in Table 30-1, can also be set as system parameters to apply the values to all searchable objects. For information, see Section 30.2.4, "How to Modify the Run Configuration of the View-Controller Project".
To configure customer properties for searchable objects:
In the Application Navigator, open the desired view object.
In the overview editor, select the General navigation tab.
Expand the Custom Properties section.
Add property name and value pairs. For more information about the properties, see Table 30-1.
Making searchable objects public allows users to perform searches without needing to log in first. Public data sources do not require any user authentication and can support anonymous users.
To make a searchable object public, define the custom property oracle.ecsf.searchableobject.public, as shown in Example 27-7, in the view_object_name.xml file.
Example 27-7 Custom Property for Making Searchable Objects Public
<Properties>
<CustomProperties>
<Property
Name="oracle.ecsf.searchableobject.public"
Value="true"/>
</CustomProperties>
</Properties>
When this value is set to true, the Security attribute values for anonymous user property of the data source deployed to Oracle SES from this searchable object is set to the ACL value or values retrieved from the searchable object's plug-in class.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|