Types of Execution Plans

1.    An execution plan is a unit of work that enables you to organize, schedule, and execute ETL processes.

2.    An execution plan comprises the following objects: subject areas, ordered tasks, indexes, tags, parameters, source system folders, and phases.

DAC supports single-source and multi-source execution plans, which are described in the following sections:

•  Single-Source Execution Plans
• Multi-Source Execution Plans

Single-Source Execution Plans

A single-source execution plan extracts data from a single instance of a single source system container, such as Siebel 7.8 or Oracle EBS 11

Multi-Source Execution Plans

There are two types of multi-source execution plans:

• Homogeneous

1.    This type of execution plan extracts data from multiple instances of the same source system.

2.     For example, a business might have an instance of Oracle EBS 11i in one location and time zone and another instance of Oracle EBS 11i in another location and time zone.

3.    In such cases, the timing of data extraction from the different instances can be staggered to meet your business requirements.

• Heterogeneous

1.    This type of execution plan extracts data from one or more instances of dissimilar source systems

2.    . For example, a business might have an instance of Siebel 7.8 in one location, an instance of Oracle EBS 11i in another location, and a second instance of Oracle EBS 11i in yet a third location.

3.    You can also stagger the timing of data extraction when you use this type of execution plan.

DAC Security

1. DAC Security Overview
2. DAC Client Installation Requirements
3. DAC Authentication in Oracle Fusion Middleware (WebLogic Server) Mode
4. DAC Authentication in Standalone Mode
5. Recommended DAC Security Setup

DAC Security Overview

Ø  DAC Repository. Resides on a database and stores the metadata (semantics of the Oracle Business Analytics Warehouse) that represents the data warehouse processes.

Ø  DAC Client. A thick client (Swing GUI).

Ø  DAC Server. Can be deployed as an enterprise application on the Web Logic Server (referred to as Web mode) or as a standalone Java application (referred to as standalone mode).

Ø  Non-interactive automation tools

Ø  Non-interactive command line tools

1.    When DAC runs in Fusion Middleware mode, users are defined in the WebLogic Server identity store (LDAP) and authenticated against a BI domain.

2.    The Fusion Middleware tier authenticates the users for access to the DAC repository.

3.    The LDAP credentials indicate: 1) whether the user is valid, and 2) the user's role.

4.    The DAC Client also accesses database credentials stored in an encrypted cwallet.sso file in the file system to access the DAC repository database.

5.    The database credentials are used to manipulate objects in the repository through direct JDBC access.

6.    When DAC runs in DAC standalone authentication mode, the DAC Client authenticates users and gets user permissions against user credentials stored in the DAC repository.

DAC Client Installation Requirements

For production environments, in both Fusion Middleware and DAC standalone authentication deployment modes, the DAC Client has access to highly sensitive password information that allows connectivity to the DAC repository, to all of the data sources accessed by the BI Server (including the transactional data source), and to the data warehouse.

Therefore, for production environments, in both Fusion Middleware and DAC standalone authentication deployment modes, you must install the DAC Client according to the following requirements:

• The DAC Client must be physically located in the server tier with the other middle-tier components.
• The DAC Client should be accessed only by trusted users.
• The DAC Client should be accessible only through remote log in tools if it is accessed outside of the server tier.
• The DAC Client should not be installed on the administrator's desktop.

DAC Authentication in Oracle Fusion Middleware (WebLogic Server) Mode

Figure illustrates the process of securing DAC when the DAC Server is running as a service on WebLogic Server.

Figure 1-1 DAC Server Running as Service on WebLogic Server

1.    DAC Client logs in using FMW authentication:

1.    Gets user name and password from user (can be optionally saved on the file system).

2.    Reads the database connection information from the encrypted cwallet.sso file stored on the file system.

3.    Logs into the DAC repository.

4.    Reads the DAC Server URL from the DAC repository.

5.    Authenticates and gets permissions through the DAC Server in the BI domain using the BI domain URL.

2.    DAC Server reads the database connection information from the file system and connects to the DAC repository upon startup.

3.    Automation utilities read the database connection information from the file system and connect to the DAC repository.

Note: The automation utilities are not interactive

4.    DAC Server command line utilities read the DAC Server information from the file system and send it as a Web service request, which is authenticated with proper user credentials.

DAC Authentication in Standalone Mode

Figure illustrates the process of securing DAC when the DAC Server is running as a standalone JVM process.

Figure 1-2 DAC Server Running in Standalone Mode

This process is as follows:

1. DAC Client logs in using DAC authentication:
1. Gets user name and password from user (can be optionally saved on the file system).
2. Reads the database connection information from the encrypted cwallet.sso file stored on the file system.
3. Logs into the DAC repository.
4. Authenticates and gets permissions against user credentials stored in the DAC repository.
2. DAC Server reads the database connection information from the file system and connects to the DAC repository upon startup.
3. Automation utilities read the database connection information from the file system and connect to the DAC repository. Note: The automation utilities are not interactive.
4. DAC Server command line utilities read the DAC Server information from the file system and send it as a Web service request, which is authenticated with proper user credentials.

Recommended DAC Security Setup

The recommended DAC security setup includes the following points:

1. DAC is used for orchestrating ETL processes, and, therefore, should be accessed by a limited number of administrators with the appropriate privileges. The schema level operations that require administrator privileges include but are not limited to the following:

Ø  Truncating tables

Ø  Managing indexes

Ø  Collecting statistics on tables after the data is populated

Ø  Querying system catalog tables

Ø  Creating the data warehouse schema

Because of the sensitive nature of schema level operations, DAC should also be secured by the operating system level security.

2. The DAC repository should be stored in a different database from the data warehouse and transactional applications databases. This allows for restriction of DAC users, if necessary.