Oracle® Health Sciences Clinical Development Analytics

Administrator's Guide for Informatica

Release 3.2

E74820-01

April 2016

Oracle Health Sciences Clinical Development Analytics Administrator's Guide for Informatica, Release 3.2

E74820-01

Copyright © 2010, 2016, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

List of Figures

List of Tables

Preface

- Audience

- Documentation Accessibility

- Finding Information and Patches on My Oracle Support

- Finding Documentation on Oracle Technology Network

- Related Documents

- Conventions

1 Maintaining the OBIEE Repository and Warehouse

- 1.1 Maintaining the Oracle Health Sciences Clinical Development Analytics OBIEE Repository

- 1.1.1 Modifying the Repository

- 1.1.1.1 Details for Selected Modifications

- 1.1.2 Merging Changes into a New Oracle-supplied Repository

- 1.2 Maintaining the Oracle Health Sciences Clinical Development Analytics Data Warehouse

- 1.2.1 Extensions

- 1.2.2 Substitutions

- 1.2.3 Modifying Data Warehouse Tables

- 1.3 Derivations

2 Extract Transform Load Programs

- 2.1 ETL Architecture

- 2.1.1 Adding Data Source Information

- 2.1.2 Handling Deletions in Siebel Clinical

- 2.1.3 Adding a New Data Source

- 2.1.4 Oracle Health Sciences Clinical Development Analytics Hierarchy

- 2.2 Executing the ETL Execution Plans

- 2.3 Customizing an ETL Execution Plan

- 2.4 Creating an ETL Execution Plan

- 2.5 Modifying an ETL Execution Plan

- 2.6 Scheduling an ETL Execution Plan

3 InForm Auto-merge Matching Rules

- 3.1 W_EMPLOYEE_DS

- 3.2 W_GEO_DS

- 3.3 W_HS_APPLICATION_USER_DS

- 3.4 W_PARTY_PER_DS

- 3.5 W_PRODUCT_DS

- 3.6 W_RXI_PROGRAM_DS

- 3.7 W_RXI_SITE_DS

- 3.8 W_RXI_THERAPEUTIC_AREA_DS

A Troubleshooting

- A.1 Oracle Business Intelligence Data Warehouse Administration Console Task Fails due to Missing Parameter File

- A.2 Sorting and Displaying Null Values in Reports

- A.3 Aborting a Workflow

Index

List of Figures

- 2-1 ETL Architecture

- 2-2 ETL for One Source Database

- 2-3 OHSCDA Hierarchy

List of Tables

- 1-1 Scenarios Requiring Necessary Adjustments

Preface

This guide provides information on the configuration of Oracle Health Sciences Clinical Development Analytics (OHSCDA).

This preface contains the following topics:

- Audience

- Documentation Accessibility

- Finding Information and Patches on My Oracle Support

- Finding Documentation on Oracle Technology Network

- Related Documents

- Conventions

Audience

This guide is intended for:

- Data Warehouse Administrators, ETL Developers, and Operators

- System Administrators

This guide assumes that you have the following general skills:

- Knowledge of Oracle Business Intelligence Enterprise Edition Plus.

- Knowledge of Oracle Business Intelligence Data Warehouse Administration Console.

- Knowledge of Informatica PowerCenter.

- Familiarity with Oracle Clinical.

- Familiarity with Oracle's Siebel Clinical.

- Familiarity with Oracle Health Sciences InForm

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Finding Information and Patches on My Oracle Support

Your source for the latest information about Oracle Health Sciences Clinical Development Analytics is Oracle Support's self-service Web site, My Oracle Support (formerly MetaLink).

Before you install and use an Oracle software release, always visit the My Oracle Support Web site for the latest information, including alerts, release notes, documentation, and patches.

Creating a My Oracle Support Account

You must register at My Oracle Support to obtain a user name and password account before you can enter the Web site.

To register for My Oracle Support:

1. Open a Web browser to http://support.oracle.com.

2. Click the Register here link to create a My Oracle Support account. The registration page opens.

3. Follow the instructions on the registration page.

Signing In to My Oracle Support

To sign in to My Oracle Support:

1. Open a Web browser to http://support.oracle.com.

2. Click Sign In.

3. Enter your user name and password.

4. Click Go to open the My Oracle Support home page.

Searching for Knowledge Articles by ID Number or Text String

The fastest way to search for product documentation, release notes, and white papers is by the article ID number.

To search by the article ID number:

1. Sign in to My Oracle Support at http://support.oracle.com.

2. Locate the Search box in the upper right corner of the My Oracle Support page.

3. Click the sources icon to the left of the search box, and then select Article ID from the list.

4. Enter the article ID number in the text box.

5. Click the magnifying glass icon to the right of the search box (or press the Enter key) to execute your search.
The Knowledge page displays the results of your search. If the article is found, click the link to view the abstract, text, attachments, and related products.

In addition to searching by article ID, you can use the following My Oracle Support tools to browse and search the knowledge base:

- Product Focus — On the Knowledge page, you can drill into a product area through the Browse Knowledge menu on the left side of the page. In the Browse any Product, By Name field, type in part of the product name, and then select the product from the list. Alternatively, you can click the arrow icon to view the complete list of Oracle products and then select your product. This option lets you focus your browsing and searching on a specific product or set of products.

- Refine Search — Once you have results from a search, use the Refine Search options on the right side of the Knowledge page to narrow your search and make the results more relevant.

- Advanced Search — You can specify one or more search criteria, such as source, exact phrase, and related product, to find knowledge articles and documentation.

Finding Patches on My Oracle Support

Be sure to check My Oracle Support for the latest patches, if any, for your product. You can search for patches by patch ID or number, or by product or family.

To locate and download a patch:

1. Sign in to My Oracle Support at http://support.oracle.com.

2. Click the Patches & Updates tab.
The Patches & Updates page opens and displays the Patch Search region. You have the following options:

- In the Patch ID or Number is field, enter the primary bug number of the patch you want. This option is useful if you already know the patch number.

- To find a patch by product name, release, and platform, click the Product or Family link to enter one or more search criteria.

3. Click Search to execute your query. The Patch Search Results page opens.

4. Click the patch ID number. The system displays details about the patch. In addition, you can view the Read Me file before downloading the patch.

5. Click Download. Follow the instructions on the screen to download, save, and install the patch files.

Finding Documentation on Oracle Technology Network

The Oracle Technology Network Web site contains links to all Oracle user and reference documentation. To find user documentation for Oracle products:

1. Go to the Oracle Technology Network at
http://www.oracle.com/technetwork/index.html and log in.

2. Mouse over the Support tab, then click the Documentation hyperlink.
Alternatively, go to Oracle Documentation page at

http://www.oracle.com/technology/documentation/index.html

3. Navigate to the product you need and click the link.
For example, scroll down to the Applications section and click Oracle Health Sciences Applications.

4. Click the link for the documentation you need.

Related Documents

For more information, see the following documents in the Oracle Clinical Release 4.6 documentation set, the Oracle Business Intelligence Data Warehouse Administration Console 10.1.3.4.1 documentation set, or the Oracle Business Intelligence Enterprise Edition Release 10.1.3.4.1 documentation set:

Oracle Business Intelligence Enterprise Edition Documentation

The Oracle Business Intelligence Suite Enterprise Edition Online Documentation Library documentation set includes:

- Oracle Business Intelligence Presentation Services Administration Guide

- Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)

- Oracle Business Intelligence Web Services Guide

- Oracle Business Intelligence Server Administration Guide

Oracle Business Intelligence Data Warehouse Administration Console (DAC) Documentation

The Oracle Business Intelligence Data Warehouse Administration Console (DAC) documentation set includes:

- Oracle Business Intelligence Data Warehouse Administration Console User's Guide

- Oracle Business Intelligence Data Warehouse Administration Console Installation, Configuration, and Upgrade Guide

Oracle Clinical Documentation

The Oracle Clinical documentation set includes:

- Oracle Clinical Administrator's Guide

- Oracle Clinical Getting Started

- Interfacing from Oracle Clinical

- Oracle Clinical Conducting a Study

- Oracle Clinical Creating a Study

- Oracle Clinical Installation Guide

Siebel Clinical Documentation

The Oracle Clinical documentation set includes:

- Siebel Data Model Reference for Industry Applications

- Siebel Life Sciences Guide

Oracle Health Sciences InForm Documentation

The Oracle Health Sciences InForm documentation set includes:

- Oracle Health Sciences InForm Upgrade and Migration Guide

- Oracle Health Sciences InForm Installation Guide

- Oracle Health Sciences InForm Study and Reporting Setup Guide

- Oracle Health Sciences InForm User Guide

- Oracle Health Sciences InForm Reporting and Analysis

- Oracle Health Sciences InForm Utilities Guide

- Oracle Health Sciences InForm Clinical Data API Guide

- Oracle Health Sciences InForm Reporting Database Schema

- Oracle Health Sciences InForm Secure Configuration Guide

- Oracle Health Sciences InForm Third Party Licenses and Notices

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

1 Maintaining the OBIEE Repository and Warehouse

This chapter contains the following topics:

- Section 1.1, "Maintaining the Oracle Health Sciences Clinical Development Analytics OBIEE Repository"

- Section 1.2, "Maintaining the Oracle Health Sciences Clinical Development Analytics Data Warehouse"

- Section 1.3, "Derivations"

1.1 Maintaining the Oracle Health Sciences Clinical Development Analytics OBIEE Repository

Each release of Oracle Health Sciences Clinical Development Analytics (OHSCDA) contains an OBIEE Repository (RPD) file. The Repository is the data store for the Oracle BI Server. It maintains the mapping of the physical tables comprising the data warehouse to the Presentation Layer, which holds the columns and tables available for use in OBIEE Analyses. As shipped, the RPD corresponds to the OHSCDA data warehouse, and can be used without any modification.

Note:
OHSCDA ships with more than one Repository (DAC and Informatica, as well as OBIEE, have Repositories). This section, however, is concerned only with the OBIEE Repository that ships with OHSCDA. Therefore, throughout this section, the terms Repository and RPD should be taken to mean the OBIEE Repository shipped with OHSCDA.

However, you might find it desirable to modify the Oracle-supplied OHSCDA Repository file (RPD), for any of the following reasons:

- You want to add a column or table to the data warehouse, and propagate that addition into the layers of the Repository.

- You want to add a calculated column in the Presentation Layer as a function of some set of Physical layer columns.

- You want to modify a Repository variable value, or add a new repository variable, for use in some Presentation Catalog calculation. For instance, you may want to modify the frequency with which the value of the dynamic repository variable CURRENT_DAY is refreshed. For more information about why OHSCDA must refresh this variable, refer to the Note in step 13 of the Executing the ETL Programs section.

This section describes the procedures you must follow to carry out these types of modifications.

You should be aware that, once you have modified the Oracle-supplied Repository, it is your responsibility to merge these modifications into Repositories supplied by Oracle in subsequent patches and releases of OHSCDA. Details on how to re-apply your modifications are provided below.

Caution:
Changes to the Repository should be made with care.
Privileges to make changes in the Repository should be granted only to a limited set of users who need to make such changes and also know how to make them correctly.

Changes should be tested on a side copy of the Repository before being released for production use.

1.1.1 Modifying the Repository

In OHSCDA Standard configuration, maintaining versions of the Repository is the responsibility of the administrator. Oracle recommends that you:

- Make a backup copy of each state of the repository before you modify it

- Attempt all modifications on a side copy of the Repository before putting it into production use

- Verify all changes to the Repository by running requests from the Presentation Service against the modified Repository

Therefore, Oracle requires that you do not modify the deployed OHSCDA Repository directly.

If you need to modify the Repository, use the OBIEE Administration Tool.

1.1.1.1 Details for Selected Modifications

This section contains details on how to perform certain modifications to the RPD.

To modify the frequency with which CURRENT_DAY is refreshed:

1. In Oracle BI Administration Tool, click Manage > Variables.

2. Expand Repository and click Initialization Block > ETL_Refresh_Ranges.

3. In the Repository Variable Init Block - ETL_Refresh_Ranges screen, modify the value of Refresh interval.
Refresh interval indicates how often you want to refresh the value of CURRENT_DAY dynamic repository variable. By default, this value is set to 5 minutes. That is, the CURRENT_DAY dynamic repository variable is refreshed every five minutes. Modify Refresh interval to a suitable value.

See Also:

- Oracle® Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 for more information about modifying the RPD.

1.1.2 Merging Changes into a New Oracle-supplied Repository

Each OHSCDA release, and some patches, includes a copy of the OHSCDA Repository. If you do modify your copy of the OHSCDA Repository, you must merge your changes into the Oracle-supplied Repository each time you receive a release or patch of OHSCDA that includes a repository. At upgrade time, use the OBIEE Merge Repository Wizard (accessed through File > Merge) in the Repository Administration Tool to merge your modified RPD with the Oracle-supplied RPD.

For information on comparing and merging Repositories, refer to Chapter 15, Managing Oracle BI Repository Files, in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1.

1.2 Maintaining the Oracle Health Sciences Clinical Development Analytics Data Warehouse

You may need to modify the OHSCDA data warehouse, typically for one of the following reasons:

- Derivation: Calculation of a new measure as a function of some supplied measures.

- Extension: Adding data that was not delivered with OHSCDA.

- Substitution: Swapping data from a different source for a column that was delivered with OHSCDA.

Caution:
Exercise caution when you modify the data warehouse. Please conform to the recommendations mentioned in Section 1.2.3, "Modifying Data Warehouse Tables".

1.2.1 Extensions

An extension is a new column added to the data warehouse for data not extracted from the transactional sources by the SDE supplied with OHSCDA.

Example: Adding the study manager's name as an attribute of the study dimension for each study. The following are the assumptions:

- This information is available in a non-Oracle Clinical database, in a table named STUDY_MANAGERS. The column in that table holding the Study Manager name is STUDY_MANAGER_NAME.

- This table has a foreign key to the primary key in Oracle Clinical table OCL_STUDIES.

Note:
When you add extension columns to the OHSCDA data model, the column name must start with "X_". This avoids collisions with names of columns added by Oracle in later releases of OHSCDA.

You can add the column either to the target table, or to an extension table. To minimize the level of effort required when implementing a release with a new repository, Oracle recommends that you add extensions to the warehouse through user-defined extension tables, rather than by adding new columns directly into the relevant staging and target tables.

Perform the following tasks to add the study manager name to the study dimension for each study:

1. Modify staging table W_RXI_STUDY_DS, adding the X_STUDY_MANAGER_NAME column. To modify the staging table, perform the following tasks in Oracle Business Intelligence Data Warehouse Administration Console (DAC):

1. Duplicate the container in DAC (to ensure that the changes are not overwritten in the next OHSCDA upgrade) or use an existing customized table definition.

2. Navigate to the Design > Tables subtab and add the new column under W_RXI_STUDY_DS and save it.

2. Modify the SDE that populates W_RXI_STUDY_DS, as indicates in the following steps:

- Copy the SDE into another folder (to ensure that the changes are not overwritten in the next OHSCDA upgrade) or use an existing customized SDE.

- Add the STUDIES_MANAGERS table as a source in the Informatica program.

- Add a mapping of column STUDY_MANAGER. STUDY_MANAGER_NAME to W_RXI_STUDY_DS.X_STUDY_MANAGER_NAME.

- To modify the SDE, perform the following tasks in DAC:
a. Navigate to Design > Tasks subtab.

b. Navigate to SDE of Study Dimension. Right click and select Synchronize.

3. If it does not already exist to support some other extension, create extension table W_RXI_STUDY_DX, containing one column [STUDY_WID] to function as a foreign key that joins to the primary key in W_RXI_STUDY_D. This table is populated with one row for each row in W_RXI_STUDY_D when the Study SIL executes.

4. Add the extension table W_RXI_STDY_DX. To add a table, perform the following tasks in DAC:

1. Duplicate the container in DAC (to ensure that the changes are not overwritten in the next OHSCDA upgrade) or use an existing customized table definition.

2. Navigate to Tables subtab Under Design Tab and add the new table W_RXI_STDY_DX and save it.

5. Modify the SIL that populates W_RXI_STUDY_D. Add instructions to create a record in W_RXI_STUDY_DX for each record in W_RXI_STUDY_D, and to copy W_RXI_STUDY_DS. STUDY_MANAGER_NAME into W_RXI_STUDY_DX.STUDY_MANAGER_NAME for each record.
To modify the SIL, perform the following tasks in DAC:

1. Copy the SIL into another folder (to ensure that the changes are not overwritten in the next OHSCDA upgrade) or use an existing customized SIL.

2. Add the new column and save.

6. Modify the repository:

Important:
Create a backup of the repository before modifying it. Retain a log of changes you make to the Repository so you can ensure that the Merge Wizard correctly re-applies them to the next repository that Oracle ships.

1. Import the definition of the extension table, W_RXI_STUDY_DX, into the Repository.

2. Using W_RXI_DISCREPANCY_FX as an example, propagate the extension table and its contents to the Business and Presentation layers.

1.2.2 Substitutions

A substitution occurs if you have a preferred alternative source of data for a column that OHSCDA populates from Oracle Clinical or Siebel Clinical. For example, you have a system for defining what data collection instruments (DCIs) are mandatory for a given study, subject, or subject visit, and you prefer that over the OHSCDA calculation that is based on expected data collection modules (DCMs) and subject visit schedules. In this case, your column will be present in a table, and the SDE that extracts the data to a staging table already exists. You will have to perform the following tasks:

1. Create a view that joins the Oracle Clinical table and the table containing your mandatory DCI information, in which your values replace the Oracle-supplied values for the column of interest. Call this the Substitution View.

2. Modify the SDE to read from the Substitution View, rather than the Oracle-supplied table.
To modify the SDE, perform the following tasks in Informatica:

1. Copy the SDE into another folder (to ensure that the changes are not overwritten in the next OHSCDA upgrade) or use an existing customized SDE.

2. Modify the definitions and save.

If you make changes to a source table, you must propagate that change forward as far as necessary. Some of the scenarios and the related necessary adjustments are described in the Table 1-1.

Table 1-1 Scenarios Requiring Necessary Adjustments

Scenario

Adjustments Required

New table has the same layout as the old table, but is passed through from a different source

Change the SDE that reads the old table to instead read the new table.

Modified table has modified layout

1. Modify the SDE to read the modified layout.

2. Modify the staging table populated by the SDE to include the modified layout.

3. Modify the SIL to read the modified layout.

4. Modify the target table to include the modified layout.

5. Modify the RPD to accept the changed data warehouse table.

New table

1. Add a staging table to accept the new input.

2. Add an SDE to read from the new table and write to the staging table.

3. Add a warehouse table to make the new data available to the BI Server.

4. Add an SIL to populate the new data warehouse table from the new staging table.

5. Modify the RPD to accept the new warehouse table.

1.2.3 Modifying Data Warehouse Tables

Depending on what changes are required to the data warehouse, it is necessary to modify either the source table in Informatica and DAC, or the source, staging, and target tables.

Managing Indexes

OHSCDA is delivered with a set of indexes. If you wish, you can create additional indexes to meet your query requirements. Use DAC for this purpose.

Note:
Oracle recommends that you Drop and re-create all indexes only for full load. This should be disabled for incremental load.

It is useful to drop all indexes on the warehouse tables before loading large volumes of data, and to recreate them afterward. DAC can automate this process for you. To drop indexes before a load, and recreate them afterward, perform the following tasks in DAC:

1. Navigate to the Execute > CDA - Complete Warehouse execution tab.

2. Select Drop and Re-create Index and save.

If set to Yes, Oracle DAC drops all indexes on all target tables before the Informatica Program is executed, and recreates them after execution.

1.3 Derivations

A derivation is a calculation of a new measure as a function of some supplied measures. You can use any of the following approaches to calculate derivations:

Note:
For more information on the existing data model, see Oracle Health Sciences Clinical Development Analytics Electronic Technical Reference Manual.

- Calculate the derivation as part of the creation of an analysis.
In this approach, only the Presentation Catalog is modified. However, you must specify the calculation for each analysis, and the calculation is executed every time the analysis is executed.

- Calculate the derivation in the physical or business layer of the RPD and propagate it to the presentation layer. This makes the derivation you created appear in Answers as a column.
Using this approach, you can specify the calculation once and use it for multiple analyses. Once it has been propagated to the Presentation Layer, the derived value looks the same as any other Answers column to an end user.

- Calculate the derivation in the data warehouse.
In this approach, you add an extension column to the warehouse to hold the derived values. To do so:

1. Add the result column to the staging and target table of the fact or dimension in which the derivation is being created. It is an extension column, so its name must begin with "X_".

2. Modify the SDE to calculate the derived value during extract of records from the sources.

3. Modify the SIL to transfer the derived value from the Staging to the Target table.

4. Create and execute a script to provide values for the derived column in rows already present in the Target.

5. Add the column to all layers of the RPD.

In carrying out these steps, follow the rules described above for changes to the RPD and warehouse.

2 Extract Transform Load Programs

This chapter contains the following topics:

- Section 2.1, "ETL Architecture"

- Section 2.2, "Executing the ETL Execution Plans"

- Section 2.3, "Customizing an ETL Execution Plan"

- Section 2.4, "Creating an ETL Execution Plan"

- Section 2.5, "Modifying an ETL Execution Plan"

- Section 2.6, "Scheduling an ETL Execution Plan"

To load data from the source systems to the data warehouse, OHSCDA uses Extract Transform and Load (ETL) programs that

- Identify and read desired data from different data source systems,

- Clean and format data uniformly, and

- Write it to the target data warehouse.

In OHSCDA, Oracle Clinical, Oracle's Siebel Clinical, and InForm are the source systems for which Oracle provides predefined ETL.

2.1 ETL Architecture

ETL is the process by which data is copied from a source database and placed in warehouse tables, available for analytic queries.

Figure 2-1 ETL Architecture

OHSCDA supports the extraction of data from one or more transactional application source databases. In OHSCDA, ETL is performed by execution of Informatica Mappings. A mapping is a program that selects data from one or more tables, performs transformations and derivations on the data, and inserts or updates the results in a target table. Mappings are stored in the Informatica Repository. Oracle uses the Oracle Data Warehouse Admin Console (DAC) to schedule and supervise the execution of the entire set of ETL necessary to populate the CDA warehouse.

Because data can be extracted from databases managed by different applications, the ETL mappings to load any given warehouse table are composed of two parts. The first part is a mapping that reads from a specific application's database and writes to a common warehouse staging table. This mapping is referred to as SDE, for Source-Dependent Extract. Records in the staging table have a common format, regardless of the source from which they were extracted. For a given warehouse table, there must be one SDE for each supported source application. The second mapping for the given warehouse table reads from its staging table and writes to the final warehouse table. This part is called as the SIL, for Source-Independent Load.

Figure 2-2 shows the ETL process for extracting data from two tables (one dimension D1 and one fact F1) in one source application database.

Figure 2-2 ETL for One Source Database

Each numbered arrow represents the execution of a Mapping. The Mappings are executed in the order indicated by the numbers. Mapping 4, the SIL that loads fact F1 into the warehouse target table for the fact, has two components. The first part (4a) represents the copy, transformation, and derivation of the staged data for the fact. The second part (4b) represents the setting of the values of each record's foreign key to dimension D1. The result is that dimension D1 can be queried as one of the dimensions in the star-schema centered on fact F1.

OHSCDA provides SIL for each of its warehouse tables. It provides SDE to stage data for these tables from InForm, Oracle Clinical, and Siebel Clinical database. The execution of the mappings is under the control of the Oracle DAC.

The OHSCDA ETL architecture is flexible. It allows you to integrate data from multiple databases instances for one application (for example, multiple Oracle Clinical databases), or databases from different source applications (for example, one Oracle Clinical and one Siebel Clinical), or any combination of these.

The OHSCDA ETL architecture is extensible. OHSCDA provides SDE mappings for InForm, Oracle Clinical, and Siebel Clinical. You can add data from another application to the OHSCDA warehouse by creating the SDE to map its database tables to the OHSCDA staging tables.

For each source application there is one SDE mapping for each warehouse table. This SDE extracts data from the source system and loads it to the staging tables. SDEs have the following features:

- Incremental submission mode: OHSCDA-supplied ETL uses timestamps and journal tables in the source transactional system to optimize periodic loads.

- Bulk and normal load: Bulk load uses block transfers to expedite loading of large data volume. It is intended for use during initial data warehouse population. Bulk load is faster, if data volume is sufficiently large. However, if load is interrupted (for example, disk space is exhausted, power failure), load can be re-started from task that failed in DAC.
Normal load writes one record at a time. It is intended to be used for updates to the data warehouse, once population has been completed. Normal load is faster, if data volume is sufficiently small. You can also restart load if the load is interrupted.

Setting Bulk or Normal load option should be done at Workflow session in Informatica. Perform the following steps to set the load option:

1. Navigate to Session in a workflow and edit the task properties.

2. Navigate to the Mappings subtab and select 'Bulk/Normal' under Target Load type.

3. Save the workflow.

There is one SIL mapping for each warehouse target table. The SIL extracts the normalized data from the staging table and inserts it into the data warehouse star-schema target table. SILs have the following attributes:

- Concerning changes to dimension values over time, OHSCDA overwrites old values with new ones. This strategy is termed as Slowly Changing Dimension approach 1.

- OHSCDA's data model includes aggregate tables and a number of indexes, designed to minimize query time.

- By default, bulk load is disabled for all SILs.

- The results of each ETL execution are logged by Informatica. The logs hold information about errors encountered, during execution.
Informatica provides the following four error tables:

- PMERR_DATA

- PMERR_MSG

- PMERR_SESS

- PMERR_TRANS

During ETL execution, records which fail to be inserted in the target table (for example, some records violate a constraint) are placed in the Informatica PowerCenter error tables. You can review which records did not make it into the data warehouse, and decide on appropriate action with respect to them.

2.1.1 Adding Data Source Information

As you read data from different database instances, you need to specify the source of the data. OHSCDA provides the W_RXI_DATASOURCE_S table (in RXI schema) that stores all information about all data sources from which data is extracted for OHSCDA. The following are some of the columns in this table:

- ROW_WID: A unique ID for each record in the table.

- DATASOURCE_NUM_ID: The ID for the database. Must be coordinated with the value given to the database in DAC when ETL is run.

- DATASOURCE_NAME: A meaningful name of the database.

- DATASOURCE_TYPE: Application system that manages the database.

- DESC_TEXT: Optional text describing the purpose of the database.

- INTEGRATION_ID: Set this to the same values as DATASOURCE_NUM_ID

See Also:

- Oracle Health Sciences Clinical Development Analytics Electronic Technical Reference Manual, for more information about the W_RXI_DATASOURCE_S table.

- Section 2.1.3, "Adding a New Data Source" for more information on how to add a new data source to OHSCDA.

2.1.2 Handling Deletions in Siebel Clinical

OHSCDA provides an optional feature to manage hard deletion of records in Siebel Clinical. You create triggers in the source system to handle deletion of records. To do this:

1. Navigate to the temporary staging location where the OHSCDA installer copies the installation files.

2. Connect to the Siebel Clinical data source and run the ocda_sc_del_trigger.sql script delivered with OHSCDA. This script creates the RXI_DELETE_LOG_S table and triggers on tables provided as input. The following are the tables in Siebel Clinical for which OHSCDA supports creating triggers:

- S_CL_PTCL_LS

- S_PROD_INT

- S_CL_SUBJ_LS

- S_CONTACT

- S_CL_PGM_LS

- S_PTCL_SITE_LS

- S_EVT_ACT

- S_ORG_EXT

Provide a list of comma separated values of table names for which the triggers need to be created as the script's input. For example, S_CL_PTCL_LS, S_PROD_INT, and S_CL_SUBJ_LS. The tables names that you provide can only be a subset of the tables listed above.

Note:
When you delete a record in the table, the primary key of the deleted record is inserted in the RXI_DELETE_LOG_S table on the Siebel source system.

3. Set the value of the DELETE_FLOW submission parameter to Y in DAC, on the Source System Parameters tab under CDA_Warehouse container within the Design view.

4. Execute the ETLs as listed in the Section 2.2, "Executing the ETL Execution Plans".
The Siebel Clinical related SDE mappings read the above instance of the RXI_DELETE_LOG_S table.

Note:
Records that are deleted in the source system are soft deleted in the data warehouse.

2.1.3 Adding a New Data Source

OHSCDA provides predefined source-dependent extract (SDE) mappings for InForm, Oracle Clinical, and Siebel Clinical. Enter your source system related information in W_RXI_DATASOURCE_S table in Section 2.1.1, "Adding Data Source Information" where structure of w_rxi_datasource_s table is described. If you want to add another database (whether for one of these applications or for another application), perform the following tasks:

1. Create a new SDE programs to load the tables from source system to the staging area. For more information about creating a new SDE program, see Section 2.4, "Creating an ETL Execution Plan".

2. Insert a record into the W_RXI_DATASOURCE_S table, assigning the source a unique DATASOURCE_NUM_ID. Set this value to a number greater than 100.

Important:

- When calling an SDE mapping to read from a particular database instance, ensure that you pass in the value of DATASOURCE_NUM_ID that corresponds to that database. Also, pass ENTERPRISE_ID (normally 0) to the SDE.

- If you write new SDE, ensure that it sets the value of DATASOURCE_NUM_ID in the staging table to which it writes.

3. In DAC, navigate to the Setup view, and then select the Physical Data Sources tab.

4. Enter values in the following fields:

- Name: Logical name for the database connection.

- Type: Select Source for the database connection for a database.

- Connection Type: Type of database.

- Dependency Priority: Number used to generate dependencies when designing execution plans.

- Data Source Number: Unique number assigned to the data source category so that the data can be identified in the data warehouse. Enter the same value as you have given in the W_RXI_DATASOURCE_S table.

5. For source applications other than Siebel Clinical, it is necessary to load data into CDA's LOV seed table for each database instance from which CDA is sourced. So, if the database you are adding is not a Siebel Clinical database, perform the following steps:

1. Make a copy of OCDA_W_RXI_LOV_S_seed.sql.

2. In the copy, modify the value of datasource_num_id to the value that you specified in W_RXI_DATASOURCE_S for the source database that you are adding.

3. Connect to the RXI account.

4. Run the modified copy of OCDA_W_RXI_LOV_S_seed.sql.

2.1.4 Oracle Health Sciences Clinical Development Analytics Hierarchy

This section describes the hierarchy that organizes the ETL mappings in DAC. Figure 2-3 displays the OHSCDA hierarchy.

Figure 2-3 OHSCDA Hierarchy

The following is the OHSCDA hierarchy:

- CONTAINER (CDA_Warehouse): A single container that holds all objects used for OHSCDA.

- EXECUTION PLAN: A data transformation plan defined on subject areas that need to be transformed at certain frequencies of time. An execution plan is defined based on business requirements for when the data warehouse needs to be loaded. Single Execution Plan to Load Complete Warehouse.

- SUBJECT AREAS: A logical grouping of tables related to a particular subject or application context. It also includes the tasks that are associated with the tables, as well as the tasks required to load the tables. Subject areas are assigned to execution plans, which can be scheduled for full or incremental loads.

- TASK GROUPS: This is a group of tasks that should be run in a given order.

- TASKS: A unit of work for loading one or more tables. A task comprises the following: source and target tables, phase, execution type, truncate properties, and commands for full or incremental loads. Each task is a single Informatica workflow.

2.2 Executing the ETL Execution Plans

To load data from the source to their target tables in the data warehouse, run the Execution Plan packaged with OHSCDA. Perform the following tasks in DAC:

Note:
Before executing the ETL load plans, you must create a validation procedure to populate the Patient Statuses table for each study using two packaged procedures provided with Oracle Clinical. For information on how to create a validation procedure, see Oracle Clinical Creating a Study.

1. Navigate to the Execute view.

2. Select the CDA – Complete Warehouse execution plan.

3. Set the parameter values under the Parameter tab.

4. Build the execution plan.

5. Click Run.

Note:
The prune_days parameter is used to determine the extraction end date for the incremental load. By default, the value of this parameter is 1. This indicates that the source extraction end date is a day less than the ETL program run date. For example, if the ETL program run date is 28 July, 2010 the source extraction end date is 27 July, 2010.

6. If Oracle Clinical is your only data source:

1. Navigate to the Execution Plans tab.

2. Click the CDA - Oracle Clinical Warehouse execution plan.

3. Set the required parameters.

4. Build the execution plan.

5. Click Run.

7. If Siebel Clinical is your only data source:

1. Navigate to the Execution Plans tab.

2. Click the CDA - Siebel Clinical Warehouse execution plan.

3. Set the required parameters.

4. Build the execution plan.

5. Click Run.

8. If InForm is your only data source:

1. Navigate to the Execution Plans tab.

2. Click the CDA - Inform Warehouse execution plan.

3. Set the required parameters.

4. Build the execution plan.

5. Click Run.

Note:
Execution of the ETL (specifically the OCDA_ETL_RUN_S_POP program) populates W_ETL_RUN_S.LOAD_DT with the timestamp for the execution of the ETL. This ETL execution timestamp is used in the calculation of OHSCDA measures concerning the amount of time that currently open discrepancies have been open.
While the timestamp is captured in CURRENT_ETL_LOAD_DT, it is only available for calculation of discrepancy intervals through the OBIEE Dynamic Repository Variable CURRENT_DAY. CURRENT_DAY is refreshed from LOAD_DT at a fixed interval, by default 5 minutes, starting each time the Oracle BI Service is started. Between the time that the ETL is run, and the time that CURRENT_DAY is refreshed, calculations of intervals that currently open discrepancies have been open will be inaccurate.

The following are the two remedies:

- Restart the Oracle BI Server after every execution of the ETL. This will cause CURRENT_DAY to be refreshed to the correct value.

- If this is inconvenient, you can modify the intervals between refreshes of the value of CURRENT_DAY. For more information on how to modify the refresh interval for CURRENT_DAY, see Section 1.1, "Maintaining the Oracle Health Sciences Clinical Development Analytics OBIEE Repository".

Tip:
You can schedule the jobs to execute at regular intervals. For more information on scheduling jobs, see Section 2.6, "Scheduling an ETL Execution Plan".

If InForm is your data source, with automerge, to execute the CDA - Complete Inform Automerge execution plan:

1. Set the value of AUTO_MERGE_FLG to Y in the Source System Parameters tab under CDA_Warehouse container within the Design view.

2. Navigate to the Execution Plans tab.

3. Click the CDA - Complete Inform Automerge execution plan.

4. Set the required parameters.

5. Build the Execution Plan.

6. Click Run.

2.3 Customizing an ETL Execution Plan

When you customize an ETL Execution Plan, it is your responsibility to maintain version control over changes to ETL mappings.

Oracle recommends that you carefully track the changes you make to Oracle-supplied ETL so that you can re-apply these changes in subsequent releases.

2.4 Creating an ETL Execution Plan

Though OHSCDA includes ETL Execution Plans for extracting data from InForm, Oracle Clinical, and Siebel Clinical to OHSCDA data warehouse, you may want to create your own ETL to extract data from other data sources.

Note:
The value of DATASOURCE_NUM_ID is set to 1 for Oracle Clinical, 2 for Siebel Clinical, and 3 for InForm. If you want to add your own data sources, set this value to a number greater than 100.

See Also:

- Informatica PowerCenter Online Help

2.5 Modifying an ETL Execution Plan

You may also want to modify an existing ETL load plan to meet your reporting requirements.

See Also:

- Informatica PowerCenter Online Help

To modify an ETL without any changes to the associated tables or columns, perform the following tasks:

1. Identify the Execution Plan that needs to be modified in Informatica repository.

2. Open and modify the ETLs (transformation and/or workflow).

3. Test and save the changes in repository.

4. Connect to DAC and navigate to the corresponding task.

5. Right-click the task and synchronize it.

6. Navigate to the execution plan and execute ETL to verify the changes.

The ETL execution plans that extract data for the warehouse fact tables assume that the dimensions to which each fact is related are up-to-date at the time the fact ETL Execution Plans are executed. This assumption is the basis for certain fact calculations that would provide erroneous results if the assumption were not true. For example, in the received CRFs fact, the value of the pCRF entry complete measure depends on whether or not the study requires second pass entry. But that piece of information -- second pass entry required -- is obtained from an attribute of the Study dimension. So, if the second-pass requirement for a study changes, and the change is not applied to the Study dimension, the Received CRF fact attributes will contain incorrect values.

As shipped, OHSCDA ETL workflows ensure this interlock by executing the ETL for related dimensions immediately before running the ETL for a fact. This is standard warehouse management practice, but especially important given the interdependence of the dimensions and the fact. The need to execute dimension ETL immediately before corresponding fact ETL, and the danger of not doing it, is emphasized here because it is possible (though discouraged) to modify these shipped workflows.

To modify one or more tables or columns without any changes to the associated ETL programs (typically to widen a column):

1. Change the table properties as needed.

2. Save the mapping and refresh the workflow.

3. Connect to DAC and navigate to corresponding task and refresh it.

Note:
If the changes to the tables or columns are not compatible with the table that is installed in the data warehouse schema, you will get a warning while making the change. For example, if you are reducing the length of a number column from 15 to 10, the change is not compatible with the existing data in the table.

2.6 Scheduling an ETL Execution Plan

When you submit an Execution Plan for execution in DAC, you can schedule it execute at regular intervals. To schedule an Execution Plan, perform the following tasks:

1. Navigate to the Scheduler tab within the Execute view.

2. Create a new schedule plan.

3. Enter the required details and click Save.

3 InForm Auto-merge Matching Rules

This chapter describes the rules for identifying matches across InForm studies.

If records from two studies match on identifiers listed in the following sections, the single best record will be created from the source record with the latest modification timestamp. If timestamps are same on the matching records, use the record with the largest primary key ID value. Ignore case for all string comparisons.

3.1 W_EMPLOYEE_DS

For employee dimension, we consider a user who has RIGHTSGROUP = 'CRA' to be a CRA.

Two users are considered identical if their values on all of the following are identical:

- upper(IRV_CUR_USER.USERFIRSTNAME)

- upper(IRV_CUR_USER.USERLASTNAME)

- upper(IRV_CUR_USER.USERPOSTALCODE)

- upper(IRV_CUR_USER.USERCOUNTRY)

3.2 W_GEO_DS

Two geographies are identical if they match on Country, State/Province, City, and PostalCode.

For InForm, the following columns are used for comparison and auto-merge.

Attribute

Column in IRV_CUR_SITE

Col in IRV_CUR_USER

Country

SITECOUNTRY

USERCOUNTRY

State/Province

SITESTATEPROVINCE

USERSTATEPROVINCE

City

SITECITY

USERCITY

PostalCode

SITEPOSTALCODE

USERPOSTALCODE

Choose geographies for users only from those users where RIGHTSGROUP in ('PI','CRA').

3.3 W_HS_APPLICATION_USER_DS

Two users are considered identical if their values on upper(IRV_CUR_USER.USERNAME) are identical.

3.4 W_PARTY_PER_DS

For principle investigators, we consider a user who has RIGHTSGROUP = 'PI' to be a PI.

Two users are considered identical if their values on all of the following are identical:

- upper(IRV_CUR_USER.USERFIRSTNAME)

- upper(IRV_CUR_USER.USERLASTNAME)

- upper(IRV_CUR_USER.USERPOSTALCODE)

- upper(IRV_CUR_USER.USERCOUNTRY)

3.5 W_PRODUCT_DS

Two studies are considered to be testing the same product if their values of upper(IRV_STUDYVERSIONS.SPONSORDRUGNAME), in their latest studyversion, are identical.

3.6 W_RXI_PROGRAM_DS

Two studies are considered to be part of the same program if their values of upper(IRV_CUR_SPONSOR.PROGRAMNAME) are identical.

3.7 W_RXI_SITE_DS

Two sites are considered identical if the following attributes matched in IRV_CUR_SITE:

- upper(SITENAME)

- upper(SITEPOSTALCODE)

- upper(SITECOUNTRY)

3.8 W_RXI_THERAPEUTIC_AREA_DS

Two studies are considered to be part of the same therapeutic area if their values of upper(IRV_CUR_SPONSOR.THERAPUTICAREA) are identical.

A Troubleshooting

This appendix contains the following topics:

- Section A.1, "Oracle Business Intelligence Data Warehouse Administration Console Task Fails due to Missing Parameter File"

- Section A.2, "Sorting and Displaying Null Values in Reports"

- Section A.3, "Aborting a Workflow"

A.1 Oracle Business Intelligence Data Warehouse Administration Console Task Fails due to Missing Parameter File

In DAC 10.1.3.4.1 + patch (***) command_infa.xml uses -paramfile as the default option for the parameter file. The DAC tasks will fail if DAC and Informatica servers are on different machines.

To fix the problem, perform the following steps:

1. Navigate to <DAC>\conf folder and edit the file infa_commands.xml.

2. Edit the block START_WORKFLOW_7 or START_WORKFLOW_8 and change the content as follows:

- For START_WORKFLOW_7 replace the following line:
pmcmd startworkflow -sv %SERVER -d %DOMAIN -u %USER -p %PASSWORD -f %FOLDER -paramfile %PARAMFILE %WORKFLOW

with

pmcmd startworkflow -sv %SERVER -d %DOMAIN -u %USER -p %PASSWORD -f %FOLDER -lpf %PARAMFILE %WORKFLOW

- For START_WORKFLOW_8 replace the following line:
pmcmd startworkflow -sv %SERVER -d %DOMAIN -u %USER -p %PASSWORD -f %FOLDER -paramfile %PARAMFILE %WORKFLOW

with

pmcmd startworkflow -sv %SERVER -d %DOMAIN -u %USER -p %PASSWORD -f %FOLDER -lpf %PARAMFILE %WORKFLOW

Note:
These modifications should be done both on the DAC client and the server machines.

3. After you modify this file, restart the DAC server and client for the changes to take effect.

A.2 Sorting and Displaying Null Values in Reports

In order to understand results shown in OBIEE reports, it may be necessary to understand how null values are sorted and displayed in reports.

Oracle uses NULL as a pseudo-value for a table cell when there is no actual value. For example, if the number of documents awaiting completion for a site is unknown, the column containing that attribute of the site will be set to null in the database.

As null values can appear in among data, OBIEE has rules that determine how to display the null values. And as OBIEE supports sorting of data in a column, it has rules for how nulls should be sorted.

The following are the rules:

- Oracle's sorting order cause a null value to be treated as greater than any non-null value.

- In table views, OBIEE generally displays null values as empty cells.
The exception is when the request designer has specified that the user can navigate to a different request by clicking on a value in the column that contains null. In that case, in order to give the user something to click on, OBIEE displays the null value as a zero.

These rules can produce unexpected results. This following section describes how to interpret such unexpected results. It also describes actions you can take in creating OBIEE requests to override OBIEE's default rules.

The results of these rules are:

- If the data in a column contain nulls and non-nulls, and the column is sorted, and navigation is not enabled from cells in the column, then:

- Nulls will display as blank cells

- Blank cells will sort as larger than the largest non-null value

- If the data in a column contain nulls and non-nulls, and the column is sorted, and navigation is enabled from cells in the column, then:

- Nulls will display as zeros

- Cells representing nulls (but now displaying as zeros) will sort as larger than the largest non-null value. If there are actual zeros in the column as well, they will sort as smaller than the smallest positive value in the column. So, if you have both real zero values and null values, and cell-based navigation is enabled, and you sort the column, you will get two clumps of zeros - one representing the nulls, the other representing the actual zeros - separated by the non-negative actual values.

- OBIEE does have a capability that can be used to make it easier to identify null values. In requests, you can use the IFNULL function to specify that NULL should be replaced by a large negative value that could not be a real value for the column. For instance, if "# Documents Outstanding" could be null in your data, and you want to include it in a request, you could change the functional definition of the column in the request from "# DocumentsOutstanding" to IFNULL("# Documents Outstanding", -99). This would cause nulls to sort and display as if their value was -99.

If you use IFNULL, it is important that you:

- Choose a value that could not also be a legitimate value (this may vary from column to column, though it is preferable to use the same IFNULL replacement across all columns).

- Communicate to your end users the meaning of the IFNULL values.

A.3 Aborting a Workflow

A workflow can be aborted by the following two methods:

Method 1

Perform the following steps in DAC to abort a workflow:

1. Navigate to Execute > Execution Plan sub tab.

2. Click the Execution Plan you want to abort.

3. Click Abort.

Method 2

Perform the following steps in Informatica PowerCenter to abort a workflow:

1. Open the Informatica PowerCenter Workflow Monitor.

2. In the Repositories tree, navigate to the particular folder that contains the Informatica job.

3. In the Workflow Run pane, select and right-click the workflow, and click Abort.

See Also:

Informatica PowerCenter Online Help

Index
A  B  C  D  E  I  L  M  N  O  P  R  S

A

adding, new data source, 2.1.3

architecture

ETL programs, 2.1

B

bulk and normal load

about, 2.1

bulk load, 2.1

C

creating

ETL programs, 2.4

customizing ETL programs, 2.3

D

data warehouse

maintaining, 1.2

modifying tables, 1.2.3

derivations

about, 1.3

definition, 1.2

domain hierarchy, OHSCDA, 2.1.4

E

ETL programs

architecture, 2.1

creating, 2.4

customizing, 2.3

definition, 2

executing, 2.2

modifying

one or more tables, 2.5

without changes to the associated tables or columns, 2.5

scheduling, 2.6 executing ETL programs, 2.2 extensions

about, 1.2.1

definition, 1.2

I

incremental load, 2.1

indexes, managing, 1.2.3

L

load

bulk, 2.1

incremental, 2.1

normal, 2.1

M

maintaining

data warehouse, 1.2

repository, 1.1

managing indexes, 1.2.3 modifying

ETL programs

one or more tables without changes to the associated ETL programs, 2.5

without changes to the associated tables or columns, 2.5

N

normal load, 2.1

O

OHSCDA

domain hierarchy, 2.1.4

P

patches, Preface

R

repository, maintaining, 1.1

S

scheduling

ETL programs, 2.6

source-dependent extract (SDE)

features, 2.1

source-independent load (SIL)

features, 2.1

substitutions

about, 1.2.2

definition, 1.2

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2016, Oracle and/or its affiliates. All rights reserved.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.

Private Alpha and Beta Draft Documentation Notice

If this document is in private preproduction status:

The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your beta trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.