Sample search application

The sample search application comprises two separate packages that contain two individual applications. The search servlet application EAR file name is search.ear and the search portlet application file name is searchportlet.war. The search.ear file contains a Web Application Resource (WAR) file named ESSearchApplication.war, which contains the stand-alone search application.

Overview

The sample code for the search application is provided in the ES_INSTALL_ROOT/samples/search directory.

The search application is built by using a number of modern Web technologies and frameworks that include but are not limited to the ones that are listed here. You must be familiar with these technologies before you customize the source code for the applications.

Apache Struts 1.2
WebSphere Portal Struts Portlet Framework
Java™ Servlet Specification Level 2.4
Java Server Pages (JSP)
JavaScript™
Asynchronous JavaScript and XML (AJAX)
Dojo toolkit version 1.3.2
Cascading Style Sheets (CSS)

Struts and the Struts Portlet Framework

Apache Struts is a popular open source project for implementing Web applications that use a Model-View-Controller (MVC) design pattern. The Model consists of the business logic or database layer, the View represents the page design, and the Controller represents the code that is used to control the navigation through the application. By separating these three aspects of the design of a Web application, the Struts framework allows for extensibility and maintainability. The reasons for the popularity of the Struts framework in a standard servlet environment also apply to developing portlet applications.

The Struts Portlet Framework allows developers to build portlet applications for use in the WebSphere Portal environment by using the Struts framework. With the exception of a few special considerations, the packaging and structure of a Struts portlet application is very similar to that of a standard Struts servlet application. Due to these similarities, a single code base can be used to create both a sample search servlet application and a sample search portlet application.

Java classes

The Java classes that make up the sample search application are shared across all three of the Web application samples that are provided. The source code for these classes is included with the product in the ES_INSTALL_ROOT/samples/search/source directory. The classes are divided into the following packages under the com.ibm.es.oze.searchui base package:

actions: This package contains all of the REST servlet implementation classes that support the responses with client XMLHttpRequest that the user can take within the search application view. Additionally, there is one specialized class, InitAction. This class implements the org.apache.struts.action.PlugIn interface. This class is used only within the sample search servlet application to perform some initialization tasks before loading the actual Struts ActionServlet class.
common: This package contains utility functions for use by the entire application.
facet: This package contains implementation classes for Facet Tree and Category Tree.
fetch: This package provides clickable URL support for documents that are crawled by crawlers that are not directly URL-addressable, such as the Windows file system or Content Integrator crawlers. When a user clicks such a URL, the request is forwarded to this servlet, which in turn writes the file contents directly to the servlet's output stream.
helpers: This package contains classes that encapsulate several functions, including the SIAPI methods, identity management API methods, and the objects that are used by the category tree.
query: This package contains bean objects and utility classes related to queries.
resources: This package contains the translated resource bundles for the application. All of the predefined strings displayed on the application screens are contained in these bundles.
valueObjects: This package contains value objects (beans) that are used by the application to pass information between the Action classes and the View (JSP pages).

Web content

The directory structure for the Web applications is very similar. Many of the JSP pages and other Web application support files are shared. The source code for these files is included with the product in the ES_INSTALL_ROOT/samples/search/WebContent directory. The following information describes the content and layout of the directory structure, starting from the root directory:

root: The root directory is the directory named after the Web application. This directory contains all of the JSP pages for the given application and other subdirectories. For example, the root directory for the search portlet application is named searchportlet.war. When working with the source code, the root directory is the WebContent folder.
common: This directory contains JSP pages that are commonly included by other pages or used as utilities. For example, headers of each page or dialogs that are used in some pages.
css: This directory contains all of the cascading style sheet (CSS) files that are used by the various Web applications. The majority of the style sheets used within the search servlet application are provided by WebSphere Portal so that the appearance and behavior of the servlet application matches the portlet application.
images: This directory contains all of the image files that are used by the Web applications.
layouts: This directory contains all of the layout JSP pages. These JSP files determine how the view of the application is structured in different instances. For example, different layouts are defined for the servlet application and the portlet application.
META-INF: This directory contains the files that are included in the META-INF directory of the search.ear file. These files include the enterprise application deployment descriptor and the WebSphere policy file.
js: This directory contains various JavaScript files that are used to provide some of the advanced interactivity within the search applications. Some of these functions include the calendar pop-ups, the search result tooltip preview, the AJAX functionality for the top results analysis charts, the AJAX functionality for the search application customizer, the AJAX functionality for the search result paging, and some helper functions. Most of these capabilities are implemented as widgets of the Dojo toolkit.
WEB-INF: This directory is a required directory in any Web application. This directory contains the struts-config.xml definition file, the Web application deployment descriptor, the config.properties file that is used to control the search servlet application settings, and the portlet deployment descriptor that contains the definitions of the portlet application.
WEB-INF/jetty: This directory contains the Web deployment descriptor (web.xml) and Struts configuration definition (struts-config.xml) for the servlet application on Jetty Web server.
WEB-INF/portal: This directory contains the Web deployment descriptor (web.xml), Struts configuration definition (struts-config.xml), and portlet deployment descriptor (portlet.xml) for the portlet application.
WEB-INF/tld: This directory contains all of the tag library definition (tld) files for the applications. The tag library definition files include the standard Struts tld files and the custom OmniFind® Enterprise Edition tld file.
WEB-INF/was: This directory contains the Web deployment descriptor (web.xml) and Struts configuration definition (struts-config.xml) for the servlet application on WebSphere Application Server.

Search portlet application

Despite the fact that the majority of the JSP and Java source is shared between the servlet application and the portlet application, several differences are worth noting:

Configuration parameters: The portlet application does not use the config.properties file and it does not support the search application customizer. The portlet's configuration is controlled through the WebSphere Portal Administration Portlet configuration interface.
Action and Render phases: The portlet application has multiple Action class implementation classes for the Action phase and Render phases of the portlet life cycle. This distinction between phases in the WebSphere Portal Server framework requires the IStrutsPrepareRender interface. See the following developerWorks® article for more information: http://www.ibm.com/developerworks/websphere/techjournal/0504_pixley/0504_pixley.html

Logging and debugging

The search applications all share a common way of logging trace and error information. The logging and tracing infrastructure for the applications is built by using the Java Logger classes provided in the core J2SE Java Runtime Environment. The LogUtil Java class defines a root logger for the com.ibm.es.oze.searchui package. This root logger is initialized with the logging.level property when the search application is initialized.

The default logging level is set to SEVERE, which means that the applications, as provided, log only Java Exceptions. You can enable more detailed information to be logged by changing the logging.level property to INFO, FINE, FINER, FINEST, or ALL. For the servlet application, you can change the logging.level property by using the search application customizer or by changing the ES_NODE_ROOT/master_config/search/search/config.properties file. For the portlet application, you can change the logging.level property by using the WebSphere Portal Administration and changing the Portlet parameter value.

The various levels of logging add information and add overhead to the applications. Some examples of the types of information logged include:

The query string and any security constraints
The processing of the identity management component, including such things as the user name that is entered by the user, the source type, and any data returned from the identity management APIs
The values of the HTTP headers and request parameters and any cookies that are included with the request
The user name of the current user, if security is enabled

In the case of the servlet application, the logging information is written to the ES_NODE_ROOT/logs/jetty/searchapp.node1.searchapp.0.log file. For the portlet application, the logging information is written to the WebSphere Portal Server SystemErr.log file.

Compiling the applications

The sample code for all three of the sample applications can be compiled from the command line by using a single build process. To build the applications, you must install and configure the following tools:

Apache ANT: ANT is a standard, open source tool for building source code by using an XML descriptor file. For more information about how to install and configure Apache ANT, see http://ant.apache.org.
IBM® Java Development Kit 1.6.0: The IBM Java Development Kit 1.6.0 is the IBM implementation of the Java Development Kit. For more information about how to install and configure the IBM JDK, see http://www.ibm.com/developerworks/java.

The ANT XML descriptor file (build.xml) is in the ES_INSTALL_ROOT/samples/search directory. This single ANT build definition file contains instructions on how to build all of the sample applications in a single build process. When the build is done, the message BUILD SUCCESSFUL is displayed on the console. The output of the build is located in the ES_INSTALL_ROOT/samples/search/bin subdirectory and consists of the following files:

search.ear: Contains the search.war servlet application.
searchportlet.war: Contains the search portlet application. This file can be deployed onto a WebSphere Portal Server by using the WebSphere Portal administration interface.

To compile the sample search applications:

From the command line, change to the ES_INSTALL_ROOT/samples/search directory.
Enter the command ant. This command automatically invokes the ANT build process and uses the build.xml file.

Rational Application Developer

Typically, many development organizations work with the source code in a graphical user interface such as the Eclipse framework. OmniFind Enterprise Edition includes support for working with the servlet application within the Rational® Application Developer version 7.5 product.

The product includes two Project Interchange ZIP files that you can import into a Rational Application Developer environment. These files are located in the ES_INSTALL_ROOT/samples/search/rad subdirectory:

search.zip, which is for a stand-alone search application
searchportlet.zip, which is for a search application that runs as a portlet in WebSphere Portal

To import the servlet application Project Interchange file in to your Rational Application Developer environment:

Open the Rational Application Developer tool.
Click File > Import.
Select Other > Project Interchange and click Next.
Click Browse next to the From ZIP file list and browse to the ES_INSTALL_ROOT/samples/search/rad subdirectory.
Select the ZIP file that you want to use and click Open.
Click Select All to select both the EAR and WAR projects and then click Finish.

After importing the Application. Open the resource folder and unzip the Full_buildscripts_1.3.2_20090825-IBM_dojo_archive.zip , which contains the dojo folders. Place all this dojo folder under the dojo folder in webcontent. The Searc Project structure look like :-

Also copy the all the jar under lib folder in WEB-INF

Now open the config.properties file and defaultConfig.properties and give the omni find server name and all details if server is at remote location

Also you can give the collection name under the field :-

By default it will take all the collection if we don't give specific collection name

Now Build the project and export the EAR. Deploy the ear on was console. After deploying. Open the Ear and click on Security role to user/group mapping and set subject as Everyone for All Authenticated role. If you are configuring search application for all authenticated user

Run the application by hitting the URL like :- https://locallhost:[Portnumber]/search/search.do?action=index&query=demo

where here query is the query parameter for search input.

Now once application is running you can configure the application based on the client requirement by removing unwanted features one by one.

Given below is the brief about the flow of the Search Applciation:-

1. Omni Find Search Application is a struts based application.

2. If you want to create a EAR then copy the xml file from WAS folder and paste in the Web-Inf

3. Flow of application:-

a. First the InitAction action class will load because this is a plugin class[<plug-in className="com.ibm.es.oze.searchui.actions.InitAction"></plug-in> under struts-config.xml], which will load the properties file and put in the session.

b. After that ForwardAction class will call and it will initialize all the parameter under the index method.

c. Then it will forward to RenderAction class which will forward to Standard.jsp if its not a porlet application.

d. Standard.jsp will call the Contents.jsp file.

e. Contents.jsp file will include all the required jsp file and build a view for the search query.

IBM WebSphere Application/Portal Server

Tuesday, 6 December 2011

How to configure and run the Sample OmniFind9.1 Search Application