Security for Oracle E-Business Suite with TDV

This topic describes TDV’s security support for Oracle E-Business Suite. Security involves two parts: authentication and access control.

The following topics are covered:

Understanding Authentication for Oracle E-Business Suite

The data source properties Database Username and Database Password are needed to connect to the Oracle database. This connection is used to verify application credentials, gather access information, execute queries, and read query results.

If Enable Multi-Organization is checked, data in Oracle E-Business Suite is restricted based on the user's application credentials. Application credentials are specified in the data source properties Application Username and Application Password, or by enabling pass-through login. The application credentials are authenticated using Oracle E-Business Suite’s API and used to obtain the users permitted organizations and responsibilities.

Understanding Access Control for Oracle E-Business Suite

An application user has one or more responsibilities. A responsibility is a level of authority in Oracle E-Business Suite that lets users access only those Oracle E-Business Suite functions and data appropriate to their roles in an organization. For data access control, each responsibility allows access to a set of books, such as U.S. Operations or German Sales, or an organization, such as New York Manufacturing or New York Distribution.

Each responsibility has one organization (org_id) associated with it, which can be set at system, site, responsibility, or user level. The organization limits users to data relevant to their organization. For example, you can limit the access of order administration clerks to sales orders associated exclusively with their sales office.

Information limited by organization is stored in Multiple Organization-enabled tables. Their names typically end in _ALL or _ALL_B. When displayed during introspection, these tables are notated with the word Secure after their names. When querying against these tables with Enable Multi-Organization checked, only information visible to the current user is retrieved. The filtering is transparent to the user.

You can specify which inventory organization is available to users by responsibility. A single responsibility, by system level or responsibility level, determines an operating unit. So a user with multiple responsibilities may have multiple organizations visible. The union of all the user's visible organizations determines how information is filtered in their queries.

Reporting with Multiple Organizations

For reporting purposes users may need to read information for which they lack the authority, as defined by their responsibilities. To achieve the flexibility required in reporting, the Oracle Applications profile option, “MO: Top Reporting Level” can be used to expand the list of organizations visible to users.

The value of this profile option is set to “Operating Unit” at the site level. Your Oracle E-Business Suite system administrator can set this profile option at the responsibility level. The following table shows the access given to a user depending on the setting of the Top Reporting Level profile option.

Using Organization Names in Queries

All secure tables (enabled for multiple organization use) contain a column named Organization ID. This query translates the organization id into meaningful organization name:

SELECT name

FROM /shared/DataService_Oracle_EBS11i_on_9i/"Data Services"/"Human Resources"/Organizations Organizations

WHERE "Organization Id" = 204

An application user has one or more responsibilities. A responsibility is a level of authority in Oracle E-Business Suite that lets users access only those Oracle E-Business Suite functions and data appropriate to their roles in an organization. For data access control, each responsibility allows access to a set of books, such as U.S. Operations or German Sales, or an organization, such as New York Manufacturing or New York Distribution. For more details, please refer to “Multiple Organizations in Oracle Applications, Release 11i.”

Each responsibility has one organization (org_id) associated with it, which can be set at system, site, responsibility, or user level. The organization limits users to data relevant to their organization. For example, you can limit access for order administration clerks to sales orders associated exclusively with their sales office.

Information limited by organization is stored in Multiple Organization-enabled tables. Their names are typically ended in _ALL or _ALL_B. When displayed during introspection, these tables are notated with word “Secure” after their names. When querying against these tables with Enable Multi-Organization checked, only information visible to the current user is retrieved. The filtering happens transparently to the user.

You can specify which inventory organization is available to users by responsibility. A single responsibility, by system level or responsibility level, determines an operating unit. So a user with multiple responsibilities may have multiple organizations visible. The union of all the user's visible organizations determines how information is filtered in their queries.

Using Data Filters with Oracle E-Business Suite

With TDV’s query engine, you can dynamically apply a data filter to control the data retrieved. So when the situation changes—for instance, a report for one organization needs to extend to several organizations—you just need to change the filter in the data source configuration.

This filter mechanism works well with Oracle’s multi-org reporting. In Oracle’s own database view, many views are limited to one organization. There is no simple way to query on these views for multiple organizations or all the organizations. With the organization ID filter and a simple view translation, multiple organizations’ data can be retrieved from the same view. For more information about Oracle’s multi-org reporting, see Understanding Multi-Org Enabled Views.

For example, the following table shows the results returned for the same query “SELECT * FROM AP_CHECKS_V”:

Use the following topics to learn more:

Choosing a Data Filter

Different data filters return different stripes of data from the same view. The following table shows the results returned for the same query “SELECT * FROM AP_CHECKS_V”:

For views that are not related to organization ID, all rows are returned in all cases.

List of Shipped Multi-Org Enabled Views

The following views are translated and extended to cover multiple organizations. The view definitions reside in the installation directory depending on the Oracle E-Business Suite version you have chosen.

C:\<TDV_install_dir>\apps\dlm\app_ds_oa\conf\<ver_num>AP_BANK_ACCOUNT_USES_V

AP_CHECKS_V

AP_HOLDS_OVERVIEW_V

AP_INVOICES_V

AP_INVOICE_PAYMENTS_V

AP_PAYMENT_SCHEDULES_V

AP_VENDORS_V

AP_VENDOR_SITES_V

AR_ADJUSTMENTS_V

AR_CASH_RECEIPTS_V

AR_CUSTOMER_CALLS_V

AR_MEMO_LINES_VL

AR_RECEIVABLE_APPLICATIONS_V

OE_ORDER_HEADERS_V

OE_ORDER_LINES_V

PER_ASSIGNMENTS_V

PER_PEOPLE

PER_PEOPLE_V

PO_DOCUMENT_TYPES_VL

PO_HEADERS_V

PO_LINES_V

PO_REQUISITION_HEADERS_V

PO_REQUISITION_LINES_V

RA_CUSTOMER_TRX_LINES_V

RA_CUSTOMER_TRX_PARTIAL_V

RA_CUST_TRX_LINE_GL_DIST_V

How Credentials Are Used

The following table describes various credentials and their usage:

Understanding Multi-Org Enabled Views

Multi-Org Enabled Views are one way to use the Oracle E-Business Suite Adapter’s dynamic filtering. The views in the existing Oracle E-Business Suite system are limiting. For example, view AP_CHECKS_V has some useful information, but for only one organization. But with the Oracle E-Business Suite Adapter, you can select rows of all organizations, or a specific list of organizations, from AP_CHECKS_V. This is done by replacing limitations in the view.

For example,

WHERE org_id = 204

You can replace this with

WHERE org_id in (204, 600)

See List of Shipped Multi-Org Enabled Views” to locate the translated views’ definition.

When TDV is querying the Oracle database, if a view’s definition is found under the directory, the view’s definition will be used.

How to Write Multi-Org Enabled Views

To write multi-org-enabled views, you need to find the view’s original definition from the database, and change the views referenced inside the original definition to grammar like this:

SELECT . . .

  AP_CHECKS_PKG.GET_POSTING_STATUS(AC.CHECK_ID) POSTING_FLAG

FROM #{AP_BANK_ACCOUNTS} ABA,…

WHERE . . .

That is, change "FROM AP_BANK_ACCOUNTS ABA” to “FROM #{AP_BANK_ACCOUNTS} ABA”.

If the organization id list is “204, -1”, the meaning of the grammar is as follows:

#{abc}

(select * from abc_ALL where org_id in (204,-1))

#{abc|real_table_name_ALL_B}

(select * from real_table_name_ALL_B where org_id in (204,-1))

#V{abc}

'(' + content from abc.sql + ')'

#L{the_column}

the_column in (204,-1)

The #V{abc} is for recursive translated view definitions.