Skip Headers
Oracle® Warehouse Builder Concepts
11g Release 2 (11.2)

Part Number E10581-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

9 Deployment and Execution

This section discusses the concepts of deploying design objects to a target schema, and executing the ETL logic defined in the deployed objects.

This section contains these topics:

About Deploying and Executing Design Objects

After you design your ETL and data quality processes, you deploy and execute the resulting design objects in order to implement the design in the target schema. The Control Center Manager provides a comprehensive deployment console for viewing and managing all aspects of deployment and execution. It provides access to the information stored in the active Control Center.

The following topics provide overviews of deploying and executing design objects:

See Also:

"Deploying to Target Schemas and Executing ETL Logic" in Oracle Warehouse Builder Data Modeling, ETL, and Data Quality Guide

Deployment Concepts

Deployment is the process of creating physical objects in a target location according to the logical objects in an OWB workspace.

For example, when you create a table using the Design Center, the metadata for this table is stored in the workspace. If the table described in your design does not already exist in the database schema referenced by the specified location, then you must create the table by deploying it. Similarly, after you design a PL/SQL mapping, you must generate code for it (which creates a PL/SQL package implementing the mapping logic), then deploy the generated code to the specified location, which loads the generated PL/SQL package to the referenced schema. You can deploy objects from within the Design Center, or use the Control Center Manager. You can also use OMB*Plus commands to deploy objects.

As soon as you define a new object in the Design Center, the object is listed in the Control Center Manager under its deployment location.

Deploying a mapping or a process flow includes these steps:

  • Generate the PL/SQL, SQL*Loader, or ABAP script, if necessary.

  • Register the required locations and deploy any required connectors. This ensures that the details of the physical locations and their connectors are available at runtime.

  • Transfer the PL/SQL, XPDL, SQL*Loader, or ABAP script from the Design Center to the Control Center. (XPDL refers to XML Process Definition Language, a format standardized by the Workflow Management Coalition.)

Note:

  • After deploying a mapping or a process flow, you must explicitly start the scripts, as described in "Starting ETL Jobs" Oracle Warehouse Builder Data Modeling, ETL, and Data Quality Guide.

  • Workspace users can deploy only those objects for which they have the COMPILE privilege. By default, his privilege is granted on all objects in the workspace. However, the workspace owner may have instituted a different security policy.

See Also:

"Deploying Objects" in Oracle Warehouse Builder Data Modeling, ETL, and Data Quality Guide

Deployment Status: Viewing Results

After you deploy an object, OWB assigns a deployment status to it. You can view the deployment status in the Control Center Manager.

The status represents the result of the deployment as follows:

  • Not Deployed: Indicates that the object has not yet been deployed to the target schema.

  • Success: Indicates that the object has been successfully deployed to the target schema.

  • Warning: Indicates that some warnings were generated during the deployment of the object. Double-click the status to view details about the warning.

  • Failed: Indicates that deployment of the object failed. Double-click the job in the Control Center jobs window to view information about why the deployment failed. The Job Log in the Design Center also captures details that you can view.

About Executing Design Objects

Execution is the process of starting the ETL logic defined in the deployed objects. For example, you define a mapping that sources data from a table, performs transformations on the source data, and loads it into the target table. When you deploy this mapping, the PL/SQL code generated for this mapping is stored in the target schema. When you execute this mapping, the job for the ETL logic is started and the data is picked up from the source table, transformed, and loaded into the target table.

Overview of Deployment and Execution Procedures

During the lifecycle of a data system, you typically will take these steps in the deployment process to create your system and perform the execution process to move data into your system:

Step 1   Select a named configuration

The Control Center for the selected configuration specifies the execution environment for the objects.

Step 2   Deploy objects to the target location

You can deploy them individually, in stages, or all at once.

Step 3   Review the results of the deployment

If an object fails to deploy, then fix the problem and try again.

Step 4   Start the ETL process for the target location

Execute the mappings or process flows that contain the ETL logic for the objects.

Step 5   Revise the design of target objects, if needed

Accommodate user requests, changes to the source data, and so forth.

Step 6   Set the deployment action

Set the modified objects to Upgrade or Replace.

Runtime Auditing for Deployments and Executions

Whenever you deploy and execute a design object, auditing information is generated and stored for you to view and manage.

The auditing information is specific to the type of object:

You view and manage the audit information through these methods:

About Scheduling Design Objects to Execute

OWB provides these scheduling options:

Integration with Third-party Schedulers

Integration with third-party schedulers depends on the features of the third party scheduler. For example, mappings and process flows in OWB are PL/SQL packages, and if there is a way in a third party scheduler to invoke a PL/SQL package, then refer to the documentation for that third party scheduler. You can also expose a mapping or a process flow as a Web Service if you are using a product like Oracle BPEL that can invoke Web services as part of orchestrating complex processes.

See Also: