15 Implement Search Functions in the UI Shell

Note that the XML is supplied without a schema; it is an internal part of applcore search and may change at any time without notice.

Attachments found at detail levels are pulled up to the parent level. If this is not required, do not include an accessor path to this level so these attachments will not be crawled.

Attachments in all categories are included. However, if that document entity has security enabled (no matter what the data security rules are), the attachments assigned to that document entity are removed from the indexed document and therefore not crawled. Their details will not be in the example XML.

The following types of attachments will be available as links:

• FILE

  An attached file. This is the primary use case.

• WEB_PAGE

  A URL, such as http://www.companyname.com. The link will be placed verbatim in the results UI as an af:goLink. Note that ECSF does not crawl Web page attachments.

• TEXT

  Text typed by the user. This is implemented by attachments internally as a hidden file, so is practically the same as FILE.

The following types of attachments will not be available as links:

• FOLDER

  A reference to a folder in Oracle WebCenter Content. Requires use of a WebCenter Content folder taskflow.

• TMURI

  Topology Manager URI. This is a URI offset to a web application defined in topology. This is a minor use case used in migration and is not supported by search.

In the ECSF Search view object design time, add a Search Plugin to the Applications Core class oracle.apps.fnd.applcore.search.plugin.FndSearchPlugin.

Developers that have an existing plugin should extend the Applications Core plugin and call super() on the methods that implement attachment functionality. Use the same parameters to the plugin as already described.

public class AppsSearchPlugin
  extends FndSearchPlugin
  implements PreIndexProcessor,
             ChangeListener
{
  /**
   * Hook into the pre index process of the crawl so we can annotate the Search view object
   * with apps specific information such as tags and attachment metadata.
   * @param ctx Search Context.
   * @param docs Documents to iterate and find tag children for.
   */
  public void preIndexProcess(SearchContext ctx,
                              List<IndexableDocument> docs)
{
  super.preIndexProcess(ctx, docs);
  // custom apps functionality ...
}
    /**
   * Get the change list for crawling.
   * @param ctx Search Context.
   * @param changeType the type of the change requested. Must be one of following
   * <ul>
   * <li>ChangeListener.UPDATE<li>
   * <li>ChangeListener.INSERT<li>
   * <li>ChangeListener.DELETE<li>
   * </ul>
   * @return an iterator of a list of primaryKeys. Returns an empty iterator if
   * nothing changed.
   */
  public Iterator getChangeList(SearchContext ctx, String changeType)
  {
     Iterator ret = super.getChangeList(ctx, changeType);
    // custom apps functionality ...
    return ret;
  }
}

Add a transient string attribute to the Search view object named FND_ATTACHMENT_METADATA to store Applications Core attribute metadata. Flag this attribute as stored in the Search view object definition.

Use the openSubFlow and closeSubFlow APIs to record sub flows to Recent Items. Whenever an ADF Controller task flow call takes place, no notification is raised to Applications Core or UI Shell. So, unlike starting a task from a tasks list, you need to explicitly notify the UI Shell for sub flow calls.

When the openSubTask API is called before a subflow is started, the sub flow ID and its parameter values are pushed onto the stack. Applications Core also notifies the Recent Items implementation with recorded task flow information. This essentially makes a sub flow able to be bookmarked by Recent Items, and can be started directly from the selection of menu items on Recent Items.

Note that registering sub flows to Recent Items is optional.

/**
* Notify UIS hell to record a given sub flow on the stack and 
* also notify Recent Items to include it on the list.
*
* @param taskFlowId Task flow to open
* @param parametersList Parameters list for the task flow.
*                       This is a semicolon delimited String
*                       of name-value pairs. For example,
*                       "param1=value1;param2=value2".
*
* @param label Label for the task flow.
* @param keyList Key list to locate the task flow instance.
*                This is a semicolon delimited keys or key-value pairs.
*                For example, "key1;key2=value2". If only the key is specified,
*                the value is picked up from parametersList with the same
*                name as the key.
*
* @param taskParametersList Parameters list to pass in to the task flow to open
*                in the target workspace. This is a semicolon delimited String
*                of name value pairs. For example,
*                "param1=value1;param2=value2."
*
* @param methodParameters This can be used for passing
*                Java object into the task flow that is specified 
*                in taskFlowId parameter. Use <code>setCustomObject() API</code>
*                in FndMethodParameters for setting the java object.
*
* @return For internal Contextual Event processing
*/
 
public FndMethodParameters openSubTask(String taskFlowId,
String parametersList,
String label,
String keyList,
String taskParametersList,
String viewId,
String webApp,
FndMethodParameters methodParameters)
 
/**
* Closes the currently-focused sub-task and the focus moves to the 
* task from which this sub-task was started.
*
* @param methodParameters For future implementation. No-op for now.
* @return For internal Contextual Event processing
*/
public FndMethodParameters closeSubTask(FndMethodParameters methodParameters)

The openSubTask API accepts the same set of parameters as used by the Navigate API. If no label is specified in the openSubTask API, Recent Items will register it with the name of the parent task flow's label. You should set a different label based on the business use case in the openSubTask API. Failing to do so will register this flow with the same label as the parent task flow's label and, therefore, will make it impossible to distinguish between the parent flow and the sub flow entry in the Recent Items list.

Whatever task flow details are registered while invoking the openSubTask API will be used by Recent Items to start it. Recent Items takes care of starting the task flow in the right work area and web application. You do not need to do anything for that. Because the openSubTask API supports parametersList, you can pass some requirement-specific values to it while registering the task flow to Recent Items. On starting, those passed values are available in the pageFlowScope. You can analyze these values and make decisions, such as if you need to first initialize the parent flow, or if you need to set Visible to False on some of the actions on the page.

The parent task flow named ToParentSFFlow is shown in Figure 15-7.

Figure 15-7 Example Parent Task Flow

The router activity decideFlow decides whether the control task flow should go to the original parent task flow path (initParent) or to the sub task flow path (toChild). The condition is defined as:

<router id="decideFlow">
  <case>
    <expression>#{pageFlowScope.Empno == null}</expression>
    <outcome id="__9">initParent</outcome>
  </case>
 
  <case>
    <expression>#{pageFlowScope.Empno != null}</expression>
    <outcome id="__10">toChild</outcome>
  </case>
 
  <default-outcome>initParent</default-outcome>
</router>

The test checks whether the Empno variable in the parent task flow's pageFlowScope is null. #{pageFlowScope.Empno} is set using its input parameter Empno when the parent task flow is called. The input parameters on the parent task flow (that is, ToParentSFFlow) are defined as:

<input-parameter-definition>
  <name>Empno</name>
  <value>#{pageFlowScope.Empno}</value>
  <class>java.lang.String</class>
</input-parameter-definition>

When the parent task flow is started from the task list, the Empno parameter is not set (that is, it is not defined in the application menu's itemNode). Therefore, the parameter is null and the router will route it to the initParent path.

When the sub task flow is recorded through the openSubTask API, the Empno parameter is set on parametersList as:

<methodAction id="openSubTask" RequiresUpdateModel="true"
                 Action="invokeMethod" MethodName="openSubTask"
                 IsViewObjectMethod="false" DataControl="FndUIShellController"
                 InstanceName="FndUIShellController.dataProvider"
                 ReturnName="FndUIShellController.methodResults.openSubTask_FndUIShellController_dataProvider_openSubTask_result">
     <NamedData NDName="taskFlowId" NDType="java.lang.String"
         NDValue="/WEB-INF/oracle/apps/xteam/demo/ui/flow/ToParentSFContainerFlow.xml#ToParentSFContainerFlow"/>
     <NamedData NDName="parametersList" NDType="java.lang.String"
                NDValue="Empno=#{row.Empno}"/>
     <NamedData NDName="label" NDType="java.lang.String"
                NDValue="#{row.Ename} complete details"/>
     <NamedData NDName="keyList" NDType="java.lang.String"/>
     <NamedData NDName="taskParametersList" NDType="java.lang.String"/>
     <NamedData NDName="viewId" NDType="java.lang.String"
                NDValue="/DemoWorkArea"/>
     <NamedData NDName="webApp" NDType="java.lang.String"
                NDValue="DemoAppSource"/>
     <NamedData NDName="methodParameters"
         NDType="oracle.apps.fnd.applcore.patterns.uishell.ui.bean.FndMethodParameters"/>
</methodAction>

You also set up:

• taskFlowId to be the parent task flow's, not the sub task flow's

• label to be the sub task flow's

When users click the link (the Ename) to which the openSubTask method is bound, openSubTask will be called. This link component is defined as:

<af:column sortProperty="Ename" sortable="false"
           headerText="#{bindings.ComplexSFEmpVO.hints.Ename.label}"
           id="resId1c2">
  <af:commandLink id="ot3" text="#{row.Ename}"
                  actionListener="#{bindings.openSubTask.execute}"
                  disabled="#{!bindings.openSubTask.enabled}"
                  action="toChild">
    <af:setActionListener from="#{row.Empno}"
                          to="#{pageFlowScope.Empno}"/>
  </af:commandLink>
</af:column>

Note that when the link is clicked:

• actionListener and the action specified on the link are executed, in that order.

• openSubTask is called only from the original parent task flow path (that is, initParent), not from the sub task flow path (that is, toChild).

The EmployeeDetails activity in Figure 15-7 is a Task Flow Call activity that invokes the ToChildSFFlow sub task flow. Before the sub task flow is executed, add initialization steps. These initialization steps could include, but are not limited to:

• Set up parent states. For this example, set the selected employee's row to be the current row.

• Set up the Contextual Area state.

• Set up states to allow the sub task flow to navigate back to the parent task flow.

There are two approaches to setting up the initialization steps:

• In the parent task flow

• In the sub task flow

For the first approach, you can add logic to initialize both paths before the task flow call activity in the parent task flow. For the second approach, you initialize states in the sub task flow by using input parameters of the sub task flow. For example, the sub task flow will take an input parameter named Empno. In effect, the second approach just postpones the initialization to the sub task flow.

The definition of input parameters in the task flow call activity is:

<task-flow-call id="EmployeeDetails">
     <task-flow-reference>
       <document>/WEB-INF/oracle/apps/xteam/demo/ui/flow/ToChildSFFlow.xml</document>
       <id>ToChildSFFlow</id>
     </task-flow-reference>
     <input-parameter>
       <name>Empno</name>
       <value>#{pageFlowScope.Empno}</value>
     </input-parameter>
</task-flow-call>

Note that this means that the calling task flow needs to store the value of Empno in #{pageFlowScope.Empno}. For example, from the original parent task flow path, it is set to be #{row.Empno} using the setActionListener tag. For the sub task flow path, it is set using the parent task flow's input parameter Empno. On the sub task flow, you need to specify its input parameters as:

<task-flow-definition id="ToChildSFFlow">
   <default-activity>TochildSFPF</default-activity>
   <input-parameter-definition>
     <name>Empno</name>
     <value>#{pageFlowScope.Empno}</value>
     <class>java.lang.String</class>
   </input-parameter-definition>
   ...
</task-flow-definition>

Note that the name of the input parameter (Empno) must be the same as the parameter name defined on the task flow call activity. When the parameter is available, Oracle ADF will place it in #{pageFlowScope.Empno} to be used within the sub task flow. However, this pageFlowScope is different from the one defined in the task flow call activity because they have a different owning task flow (that is, parent task flow versus sub task flow).

The definition of the sub task flow is shown in Figure 15-8:

Figure 15-8 Example Sub Task Flow Definition

In the sample implementation, you implemented the initialization step in the sub task flow. The Empno variable is passed as a parameter to the sub task flow and used to initialize the parent state. When the sub task flow is started, the default view activity (TochildSFPF) is displayed. Before it renders, the initPage method on the ChildSFBean will be executed. The page definition of the default page is defined as:

<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel">
 <parameters/>
 <executables>
   ...
   <invokeAction id="initPageId" Binds="initPage" Refresh="always"/>
 </executables>
 <bindings>
   ...
   <methodAction id="initPage" InstanceName="ChildSFBean.dataProvider"
                 DataControl="ChildSFBean" RequiresUpdateModel="true"
                 Action="invokeMethod" MethodName="initPage"
                 IsViewObjectMethod="false"
                 ReturnName="ChildSFBean.methodResults.initPage_ChildSFBean_dataProvider_initPage_result"/>
    ...
 </bindings>
</pageDefinition>

The initPage method is specified in the executables tag and will be invoked when the page is refreshed. The initPage method itself is defined as:

public void initPage()
{ 
    FacesContext facesContext = FacesContext.getCurrentInstance();
    ExpressionFactory exp = facesContext.getApplication().getExpressionFactory();
    DCBindingContainer bindingContainer =
      (DCBindingContainer)exp.createValueExpression(
          facesContext.getELContext(),"#{bindings}",DCBindingContainer.class).getValue(facesContext.getELContext());
    ApplicationModule am = bindingContainer.getDataControl().getApplicationModule();
 
    ViewObject vo = am.findViewObject("ComplexSFEmpVO");
    vo.executeQuery();
 
    Map map = AdfFacesContext.getCurrentInstance().getPageFlowScope();
    if(map !=null){
         Object empObj = map.get("Empno");
         if(empObj instanceof Integer){
             Integer empno =(Integer)map.get("Empno");// new Integer(empnoStr);
             Object[] obj = {empno};
             Key key = new Key(obj);
             Row row = vo.getRow(key);
             vo.setCurrentRow(row);
         }
         else
         {
             String empnoStr = (String)map.get("Empno");
             Integer empno = new Integer(empnoStr);
             Object[] obj = {empno};
             Key key = new Key(obj);
             Row row = vo.getRow(key);
             vo.setCurrentRow(row);
         }
     }
}

The initPage method takes the input parameter Empno from #{pageFlowScope.Empno} as a key to select a row and set it to be the current row in the master Employee table.

For asynchronous Watchlist items, the count is updated only upon request. For example, in Expenses, there is an expense reports search panel from which users can make searches and save them in MDS for future use. Users should be able to promote their saved searches to the Watchlist for tracking. This Watchlist item (of type USER_SAVED_SEARCH) is asynchronous in that the Watchlist count will be updated only upon request, and events that change the count will not be updating the Watchlist simultaneously. In this case, Watchlist code is responsible for querying the count of an asynchronous Watchlist item on demand.

For the Expense report saved search panel example:

• Because this item is of type USER_SAVED_SEARCH, Watchlist items are created when the user promotes a saved search on the search panel in Expenses. This invokes a Watchlist service on the Watchlist that does the Watchlist item creation. This is not needed for Watchlist items of type SEEDED_QUERY or SEEDED_SAVED_SEARCH.

• A request to refresh the Watchlist item count comes from the Watchlist portlet. This will invoke an exposed service, which delegates the call to a method on a provided Watchlist JAR file.

• The method on the Watchlist JAR file will take care of rerunning the query (on the expenses database) and taking the results to update the Watchlist item count (on the Watchlist database).

At a high level, for asynchronous Watchlist items, your development tasks are:

• Determine or set up view objects to execute the query for Watchlist count. You may want to include view criteria with bind variables and specify default values for bind variables. (Not needed for Human Task)

  For example, most view objects seeded for the Watchlist would filter by user to show counts specific to the logged-in user. You could create a view criteria with a bind variable called userId and specify the default value as a groovy expression to determine the current user ID from the security context. You then would seed this view criteria ID in the setup table along with the view object. The Watchlist API would execute the view object by applying this view criteria to get the row count. Example 15-2 shows code from the view object xml for a bind variable with a default value.

• (Optional) Set up a summary view object to facilitate a refresh count and specify the summary attribute in the Watchlist setup table. Watchlist code would use this information to query the count instead of doing a rowcount on the executed view object results.

• Include Watchlist model JAR files in your service project and set up a refreshWatchlistCategory service method. This method only will contain code to delegate the call to the nested Watchlist application module method that actually executes the view object queries by reading your Watchlist setup data. This requires that all the corresponding model projects are included as JAR files in this service project so view objects are available in the class path. This service should be exposed so that the Watchlist UI can use it to start the refresh process.

• Determine and code task flows for drilldown from the Watchlist UI. There is no special coding required for these task flows; the key-value parameter string that you specify in the setup table will be used as the input parameter list when invoking the specified task flow for the UI drilldown on Watchlist items.

• (Optional) Enable saved search promotion to the Watchlist. Include Watchlist model JAR files in the corresponding project for the query panel and work with the Watchlist API. For promotion and demotion of user-saved searches, code must invoke a method in the provided Watchlist JAR, which then will handle interaction back to the Watchlist. Add promotion and demotion components on the search panel so that saved searches can be used as Watchlist items.

• Include Watchlist UI and Protected model JAR files in your UI SuperWeb project, to enable Watchlist menu drilldown in the UI Shell Global Area, as shown in Figure 15-10.

  Figure 15-10 Example Watchlist Menu Drilldown

  

• Create FND_LOOKUPS for the displayed Watchlist category and item meaning (FND_STANDARD_LOOKUP_TYPES.LOOKUP_TYPE). Product teams must seed the lookup type with the meaning for the category (VIEW_APPLICATION_ID = 0 and SET_ID = 0). The translated lookup type meaning is shown in the Watchlist UI for the category, while the corresponding lookup value meanings are shown in the Watchlist UI for items (user saved search item meanings come from the saved search directly). Product teams must create seed data for this lookup.

• Example 15-3 presents sample code to create or update the lookup.

Seed Watchlist categories and setup information. Create your category in ATK_WATCHLIST_CATEGORIES and then seed your items in the reference data table (ATK_WATCHLIST_SETUP). The watchlist_item_type determines how the Watchlist code will handle the item.

<Variable
            Name="userId"
            Kind="where"
            Type="java.lang.String">
            <TransientExpression><![CDATA[return adf.context.securityContext.userName;]]></TransientExpression>
          </Variable>

declare
begin
FND_LOOKUP_TYPES_PKG.CREATE_OR_UPDATE_ROW (
  X_VIEW_APPSNAME => 'FND',
  X_LOOKUP_TYPE => 'FIN_EXM_WATCHLIST_CATEGORY',
  X_APPLICATION_SHORT_NAME => 'EXM',
  X_MEANING => 'Expenses',
  X_DESCRIPTION => 'Expenses Watchlist Category',
  X_REFERENCE_GROUP_NAME => null
);
end;
 
declare
begin
FND_LOOKUP_VALUES_PKG.CREATE_OR_UPDATE_ROW (
  X_LOOKUP_TYPE           => 'FIN_EXM_WATCHLIST_CATEGORY',
  X_VIEW_APPSNAME         => 'FND',
  X_LOOKUP_CODE           => 'SAVED_EXPENSE_REPORTS',
  X_MEANING               => 'In Progress Expense Reports'
--  X_SET_CODE              IN VARCHAR2 DEFAULT NULL,
--  X_DESCRIPTION           IN VARCHAR2 DEFAULT NULL,
--  X_ENABLED_FLAG          IN VARCHAR2 DEFAULT 'Y',
--  X_START_DATE_ACTIVE     IN VARCHAR2 DEFAULT NULL,
--  X_END_DATE_ACTIVE       IN VARCHAR2 DEFAULT NULL,
--  X_DISPLAY_SEQUENCE      IN NUMBER DEFAULT NULL
  );
end;

1. Add this ADF Library JAR file to the SuperWeb user interface project for your application (the JAR file must be part of your Web Archive (WAR) in the WEB-INF/lib directory):

   fusionapps/jlib/AdfAtkWatchListPublicUi.jar

2. Add this dependent model ADF Library JAR file in your application (the JAR file must be part of your Enterprise Archive (EAR) in the APP-INF/lib directory):

   fusionapps/jlib/AdfAtkWatchListProtectedModel.jar

3. Add this dependent resource bundle ADF Library JAR file in your application (the JAR file must be part of your EAR in the APP-INF/lib directory):

   fusionapps/jlib/AdfAtkWatchListPublicResource.jar

4. Add these resource-ref entries to the web.xml file in your SuperWeb user interface project:

   <resource-ref>
       <res-ref-name>wm/WorkManager</res-ref-name>
       <res-type>commonj.work.WorkManager</res-type>
       <res-auth>Container</res-auth>
   </resource-ref>
   <resource-ref>
       <res-ref-name>jdbc/ApplicationDBDS</res-ref-name>
       <res-type>javax.sql.DataSource</res-type>
       <res-auth>Container</res-auth>
   </resource-ref>
   

See Watchlist Physical Data Model Entities for details of the entire Watchlist data model. Seed only ATK_WATCHLIST_CATEGORIES and ATK_WATCHLIST_SETUP.

• By default, Watchlist code will access the application module or view object that is specified in the setup table, and rerun the query to refresh the Watchlist count. The summary view object is one way to get the count. Usually this will be for efficiency reasons.

• The product team can signal that it wants the Watchlist code to use its summary view object by seeding something in SUMMARY_VIEW_ATTRIBUTE of ATK_WATCHLIST_SETUP. If this is not null, the Watchlist code will get the view object, but instead of running the query, it will take only the first row and get the specified attribute.

• Your task is to create a view object with the correct count in the attribute specified in the setup table.

1. Ensure you have enabled MDS for your application.
2. Run the application and visit the desired search page.
3. Use the UI to create saved searches and name them. For each saved search, select Run Automatically.
4. Examine the adf-config.xml file to determine where your file-based MDS repository is located.
5. In a terminal, change to the directory:

   <MDS repository>/persdef/oracle/apps/.../mdssys/cust/user/<user>/

   The <user> directory would be the user you used to save the search with, or anonymous by default.

6. Inside that directory, there should be an xxxVO.xml.xml file that contains the created saved searches. Keep that file.
7. In that XML file, note the saved search ID, which should match the View Criteria ID in the reference data.

   Note:

   This ID can be different than the display name that you entered in the saved search UI.

Refer to Implementing the Watchlist.

For the same Watchlist items, the Watchlist portlet must be able to invoke a refresh. You will set up and expose a service that includes local JAR files for this purpose. The nested Watchlist JAR file can use those local JAR files in its refresh code.

The service will expose the refreshCategory method that will delegate the call to the same method in the nested Watchlist application module. This method will be provided in the Watchlist JAR file and will contain code to perform the category-wide refresh.

Your Service project must import the other JAR files from your product that must be used by the Watchlist code.

Include AdfAtkWatchListProtectedModel.jar and AdfAtkWatchListPublicModel.jar in your service project, and nest AdfAtkWatchListPublicUi.jar in your service application module.

Set up the AppMasterDB connection that comes with it. Point it to the database where you have seeded your data in the Watchlist tables. This usually is your development database that is used for the ApplicationDB connection.

This method, shown in Example 15-4, refreshes all Watchlist items in the corresponding category.

public void refreshWatchlistCategory(String categoryCode) {
    AtkWatchlistPublicAMImpl wlAM = this.getAtkWatchlistPublicAMImpl();
    wlAM.refreshWatchlistCategory(categoryCode);
}

For subsequent steps that require running Watchlist APIs from your code, you must import the Watchlist JAR files. These also contain an AppMasterDB connection that must point to the Watchlist database.

• Add AdfAtkWatchlistProtectedModel.jar and AdfAtkWatchlistPublicService.jar (fusionapps > jlib) as ADF libraries in the appropriate data model projects, preferably in a model project that is visible to both service and user interface model project application modules.

• Add AdfAtkWatchlistPublicUi.jar as an ADF library to your user interface project.

• Configure the AppMasterDB connection.

If you have seeded the information properly, your normal task flows should work when expanded into from the Watchlist portlet.

There is a link in the UI Shell for Watchlist in the global area. To make it work, the user interface project must include these Watchlist UI JAR files: AdfAtkWatchListPublicUI and its dependent model JAR file AdfAtkWatchListProtectedModel.

These entries are required for the Watchlist service and UI to be able to work in a standalone deployment.

• Add this entry in the ejb-jar.xml file in your service project that contains the watchlist service next to the similar entry for ApplicationDB. You need resource-ref entries for both ApplicationDB and AppMasterDB:

  <resource-ref> 
    <res-ref-name>jdbc/AppMasterDBDS</res-ref-name> 
    <res-type>javax.sql.DataSource</res-type> 
    <res-auth>Container</res-auth> 
  </resource-ref>
  

• Add this entry in the web.xml file in your SuperWeb project next to the similar entry for ApplicationDB. You need resource-ref entries for both ApplicationDB and AppMasterDB:

  <resource-ref> 
    <res-ref-name>jdbc/AppMasterDBDS</res-ref-name> 
    <res-type>javax.sql.DataSource</res-type> 
    <res-auth>Container</res-auth> 
  </resource-ref>
  

• The connections.xml file should have a valid database entry for AppMasterDB.

1. In the Application Navigator, double-click an entity object.
2. In the overview editor, click the business events navigation tab.
3. On the business events page, expand the Event Publication section and click the Edit event publications icon.
4. In the Edit Event Publications dialog, click New to create a new event.
5. Double-click the new cell in the Event column, and select the appropriate event.
6. Double-click the corresponding cell in the Event Point column, and select the appropriate event point action.
7. You optionally can define conditions for raising the event using the Raise Conditions table.
8. Click OK.

<EventDef  Name="OpportunityStatusUpdate">
  <Payload>
    <PayloadItem AttrName="OpptyId"/>
    <PayloadItem AttrName="Status"/>
    <PayloadItem AttrName="Customer.CustomerId"/>
  </Payload>
</EventDef>

By default, business events are not published as Activities. You should override the isActivityPublishingEnabled() method to enable Activity publishing for an entity object. Table 15-5 shows the details about the APIs exposed in OAEntityImpl that you can override.

Note that, except for the isActivityPublishingEnabled() method, other methods mentioned in Table 15-5 should be avoided in favor of transient attributes specified in Defining Activity Attributes Declaratively.

1. Ensure your user interface project includes the Oracle WebCenter Portal Activity Streaming Service library in the Libraries and Classpath section in the project properties dialog.
2. From Resource Catalog > TaskFlows, drag and drop either an "Activity Stream" or "Activity Stream Summary - View" task flow onto the page where you want to display the Activity Stream UI.
3. Set the taskFlow resourceId parameter to #{securityContext.userName}. This will tie the task flow to the current user at runtime.
4. For additional details about the Activity Stream task flow, see the chapters in the Working with the People Connections Service partition in the Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper.

The Follow model is enforced for Activity messages when the category-id of a service contains "business" in its name. A sample service-category-definition and its reference in service-definition are provided in Example 15-14 and Example 15-15.

Note that the ID in the service-category-definition file matches the category-id in the service-definition.xml file and it contains "business".

<service-category-definition xmlns="http://xmlns.oracle.com/webcenter">
 <category id="oracle.apps.fnd.applcore.crmdemo.model.business.CasesEO"
           resourceBundle="oracle.apps.fnd.applcore.crmdemo.BusinessActivityServiceResourceBundle"
           titleKey="CASE_SERVICE_CATEGORY"
           icon="/a/s/g.gif"/>
</service-category-definition>

<category-id>oracle.apps.fnd.applcore.crmdemo.model.business.CasesEO</category-id>

The Activity types shown in Example 15-16 should be added to the service-definitions of all services that use the Follow model. These Activity types are used to construct the message published when an object belonging to the service is Followed or Unfollowed.

<activity-type name="followObject"
   displayName="Follow Object"
   messageFormatKey="ACTIVITY_FOLLOW_OBJECT_MSG"
   description="Follow Object">
</activity-type>
 
<activity-type name="unfollowObject"
   displayName="Unfollow Object"
   messageFormatKey="ACTIVITY_UNFOLLOW_OBJECT_MSG"
   description="Unfollow Object">
</activity-type>

Click Show Filters to display them on the left side of the display. They are sized to make them easy to use on touch-screen appliances.

Last Updated Date and Categories are default filters.

Figure 15-26 Search Filters Buttons

Click Last Updated Date to display the selections panel, similar to Figure 15-27.

Figure 15-27 Last Updated Date Search Filter

The valid values are:

• All

  Clears the current filter and displays results for all available dates.

• Today

  LastModifiedDate equals "todays date."

• This Week

  LastModifiedDate >= "last Sunday" AND LastModifiedDate <= "this Saturday"

• This Month

  LastModifiedDate >= "first day of month" AND LastModifiedDate <= "last day of month"

• This Year

  LastModifiedDate >= "first day of year" AND LastModifiedDate <= "last day of year"

• Custom Date Range

  As appropriate for the range. A date picker will be displayed. The dates in the custom date range default to the last year (last 365 days).

Note:

Categories are not set up at design time by developers. They should be set up either by customers or seeded by teams. Categories are created and stored in ECSF schema, and ECSF provides an API to get a list of categories to the UI for a given user. See How to Control the Look and Feel of Search.

When you click Categories, a list, similar to that shown in Figure 15-28, is displayed:

Figure 15-28 Search Categories Field Expanded

The user can select from the list of Categories. Unchecking the All category unchecks all of the categories. The subset of selected categories will be displayed in the entry area of the dropdown list as a concatenated list separated by commas.

Figure 15-29 Individually-selected Categories List

Click Save to open a list of saved searches.

Figure 15-30 Saved Searches List

• To create a new saved search that uses the last search string seen in the Search window as the search criteria, enter a name in the Name field and click OK. Make sure you have not selected an existing search.

• To rename a saved search, select it, enter a new name in the Name field, and click OK.

• To delete a saved search, select it and click Delete.

After clicking Search, a modal dialog will display the results of the search. Hovering over the main link will show the last crawled date. Figure 15-31 shows typical results.

Figure 15-31 Search Results Example

The Search Results display consists of:

• A repetition of the fields displayed in the Global Area.

• A set of filter tiles: Selected filter values will be applied to the search results.

  A category is a group of related objects. Examples include any Oracle Fusion business object, and Oracle WebCenter Portal objects such as wikis and blogs.

  A Searchable Object is the second level. A searchable object is the view object.

  If a category has only one Searchable Object, it is not shown as a filter because there is no action a user can take on it; it is automatically selected. Figure 15-31 shows an "Emp Cat" that has one searchable Object (not shown) that has three facet filters.

  Facets are formed by the Lists of Values defined on an attribute in the Searchable Object. There may be many facets for a Searchable Object, and the facets may be hierarchical, such as is the case in Figure 15-31, where a State facet contains a County facet, which contains a City facet. Only the name of the highest level facet in the hierarchy is shown.

• A Results section. The search results use the keywords in the search field with the filters applied.

  Each result found under a category provides a navigation link back to the record.

  The format of a search result is:

  • A line containing the default or primary action for the result. This may include an icon if it is defined on the search action. This line will be seen for all search results. Clicking the link navigates the user to the primary destination for the result.

  • A line containing the fixed content of the result. If any search terms match in this text, they are shown in bold. The Fixed Content is derived from the Search Properties Title field as defined in ECSF.

  • A line containing the variable content of the result. If any search terms match in this text, they are shown in bold. This text will wrap if it overflows the width of the line. The Fixed Content is derived from the Search Properties Body field as defined in ECSF.

  • A line of tags attached to this result of the form "Tags: tag1 tag2 ...". If there are no tags, this line is not shown.

  • A line of other actions in alphabetic order. Other actions are similar to the default action in that they may consist of an icon followed by a link. Clicking the link navigates the user to subsidiary destinations for the result. For example, the primary action for a result on a purchase order search may be to open the found purchase order. Other actions may include approval or rejection of the purchase order.

  • A line of attachments for this result of the form "Attachments: attach1 attach2 ...". Each attachment may consist of an icon followed by the attachment name. A search may match the search term within the attachment. Clicking an attachment will download and open the attachment. If there are no attachments, this line is not shown.

It is possible when viewing the search results, and narrowing your selections using the facet tree, to see counts against the nodes that do not add up. For example, a search on Glasses might return 16. Then if you filter the result by color, you may find Blue (5) and Red (10), which do not add up to 16. This count is the Oracle Secure Enterprise Search (SES) Approximate count based on heuristics, and not an exact count. To make the count exact, start SES and select Global Settings > Query Configuration, and click the Exact count radio button, as shown in Figure 15-32. Note that SES warns against this for performance reasons. See the Oracle Secure Enterprise Search Administration Online Help.

Figure 15-32 Setting the Exact Hit Count in SES

Two setup task flows are available for developers and customers to use in extending the Global Search metadata.

They will be available in the following Applications Core Libraries.

The created task flows are:

/WEB-INF/oracle/apps/fnd/applcore/globalSearch/
uiPublic/GlobalSearchManageConfigurationsTF.xml#
GlobalSearchManageConfigurations

/WEB-INF/oracle/apps/fnd/applcore/globalSearch/
uiPublic/GlobalSearchManageGroupsTF.xml#
GlobalSearchManageGroups

1. Select Setup and Maintenance from the Settings and Actions dropdown on the top of the page. See Using the Settings and Actions Menu.
2. On the Overview page, select the All Tasks tab.
3. Set the Search dropdown to "Task Lists and Tasks."
4. Enter "global search" in the Name field and click Search.

   The Application Global Search Configuration and Manage Suggestion Groups task flows are available under Define Global Search:

   Figure 15-33 Searching for Define Global Search in Settings and Actions

   

   Select the task flow you want to manage and click the Go to Task icon. The details are described in Setting Up a Global Search Configuration.

The configuration is loaded for the page each time it is loaded.

The algorithm is as follows:

• Determine the viewId and application for the loading page.

• Search for a configuration of type Page that matches the current viewId (unSEEDED, then SEEDED). If found, use it.

• Search for a configuration of type Application that matches the current application (unSEEDED, then SEEDED). If found, use it.

• Load the default.

In all cases, "like" searches are done, so SQL wildcards can be used and are recommended. For Application, these are required at the end because the application name often comes back with a version number, such as "HomePageApp(2.0)", so use an expression such as "HomePageApp%"

In all cases, if there is a customer (non SEEDED) configuration, it will be loaded before the SEEDed version.

As a developer there is no need to set up and ship a configuration to control the look and feel of Global Search. There is a default configuration that ships and Global Search will behave exactly how it always has. However, if you wish to change how Global Search appears to your customers, you can make and ship your own configuration. How this affects the search UI is described in this section.

Once you have clicked the Go to Task icon, described above, this dialog is opened:

Figure 15-34 Manage Global Search Configurations

From 1 (Short Name) to 11 (Last Updated Date), the fields are:

• (1) Short Name: The short name of the configuration. This is not shown in the Global Search UI.

• (2) Display Name: The display name of the Configuration. This is not shown in the Global Search UI. This value is translated.

• (3) Description: The Description of the Configuration. This is not shown in the Global Search UI. This value is translated.

• (4) Default: Is this the default configuration. There can be two Default configurations - a SEEDED configuration supplied by applcore that is the default configuration of Global Search. It cannot be changed or edited (the UI will prevent this), and a single default designated by the customer. A customer default will be loaded before the SEEDED default.

  No Oracle group should create a default group and ship it as SEED data.

  This is not shown in the Global Search UI.

• (5) Enabled: Is the group enabled. Only enabled groups can be used. This is not shown in the Global Search UI.

• (6) Product Family: The product family of the configuration. A configuration can only configure search groups in the Common product family (shipped by applcore and available on every pillar) and the same Product Family. This ensures that the Suggestion Group class can be loaded at runtime.

  This is not shown in the Global Search UI.

• (7) Module: The module of the Configuration. This is used by the SEED data extraction process to distinguish between different groups' SEED data.

  This is not shown in the Global Search UI.

• (8) Created By : Row Who. This is not shown in the Global Search UI. A row that has Created By = SEED_DATA_FROM_APPLICATION is considered SEED data.

• (9) Creation Date: Row Who. This is not shown in the Global Search UI.

• (10) Last Updated By: Row Who. This is not shown in the Global Search UI.

• (11) Last Updated Date: Row Who. This is not shown in the Global Search UI.

1. Select the configuration, as shown in Figure 15-34, and click the Edit icon.

   Note: SEEDED configurations cannot be edited. In particular, the SEEDED DEFAULT configuration can never be edited by developers or end users.

   This dialog, with the Autosuggest tab selected, is shown:

   Figure 15-35 Edit Global Search Autosuggest Configuration

   

   The fields in the top portion are described with Figure 15-34.

   From 12 (Enable personalization ...) to 19 (Maximum Number ...), the fields are:

   • (12) Enable personalization of search groups: Is the tab of Suggest groups seen in the search field popup behind the gear icon?

     If this and "Enable personalization of search categories" are no set, the gear icon is not shown.

   • (13) Suggestion Groups: The set of Suggestion groups to show. This is an initial developer design decision and determines the groups the user sees in the search popup. The user then can select a subset of these and this selection will be remembered in MDS. Shuttle the groups across that you want to show and override the default enabled state using the picker.

   • (14) Show Suggestion Group Headings: Whether to show the suggestion group header. The header includes an icon (if available) and the heading text.

     Be aware that turning headings off may run suggestions from different groups together making it hard to distinguish them.

   • (15) Show Icons: Should the suggestions show icons? If there is no icon available, or this is set to no, a bullet is shown.

   • (16) No Suggestions Message: Message to show if there are no matching suggestions. If there are no matching suggestions, the suggestion popup will not be shown.

   • (17) Show Top Suggestions: Whether to show top suggestions. Top suggestions are those shown in the suggestion list before the user has entered the "Minimum Characters for Autosuggest" and typically contains a static list of highly used suggestions as desired by the suggestion group author.

   • (18) Minimum Characters for Autosuggest: The minimum number of characters in the search field before search suggest switches from showing top suggestions to suggestions specific to the typed values.

   • (19) Maximum Number of Suggestions : The total maximum number of suggestions shown in the suggest list, spread evenly across all groups.

2. When finished editing the Autosuggest features, click the Search Field tab to display these settings:

   Figure 15-36 Edit Global Search Search Field Configuration

   

   From 20 (Minimum Number ...) to 24 (Placeholder), the fields are:

   • (20) Minimum Number of Characters: The Minimum number of characters required for searching. By default this is 1. This will affect the error message "You must enter keywords to search", "You must enter x character(s) to search."

   • (21) Maximum Number of Characters: The maximum number of characters the search field will allow. This sets the underlying af:inputText columns attribute.

   • (22) Automatically Clear Field Value after Search: Is the search field cleared after the search. This is a convenience allowing the user to enter new text without having to clear or edit the previous search terms.

   • (23) Label: The Label of the Search field. To have no label, leave this value blank. For accessibility purposes, the hidden label value will be "Search:"

   • (24) Placeholder: The placeholder or shadow text of the Search field. To have no placeholder, leave this value blank.

3. When finished editing the Search Field features, click the Search Results tab to display these settings:

   Figure 15-37 Edit Search Results Configuration

   

   From 25 (Enable saved searches) to 36 (Show Icons), the fields are:

   • (25) Enable saved searches: Whether the user can save a search. The Save button will be hidden.

   • (26) Enable recent searches: Whether recent searches are saved automatically as the user runs and filters searches.

   • (27) Filter Display Style: Whether the filters (Category filters only) are shown inline or using a popup.

   • (28) Enable personalization of search categories: Is the tab of Search Categories seen in the search field popup behind the gear icon?

     If this and "Enable personalization of suggest groups" are not set, the gear icon is not shown.

   • (29) Show subcategories in the search results: Should Searchable Objects, also called subcategories, be shown? If they are not shown, "Show Facets" is also false.

   • (30) Show Facets: Should facets for the selected subcategory be shown?

   • (31) Show hit counts: Should hit counts in the facets be shown?

   • (32) Enable clear all filters: Should the Clear Filters button be shown?

   • (33) Application: The application to which to restrict the search categories. This is optional and will restrict the categories shuttle to only the categories from that application. This drop box is populated with the unique applications with which all categories are registered in the ECSF database.

   • (34) Categories: The set of categories to show. This is an initial developer design decision and determines the categories the user sees in the search popup. The user then can select a subset of these and this selection will be remembered in MDS. To pick all categories (including those added in the future), leave the categories unshuttled.

   • (35) Last Updated Date Filters: The set of Last Updated Date to show. To pick all filters (including those added in the future), leave the filters unshuttled.

   • (36) Show Icons: Whether icons are shown in the results.

4. When finished editing the Search Results features, click the Pages tab to display these settings:

   Figure 15-38 Edit Global Search Pages Configuration

   

   The two fields are:

   • (37) View Type: The View Type to which to map this configuration. There are two types of view type: Application and Page.

     You may enter as many rows as needed here.

   • (38) View ID: This value depends on the View Type:

     Application: Enter the application short name with a wildcard at the end, for example HomePageApp%.

     To find the application name:

     1. Open the Setup and Maintenance work area and go to the Manage Taxonomy Hierarchy task.

     2. Expand the Oracle Fusion node, select a row with the Application module type, and click Edit Module.

     3. In the Application Details section, see the Application Short Name column for the value to use.

     Page: Enter the last part of the URL you get when you open that page. For example, enter ExamplePage from the URL.

     http://exampleServer/homePage/faces/ExamplePage

     Note that you cannot enter blind expressions, such as "%" because this effectively short cuts the configuration lookup algorithm. You must enter at least 5 characters that are not wildcard characters.

5. Click Save and Close or click the Manage Suggest Groups Configuration tab if it is available at the top of the page.

If Suggestion Groups have been implemented (see Create Suggestion Groups, the Manage Suggest Groups Configuration tab will be made available next to the Search Configurations tab, as shown here:

Figure 15-39 Manage Suggestion Groups Configuration

To manage a Suggestion Group, follow these steps:

1. Select a group and click the Edit icon. This configuration dialog is displayed:

   Figure 15-40 Edit Suggestion Group

   

   From 1 (Short Name) to 16 (Icon), the fields are:

   • (1) Short Name: The Short name of the Suggestion Group. This is not shown in the Global Search UI.

   • (2) Display Name: The Display name of the Suggestion Group. This is not shown in the Global Search UI. This value is translated.

   • (3) Description: The Description of the Suggestion Group. This is not shown in the Global Search UI. This value is translated.

   • (4) Displayed by default: Is this group displayed by default? This determines whether the suggestion group (see item 13 for Figure 15-35) is enabled by default. If it is not, the developer or customer can override the setting to enable the group. This allows a group to be registered and shipped in different configurations with different enabled items.

   • (5) Product Family: The product family of the suggestion group. A Global Search Configuration can only configure search groups in the Common product family (shipped by applcore and available on every pillar) and the same Product Family as the group is declared in. This ensures that the Suggestion Group class can be loaded at runtime by configurations in effect.

     This is not shown in the Global Search UI.

   • (6) Module: The Module of the Configuration. This is used by the SEED data extraction process to distinguish between different groups' SEED data.

     This is not shown in the Global Search UI.

   • (7) Created By: Row Who - this is not shown in the Global Search UI. A row that has "Created By" = SEED_DATA_FROM_APPLICATION is considered SEED data.

   • (8) Creation Date: Row Who. This is not shown in the Global Search UI.

   • (9) Last Updated By: Row Who. This is not shown in the Global Search UI.

   • (10) Last Updated Date: Row Who. This is not shown in the Global Search UI.

   • (11) Data Source: The suggestion group. This can be:

     One of the predefined suggestion groups. These are supplied in an autosuggest list on the field.

     An Expression Language expression that returns an oracle.apps.fnd.applcore.patterns.ui.behaviors.searchSuggest.AbstractSearchSuggestGroup.

     The fully qualified classname of an oracle.apps.fnd.applcore.patterns.ui.behaviors.searchSuggest.AbstractSearchSuggestGroup.

   • (12) Context Code: The Context Code for the suggest group, if it is known at registration time and is to be used in Global Search. Different group use contextCode as an initialization value in different ways. For example the Recent Items group will strip items by the contextCode and objectType. By default, Global Search sets no contextCode and objectType.

   • (13) Object Type: The Object Type for the suggest group; a sub-classification of Context Code, if it is known at registration time and is to be used in Global Search. Different groups use objectType as an initialization value in different ways. For example, the Recent Items group will strip items by the contextCode and objectType. By default, Global Search sets no contextCode and objectType.

   • (14) Heading Visible: Should the heading be shown for this group? Note that heading can be turned off for all groups at the "Global Search Configuration" level (see call out 14 in that section) overriding this value, though if the heading is off here it cannot be turned on at all.

     Be aware that turning headings off may run suggestions from different groups together and make it hard to distinguish them.

   • (15) Text: The Heading Text for the group. If set will override the heading text set in the java code of the Suggestion Group.

   • (16) Icon: The Heading Icon for the group. If set will override the icon set in the java code of the Suggestion Group.

2. Click Save and Close.

<af:inputText label="My Test Suggest Group: " id="simple">
    <fnd:searchSuggestBehavior suggestGroup1="oracle.apps.tla...MySuggestGroup"
         contextCode1="ifNeeded"
         objectType1="ifNeeded"/>
</af:inputText>

1. Use this boilerplate example to create a suggestion group. You will need to fill in the TODO items.

   import oracle.apps.fnd.applcore.patterns.ui.behaviors.searchSuggest.AbstractSearchSuggestGroup;
   import oracle.apps.fnd.applcore.patterns.ui.behaviors.searchSuggest.SearchSuggestItem;
    
   public class RequiresSubmitSearchSuggestGroup
   extends AbstractSearchSuggestGroup
   {
     /**
      * Unique name of this group.  Must be unique across all groups.
      */
     public static final String NAME = "uniquegroupname";
       // TODO add NAME.
     @Override
     public String getName()
     {
       return NAME;
     }
      
     @Override
     public String getDisplayName()
     {
       // Allow override of Heading in Manage Suggest Groups UI.
       String overRiddenDisplayName = super.getDisplayName();
       if (overRiddenDisplayName != null)
       {
         return overRiddenDisplayName;
       }
       return "Translated Heading";
       // TODO add translated heading.
     }
      
     @Override
     public String getIconURL()
     {
       // Allow override of Icon in Manage Suggest Groups UI.
       String overRiddenIconURL = super.getIconURL();
       if (overRiddenIconURL != null)
       {
         return overRiddenIconURL;
       }
       return "some/path/to/image.png";
       // TODO add icon.
     }
      
     @Override
     public List<SearchSuggestItem> getItems(String searchText,
                                             int maxSuggestedItems)
     {
       List<SearchSuggestItem> ret = new ArrayList<SearchSuggestItem>();
    
       // TODO add suggestion items based on searchText.
       // This call MUST return as fast as possible.  
       ret.add(...);   
    
       return ret;
     }
    
     @Override
     public List<SearchSuggestItem> getTopSuggestions(String searchText,
                                                      int maxSuggestedItems)
     {
       List<SearchSuggestItem> ret = new ArrayList<SearchSuggestItem>();
    
       // TODO add top items.
       // This call MUST return as fast as possible.
       ret.add(...);
        
       return ret;
     }
       
     @Override
     public void init(Map<String, Object> attributes)
     {
       // TODO: Look-up suggestions to use in getItems / getTopSuggestions if needed to allow fast calls of getItems / getTopSuggestions.
       // If they need to be looked up during those calls, you MUST ensure the lookup is fast as it will block the suggest field.
     }
    
     @Override
     public boolean requiresSubmit()
     {
       // TODO: true if the group value selection needs processSubmit(..) to process the selection, false if the suggestions are keywords
       return true;
     }
    
     @Override
     public boolean placeSelectedItemInField()
     {
        // TODO: true to place the selected item in the search field, false otherwise.
        return true;
     }
    
     @Override
     public void processSubmit(String item, Map<String, Object> attributes)
     {
       // TODO: Write code to look-up item and process it according to business rules.
     }
   }
   

2. Register the group in the setup UI.

   If your suggestion group is to be used in your own UI, just add it to your code.

   If the group is to be used in Global Search, register it in the "Manage Suggestion Group" UI. Use the fully qualified class name as the "Data Source". Use your "Product Family" and "Module".

   Set a "Context Code" and "Object Type" if necessary.

3. Register a configuration and include your group in it.

   Create a new configuration, or re-use an existing one that you control. The "Product Family" and "Module" should be the same as for the group you have registered.

   Set options as appropriate for your use case. Include the new group and any Common (Applications Core defined) groups you need. Override the display status using the "Enabled" drop box if you wish to change it.

   Map the configuration to your UI pages and applications.

   Do not set the configuration as a default configuration. There should be only one default configuration and that is developed and shipped by applcore. A customer can set a configuration of their own as a default to override the Applications Core default, but it should not be Seeded.

4. Extract and ship the setup.

   Development teams will:

   • Use the setup UI to define their metadata.

   • Ensure their module is set correctly for their LBA.

   • Use standard Seed data extraction utilities to extract that metadata and ship in their patches.

   Seed data will be extracted separately for:

   • Search Options

   • Search Groups

   Teams will only extract and ship Seed data for the modules they own.

   Use commands similar to these:

   $JDEV_JAVA_HOME/bin/java -cp $JDEV_HOME/jdeveloper/jdev/oaext/lib/oracle.apps.fnd.applseed-rt.jar:$MW_HOME/oracle_common/modules/oracle.xdk_11.1.0/xmlparserv2.jar:$MW_HOME/oracle_common/modules/oracle.odl_11.1.1/ojdl.jar \
   oracle.apps.fnd.applseed.rt.extract.Extract -dburl \
   jdbc:oracle:thin:@slcad942.us.oracle.com:1595:atgucfdv -dbuser fusion \
   -AM oracle.apps.fnd.applcore.search.model.applicationModule.FusionSearchAM \
   -VO FndFusionSuggestGroups \
   -ExtractRootPath $ADE_VIEW_ROOT/atgpf/applcore/db/data
   

   # Search Options.
   $JDEV_JAVA_HOME/bin/java -cp $JDEV_HOME/jdeveloper/jdev/oaext/lib/oracle.apps.fnd.applseed-rt.jar:$MW_HOME/oracle_common/modules/oracle.xdk_11.1.0/xmlparserv2.jar:$MW_HOME/oracle_common/modules/oracle.odl_11.1.1/ojdl.jar \
   oracle.apps.fnd.applseed.rt.extract.Extract -dburl \
   jdbc:oracle:thin:@slcad942.us.oracle.com:1595:atgucfdv -dbuser fusion \
   -AM oracle.apps.fnd.applcore.search.model.applicationModule.FusionSearchAM \
   -VO FndFusionSearchOptions \
   -ExtractRootPath $ADE_VIEW_ROOT/atgpf/applcore/db/data
   

   Use the

   [-PartitionKeyIds <Taxonomy ModuleId values> | -PartitionKeyNames <Taxonomy short name values>] 
   

   parameter to get the Seed data for your product. See Initializing Oracle Fusion Application Data Using the Seed Data Loader for a full description of Seed Data.

Figure 15-47 shows a URL Action.

Figure 15-47 Search Result Actions - URL Action

For URL Action Types, the Oracle Fusion Applications Search will open a new browser tab or window containing the URL. To configure this type, add a URL Search Result Action with these parameters.

• A unique name

• Action Type of URL

• An Action Target to the required destination, including groovy substitution parameters

• A Title

No Parameters are required; however a single iconURL parameter may be defined if an icon is required for the URL action. See Table 15-11.

The icon will be shown in the search results with the title given in the Title field. When clicked, a new browser tab or window will open with this URL.

Figure 15-48 shows a Task Action.

Figure 15-48 Search Result Actions - Task Action

For Action Types of Task, the Oracle Fusion Applications Search will open a UI Shell tab in the current page, or a new page containing the task flow. To configure this type, add a Task Search Result Action with these parameters.

• A unique name

• Action Type of Task

• A Title

Parameters are shown in Table 15-12. Note that, although this table resembles Table 15-13, it presents the use case that the majority of users will use. The information in Table 15-13 is for a very small use case.

The action will be shown in the search results with the title given in the Title field. When clicked, a new UI Shell tab window will open with this task flow. If the viewId parameter is for the current page, the UI Shell tab will be in the current page; otherwise the current page will be replaced with a new UI Shell page with the search result.

public void globalMenuNavigate(String globalItemNodeId,
                               String taskItemNodeId,
                               String taskParametersList
                               FndMethodParameters methodParameters)

public void globalMenuNavigate(String globalItemNodeId,
                               String taskItemNodeId,
                               String taskParametersList
                               FndMethodParameters methodParameters)

public void globalMenuNavigate(String globalItemNodeId,
                               String taskItemNodeId,
                               String taskParametersList
                               FndMethodParameters methodParameters)

/WEB-INF/oracle/apps/fnd/applcore/patterns/uishell/GlobalSearchDummyResultsTaskFlow.xml#GlobalSearchDummyResultsTaskFlow

This information applies to the next three parameters: FUSETaskFlowId, FUSENavTaskKeyList and FUSENavTaskLabel.

Starting with Release 11, Applications Core ships a single FuseOverview page used by all Oracle Fusion applications. All content is supplied by the menus.

The pre-Release 11 navigation will continue to work, however there is a limitation on the taskflows that can be opened. That is addressed by these new parameters.

The navigation made by this call will only navigate to a defaultMain taskflow:

FndUIShellController.globalMenuNavigate(FUSECardCode, FUSEObjectCode, FUSETaskflowParamsList, null)

This is okay for some teams because they open the results in a popup using adfc navigation flow cases built into their flows.

For teams coming new to FUSE search in Release 11, the requirement is to open a dynamicMain taskflow, much the same as in classic UIShell.

With the addition of these parameters a user can be sent to a dynamicMain taskflow.

There are now two use-cases for configuring FUSE Task Action parameters:

• The original defaultMain navigation:

  Enter FUSECardCode, FUSEObjectCode, FUSETaskflowParamsList parameters only.

• New dynamicMain navigation:

  Enter FUSECardCode, FUSETaskflowParamsList, FUSETaskFlowId and, optionally, FUSENavTaskKeyList and FUSENavTaskLabel.

  Do not enter FUSEObjectCode.

The Classic UIShell and FUSE parameters can continue to co-exist in the same action.

Ordinarily, taskFlowID uses the format <path><name>.xml#<name>; for instance taskFlowID="/WEB-INF/CaseDetails.xml#CaseDetails". However, Oracle Fusion Applications Search has taskFile and taskName attributes as shown in Figure 15-48. The code will merge them, adding the "#," so they become <taskFile>#<taskName>.

Parameters always are passed as parameter name=value. Often, it is either a literal value or an expression to an attribute such as col1. Example 15-22 shows how to pass four parameters.

<SearchResultActions>
  <Action
    Name="View Lookup Type"
    ActionType="Task"
    DefaultAction="true">
    <Title>
      <![CDATA["Lookup: " + Meaning]]>
    </Title>
    <ActionTarget>
      <![CDATA[null]]>
    </ActionTarget>
    <Parameters>
      <Parameter Name="navTaskParametersList">
        <Value>
          <![CDATA["lookupType=" + LookupType + ";viewApplicationId=" + ViewApplicationId + ";language=US;meaning=" + Meaning]]>
        </Value>
      </Parameter>
      <Parameter Name="webApp">
        <Value>
          <![CDATA['GlobalSearch']]>
        </Value>
      </Parameter>
      <Parameter Name="TaskFile">
        <Value>
          <![CDATA["/WEB-INF/LookupTypeSearchResultsTaskFlow.xml"]]>
        </Value>
      </Parameter>
      <Parameter Name="navTaskKeyList">
        <Value>
          <![CDATA["meaning=" + Meaning]]>
        </Value>
      </Parameter>
      <Parameter Name="TaskName">
        <Value>
          <![CDATA["LookupTypeSearchResultsTaskFlow"]]>
        </Value>
      </Parameter>
      <Parameter Name="viewId">
        <Value>
          <![CDATA["TestUIShellPage"]]>
        </Value>
      </Parameter>
    </Parameters>
  </Action>

In the ECSF search UI in JDeveloper, it is possible to define no action, or a single default action.

If a default action is defined, it will be used. The other actions will be shown in sorted order based on task title. If no default action is defined, the first sorted action will be used as the default action.

This sorting mechanism is used because there is no way, using the current ECSF APIs, to provide a stable order of actions.

Due to this sorting mechanism, it is strongly recommended to have stable, sortable task titles (they may be groovy bound and therefore mutate based on an individual search result) to prevent confusing the end user.

When the user is using Oracle Fusion Applications Search before saving a search, he or she may perform several interactions with the UI including:

• Expanding the attribute filters by selection (performs searches)

• Narrowing the search terms

• Opening unsearched groups (which performs searches in those groups)

• Scrolling through results in a group

This is called the click path of the user.

When a search is saved, some of this information (the structural part at the tip of the click path) is saved, but prior actions and exact scroll positions are not. This means that when running a saved search, the following items are not restored to the user:

• Exact expanded groups in the result at the time of save

• Scroll positions within a group

• Full LOV expansion state of attribute filters

When ECSF returns facet information, it returns facet entries only for the level below that which is selected. For example, if there are no filters, the facets will be shown correctly with one level of detail. If a first-level facet is selected, that selection will be shown, but not its siblings. If there are facets below that level, this next level will be shown as these are returned. As the user starts to refine or expand the attribute filters, the search filters will be filled in based on this new click path.

Oracle Business Intelligence results will be shown in a results area separate from Oracle Fusion Applications Search view object results. To implement this separation, Oracle Fusion Applications Search shows results in a multiple-tab format.

The tabs are named Applications, where all Search view objects and WebCenter Portal results will reside, as well as Business Intelligence. The split is performed at a category (or searchable groups) level, so you will see a consolidated list of categories in the multi-select category dropdown. These categories are split at search time.

The business rule that splits categories into the Oracle Business Intelligence table is a lowercase category_name, such as bi_%.

Although the formatting of Oracle Business Intelligence results will be slightly different, no developer action is required.

Users must be defined in multiple applications if you do not have a single authentication store.

Ensure that you have a user defined that is common across both Fusion Applications and any external applications such as Oracle WebCenter Portal or Oracle Business Intelligence.

For instance, you can create an fmwadmin user on the Oracle Fusion Applications side by adding to the jazn-data.xml file.

With Oracle Secure Enterprise Search (Oracle SES) Authentication pointing to the ECSF SearchFeedServlet, which is using the WebLogic Server container security, this user will be verified by the Oracle SES authentication callbacks.

In a true enterprise environment, both the Oracle Fusion Applications web container and WebCenter Portal would be set up with the same OID.

Using two different authentication stores will mean you get multiple logins when clicking results.

1. In the ECSF Search view object design time, add a Search Plugin to the Applications Core class oracle.apps.fnd.applcore.search.plugin.FndSearchPlugin.
2. Configure attachments that will be crawled.

   Add a parameter with a comma-separated list of accessor paths with key ATTACHMENT_VIEW_LINK_ACCESSOR_PATHS.

3. Configure searchable view object incremental crawl detection of searchable view objects with new attachments.

   Optionally, add an attribute with key INCREMENTAL_CRAWL_ATTACHMENT_ENTITY_NAME and value of the Attachment Entity Name (the value you enter in the Attachment View Link wizard, such as GS_PRODUCTS).

   This will add searchable view objects to the crawl list when new attachments are added. This is useful as the searchable view object last_update_date value is not updated when an attachment is added, and the document will not be detected as needing a re-crawl. This will flag the individual searchable view object row to be recrawled. Note that it is not possible to detect changed attachments this way at the detail level (for example a purchase order line's attachments), because the reverse lookup would obtain the primary key of the line item and not the searchable view object.

1. Extend the Applications Core plugin and call super() on the methods that implement attachment functionality. Use the same parameters to the plugin as described above.

   public class AppsSearchPlugin
     extends FndSearchPlugin
     implements PreIndexProcessor,
                ChangeListener
   {
     /**
      * Hook into the pre index process of the crawl so we can annotate the SVO
      * with apps specific information such as tags and attachment metadata.
      * @param ctx Search Context.
      * @param docs Documents to iterate and find tag children for.
      */
     public void preIndexProcess(SearchContext ctx,
                                 List<IndexableDocument> docs)
   {
     super.preIndexProcess(ctx, docs);
     // custom apps functionality ...
    
   }
       /**
      * Get the change list for crawling.
      * @param ctx Search Context.
      * @param changeType the type of the change requested. Must be one of following
      * <ul>
      * <li>ChangeListener.UPDATE<li>
      * <li>ChangeListener.INSERT<li>
      * <li>ChangeListener.DELETE<li>
      * </ul>
      * @return an iterator of a list of primaryKeys. Returns an empty iterator if
      * nothing changed.
      */
     public Iterator getChangeList(SearchContext ctx, String changeType)
     {
        Iterator ret = super.getChangeList(ctx, changeType);
       // custom apps functionality ...
       return ret;
     }
   }
   

2. Add the transient stored attribute FND_ATTACHMENT_METADATA.

   Add a transient String attribute to the searchable view object named FND_ATTACHMENT_METADATA to store Applications Core attribute metadata. Flag this attribute as stored in the searchable view object definition.