Installation & Maintenance Guide forOracle EBS DBAs

Version 2018.0

Desktop Reporting

Document Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .i

Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Version History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .i Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .i

Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Hubble Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Oracle Database and User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

HR & Payroll Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Install Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 GRANT SELECT, INSERT ON APPS.FND_LOG_MESSAGES . . . . . . . . . . . . . . . . 7

GRANT SELECT, INSERT, DELETE ON MO_GLOB_ORG_ACCESS_ TMP 7

GRANT SELECT, DELETE ON FND_MO_SP_PREFERENCES . . . . . . . . . . . . . . . 7

Install Script - Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Hubble Connection Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Custom Database Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Other Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Object Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Document Information | Notices

Page i

Document Information

Notices

CopyrightHubble® is a brand name of the insightsoftware.com Group. insightsoftware.com is a registered trademark of insightsoftware.com Limited. Hubble is a registered trademark of insightsoftware.com International Unlimited.

Other product and company names mentioned herein may be the trademarks of their respective owners. The insightsoftware.com Group is the owner or licensee of all intellectual property rights in this document, which are protected by copyright laws around the world. All such rights are reserved.

The information contained in this document represents the current view of insightsoftware.com on the issues discussed as of the date of publication. This document is for informational purposes only. insightsoftware.com makes no representation, guarantee or warranty, expressed or implied, that the content of this document is accurate, complete or up to date.

DisclaimerThis guide is designed to help you to use the Hubble applications effectively and efficiently. All data shown in graphics are provided as examples only. The example companies and calculations herein are fictitious. No association with any real company or organization is intended or should be inferred.

Version History

Customer Support

For more information regarding our products, please contact us at http://gohubble.com/.

For product support including Training, Documentation and Customer Support, visit our Hubble Community at https://community.gohubble.com/.

Date Revision Software Version Comments

13th Nov 2017 1.0 2018.0

16th Jan 2018 1.1 2018.0 Minor amendments.

Procedures

Introduction

Hubble is an intuitive, real time, SQL-based tool that facilitates reporting on Oracle EBS Applications for end users. To function, Hubble requires a one-off installation of a custom schema, typically called Hubble, on the applications database. The information provided in this document is related to the Hubble schema only. A corresponding client-side tool is installed on user terminals which connects to and uses the Hubble schema for reporting.

ObjectiveThis document is directed to Oracle Applications DBAs and is intended as a reference, overview and description of a Hubble installation on an Oracle EBS Applications database. The installation process uses a script, creates custom views during the configuration and requires the creation of an Object Repository. The impact on the Oracle EBS Application’s database, security and performance is outlined in this document.

NoticeCustomers should be aware that creating a new schema on an Oracle database can be considered a customization and should ensure that their current software licensing agreement with Oracle Corporation entitles them to perform this activity.

Prerequisites● Creation of a tablespace for Hubble (optional)● Hubble Installation Script ● Oracle SYSTEM access

Hubble Installation

Oracle Database and UserThis install requires SYSTEM access to your Oracle Applications database and involves the creation or definition of a database user and a corresponding schema normally defined as HUBBLE. Using APPS or another user will typically result in an installation that will not work as intended.

Using the HR module in Hubble will require the use of the APPS user in addition to the HUBBLE user in order to allow Oracle HR Security to be upheld.

This document is specific to Hubble version 2018.0.

Page 1

Procedures | Hubble Installation

HR & Payroll ModuleIn order to enable security and allow the application to mirror EBS settings, Hubble uses the seeded Oracle Secure Views. Due to constraints within the security logic, these views can only be accessed correctly using the APPS schema. As a result, the HR and/or Payroll Module requires an HR Security connection in the profile that connects using the APPS schema.

Activate the HR and/or Payroll module for selection by following the below steps.

1. If you are creating a new repository, you will need your standard connection to the Hubble schema plus an additional connection to the same database that uses the APPS user.

2. The profile wizard on the Oracle Connectivity screen now has an additional field for the HR Security Connection that is used for both HR and Payroll. Here you will select the Connection with the APPS user.

3. The HR and/or Payroll Module can now be selected in the Module Selection window of the profile wizard if the repository has an HR License.

Install Script

Install Script For Reporting in HubbleThe script creates a user/schema, necessitating whoever is running it to select a username, password, SYSTEM user and default and temporary tablespaces. A pre-existing username, TNS Admin entry and index creation are all optional entries.

There are various prompts when running the script.

1. Enter the desired username and password:

2. If you have a pre-existing username you can enter this username in this field to pick up any grants that have been applied (useful for DX upgrades); leave blank otherwise.

Page 2

Procedures | Hubble Installation

3. Enter default and temporary tablespaces. If the below fields are left blank, then the SYSTEM and TEMP tablespaces will be used.

4. Enter details for the user we will use to run the script:

Page 3

Procedures | Hubble Installation

The install script will perform various GRANT privileges on the newly-created database user, including granting permission to create views and synonyms. This script will also create some procedures and packages used in the Hubble application. Required Permissions are covered later in this guide.

1. Enter Y/N to adding indexes. To improve performance at login, two indexes are created on FND tables:

FND_TABLES_INSIGHT1 on FND_TABLESFND_COLUMNS_INSIGHT1 on FND_COLUMNS

2. Enter Y/N to add indexes to improve the performance of Fixed Asset reports.

IS_NDX_FA_TRANS_NULL on FA_BOOKSIS_NDX_FA_TRANS_DATE_ENT on FA_TRANSACTION_HEADERSIS_NDX_FA_DIST_TRANS & IS_NDX_FA_DIST_NULL on FA_DISTRIBUTION_HISTORY

A breakdown of what the script does is detailed below.

Install Script Breakdown for Reporting in HubbleCreate user and grant privileges (Lines 1 to 70).

1. Gather login information, such as the user name and name and password for system user.

2. Check if the user we want to create exists. If it does not exist, create it.

These indexes, while recommended, are not mandatory. The person who runs the script will have the option of not creating these via a prompt.

Page 4

Procedures | Hubble Installation

3. Grant basic connection privileges:

a. Connect.

b. Resource.

c. Create View. We need to create some views in Administrator.

d. Create Synonym. We need to create synonyms.

Grant access to tables, views and procedures needed (Lines 70 to 1207)

1. Definition of containers to store tables and/or procedures to grant access to:

a. SELECT_COMMON – Grant select and create synonyms on EBS 11i and R12.

b. SELECT_SYS_COMMON - Grant select and create synonyms on EBS 11i and R12 to tables/views belonging to SYS.

c. SELECT_11I – Grant select and create synonyms on EBS 11i only.

d. SELECT_R12 - Grant select and create synonyms on EBS R12 only.

e. ALL_COMMON – Create synonyms on both EBS versions.

f. ALL_11I - Create synonyms on EBS 11i only (empty).

g. ALL_R12 - Create synonyms on EBS R12 only.

h. EXECUTE_COMMON – Grant execute on both servers.

i. EXECUTE_11I – Grant execute on EBS 11i only (empty).

j. EXECUTE_R12 – Grant execute on EBS R12 only.

2. Logic to grant specific privileges to a small set of tables that require insert and/or delete access. These tables are:

a. FND_LOG_MESSAGES (SELECT, INSERT) - used by FND_GLOBAL.APPS_INITIALIZE function to allows the correct security to be applied to the EBS User. My Oracle support document (822225.1).

b. MO_GLOB_ORG_ACCESS_TMP (SELECT, INSERT, DELETE) - used as part of Multi Org Process. My Oracle support documents (462383.1 and 1564525.1).

c. FND_MO_SP_PREFERENCES (SELECT, DELETE) - referenced by MO_GLOBAL package to perform DML operation on this table.

3. Logic to read each of the containers, depending on the EBS version with we are running the script.

Grant access to tables used by KFF (Key Flex Field) definitions (Lines 1208 to 1290)

Most of the GRANT ALL and GRANT EXECUTE objects come from How To Run the FND_GLOBAL.APPS_INITIALIZE Using A User Other Than APPS (Oracle Doc ID 822225.1). “FND_GLOBAL.APPS_INITIALIZE” helps us to initialize the database connection as the EBS front end would do. It initializes variables that affect views and security, among other things.All Oracle documents referenced in this guide, such as Doc ID 822225.1, can be found in My Oracle Support.

Page 5

Procedures | Hubble Installation

1. The method will run the SQL below to obtain the tables used by KFF:

a. SELECT APPLICATION_TABLE_NAME

b. FROM APPS.FND_FLEX_VALIDATION_TABLES

c. WHERE FLEX_VALUE_SET_ID IN (

d. SELECT FND_ID_FLEX_SEGMENTS.FLEX_VALUE_SET_ID

e. FROM APPS.FND_ID_FLEX_SEGMENTS FND_ID_FLEX_SEGMENTS,

f. APPS.FND_ID_FLEX_STRUCTURES FND_ID_FLEX_STRUCTURES,

g. APPS.FND_FLEX_VALUE_SETS FND_FLEX_VALUE_SETS

h. WHERE FND_ID_FLEX_SEGMENTS.ID_FLEX_NUM = FND_ID_FLEX_STRUCTURES.ID_FLEX_NUM AND FND_ID_FLEX_SEGMENTS.ID_FLEX_CODE IN ('GL#', 'LOC#', 'CAT#', 'KEY#', 'MCAT', 'MTLL', 'CT#') AND FND_FLEX_VALUE_SETS.FLEX_VALUE_SET_ID = FND_ID_FLEX_SEGMENTS.FLEX_VALUE_SET_ID

i. AND FND_FLEX_VALUE_SETS.VALIDATION_TYPE = 'F');

2. Step through the resulting tables,` running GRANT SELECT ON table_name TO user_name.

Grant access to the additional tables for which the “old user” has access to (Lines 1291 to 1316).

Create a view for Table Discovery (Lines 1317 to 1350).

1. GRANT SELECT ON ' || V_REC.TABLE_NAME

Create indexes for Hubble (Lines 1351 to 1457)

1. FND_TABLES_INSIGHT1 on FND_TABLES

2. FND_COLUMNS_INSIGHT1 on FND_COLUMNS

3. IS_NDX_FA_TRANS_NULL on FA_BOOKS

4. IS_NDX_FA_TRANS_DATE_ENT on FA_TRANSACTION_HEADERS

5. IS_NDX_FA_DIST_TRANS & IS_NDX_FA_DIST_NULL on FA_DISTRIBUTION_HISTORY

Create functions and packages to be used when running Hubble (lines 1458 to END)

1. Function GETLONGCOLUMN: Gets text within columns with LONG data type. The driver does not support it; it is only used for KFF.

2. Function FINDLONGCOLUMNLENGTH: Gets the size of a LONG column to be able to read using GETLONGCOLUMN.

3. Function SAFE_DIVIDE: Safe divide changes the divisor to 1 if it is 0, thus preventing an exception to be thrown.

4. Function INITAPPS: Function used to initialize the database. This is the function which runs “FND_GLOBAL.APPS_INITIALIZE”.

All functions are created using the user created; we do not invade other users or system space.

Page 6

Procedures | Permissions

Permissions

Hubble makes use of standard EBS Views, Packages and Functions to ensure we can replicate specific elements of this functionality. The most notable of these to a DBA might be:

GRANT SELECT, INSERT ON APPS.FND_LOG_MESSAGESTo replicate EBS security, we follow How To Run FND_GLOBAL.APPS_INITIALIZE Using A User Other Than APPS (Oracle Doc ID 822225.1). This document states we need to “GRANT ALL on FND_LOG_MESSAGES to …” the database user. We have limited the grants to SELECT and INSERT.

GRANT SELECT, INSERT, DELETE ON MO_GLOB_ORG_ACCESS_TMPTo allow us to use Oracle’s Multi Org functionality, we follow SQL Queries and Multi-Org Architecture in Release 12 (Oracle Doc ID 462383.1) as advised in MO_GLOBAL.INIT('PO') Failure In Sqlplus ORA-01031: insufficient privileges (Oracle Doc ID 1564525.1). We also need to grant additional privileges on APPS.MO_GLOB_ORG_ACCESS_TMP to the database user.

GRANT SELECT, DELETE ON FND_MO_SP_PREFERENCESAgain to allow us to use Oracle's Multi Org functionality, in Release 12, we need to grant Select and Delete privileges on FND_MO_SP_PREFERENCES.

We only require GRANT ALL access in the three cases above. Attached below is a list of all EXECUTE permissions we need and why we require them.

Table Name Usage

FND_LOG_MESSAGES This is used to identify information about the user who has logged in so the correct security can be applied as per Oracle Doc ID 822225.1. Hubble will not directly write to these tables.

MO_GLOB_ORG_ACCESS_TMP Used for the MOAC Process Oracle Doc ID 462383.1.

APP_EXCEPTION This is used to identify information about the user who has logged in to apply the correct security as per Oracle Doc ID 822225.1Referenced by the AP_INVOICES_PKG.Referenced by MO_GLOBAL.

AP_INVOICES_UTILITY_PKG Referenced by the Oracle AP_INVOICES_V view.

AP_PAYMENT_UTIL_PKG Required to allow Hubble to use the seeded Oracle View AP_DOCUMENTS_PAYABLE.

AP_PREPAY_UTILS_PKG Required for AP Approval Status PL/SQL Package.

AP_ETAX_SERVICES_PKG' Required for AP Approval Status PL/SQL Package.

FND_CACHE_VERSIONS_PKG This is used to identify information about the user who has logged in so we can apply the correct security as per Doc ID 822225.1. (fnd_cache_versions is a synonym for this package.)

FND_CLIENT_INFO This is used to identify information about the user who has logged in so the correct security can be applied as per Doc ID 822225.1.Referenced by MO_GLOBAL.

FND_CONTEXT Referenced by FND_GLOBAL.

FND_DATE Used to format and convert dates.

Page 7

Procedures | Permissions

Install Script - Budgeting

Install Script ‘DATAENTRYUSER.SQL’ For Budgeting in Hubble

This section is only applicable if you are using the Budgeting functionality in Hubble.

The script creates a user/schema to be used with the budgeting component, granting relevant permissions to this user and the existing reporting user/schema.

FND_GLOBAL This is used to identify information about the user who has logged in so we can apply the correct security as per Oracle Doc ID 822225.1Referenced by FND_PROFILE.Referenced by MO_GLOBAL.Referenced by HR_SIGNON.

FND_LOG This is used to identify information about the user who has logged in so we can apply the correct security as per Oracle Doc ID 822225.1.Referenced by APP_EXCEPTION.Referenced by MO_GLOBAL.

FND_LOG_REPOSITORY This is used to identify information about the user who has logged in so we can apply the correct security as per Oracle Doc ID 822225.1.Referenced by FND_GLOBAL.

FND_MESSAGE This is used to identify information about the user that has logged in to apply the correct security as per Oracle Doc ID 822225.1.Referenced by APP_EXCEPTION.Referenced by FND_PROFILE.Referenced by FND_CACHE_VERSIONS_PKG.Referenced by MO_GLOBAL.Referenced by HR_SIGNON.

FND_NUMBER Referenced by FND_GLOBAL.

FND_PROFILE This is used to identify information about the user who has logged in so we can apply the correct security as per Oracle Doc ID 822225.1.Referenced by FND_GLOBAL.Referenced by MO_GLOBAL.Referenced by FND_DATE.Referenced by HR_SIGNON.Referenced by JG_CONTEXT.

GL_ACCESS_SET_SECURITY_PKG Performs DML operations on temporary tables.

HR_SIGNON This is used to identify information about the user who has logged in so the correct security can be applied as per Oracle Doc ID 822225.1.This is used as part of the security.

IBY_UTILITY_PVT Used by the Oracle View IBY_SEC_EXT_BANK_ACCOUNT_V

JG_CONTEXT This is used to identify information about the user who has logged in so we can apply the correct security as per Oracle Doc ID 822225.1.

MO_GLOBAL Used as part of the Multi Org Process Doc ID (462383.1).

Table Name Usage

Page 8

Procedures | Permissions

Prerequisites

1. Creation of a tablespace for Budgeting (optional).

2. The reporting user/schema must pre-exist on the DB. If it does not, be sure to complete the “Install Script For Reporting in Hubble” on page 2 as you will need the reporting user/schema name to run the DataEntryUser script.

3. Know the Oracle SYSTEM Password.

Running the Script

There are various prompts when running the script.

1. Enter the desired username and password. This should be something that identifies the user/schema e.g. HUB_BUD_ and then the build number = HUB_BUD_2016_1

2. Enter the tablespaces names for the Budgeting user and for temporary tables. If the below fields are left blank, then the SYSTEM tablespaces will be used.

3. Enter the reporting user/schema name. This is the one from the Prerequisite item 2.

Page 9

Procedures | Hubble Connection Protocol

4. Enter the SYSTEM username, which is usually ‘SYSTEM’, and the password.

Install Script ‘DATAENTRYUSER.SQL’ Breakdown for Hubble Budgeting 1. Collect the required information needed to run the script (lines 1-35).

2. Connect as the SYSTEM user (lines 36-40).

3. Create the new budgeting user/schema (lines 41-65).

4. Grant required permissions for tablespace, connection and table selects (lines 66-73).

5. Connect as the budgeting user/schema (lines 74-75).

6. Creates a sequence, table and trigger for the ISGENERIC table [a preloaded table for budgeting] (lines 76-126).

7. Connect as SYSTEM and grant read access on the ISGENERIC table to the reporting user/schema (lines 127-132).

Hubble Connection Protocol

Below is the sequence for a Hubble user to connect from a client machine to the Oracle database.

1. Hubble connects to EBS data stored in the Oracle DB using the JDBC Thin Driver from Oracle Corporation.  The Oracle JDBC Thin Driver implements the Oracle O3LOGON challenge-response protocol to authenticate the user.

2. The connection to the EBS database is made using a system account setup in Administrator, which is controlled by your own IT department. It is set up so that end users do not need any details about it.  It is the responsibility of the customer to set the policy for and to control access to our Administrator application.

3. The Hubble User ID is the same as the EBS User ID.  However, because Oracle has encrypted the EBS password, Hubble has its own application passwords.

4. The Hubble password is encrypted within our own application and the generated hash is compared to the hash stored in the Object Repository at login time. 

5. When a Hubble user logs in to our application, only the encrypted hash is transmitted.  If it matches the hash in the Object Repository, then the user can login.

6. Next, the Hubble application queries EBS to find the user’s list of Responsibilities.  The user is asked to select a Responsibility from this list.   The data security rules for the chosen EBS Responsibility will affect the SQL statements that the Hubble application sends to the EBS database server whenever a query is executed.

Page 10

Procedures | Custom Database Views

7. At no time is a password sent from the Hubble application to the Hubble Object Repository or to EBS in an unencrypted form. 

More information on the Oracle 03 Login Challenge Response can be found at the following location: http://docs.oracle.com/cd/B19306_01/java.102/b14355/clntsec.htm.

Custom Database Views

Once the Hubble schema has been created, a client-side tool, Administrator, is used to further configure the system. The full set of configuration steps are outlined in the Hubble Administration & Configuration Guide.

During the configuration of the ERP Connection Profiles in Administrator, there is a step that creates custom database views inside the Hubble schema. The number and definition of the database views is determined by the modules or features the organization is licensed for in the license key. An illustration of the form within the ERP Connection Profile, which displays a sample of the views created, is displayed below.

Page 11

Procedures | Custom Database Views

Page 12

Procedures | Other Considerations

Other Considerations

Object RepositoryA critical first step in configuring Hubble is to create an Object Repository. The below excerpt from the Hubble Administration and Configuration Guide explains the purpose, the requirements, and the fundamental components of the Object Repository.

The Object Repository contains the application’s configuration information, user-specific information, and objects such as hierarchies, calculations and Reusable Inquiry Objects. Report parameters are stored in the repository, but not the report results themselves.

The repository needs to be created on a relational database server that is available whenever the user logs on to the Hubble application. The application uses the Repository to perform critical processes such as user verification and validation of permissions. The application has a built-in database layer that will allow access from the application to the database.

The repository contains a number of tables that are created during the initial application configuration. These tables can be created in an existing database/schema/library, but it is preferable for disaster recovery purposes to create a separate database/schema/library to hold the new repository tables. All users need to have read/write permissions to the Repository; this is typically handled using a system user profile.

The size of the Repository differs from site to site depending on the number of users and reports created and saved. The majority of customers have repository databases under 1GB in size and they should not require any special configuration with regards to portioning, etc.

PerformanceDepending on how your database has been tuned, there is the potential to affect the performance of your system. Typically the effect should be same as running a SQL query on your database, which should be negligible.

Maintenance

Table PermissionsDBAs should note that revoking table permissions on the Hubble user after an installation will cause problems on the front-end tool, and would likely stop the related reports from working correctly.

Environment RefreshRefreshing the environment containing the Hubble schema from another which does not contain it will require re-installation of the schema. This would likely only be an issue where the install does not exist on the production environment.

The Object Repository can reside on any relational database server and is not restricted to an Oracle database.

Page 13

Procedures | Other Considerations

Database PasswordsIf the Hubble database user password is changed, a corresponding change will need to be made in the Administrator application. A new RepositorySelection.xml file will need to be generated and distributed to users’ client machines if the password change is on the repository connection.

Page 14