Searching Enterprise Applications (Siebel 7 - Oracle



Searching Enterprise Applications (Siebel 7.8 and E-Business Suite 11i) with Oracle Secure Enterprise Search 10.1.8

An Oracle White Paper

Jan 2007

Searching Enterprise Applications (Siebel 7.8 & E-Business Suite 11i) with Oracle Secure Enterprise Search

Executive Overview 3

Introduction 3

Architecture: Using Search as a Service 4

Text Indexing vs. Search Federation 5

Integrating Oracle Secure Enterprise Search and Applications 6

Indexing and Searching Application Content 6

Secure Searching of Indexed Application Content 6

Steps to enable Secure Crawling of Application Content 7

Secure Application Content Search Examples 8

Searching other business modules 18

Suggested Links, Suggested CONTENT and Search Federation 19

Suggested Links 19

Federated Suggested Content 20

Federation of Search and Result Merging 24

Conclusion 24

Executive Overview

Using an enterprise search engine to access application data is a natural and powerful extension of the familiar, language-based, single search box and search results page user interface which allows more users to easily access and leverage information managed in enterprise applications. Oracle envisions Search as the primary point of integration and of access to all enterprise applications and data sources. Customers will benefit from increased productivity for employees, managers and executives through reduced training, quicker intuitive access, and unified multi-source results. In this paper, we look at how Oracle Secure Enterprise Search can handle such enterprise application data sources.

Introduction

Oracle Secure Enterprise Search (SES) is a product that enables you to find information within your corporate intranet by keyword or contextual searches.

SES can now be extended to provide simple, fast and secure access to applications stored within a variety of Oracle applications (e.g. E-Business Suite, Siebel, etc.), and to use this capability as a distinguishing user experience advantage.

Enabling search for Enterpise Applications enhances users’ experience by providing:

o Direct Navigation

Users can go directly to an application menu function or option based on keywords. For example, typing in “notifications” should be able to provide a link that can take the user directly to his / her “notifications” page within the Employee Self-Service menu in E-Business Suite.

o Speedy and Secure Information Retrieval

Users can quickly search and retrieve relevant application’s transactional and non-transactional data in the context of application sources, using simple keyword input or in combination with advanced search criteria, much in the way they use traditional search engines. Because most of the time we are dealing with protected application sources, the underlying access and security policies from each application must be enforced.

o Unified Search across multiple application modules

Users can use SES as a single point of searching and accessing information across multiple application modules. Thus users need not have to know which application module contains the relevant information before searching. This also helps in collating information from multiple application modules in a single screen without having to first navigate to each module.

o Visualization

Finally, the visualization of information specific to a datasource can further enhance the productivity of the end user. For example, instead of showing a standard hit list for human resources people results, it might be more useful to show a simple table for each hit that contains all the relevant information (e.g. name, address, contact information, etc.) upfront in an easy-to-understand format.

This document explores the various ways that searching enterprise application data can be implemented securely, thus preventing access to that content by unauthorized users.

Architecture: Using Search as a Service

Oracle Secure Enterprise Search is a standalone product that provides a simple to use, yet powerful way of searching all your data. Oracle SES is a self-contained product that can crawl and index any content and returns Internet-like search results. It also provides a query service API that can be plugged easily into various components to get a search service.

The SES data store accepts a document (which may be composed or virtual) along with a set of metadata attributes and security information.

SES consists of the following components:-

• Crawling Component – Provides an infrastructure for plugging in various crawler agents and to process the crawled data by extracting various metadata.

• Indexing Component – Provides infrastructure for indexing the crawled documents along with their metadata and security attributes using the database text engine.

• Query Component – Provides the infrastructure for answering the end user’s search using the text index. It also includes other technologies to enhance the search such as suggested links, suggested content, alternate keywords etc. It also provides support for federating the search to other SES instances.

• Administration Component – Provides support for administering all the components

• Security Component – Provides the infrastructure for plugging in different identity and authorization mechanisms which is flexible enough to support complex security models in applications.

• Presentation Component – Provides the external presentation for the search results along with web service APIs for the query and administration components. The web service APIs allows SES to be installed and configured separately while participating in an SOA environment as a search service.

In short, SES provides a search platform that can be used to provide a rich search experience to the end user.

Text Indexing vs. Search Federation

There are two different but complementary techniques, which can be used to search enterprise application content:

i. Collect the content from application sources and create a text index on it. The process of collecting this information is known as crawling, and is performed by a crawler. Once the index is created for a given data source it becomes immediately searchable. This is the traditional enterprise search engine approach.

ii. Federate or broker the query to an external search provider that can take the query as input and produce an instantaneous response, usually limited to a very small number of results, which can be either merged with the regular search results or shown separately. The underlying provider could be serving either text-indexed data or real-time transactional data. This is the traditional enterprise portal approach.

As we will see, Oracle SES natively supports crawling and indexing as well as federation to other SES instances and can be easily extended to support any arbitrary search engine provider either for result merging or for separate data access display.

Integrating Oracle Secure Enterprise Search and Applications

There are two modes in which enterprise application search can be deployed: the SES standalone case and the embedded search case. In the standalone case, users can come directly to the search site and search for application data, while in the embedded case the user is inside the application context and performs a search through the application.

In this paper, we will focus on the standalone search case and show how we can search application content using SES as the main point of entry.

Indexing and Searching Application Content

Secure Searching of Indexed Application Content

Security for searching usually consists of two steps: a) authenticating the user against a directory service that typically holds user/group information and b) restricting the search results to only those people authorized to see them. Application security is often complex and does not lend itself easily to a simple user/group model. Often there are dynamic security rules that must be applied.

Authentication: E-Business Suite & Siebel authenticate users either at the database level or through Single Sign On. In the case of single sign on, the user is authenticated through an LDAP directory using the SSO server. Here, the identity plugin appropriate for the directory service must be used (e.g. Active Directory or OID).

In the case where the database authentication is used, SES 10.1.8 supplies an identity plugin that can be used to authenticate users coming to SES. This authentication plugin talks to the database and verifies the user’s identity.

Authorization: E-Business Suite applications often use complex security constraints which do not lend well to the traditional user and group security model. SES allows a flexible authorization model in addition to the traditional user-group security model. In the flexible authorization model, a crawler can supply security attributes for each document. During query time, an authorization plugin must supply the appropriate values for these security attributes for the logged in user.

For instance, the HR OLM – Courses module uses activity_version_id column for securing the content, whereas the Procurement module uses employee_id for securing the objects. Siebel modules use business ID (BU_ID) or position (POSTN) to secure various business objects. During crawl time, each document must be annotated with the values of these security attributes and during query, the appropriate security values for the logged in user must be supplied by the authorization plugin.

Real Time Security Filtering: If the security cannot be fully established during crawl time due to dynamic or fast changing security attributes or the security enforced between crawls must be checked, the Result Filter plugin can be used. A Result Filter is a customer-provided plugin that is called once the search returns results. The plugin can prune the result list based on the current user’s security.

Steps to enable Secure Crawling of Application Content

SES 10.1.8 allows secure searching of E-Business Suite 11i and Siebel 7.8 by fetching the business object data and security information through JDBC.

Future releases of SES and Siebel/E-Business Suite will use an extended RSS mechanism to communicate change information and the JDBC access to the data will not be required.

Following are the steps for setting up search for each distinct application module (i.e. datasource):

1. Identify the target application to search

2. Understand what needs to be searched

a. Consider what makes up “a document”. For example, if the target is a human resources database, all the information about each employee can be treated as single document, but a “summary” documents for each department with a list of all employee names within that department can also be created.

3. Understand how changes should be captured

a. The SES E-Business Suite 11i & Siebel 7.8 crawlers require that the last modified date be changed for each document with every change to the document content or its attributes.

4. Understand the target Application’s Security Model

o Understand the objects (or data) to search and how their security is mapped. For example, an object might be viewable by a set of users and/or roles.

o Identify if there is a way to invert the security – i.e. given a document, can you get the list of users/roles/attributes that can be used to limit who can view the document?

o Conversely, given a user, can you identify the roles/attributes that belong to the user?

5. Create the SQL statements and views necessary to construct the document along with the security attributes and authorization query to list the security attributes for a logged-in user.

6. Enable the Identity Plugin

a. SES provides default identity plugin implementations for EBS 11i and Siebel 7.8 applications. The identity plugin authenticates the end user logging into SES by talking to the database authentication modules. Activate the identity plugins appropriately supplying the connection information and an administrative login for authenticating/validating users. If the target applications use single sign on, then you can use the identity plugins that talk to the appropriate LDAP directory services for authentication.

7. Create the datasource

o SES provides default crawler plugins for crawling EBS 11i database instance and Siebel 7.8 databases. Create the appropriate datasource and plug-in the SQL statements for authorization.

Secure Application Content Search Examples

Let us take three sample examples to illustrate how to setup the system for crawling applications, namely, E-Business Suite HCM (Human Resources), E-Business Suite Procurement and Siebel’s Service Request modules. The queries for these are supplied with SES 10.1.8 and are illustrative of how to setup the application searches for other modules.

E-Business Suite Modules

Authentication set-up for E-Business Suite 11i sources

SES 10.1.8 provides an identity plugin for E-Business Suite 11i application, which can be used while setting up data sources for any any E-Business Suite 11i module. This identity plugin communicates with the EBS 11i’s database to authenticate and validate users.

[pic]

the identity plugin for an EBS11i data source can be set-up as depicted in the above figure. The parameters for activating the identity plugin are as listed below:

1. User Validation Database Connection String: JDBC connection string for the EBS 11i database

2. User ID: User Id to login to the EBS 11i database

3. Password: Password to login to the EBS 11i database

4. User Authentication Query:

SELECT fnd_web_sec.Validate_login(upper(?),?) FROM dual

5. User Validation Query:

SELECT 1 FROM fnd_user WHERE user_name = upper(?)

Source set-up for EBS 11i - Procurement Module

The crawler plugin for EBS 11i can be set up to crawl the Procurement data.

Prior to setting up a source to crawl Procurement module, the SES integration patch (ARU Patch No. 5608131) must be applied to EBS. This patch creates the views necessary in EBS database for crawling.

The parameters for setting up the crawler plugin to crawl procurement module are as described below:

1. Database Connection String: JDBC connection string for the E-Business Suite database from which the content has to be crawled.

2. User ID: User ID to login to the E-Business Suite database.

3. Password: Password to login to the E-Business Suite database.

4. View: ICX_POR_SES_REQS_V.

5. Document Count: -1

[pic]

Source Setup for EBS 11i Procurement Module

[pic]

Authorization Setup for EBS 11i Procurement Module

6. URL Prefix:

7. Cache File: Local file to which the contents can be temporarily cached while crawling. For example, /tmp/cachefile

8. Path Separator: #

9. Parse Attributes: False

10. Grant Security Attributes: EMPLOYEE_ID

Authorization in EBS 11i - Procurement

The parameters for authorization plugin are as follows:

1. Authorization Database Connection String: JDBC connection string for the authorization database. The values of the security attributes to which a given user is authorized will be retrieved from this database.

2. User ID: User ID to login to the authorization database

3. Password: Password to login to the authorization database

4. Authorization Query:

SELECT employee_id FROM fnd_user WHERE user_name = upper(?)

5. Single Record Query: TRUE

The Procurement module can now be crawled and indexed to enable users to search their requisitions. The search result will be restricted to only those requisitions that the currently logged in user is authorized to view.

[pic]

[pic]

Source set-up for Human Resources – Employee Directory

SES cab be setup to crawl and search Employee directory. The SES integration patch (Patch No. 5728152) must be applied to EBS to load the necessary views. The source to crawl the directory can then be set up with the following parameters:

1. Database Connection String: JDBC connection string for the E-Business Suite database from which the content has to be crawled.

2. User ID: User ID to login to the E-Business Suite database.

[pic]

Source Setup for EBS 11i Employee Directory Module

3. Password: Password to login to the E-Business Suite database.

4. View: hr_ses_empdir_v

5. Document Count: -1

6. URL Prefix:

7. Cache File: Local file to which the contents can be temporarily cached while crawling. For example, /tmp/cachefile

8. Path Separator: #

9. Parse Attributes: True

10. Grant Security Attributes: person_id

Authorization in Human Resources - Employee Directory

The authorization plugin parameters are as listed below:

1. Authorization Database Connection String: JDBC connection string for the authorization database. The values of the security attributes to which a given user is authorized will be retrieved from this database.

2. User ID: User ID to login to the authorization database

3. Password: Password to login to the authorization database

4. Authorization Query:

SELECT distinct person_id FROM hr_ses_empdir_filter_v

WHERE level Director->Manager->Employee. The components of the path must be separated by “/” symbol.

▪ ATTACHMENT_LINK (varchar2) - if you have a public HTTP Link to your attachment, we can crawl that page using this column. This will be used INSTEAD of the solution or attachment columns.

▪ CONTENTTYPE (varchar2) - Indicates the content type of the text content (text/plain or text/html) Can also be used to indicate the content type (if known) for the binary content.

▪ All other columns are automatically converted to SES search attributes and can be used to restrict searches using the Advanced Search page.

Security Columns:

During the creation of the datasource, if there are security attributes involved in the query, they must be listed under the “Grant Security Attributes” or “Deny Security Attributes” parameter values. For example, if the SQL query lists the security attribute values under the “VISIBILITY_ID” column, then list the column as the security attribute column in the “Grant Security Attributes”.

The values of the security attribute columns must be not null and they are added as security attributes to the document. The authorization query MUST supply values for the logged in user for those security attributes.

Authorization Query:

This query MUST contain all the columns as listed under the Grant and Deny security attribute parameters during the data source creation, in addition to a bind parameter (using JDBC syntax - ?), which will be used to bind the user name. This query will be executed every time a user logs in into SES so as to obtain their security credentials.

The query can either return a single row per user or return multiple records. In the case where the query is returning a single row, the values of security attribute should be separated by a space. In this case, enter the value of the parameter 'Single Record Query' in the authorization plugin set-up page to 'true'

If the query returns multiple records per user, then the value of an attribute in each record will be interpreted as a single value of the attribute. In this case, enter the value of the parameter 'Single Record Query' in the authorization plugin set-up page to 'false'.

Suggested Links, Suggested CONTENT and Search Federation

As we will see in the following sections, crawling and indexing application content is not the only way of providing secure application search.

Suggested Links

Suggested link is a mechanism in SES to suggest or recommend a website for a given search keyword or term. This is useful to either boost the relevance of a website or to show sites that are not otherwise crawled.

This can be created by going to the admin screen under Search > Suggested Links and entering the keyword to trigger the link and the actual link itself as a suggested link.

The suggested link mechanism allows Text expressions to be used for the triggering keywords. Thus simple keywords such as “cat” can be used in addition to “cat AND dog” which will only trigger the link if both the words are present in the user’s search term.

For example,

o Keywords: “Café” or “bon appetit”

o URL:

Or

o Keywords: “hr info" or "hr" or "personal info" or "personal information"

o URL:

The suggested link mechanism is the easiest way of providing enterprise application search without requiring sophisticated programming, a search provider or any change to the target application.

Federated Suggested Content

Suggested content data access is similar to that of the suggested link mechanism except that the link is actually executed. The query is brokered and the resulting data retrieved from the backend search provider and displayed to the user. This access of data in real time requires that the link to the backend provider be registered along with the security credentials required to access it, the triggering keywords and an XSLT stylesheet to render the results. The backend provider is expected to return an XML fragment containing the results while the XSLT is used to format the results. SES does not impose any restriction on the structure of the XML, just that the resultant HTML after applying the stylesheet must be reasonable sized so that it can fit in a result box.

SES allows you to fill in various parameters in the URL sent to the backend including search terms, current date, time and other cookie values. Security is enforced either by propagating certain end-user cookies or by using an service-to-service authentication mechanism.

Suggested content is useful integration for the cases where

1. The backend data cannot be easily crawled and indexed

2. The data is highly transactional and hence does not lend itself to a crawl/index approach

3. We want to show the latest information that is not available until the next crawl. For example, in a purchase order case, we might crawl the data once an hour. The real time data access might be used to show results that have come within the hour.

4. We want to show the most useful information immediately – for example, if the user types in meeting, it is useful to return the immediate meeting for that user within the next few hours. This is extremely useful, even if we have already crawled and indexed the calendar meeting that we might have done.

This Suggested Content mechanism is compatible with the Google OneBox results. Hence any existing OneBox implementation can be immediately used as a suggested content feature. The suggested content is more powerful than the current OneBox method, since it allow arbitrary parameters to be supplied in the URL and is more secure as it allows service to service authentication as opposed to simple cookies which are vulnerable to attacks.

For example, you can register the following suggested content -

o Name: People

o Triggering Pattern: (\S+) (\S+)

o URL: $ora:q1&n2=$ora:q2

o Security: None

o XSLT stylesheet:

mailto:

Now, this suggested content will be triggered whenever there are exactly two terms in the query. The ora:q1 and ora:q2 entries in the URL

$ora:q1&n2=$ora:q2 will be substituted with the two terms and the link will be traversed. The person.jsp page will return an XML fragment if there is a matching user or users in the people database. The XML will then be formatted and the result shown in a box in the result page.

Here is an example search result page using the search term “Larry Ellison”

All the E-Business Suite and other connectors built for the Google OneBox will work with the suggested content mechanism.

Federation of Search and Result Merging

SES supports federation to other SES instances. The federation uses the Web Service Query API to federate the query and then merge the results into a single list. In order to federate to other search engines, this Web Service API needs to be implemented and deployed on the other application.

If an application already has implemented a full-text or transactional search that returns document like entries, then implementing the Web Service API for such application immediately provides a way to federate and retrieve information from such data source.

Conclusion

Application Search can be broken into two parts – simple, unified access to application content (via federation – Real-time Data Access) and extensive access to crawled application content. This white paper explores the basic concepts of enterprise application search and explains different alternatives for implementing such search today with Oracle Secure Enterprise Search.

SES already provides a uniform secure search-and-locate capability across files on the desktop, file system, html documents from web servers, application data in databases, emails in collaboration servers, documents in content repositories, etc. With the growing importance of application search, it will more likely to become a fundamental piece in the Fusion Middleware strategy allowing unified secure access to all Oracle applications (e.g. E-Business Suite, Siebel, etc) and non-Oracle applications (e.g. SAP) from one search UI

Secure Search with Oracle Secure Enterprise Search

January 2007

Authors: Muralidhar Krishnaprasad, Shashi Anand B, Joaquin Delgado

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200



This Document Is For Informational Purposes Only And May Not Be Incorporated Into A Contract or Agreement.

Oracle is a registered trademark of Oracle Corporation. Various

product and service names referenced herein may be trademarks

of Oracle Corporation. All other product and service names

mentioned may be trademarks of their respective owners.

Copyright © 2006 Oracle Corporation

All rights reserved.

-----------------------

IdentityPlugin

Administration

Identity Management

SES Index

Federation

Crawling Layer

Metadata Extraction

CS plugin

NTFS plugin

CS plugin

Other plugins

Security Layer

CS Authz plugin

Other Authz Plugin

Other

SES

Instances

Query Layer

WS API

Presentation Layer

Suggested Content Box

1

2

3

4

Desktop Documents

SIEBEL Call Center Data

EBS Knowledge Base Data

Direct Menu Navigation

[pic]

Regular Search Results

-----------------------

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download