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. Because the binding information describes how a searchable object behaves in a given context, it is sometimes called search metadata.
To create searchable objects, 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 About Enabling Search on Fusion File Attachments.
(Optional) Enable the capability to crawl searchable objects with Oracle WebCenter tags. For more information, see About 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 (ECSF) 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 their attributes to search, and creates the necessary metadata for ECSF. The ECSF metadata can be packaged into an application archive and subsequently used by the ECSF runtime environment to deploy data sources into Oracle Secure Enterprise Search (Oracle SES) to perform crawl 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 to make the searchable objects usable during runtime for both crawl and query operations.
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, include only attributes you intend to search).
Exclude large objects (LOBs) from searchable objects unless you intend to search LOB contents.
Restrict the use of multilevel view objects to five levels to avoid causing severe feed performance degradation.
Collocate 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.
Remember that 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.
Remember that attachments (Oracle Content Management SDK or LOBs) require record by record processing, and every record requires one additional network round-trip.
Store attributes only when necessary. Use attributes stored in Oracle SES only for the following purposes:
Faceted navigation
Advanced search
Search result actions
Primary keys
If the value of an attribute must be searchable, then 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 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.
Identify 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 is 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 How to Make View Object Attributes Searchable.
Raising change events. For information, see About Raising Change Events Synchronously.
If neither mechanism is implemented, then the data that has been added or modified since the initial crawl will not be indexed, and therefore will not be searchable.
Before you can define searchable objects, you must be familiar with the following:
Oracle JDeveloper and Oracle Application Development Framework technology. You must also understand how to build applications using entity objects, view objects, and view links.
How view objects are used in ECSF. For more information, see the "Managing Search with Oracle Enterprise Crawl and Search Framework" chapter in the Administrator's Guide.
How to use Groovy expressions when defining search metadata. For information, see About Using Groovy Expressions in ECSF.
To define searchable objects and searchable attributes, use the Search navigation tab of the overview editor in Oracle JDeveloper to complete the following tasks:
Note:
You must choose the Oracle Fusion Applications Customization role when start 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.
ECSF indexes data based on a view object, which represents the top-level view object to crawl. Many business objects are hierarchical, and ECSF optimizes the Oracle Application Development Framework (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. After 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 to be searchable, you must 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. Generate the view link accessor only 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 About 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 following 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 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 What You May Need to Know about Preventing Conflicts with 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 following 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. 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 29-1, which shows the accessor information about the Relationship navigation tab of the view link editor, the name of the view link accessor is ZipLov
.
Figure 29-1 Location of View Link Accessor Name for Child View Object
You can also find the name of view link accessor in the <ViewLinkAccessor>
tag of the XML source code of the view object.
Alternatively, you can use the curdoc
keyword to access the current document, as shown in Example 29-1.
The curdoc
keyword is used to access child documents and their attributes.
Example 29-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;
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 29-2 illustrates the Purchase Order searchable object with a five-level structure.
Figure 29-2 Searchable Object with Five Levels
Using Groovy expressions in the search metadata, you can access attributes in the levels 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. For example, if you reference view object attributes with viewLinkAccessorName.viewLinkAccessorName.voAttrName
, then the result of the expression POLine.LineDetail.AttributeX
is the concatenation of all AttributeX
values for the LineDetail
attribute of all POLine
levels of the current PurchaseOrder
searchable object.
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 29-2, in the Body field.
The class name of the Hiredate
attribute's value is displayed and can be viewed in the Data Feed:
Hiredate type: java.sql.Date
.
After you determine the Java data type of a view object attribute, you can apply standard Java formatting techniques to format its value. Example 29-3 shows a sample Groovy expression for formatting a date.
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 29-4.
The Groovy expression evaluates to:
Quantity: 2,450
Example 29-2 Sample Groovy Expression to Determine Attribute's Java Data Type
'Hiredate type: ' + (Hiredate != null ? Hiredate.getClass().getName() : 'null');
Example 29-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);
Example 29-4 Sample Groovy Expression for Formatting Numbers
fmt = new java.text.DecimalFormat('#,###,###'); 'Quantity: ' + fmt.format(Qty);
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 29-3, to set search property values for view objects.
Figure 29-3 Search Page for Configuring Search Properties of 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.
To set search property values for view objects, do the following:
Caution:
Do not modify the Oracle Fusion Applications Help searchable object named TopicSearchPVO
.
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, do the following:
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 want 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 How to Make 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 for ECSF to load the interface.
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 the view_object_name
_ECSF.xml
file. If you manually modify the search metadata in the XML file, then 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 navigation tab of the overview editor in JDeveloper, shown in Figure 29-6, to set property values for view object attributes.
Figure 29-6 Search Page for Configuring Search Properties of View Object Attributes
Using the Search navigation tab, 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.
Modify a searchable attribute by editing the search property values for the view object attribute.
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 searching to construct documents for indexing.
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, then 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 Portal tags are associated with the searchable object. For information, see About 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:
Do not manually delete an attribute that has a corresponding search attribute from a view object, because it 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 is LANGUAGE
(all caps) and the Oracle SES default search attribute name is Language
.
The 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, and 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 will not 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 supports facets only on attributes of type STRING
, if a facet is defined on a nonstring attribute, then 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. ECSF does check for stored attribute conflicts. For more information, see About Checking for Stored Attribute Conflicts.
Consider 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 |
---|---|---|
|
|
|
|
|
|
|
|
|
You use the Search Designer to annotate a subset of these attributes (Name
and OrganizationId
) to store in Oracle SES for search purposes. For more information, see About Search Designer.
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 |
---|---|
|
|
|
|
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, then 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 whether an attribute is used for a facet. If it is used for a facet, then 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. Go to the JDeveloper ADF view object attribute editor and update the Alias property value, as shown in Figure 29-8. For example, in the view object attribute editor, change the Alias value from PARTY_ID to PARTY_ID_FACET.
Figure 29-8 Changing the Alias Value in the Attribute Editor
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 checks for stored attribute conflicts during Search Object deployment. If ECSF detects that the SO has attributes in it that will cause a conflict in SES, an error message will be shown that describes the error. Depending on the situation, the message will appear similar to one of these:
The source attribute in runtime.EmpViewAdmin11gTest with name Host and type NUMBER conflicts with the attributes defined in these sources: Source: runtime.EmpView DataType: STRING Source: runtime.EmpView2 DataType: STRING
The source attribute in runtime.EmpViewAdmin11gTest with name Mgr and type NUMBER conflicts with the attribute defined in SES with type STRING. This attribute is not being used by any sources.
You will have to change the SO so that the conflicting attribute either has a new name or has the same type as the attributes already defined in SES.
ECSF determines if a user has access to a search category depending on whether 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 About Using the Search PlugIn Dialog.
To set permissions, do the following:
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, do the following:
Example 29-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 policy store is used to determined which users have access to which objects. Add an application policy store to jazn-data.xml
.
To add the application policy store, do the following:
Example 29-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>
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 How to Add Dynamic Main Area and Regional Area Task Flows to a Page. Figure 29-9 illustrates an example of the results of a filtered search.
Figure 29-9 Search Results with Action Links
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 29-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 How to Use the Actionable Results API with 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:
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, do the following:
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, do the following:
\WEB-INF\task-flow-definition.xml
.<task-flow-definition>
element, for example, <task-flow-definition id='task-flow-definition'>
and note the value of the id
attribute.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
.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'
.You can modify search result actions as needed to change the action links that display with the search results.
To modify search result actions, do the following:
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 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 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 are 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.
Related Links
The following document provides more information about the topic discussed in this section:
For more information, see the "Working with List of Values (LOV) in View Object Attributes" section in Developing Fusion Web Applications with 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, do the following:
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, do the following:
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 29-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 Defining Lists of Values.
You can use this feature to define facets to filter result records against a child VO attribute. Without this feature, facets could only allow users to filter search results to those results where an attribute in the result record matches a certain value, such as Color="Red", or Status="Open". This feature allows a Stored Attribute to be defined against a child VO attribute and for a facet to be defined against this stored attribute. Thus, users will be able to filter search results such that only results whose child VO attribute matches a certain value will be returned.
ECSF design time uses transient attributes to allow child VO attributes as searchable attributes by allowing them in the facet definitions.
The Override Source property value is expressed at the view attribute level and it is resolved at both the query time and crawl time. The Override Source drop-down list (see Figure 29-7) is populated with all the attribute names from the view links that are associated with the current VO.
The code for querying for facets will not change.
At query time, a FacetPath will be converted to filters against the corresponding Stored Attributes in the facet path. With this feature, some stored attributes will contain multiple values, and the filter will select a search document if any of the values in its stored attribute matches the value in the filter.
Facet counts will work without any changes. When a stored attribute contains more than one value, each value will contribute to incrementing the count for that value.
To set up a view object, do the following:
Use the Select Text Resource dialog to select a text resource from an existing resource bundle.
To select a matching text resource, do the following:
Use the Select Text Resource dialog to create and select a new text resource.
To create and select a new text resource, do the following:
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, do the following:
You can delete root search facets to remove them from the table on the Search navigation tab.
To delete root search facets, do the following:
You can delete child search facets to remove them from the facet tree.
To delete child search facets, do the following:
You can define facets to support ranges for numbers and dates.
To define facets that support ranges, do the following:
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 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 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 29-1, can also be set as system parameters to apply the values to all searchable objects. For information, see How to Modify the Run Configuration of the View-Controller Project.
To configure customer properties for searchable objects, do the following:
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 29-7, in the view_object_name
.xml
file.
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.
Example 29-7 Custom Property for Making Searchable Objects Public
<Properties> <CustomProperties> <Property Name="oracle.ecsf.searchableobject.public" Value="true"/> </CustomProperties> </Properties>