Oracle ODI 12c Student Guide 2

Oracle Data Integrator:
Administration and Development

Student Guide – Volume 2
D48459GC40
Edition 4.0
January 2010
D65207
Author Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Viktor Tchemodanov Disclaimer
This document contains proprietary information and is protected by copyright and other intellectual
Technical Contributors property laws. You may copy and print this document solely for your own use in an Oracle training
and Reviewers course. The document may not be modified or altered in any way. Except where your use constitutes
"fair use" under copyright law, you may not use, share, download, upload, copy, print, display,
Christophe Dupupet perform, reproduce, publish, license, post, transmit, or distribute this document in whole or in part
Benoit Gagnon without the express authorization of Oracle.
Denis Gray The information contained in this document is subject to change without notice. If you find any
Art Hetherington problems in the document, please report them in writing to: Oracle University, 500 Oracle Parkway,
Redwood Shores, California 94065 USA. This document is not warranted to be error-free.
Taj-ul Islam
Gerry Jurrens Restricted Rights Notice
FX Nicolas If this documentation is delivered to the United States Government or anyone using the
documentation on behalf of the United States Government, the following notice is applicable:
Nagavalli Pataballa
Pallavi Rajan U.S. GOVERNMENT RIGHTS
The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or disclose these
Usha Ramanathan training materials are restricted by the terms of the applicable Oracle license agreement and/or the
Noel Schneider applicable U.S. Government contract.
Phillip Scott Trademark Notice
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be
Editor trademarks of their respective owners.
Amitha Narayan
Graphic Designer
Rajiv Chandrabhanu
Publishers
Jayanthy Keshavamurthy
Giri Venugopal
Contents
1 Introduction
Course Objectives 1-2
Objectives 1-3
Agenda of Lessons 1-4
Oracle Data Integrator: Introduction 1-6
What Is Oracle Data Integrator? 1-7
Why Oracle Data Integrator? 1-8
Conventional Integration Process: ETL 1-10
EL-T 1-11
ODI Architecture and Components 1-13
ODI Architecture 1-14
ODI Components: Overview 1-16
Graphical Modules 1-17
ODI Designer 1-18
ODI Operator 1-19
ODI Topology Manager 1-20
ODI Security Manager 1-21
What Is an Agent? 1-22
Types of ODI Agents 1-23
Run-Time Components: Example 1-24
Metadata Navigator 1-25
Oracle Data Integrator Repositories 1-26
ODI Repositories 1-27
Master and Work Repositories 1-28
Repository Setup: Example 1-30
Components: A Global View 1-31
Quiz 1-32
Summary 1-34
2 Administering ODI Repositories and Agents

Objectives 2-2
Administering the ODI Repositories 2-3
Why Administering? 2-4
Steps to Set Up ODI Repositories 2-5
Creating Repository Storage Spaces 2-6
Creating the Master Repository 2-7
Connecting to the Master Repository 2-8
Importing Master Repository 2-10
Exporting the Master Repository 2-11
iii
Creating a Work Repository 2-12
Connecting to the Work Repository 2-14
Changing the Work Repository password 2-16
Managing ODI Agents 2-17
ODI Physical Agent 2-18
Creating a Physical Agent 2-19
Launching a Listener Agent 2-20
Launching a Scheduler Agent 2-21
Launching a Web Agent 2-22
ODI Agent Parameters 2-23
Stopping the ODI Agent 2-25
Load Balancing: Example 2-26
Quiz 2-28
Summary 2-29
3 ODI Topology Concepts

Objectives 3-2
ODI Topology: Overview 3-3
What Is Topology? 3-4
What Is in the Topology? 3-5
Data Servers and Physical Schemas 3-6
What Is a Data Server? 3-7
Important Note 1 3-9
What Is a Physical Schema? 3-10
Physical Schemas: Properties 3-11
Concepts in Reality 3-12
Defining Topology: Examples 3-14
Infrastructure (Production): Example 3-15
Physical Architecture in ODI: Example 3-16
Infrastructure (Development): Example 3-17
Fragmentation Problem 3-18
Defining the Physical Architecture: Example 3-20
The Infrastructure: Example 3-21
Physical Architecture in ODI 3-22
Logical Schemas and Contexts 3-23
What Is a Logical Schema? 3-24
Information System: Example 3-27
Defining the Logical Architecture 3-28
Logical Versus Physical Architecture 3-29
Note: Design Time Versus Run Time 3-30
What Is a Context? 3-31
iv
Defining Contexts 3-33
Mapping Logical and Physical Resources 3-34
Agents in Topology 3-36
Agents 3-37
Infrastructure with Agents: Example 3-39
Defining Agents: Example 3-40
Defining a Topology: Best Practices 3-41
Planning the Topology 3-42
Matrix of Logical and Physical Mappings 3-43
Quiz 3-44
Summary 3-46
4 Describing the Physical and Logical Architecture

Objectives 4-2
Topology Manager 4-3
What Topology Manager Contains 4-4
Topology Manager: Overview 4-5
Creating Physical Architecture 4-7
Physical Architecture View 4-8
Prerequisites for Connecting to a Server 4-9
Important Note 4-10
Creating a Data Server 4-11
Creating a Data Server: JDBC 4-12
JDBC Driver 4-13
JDBC URL 4-14
JDBC URL: Example 4-15
Drivers and URLs: Examples 4-16
Creating a Data Server: JNDI 4-17
Testing a Data Server Connection 4-18
Creating a Physical Schema 4-19
Creating Logical Architecture 4-20
Logical Architecture and Context Views 4-21
Defining a Context 4-22
Creating a Logical Schema 4-23
Creating a Logical Agent 4-24
Linking the Logical and Physical Architecture 4-25
Quiz 4-26
Summary 4-28
5 Setting Up a New Project

Objectives 5-2
ODI Projects 5-3
What Is a Project? 5-4
v
Oracle Data Integrator Projects: Overview 5-5
How to Use ODI Project in Your Work? 5-6
Creating a New Project 5-7
Using Folders 5-8
What Is a Folder? 5-9
Creating a New Folder 5-10
Organizing Projects and Folders 5-11
Understanding Knowledge Modules 5-12
What Is a Knowledge Module? 5-13
Types of Knowledge Modules 5-14
Which Knowledge Modules Are Needed? 5-15
Knowledge Modules: Examples 5-16
Importing a New Knowledge Module 5-17
Replacing Existing KMs 5-18
Exporting and Importing Objects 5-20
Exporting and Importing 5-21
Exporting an Object 5-22
Importing an Object 5-23
ID Numbers: Overview 5-24
Import Types 5-25
Choosing the Import Mode 5-26
Using Markers 5-27
What Is a Marker? 5-28
Tagging Objects with Markers 5-29
Removing Markers 5-30
Marker Groups 5-31
Project and Global Markers 5-32
Creating a Marker Group 5-33
Quiz 5-34
Summary 5-36
6 Oracle Data Integrator Model Concepts

Objectives 6-2
What Is a Model? 6-3
Understanding the Relational Model 6-4
Relational Model 6-5
Relational Model: Tables and Columns 6-6
Relational Model: Keys 6-7
Relational Model: Foreign Keys 6-8
Relational Model: Constraints 6-9
Relational Model: Indexes 6-11
Relational Model Support in ODI 6-12
Additional Metadata in ODI 6-13
Understanding Reverse Engineering 6-15
vi
What Is Reverse Engineering? 6-16
Methods for DBMS Reverse Engineering 6-17
Other Methods for Reverse Engineering 6-18
Standard Versus Customized Reverse Engineering 6-19
Note 6-20
Creating Models 6-21
How to Create a Model by Reverse Engineering 6-22
Step 1: Creating and Naming a New Model 6-23
Note 6-24
Step 2: Defining a Reverse Engineering Strategy 6-25
Step 3: Starting the Reverse Engineering Process 6-27
Selective Reverse Engineering 6-28
Step 4: Fleshing Out Models 6-29
Quiz 6-30
Summary 6-32
7 Organizing ODI Models and Creating Datastores

Objectives 7-2
Organizing Models 7-3
What Is a Model Folder? 7-4
Creating a Model Folder 7-5
What Is a Submodel? 7-6
Creating a Submodel 7-7
Organizing Datastores into Submodels 7-8
Setting Up Automatic Distribution 7-9
Creating Datastores 7-10
Creating a Datastore in a Model 7-12
Adding Columns to a Datastore 7-13
Constraints in ODI 7-14
What Is a Constraint in ODI? 7-15
Constraints in ODI 7-16
Creating a Mandatory Column 7-17
Creating Keys and References 7-18
Creating a Key 7-19
Checking a Key 7-20
Creating a Reference 7-21
Creating a Simple Reference 7-22
Creating a Complex Reference 7-23
Checking a Reference 7-24
Creating Conditions 7-25
Creating a Condition 7-26
Checking a Condition 7-27
Overview 7-28
When and Why? 7-29
vii
An Overview of the Process 7-30
Exploring Your Data 7-31
Displaying the Contents of a Datastore 7-32
Viewing the Distribution of Values 7-33
Analyzing the Contents of a Datastore 7-34
Constructing Business Rules 7-35
Defining Business Rules in ODI 7-36
From Business Rules to Constraints 7-37
Deducing Constraints from Data Analysis 7-38
Testing a Constraint 7-39
Auditing a Model or Datastore 7-40
How to Review Erroneous Records 7-41
Quiz 7-42
Summary 7-44
8 ODI Interface Concepts

Objectives 8-2
ODI Interfaces 8-3
What Is an Interface? 8-4
Business Rules for Interfaces 8-5
Where Are the Rules Defined? 8-6
Mapping, Join, and Filter 8-7
What Is a Mapping? 8-8
What Is a Join? 8-9
What Is a Filter? 8-10
Behind the Rules 8-11
How does ODI Implement Business Rules? 8-12
A Business Problem 8-13
Implementing the Rules 8-14
Integration Process 8-15
Process Details 8-16
Process Implementation: Example 1 8-17
Staging Area and Execution Location 8-20
What Is the Staging Area? 8-21
Execution Location 8-22
Understanding Knowledge Modules 8-23
From Business Rules to Processes 8-24
Knowledge Modules 8-25
What Is a Knowledge Module? 8-26
Code Generation 8-27
KM Types Used in Interfaces 8-28
Interfaces: An Overview 8-29
viii
What Is an Interface? 8-30
Creating a One-to-One Interface 8-31
Creating and Naming an Interface 8-32
Defining the Target Datastore 8-33
Important Note 8-34
Defining the Source Datastore 8-35
What Is a Mapping? 8-36
Defining the Mappings 8-37
Valid Mapping Types 8-38
Saving the Interface 8-39
Executing the Interface 8-40
Quiz 8-41
Summary 8-43
9 Designing Interfaces
Objectives 9-2
Multiple Sources and Joins 9-3
Multiple Source Datastores 9-4
Creating a Join Manually 9-5
Advanced Joins 9-6
Types of Joins 9-7
Setting Up a Join 9-8
Filtering Data 9-10
Filters in ODI 9-11
Defining a Filter Manually 9-12
Setting Up a Filter 9-13
An Overview of the Flow in ODI Interface 9-14
Flow 9-15
What Defines the Flow? 9-16
The Scenario 9-17
The Basic Process 9-18
Selecting a Staging Area 9-19
What Is the Staging Area? 9-20
Case Study: Placing the Staging Area 9-21
Important Note 9-22
How to Specify the Staging Area 9-23
Case Study: Flow 1 9-24
Case Study: Flow 1 in ODI 9-25
Case Study: Flow 2 in Oracle Data Integrator 9-27
Case Study: Flow 3 in ODI 9-29
Configuring Filters, Joins, and Mappings 9-30
Options for Filters, Joins, and Mappings 9-31
ix
Setting Options for Filters, Joins, and Mappings 9-32
How to Disable a Transformation 9-33
How to Enable a Mapping for Inserts or Updates 9-34
Execution Location 9-35
Execution Location and Syntax 9-36
Why Change the Execution Location? 9-37
How to Change the Execution Location 9-38
Selecting the KM 9-39
Which KMs for Which Flow? 9-40
More About KMs 9-42
Identifying IKMs and LKMs 9-43
IKMs and LKMs: Strategies and Methods 9-44
Flow: Example 1 9-45
How to Specify an LKM 9-48
How to Specify an IKM 9-49
Common KM Options 9-50
Quiz 9-51
Summary 9-52
10 Interfaces: Monitoring and Debugging

Objectives 10-2
Monitoring Interfaces 10-3
Operator: Viewing the Log 10-4
Using Operator 10-5
Sessions, Steps, Tasks: The Hierarchy 10-6
Viewing Sessions and Tasks 10-7
How to Monitor Execution of an Interface 10-8
How to Troubleshoot a Session 10-9
1. Identifying the Error 10-10
2. Reviewing the Code 10-11
3. How to Fix the Code and Restart the Session 10-12
4. Fixing the Interface 10-13
Keys to Reviewing the Generated Code 10-14
Working with Errors 10-15
Common Errors and Symptoms 10-16
Important Note 10-18
Tips for Preventing Errors 10-19
Quiz 10-20
Summary 10-22
11 Designing Interfaces: Advanced Topics

Objectives 11-2
Working with Business Rules 11-3
x
Business Rules in Interfaces 11-4
Business Rule Elements 11-5
More Elements 11-6
Using Variables 11-7
Using a Variable in Code 11-8
Binding Versus Substitution 11-10
Note: Case-Sensitivity 11-11
Using Sequences 11-12
Referring to Sequences 11-13
Note: Sequences Updated by Agent 11-14
Using Sequences in Mappings Correctly 11-15
Using ODI Sequences in Mappings 11-16
Populating Native Identity Columns 11-17
Note 11-18
Using User Functions 11-19
What Is a User Function? 11-20
Why Use User Functions? 11-21
Properties of User Functions 11-23
Using User Functions 11-24
How to Create a User Function 11-25
Defining an Implementation 11-26
Syntax and Implementations 11-27
User Functions at Design Time 11-28
User Functions at Run Time 11-29
Note: Functions in Execution Log 11-30
Using Substitution Methods 11-31
Substitution Methods: Examples 11-34
The Expression Editor 11-35
Modifying Knowledge Modules 11-37
Description of KM Steps 11-38
Details of the Steps 11-39
Setting KM Options 11-40
Developing Your Own KM: Guidelines 11-41
Using RKM for Customized Reverse Engineering 11-43
Quiz 11-45
Summary 11-46
12 Using ODI procedures

Objectives 12-2
Procedures: Overview 12-3
What Is a Procedure? 12-4
Procedure: Examples 12-5
Creating Procedures: Overview 12-7
xi
Creating a Blank Procedure 12-8
How to Create a New Procedure 12-9
Adding Commands 12-10
Creating a Command 12-11
Arranging Steps in Order 12-13
Which Parameters Should Be Set? 12-14
Valid Types of Commands 12-15
More Elements 12-16
Why Use a Source Command? 12-17
Adding Options 12-18
Types of Options 12-19
How to Create a New Option 12-20
How to Make a Command Optional 12-21
Using an Option Value in a Command 12-22
Running a Procedure 12-23
Procedure Execution 12-24
Using Operator to View Results 12-25
Quiz 12-26
Summary 12-28
13 Using ODI Packages

Objectives 13-2
Packages: Overview 13-3
What Is a Package? 13-4
How to Create a Package 13-5
1. Creating and Naming a Package 13-6
How to Create and Name a Package 13-7
Package Diagram 13-8
Package Diagram Toolbar 13-9
2. Adding Steps to the Package 13-11
Steps 13-12
How to Create an Interface Step 13-13
What Is an ODI Tool? 13-14
How to Create an ODI Tool Step 13-15
Note 13-16
3. Arranging Package Steps in a Sequence 13-17
Sequencing Steps 13-18
A Simple Package 13-19
How to Sequence Package Steps 13-20
Executing a Package 13-21
Review of Package Steps 13-23
Basic Step Types 13-24
Advanced Step Types 13-25
Procedure Steps 13-26
xii
How to Create a Procedure Step 13-27
Model, Submodel, and Datastore Steps 13-28
How to Create Model, Submodel, and Datastore Steps 13-29
Models, Submodels, and Datastore Steps 13-30
Variable Steps 13-32
How to Create a Variable Step 13-33
Variable Steps 13-34
Controlling the Execution Path 13-36
Controlling Execution 13-37
Error Handling 13-38
How to Create a Loop 13-39
The Advanced Tab 13-40
Quiz 13-41
Summary 13-43
14 Managing ODI Scenarios and Versions

Objectives 14-2
Scenarios 14-3
What Is a Scenario? 14-4
Properties of Scenarios 14-5
Managing Scenarios 14-6
Scenario-Related Tasks 14-7
Generating a Scenario 14-8
Regenerating a Scenario 14-9
Generation Versus Regeneration 14-10
Executing a Scenario from the GUI 14-11
Executing a Scenario from a Command Line 14-12
Executing a Scenario from a Project 14-13
Exporting a Scenario 14-14
Preparing for Deployment 14-15
Preparing Scenarios for Deployment 14-16
Automating Scenario Management 14-17
Scheduling the ODI Scenario 14-18
Overview of ODI Version Management 14-20
What Is Version Management? 14-21
Working with Object Flags 14-22
Creating Versions 14-23
Restoring Versions 14-24
Using Version Browser 14-25
Using the Version Comparison Tool 14-26
Opening the Version Comparison Tool 14-28
Handling Concurrent Changes 14-29
Quiz 14-31
Summary 14-33
xiii
15 Enforcing Data Quality with ODI
Objectives 15-2
Data Quality 15-3
Why Data Quality? 15-4
When to Enforce Data Quality 15-5
Data Quality in Source Applications 15-6
Data Quality Control in the Integration Process 15-7
Data Quality in the Target Applications 15-8
Business Rules for Data Quality 15-9
Data Quality Business Rules 15-10
From Business Rules to Constraints 15-11
Enforcing Data Quality 15-12
Data Quality System: Overview 15-13
Static and Flow Controls: Differences 15-14
Data Quality Control: Properties 15-15
Synchronous Control 15-16
Enforcing Data Quality with ODI 15-17
What Is Data Quality Control? 15-18
What Is a Constraint? 15-19
What Can Be Checked? 15-20
How to Enforce Data Quality in an Interface 15-21
1. Enabling Static/Flow Control for an Interface 15-22
Setting Up Static/Flow Control 15-23
How to Enable Static/Flow Control 15-24
2. Setting the Options 15-25
How to Set the Options 15-26
3. Selecting Which Constraints to Enforce 15-27
How to Select Which Constraints to Enforce 15-28
How to Select Which Constraints to Check 15-29
Differences Between Control Types 15-30
4. Reviewing Erroneous Records 15-31
How to Review Erroneous Records 15-32
Quiz 15-33
Summary 15-35
16 Working with Changed Data Capture

Objectives 16-2
Why Changed Data Capture? 16-3
CDC Techniques 16-4
Changed Data Capture in ODI 16-5
Journalizing Components 16-6
CDC Infrastructure in ODI 16-7
Simple Versus Consistent Set Journalizing 16-8
Limitations of Simple CDC Journalizing: Example 16-9
xiv
Consistent CDC Journalizing 16-10
Consistent CDC: Infrastructure 16-11
Setting Up Journalizing 16-12
Setting CDC Parameters: Example 16-13
Arranging the Datastores in Order for Consistent Set Journalizing: Example 16-14
Adding a Subscriber: Example 16-15
Starting Journal: Example 16-16
Journalizing Status 16-17
Viewing Data/Changed Data: Example 16-18
Using Changed Data 16-19
Quiz 16-21
Summary 16-23
17 Administering ODI Resources: Advanced Topics

Objectives 17-2
Using Open Tools 17-3
What Are Open Tools? 17-4
Installing Open Tools 17-5
Note 17-6
Adding a New Open Tool 17-7
Removing an Open Tool 17-12
Using Open Tools in a Package: Example 17-13
Using Open Tools in a Procedure or in a KM: Example 17-14
Developing Your Own Open Tools 17-16
Developing Your Own Open Tools: Example 17-17
Developing Your Own Open Tools: Implementing the Class 17-18
Open Tools at Run Time 17-24
Reference Information 17-28
Setting Up ODI Security 17-29
Introduction to Security Manager 17-30
Overview of Security Concepts 17-32
Defining Security Policies 17-34
Creating Profiles 17-35
Creating Users 17-36
Assigning Profile to a User 17-37
Assigning an Authorization by Profile or User 17-38
Defining Password Policies 17-39
Setting User Parameters 17-40
Quiz 17-41
Summary 17-43
18 Using Web Services and Integration of Oracle Data Integrator with SOA
Objectives 18-2
Web Services in Action 18-3
Two Types of Web Services 18-4
xv
Using Data Services 18-5
What Are Data Services? 18-6
Generation of Data Services 18-7
Data Services in Action 18-8
Setting Up Data Services 18-9
1. Setting Up Data Sources in a Web Services Container: Example 18-11
2. Configuring the Topology 18-13
2. Configuring the Topology: Example 18-14
3. Setting Up the Model 18-17
3. Setting Up the Model: Example 18-19
4. Generating, Deploying, and Testing Data Services: Example 18-24
Testing Data Services: Example 18-27
Using Public Web Services 18-31
What Are Public Web Services? 18-32
Public Web Services in Action 18-33
Installing Public Web Services 18-34
Using Public Web Services 18-36
A Simple SOAP Request for the OdiInvoke Web Service: Example 18-37
Note 18-38
A Simple SOAP Request for the OdiInvoke Web Service: Example 18-39
A Simple SOAP Response for the OdiInvoke Web Service: Example 18-40
Invoking Web Services 18-41
OdiInvokeWebService Tool 18-42
Invoking a Web Service: Example 18-44
Processing a Web Service Response 18-49
Integration of ODI with SOA 18-52
ODI with SOA: Example 1 18-53
Oracle Data Integrator with SOA: Example 2 18-54
Example 2: Creating an ODI Error Hospital with BPEL Human Workflow 18-55
Quiz 18-61
Summary 18-63
Appendix A: Practices and Solutions
xvi
Using ODI Packages
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

Objectives
After completing this lesson, you should be able to:

• Use Oracle Data Integrator (ODI) packages to create a
complete workflow
• Create package steps of different types
• Execute a package
• Create package steps based on procedures, variables,
tools, and models
• Define complex workflows in ODI packages, involving
branches and loops
Objectives
In this lesson, you learn how to create packages that can run interfaces and other tools automatically.
By now, you should have a good understanding of the ODI interfaces. These are the most important
objects that will be used in a package.
In this lesson, you focus on using these interfaces to create a complete data integration job. An ODI
package contains all necessary steps to run a complete job. You should also learn how to create
several kinds of steps, and then run the package.
Oracle Data Integrator: Administration and Development 13 - 2

Packages: Overview

What Is a Package?
• A package is an organized sequence of steps that makes

up a workflow.
• Each step performs a small task and these tasks are
combined to make the package.
What Is a Package?
An ODI package defines a complete data integration job. A job is made up of many smaller steps.
Normally, you design these steps first, such as the ODI procedures and interfaces. Other steps are
created in the package.

How to Create a Package
1. Create and name a blank package.

2. Create the steps that make up the package:
– Drag interfaces from the Projects view onto the
Diagram tab.
– Insert ODI tools from the toolbox.
3. Arrange the steps in order:
– Define the first step.
– Define the success path.
– Set up error handling.
How to Create a Package

There are other steps that can be used to create a package, but in this lesson you focus on just two
types of steps: interfaces and tools.
The basic process for creating a package is as follows:
1. You make a blank package and name it.
2. Then, you load the package with the steps that it later executes. You can drag interfaces from
the Project view onto the package’s Diagram tab. This creates a link rather than a copy to the
interface. Thus, you can keep working on your interface and your changes update the package.
You can also add ODI tools into the package. Tools do useful things, such as sending email,
copying files, or waiting for the data to arrive.
3. Finally, you arrange the steps in a meaningful order. You begin by defining the first step to be
executed. Then, you tell ODI what to do next when the first step succeeds. You can also tell
ODI what to do if the first step fails. Thus, you can link complex sequences of operations with
error handling or error recovery.
These three steps are covered in greater detail in the following slides.

1. Creating and Naming a Package
1. Creating and Naming a Package

The first step is to create a package and give it a name.

How to Create and Name a Package
1. Navigate to the project and folder where you want to

create your package.
2. Right-click the Packages node and select Insert Package.
3. Enter the Name.
4. Enter the Description.
5. Click the Diagram tab.
How to Create and Name a Package

To create a blank package, perform the following:
1. Locate the project and folder in the Projects view where you want to create the package. A
package always belongs to a project, but you can use interfaces from other projects in the
package.
2. Right-click the Packages node and select Insert Package.
3. Provide a meaningful name to your package in the Name field.
4. Describe what the package does by entering details in the Description field. This description
appears in the package documentation and is useful when performing changes or maintenance.
5. To begin adding steps, click the Diagram tab.

Package Diagram
Toolbar
Diagram
Oracle Data
Integrator
Toolbox for tool step
ODI Interface step
tools (selected)
Interface step
(selected)
Package Diagram
This is how the Diagram tab of a package appears.
The Diagram represents the steps of the package as icons, with green links representing the success
path between them. The currently selected step is highlighted by a box around it. The first step is
marked with a green arrow.
At the bottom, you see the properties of the currently selected step. You can rename the step here.
Different properties are displayed for different types of steps.
In Toolbox at the left, all the tools that you can use are categorized. You can also access the tools
without categorization under All. Tools are covered in the next slide.
On the toolbar, there are buttons for sequencing packages. This is examined more closely in the next
slide. You can move or undock the Toolbox and the Properties pane to improve your workspace.

Package Diagram Toolbar
Hide/show Execute package

toolbox
Execute selected step
Print package
Hide/show Edit selected step
properties Page setup
Hide/show
success links
Hide/show
failure links
Select Rearrange
Next step on selection Shows errors
success in the diagram
Delete selection
Next step
Duplicate
on failure
selection
Package Diagram Toolbar

The following three tools are the most important. You use them frequently.
• “Next step on success”: You can draw a link from one step to the next with this. If the first
step executes successfully, ODI executes the next step in the chain. For example, the first step
might populate your ORDERS table, whereas the second can write the total number of orders to a
file.
• “Next step on failure”: This does the opposite. You can draw a link from one step to another
that should be run if the first fails. For example, you can create a failure link from the second
step above to an email step. If ODI is unable to write to the file, it sends an email informing you
about the problem.
Linking steps are covered in detail in the slides that follow.
• “Select”: You can use this tool to stop drawing links and to lay the diagram out more clearly.

Package Diagram Toolbar (continued)
• “Hide/show toolbox” and “Hide/show properties” give you more space to work in by hiding the
relevant panes.
• “Hide/show success links” and “Hide/show failure links” enable you to see certain aspects of
the diagram more clearly by hiding links.
• “Duplicate selection” and “Delete selection” are self-explanatory and can also be accessed by
right-clicking a step.
• “Rearrange selection” rearranges the diagram completely and automatically according to a
predetermined algorithm.
• “Execute selected step” is useful to see the result of just one step. “Execute package” runs all
steps starting from the first step. You can also use the Execute button in the lower-right corner
of the window.
• “Page setup” and “Print package” enable you to configure and print a comprehensive report of
all the steps in your package.
• Finally, “Show errors in the diagram” checks your diagram for errors, such as unlinked steps.

2. Adding Steps to the Package
2. Adding Steps to the Package

To make the package do something, you add steps on the Diagram tab.

Steps
• The two most common package steps are:

– Interface steps
– ODI tool steps
• Steps are created and sequenced in the package diagram.
Steps
The most useful package steps for most situations are either interfaces or ODI tools. Interfaces, as
you know by now, transfer data from one or more source datastores into a target datastore. ODI tools
perform a much wider variety of tasks, including sending email or waiting for data. There are other
steps, such as updating or testing variables, but they are not covered here.
Steps are created by dragging objects onto the package diagram, which is found on the Diagram tab.
They are then sequenced by creating links from one step to the next.

How to Create an Interface Step
1. Expand the project and folder

containing the interface.
Expand the Interfaces node.
2. Drag the interface onto the
package diagram.
– The new step appears.
3. Optionally, change the
step name in the
Properties panel.
4. Click the Apply button
to save.
How to Create an Interface Step

To create an interface step, perform the following:
1. Find the interface that you want to add. To do this, expand the project and folder nodes in the
Projects view. Then expand the Interfaces node.
2. Then, drag the interface onto the package diagram. You see an icon representing the interface
step in the package.
3. You may want to change the name of the interface step.
4. Finally, click the Apply button to save your package. You should do this frequently when
working on packages.
Notes
• Interfaces are reusable. When you create an interface, you can use it several times in the same
package. You can even copy it into several different packages simultaneously.
• You can use interfaces from other projects in your package. However, it is recommended that
you avoid doing this because it makes it difficult to keep your project organized.

What Is an ODI Tool?
• ODI tools are macros that provide useful functions to

handle files, send emails, use Web services, and so on.
• Tools can be used as steps in packages.
What Is an ODI Tool?

You now learn about the ODI tools. These are macros that you can use to perform file-handling
operations, send or receive emails, or connect to Web services. They are useful in packages to create
completely automated tasks.

How to Create an ODI Tool Step
1. In Toolbox, expand the group

containing the tool
that you want to add.
2. Click the tool.
3. Click the diagram.
– A step named after
the tool appears.
4. Change the step name
in the Properties panel.
5. Set the tool’s properties.
6. Click the Apply button
to save.
How to Create an ODI Tool Step

You can create a tool step as follows:
1. Find the tool that you want to add in Toolbox. Tools are arranged in different categories, such
as Internet, Event Detection, and so on. When you know the name of a tool, it may be quicker
to look directly in the “All” list, where all the tools are listed alphabetically.
2. Click the tool that you want to add. Each tool has a different icon.
3. Click in the diagram. The tool now appears as a step at that location. Tool steps are shown as
the corresponding icons.
4. (Optional) Change the step name in the Properties panel. This helps distinguish between, for
example, an email step that reports an error and an email step that sends the results of an
operation. Otherwise, they appear as OdiSendMail1 and OdiReadMail2.
5. Configure the properties of the tool in the Properties panel. For example, for an OdiSendMail
step, you must set the name of the mail server, the text to send, and so on.
6. Click the Apply button to save your changes.

Note
• Tool steps cannot be reused, but can be duplicated.

• To create a sequence of reusable tool commands, you
must create a procedure.
Note
Unlike interface steps, tool steps are simple commands that call the macros of ODI tools. You cannot
reuse a tool step, but you can duplicate it.
To create reusable ODI tool commands, you must create a procedure. You can place several tool
commands inside a single procedure. Then, you can reuse the same procedure in many different
packages. You can, of course, duplicate steps within the same package, if you want to perform the
same action multiple times. But, they are copies of each other and so are maintained separately.

3. Arranging Package Steps
in a Sequence
3. Arranging Package Steps in a Sequence

After creating the package and placing steps into it, you arrange the steps in a sequence.

Sequencing Steps
• The first step must be defined.

– Right-click and select First Step.
• After each step, the flow splits in two directions:
– Success: ok (return code 0)
– Failure: ko (return code not 0)
Sequencing Steps
Every package must have a first step. This is where the execution of a package always begins. To
define the first step, select a step, right-click and select First Step.
After that, the sequence of steps splits in two directions: If the step executes successfully, the
execution follows the green “ok” link. If the step fails, it follows the red “ko” link. Success is defined
by the step returning a code 0. Any return code other than 0 is treated as a failure.

A Simple Package
• This package executes two interfaces, and then archives

some files.
• If one of the three steps fails, an email is sent to the
administrator.
Step on success
First step
Step on
failure
A Simple Package
This is an example of a simple package. When it is executed, the first step “Load Country Table” is
executed. If it fails, the step “Mail the Admin” is carried out. You can see this by the red “ko” path,
which indicates the path to follow after a step fails. The package then terminates. If it succeeds,
however, the execution proceeds to “Load City Table.” This is shown by the green “ok” path. Again,
if it fails, ODI sends an email to the administrator. Lastly, if the first two steps succeed, the “Archive
Files” step is carried out. This also sends an email if it fails.
Note: A package can be designed to end at many different points depending on which steps succeed
or fail. But there must always be one starting step. In this example, the package may end after
archiving some files, or it may end after sending an email to the administrator. But it always starts by
loading the Country table.

How to Sequence Package Steps
1. Define the first step.

– Right-click and select First Step.
2. Define the success path.
a. Select the “Next step on success” tool.
b. Click the first step, the second step, and so on for the entire
success path.
3. Set up error handling.
a. Select the “Next step on failure” tool.
b. Click one step, then click the next step.
c. Repeat to define the failure path wherever needed.
4. To delete links or steps:
a. Use the Select tool to select a link or step.
b. Click the Delete selection button (or press the Delete key on
the keyboard).
5. Click the Apply button to save.
How to Sequence Package Steps

The basic process for arranging package steps into a sequence is as follows:
1. Define the first step. Right-click a step and select First Step.
2. Define the success path for your package. Connect the normal sequence of steps into a
continuous sequence. To do this, click the “Next step on success” tool, which resembles a green
arrow with the word “ok” above it. Now, click all the steps in the sequence from the first to the
last. Click the Select tool, which resembles a cursor, to stop sequencing.
3. You often add error-handling behavior. This works the same way. Click the red “ko” button
representing the “Next step on failure.” Now click a step and the corresponding error recovery
step. Of course, this step can itself fail. For example, the mail server that is used to send reports
can be down. In that case, you may want to have a failure path from the OdiSendMail step to
the OdiFileAppend step. Then, you can report the error into a log file.
4. To delete unwanted links on steps, select the step or link with the Select tool. Then, use the
“Delete selection” button on the toolbar, or right-click and select Delete. You can also use the
keyboard by pressing the Delete key.
5. Finally, click the Apply button to save your package.
Remember that to make links, you select the appropriate link tool, and then click the two steps—do
not try to click and drag here.
Note: All the steps in the diagram must either be on the success path or connected by a failure path to
it. If there are unlinked steps, the “Error” button appears highlighted. You can click the button to see
what the problem is.
Executing a Package
Executing a Package
Now that you have created a package, you want to execute it. This is similar to executing an
interface. In this case, however, each interface or tool step becomes a step in the session.

Executing a Package
1. Click the Execute

button.
2. Open Operator.
– The package is
executed as a session.
— Each package step is
a step in Operator.
— Tool steps appear
with a single task.
— Interface steps show
each command
as a separate task.
Executing a Package (continued)

To execute the package, click the Execute button in the package window. As with interfaces, you can
specify the context and the agent to run the package with.
When you receive a notification that the session has started, open Operator. The package represents a
session in Operator. Interface and tool steps are represented as steps. Interface steps are then
subdivided into tasks that carry out the individual data transfer operations. Tool steps, however, have
only one task.
Note: Be sure to test each interface individually before using it in a package. Likewise, you can test
individual steps in the package. To do this, right-click a step and select Execute Step. This is called
“unit testing.” In some cases, it may not be possible to test an individual step, for example, when it
requires a variable that is defined in the package. However, it is a good practice to test each step
individually, whenever possible.

Review of Package Steps
Types of Package Steps

The first section provides a quick summary of all the types of package steps available.

Basic Step Types
The following types of steps are straightforward to understand.

They carry out a clearly defined operation when executed.
Interface Reusable reference to an existing interface

Created by drag-and-drop
Oracle Data Integrator Tool Nonreusable call to an ODI tool
OS Command Nonreusable call to an OS command
Procedure Reusable reference to an existing procedure

Created by drag-and-drop
Basic Step Types

The first group of steps is quite simple conceptually. They each represent an action that can be
performed. When executed in a package, that action is carried out. These should look familiar to you
now.
• Interface steps execute an interface to move data from one place to another. You drag an
interface into the package to create a package step. This retains a reference to the original
interface.
• An ODI tool step calls an Oracle Data Integrator tool with some configured parameters. The
step is not reusable because it does not exist anywhere outside the package.
• An OS Command step is the same, but the command is sent directly to the operating system
instead of the ODI tool engine. OS Command steps are also not reusable.
• The last for this group, the procedure steps call the procedures you have defined. You can
configure the options for the procedure first. You can create this type of step by dragging and
dropping a procedure to make a reference to it.

Advanced Step Types
• Drag an object into the package to create the step.

• This creates references, not copies.
Model steps Reverse engineering, static control, or journalizing

operations
Sub-model steps Static control operations
Datastore steps Static control or journalizing operations
Declare, set, increment, refresh, or evaluate the

Variable steps
value of a variable. A variable can be used to
create single steps.
Advanced Step Types

There are more complex types of steps that work on elements of models or variables, and each has
several modes. All of the following types of steps are created by dragging an object into the package.
This creates a reference, or link, rather than a copy of the object. It means that modifying the original
object will affect the behavior of the package.
The first three types of steps perform operations on models, submodels, and datastores. A model is a
collection of related datastores. A submodel is an optional additional level of hierarchy. You can set
this using the Models view.
There are three subtypes of model steps. You can reverse engineer a model to update its structure
from a database, perform a static data check on all the datastores in it, or configure journalizing
behavior at run time.
Submodel steps have only one option: statically checking the data. Unlike static control in interfaces,
static control in packages can delete invalid rows that are detected.
Datastore steps allow both static control and journalizing configuration.
The other type of step in this category is variable steps. These come in four types to declare, set or
increment, refresh, and evaluate the value of a variable. Each variable can be used to create several
different steps within the same package. This will be covered in greater detail later.

Procedure Steps
Procedure Steps
You begin by looking at procedure steps. Unlike other types of steps, procedures are primarily
intended to be used in packages. You should, therefore, be familiar with how to do this.

How to Create a Procedure Step
1. Under a project, select the

procedure that you want to
work with.
2. Drag it into the package.
3. Set the step name.
There is only one type of
procedure step.
4. Override any options
on the Options tab.
How to Create a Procedure Step

To create a procedure step, perform the following:
1. Locate and select the procedure you want to use in the Projects view.
2. Drag it onto the package diagram.
3. You may want to change the name of the step to make its role in the package clearer. In
particular, if you have several different procedure steps referring to the same procedure, you
should distinguish between them. You set the name in the Properties pane, which appears at the
bottom of the window.
4. Click the Options tab. Here you can override the default values for options that have been
defined on the procedure.

Model, Submodel,
and Datastore Steps
Model, Submodel, and Datastore Steps

Now, you look at a group of related steps: model steps, submodel steps, and datastore steps.

How to Create Model, Submodel,
and Datastore Steps
1. Select the model,
submodel, or datastore
that you want to work
with in the Models
view.
2. Drag it into the
package.
3. Select the type
of operation to
perform.
4. Set the Options
for the chosen
operation.
How to Create Model, Submodel, and Datastore Steps

The process for the three types of steps is basically the same. Perform the following:
1. Select the model, submodel, or datastore that you want to use. They are all found in the Models
view.
3. Select the type of operation you want to perform on this object. The possibilities are reverse
engineering the model, configuring journalization options, and running a static data check. As
you saw earlier, the operations available depend on the type of object. Each of these operation
types has various options that can be set.
4. Click the Options tab of the Properties pane to set these options.

Models, Submodels, and Datastore Steps
• Reverse Engineering type:

– The reverse method
Datastore
Submodel
Model
defined for the model is used.
– If using customized reverse engineering,
you must set the RKM options
on the Options tab. Reverse engineer
• Check type: Journalize

– The static control strategy Check
(CKM) set for the model and
the datastores
– Options for the CKM are set on the Options tab.
– Select “Delete Errors from the Checked Tables” to
remove erroneous records.

Now, the different operations are covered in greater detail. Models permit all three types of
operations, and static data checks can be performed on all the three types. The only other
combination possible is setting journalization options for a datastore.
• The reverse engineering step type performs a reverse engineering procedure on the linked
model. This updates the metadata for the model in the repository to synchronize it with the
structure of the model in the database. There are two reverse engineering methods that can be
used: Standard and Customized. The method that has been defined directly on the model is the
one that will be used here. If the model is set to use a customized method, the RKM selected on
the model will be used. However, you should define the options for this RKM on the Options
tab in the package step.
• The Check type runs a static data check on your datastore, submodel, or model. The Check
Knowledge Module (CKM) is used. This is set on the Controls tab of the relevant object in the
Models view. To set the relevant options for the CKM, click the Options tab in the Properties
pane of the package step. For example, you may want to drop the existing ERRORS table when
performing an automated static check. In this case, click the Options tab and set the
DROP_ERROR_TABLE option to True. The “Delete Errors from the Checked Tables” check box
appears on the General tab for check operations. When deselected, errors found during the
check are copied to an ERRORS table, but not removed from the source datastores. However,
when selected, they are removed from these datastores.

Datastore
Submodel
Model
• Journalize step type:
– The journalizing
type and strategy
Reverse engineer
(JKM) set for the
model is used in the Journalize
step.
– The journalizing Check
mode
(simple/consistent
set) determines
which options are
available.
– JKM-specific
options are set on
the Options tab.
Models, Submodels, and Datastore Steps (continued)

The Journalize step type enables you to reconfigure journalization for Changed Data Capture for the
given datastore or model. This enables you to stop journalization, add subscribers, and so on.
You cannot change the journalization mode or the Journalizing Knowledge Module (JKM) used.
These options should be defined on the model itself.
The choice of either the Simple or Consistent Set mode determines which options are shown. In
particular, options for change consumption appear only when using the Consistent Set mode.
Lastly, use the Options tab to set options specific to the JKM, if there are any.
Note: Model steps, submodel steps, and datastore steps can have a major impact on your model when
executed. For example, reverse engineering at run time can create new datastores and add foreign
keys or columns. Modifying journalization options can cause changes to be discarded. Even running
a static check can delete invalid rows from your datastores. However, these capabilities can also be
very useful. For example, static checks can regularly clean your data, or journalizing steps can
reinitialize a Changed Data Capture environment periodically. However, it is recommended that you
be very careful when using them.

Variable Steps
Variable Steps
You now look at placing variables in packages. There are four different types of variable steps that
you can create this way.

How to Create a Variable Step
1. Select the variable in:

– The Projects view, or
– The Others view
2. Drag it into the
package.
3. Select the type of
operation to perform.
4. Set the options for the

operation to perform.
How to Create a Variable Step

Variable steps are created in a way very similar to procedure steps and model steps. Like model
steps, you must select from several different types of steps. Perform the following:
1. Select the variable from the Projects view if it is a project variable. Global variables are found
in the Others view.
3. On the General tab, select from one of the four available types of variable steps. These choices
are covered in the next slide.
4. Set the options specific to the particular operation. For example, for the Evaluate Variable type,
you set the value to compare against as well as the operator for comparison.

Variable Steps
• Declare Variable step type:

– It forces a variable to be taken into account.
– Use this step for variables used in transformations, or in the
topology.
• Set Variable step type:
– It assigns a value to a
variable or increments
the numeric value of
the variable.
Variable Steps
The four types of variable steps are as follows:
• The Declare Variable step is often placed at the start of a package. It explicitly defines the
variable that is used in an interface, procedure, or other package step. In general, variables are
implicitly declared when they are referred to in a package. However, in certain complex
situations, this cannot be guaranteed. Using this kind of step also improves readability, as you
can visually display all the variables that are used in the package.
The variable’s value may not be its default value when the step is executed. In this case, the
variable’s persistence type determines what happens. If it is “historized” or “last value,” the
Declare Variable step does not change the stored value. If it is “not persistent,” however, the
stored value is discarded. It is then replaced by the default value of the variable.
• The Set Variable step is straightforward and can be used to perform two different actions. You
can assign a specific value to a variable. For example, you can set an error counter to zero. You
can also increment the value of a variable. For example, you can count the number of times a
particular step is executed by putting a Set Variable step just before it with an increment of one.

Variable Steps
• Refresh Variable step type:

– It refreshes the value of the variable by executing the defined
SQL query.
• Evaluate Variable step type:
– It compares the variable value with a given value, according
to an operator.
– You can use another variable in the Value field.
Variable Steps (continued)

The other two variable steps are:
• The Refresh Variable step updates the variable value by executing the SQL expression of the
variable. It is important to realize that variables are not automatically updated.
For example, you have a variable with an expression that retrieves the number of rows in a
table. In your package, you add more rows to that table. Before accessing the value of the
variable again, you should include a Refresh Variable step to take into account the added rows.
Note that it is not illegal to refresh a variable with no SQL expression. In this case, nothing
happens.
• The Evaluate Variable step compares the value of the variable against a constant value or
another variable. This is used to create branches and loops later in this lesson. You can use any
mathematical comparison, such as equals, greater than, less than, and so on. You can also use
the SQL membership operator “IN.” The execution path of the package then splits according to
the result of the comparison. Using the “ok” and “ko” tools, you define the “true” and “false”
paths.

Controlling the Execution Path
Controlling the Execution Path

Having seen how to create the various types of package steps, you now use them to make parts of the
package repeat several times in a loop, and branch as a result of a step.

Controlling Execution
• Each step may have two possible next steps:

– Next step upon success
– Next step upon failure
• If no next step is specified, the package stops.
• Execution can branch:
– As the result of a step (success/failure)
– Because of an Evaluate Variable step
Controlling Execution
After each step in a package is executed, there are two possible choices for the next step:
• If the step is executed correctly, the “success” path is taken.
• If the step fails, the “failure” path is taken.
• If the next step does not exist, the execution of the package ends. For example, if a step fails
and there is no failure step, the package stops. Similarly, if a step succeeds but does not define
the next step on success, execution stops.
There are two distinct ways of making a branch:
• You can use the success and failure paths leading out of each step.
• You can use an Evaluate Variable step. This performs a comparison on a variable and takes one
of two different paths depending on the result of the comparison.
Some examples of these control structures are covered in the next slide.

Error Handling
• Interfaces fail when a fatal error occurs or when the

number of permitted errors is exceeded.
• Procedures and other steps fail when a fatal error occurs.
• Try to take the possible errors into account.
Simple error handling
Error Handling
As stated earlier, steps have a failure path that is taken if the step fails. Failure, in this context, has
several different causes.
• Interfaces fail when a fatal error occurs, which prevents them from executing completely or
when the source datastore cannot be found on the database. However, they also fail when the
predetermined maximum number of errors is exceeded during flow control.
• For example, you can specify a limit of 10 errors while processing an interface. If more than 10
errors are detected, the interface stops and is considered to have “failed.”
• Procedures and other steps fail when a fatal error occurs, which prevents them from continuing.
Note, for procedures, you can specify that errors for a particular step should be ignored. These
will not cause the procedure to fail as a whole.
You should take into account the possibility of errors for every step. It is possible for every type of
step to fail, so you should build error handling to respond to these situations.
A common solution is to link the failure path of every step to a common step that emails an
administrator. You may want to consider adding error handling for the case where the mail server is
down. For example, you can then write a file to a log file.

How to Create a Loop
• Loops need a counter variable.
3.
1. 2.
Package Loop 4.
1. Set the counter to an initial value.

2. Execute the step or steps to be repeated.
3. Increment the counter.
4. Evaluate the counter value and loop to step 2 if the goal
has been reached.
How to Create a Loop

Now that you have seen how to create a branch, you can use a branch to create a loop.
You need a variable to act as a “counter” for the loop. This variable usually starts at 0 or 1, and is
incremented until it reaches the desired number of repetitions.
The loop usually appears as shown in the slide and has the following stages:
1. Set the counter to an initial value. In this case, you set the COUNT variable to 0. This is done
using the “Set Variable” step in “Assign” mode.
2. Then, you execute a procedure referred to as “Looping Procedure” here. This can be more than
one step, including branches and even subloops.
3. Next, you increment the value of the counter to record the fact that you have executed the body
of the loop one more time. This is done by using the “Set Variable” step in “Increment” mode.
4. Lastly, you evaluate the value of the counter by using the “Evaluate Variable” step. In this case,
you test whether it is greater than nine. You link the “false” branch back to the start of the
looping procedure. The “true” branch is connected to the next step of the package.

The Advanced Tab
• The Advanced tab of each step enables you to specify how

the next step is determined.
• You can specify a number of automatic retries upon failure.
List of all possible

Where to go next if package steps.
the step completes Choose the one to be
successfully executed next if this
one succeeds.
How many times
the step should
be reattempted Time interval (in seconds)
between each attempt
Where to go next
if this step fails
List of all possible
Specifies if step package steps. Choose
execution report the one to be executed
is to be conserved next if this one fails.
in the log
The Advanced Tab

When you click any step in a package, you see an Advanced tab in the Properties pane. This tab
enables you to indicate how the next step in the package is chosen. Most of the options are equivalent
to drawing arrows in the diagram. In some cases, it may be more convenient or efficient to use this
tab instead.
Note, you can specify how many times a step is automatically retried if it fails. You can also do this
manually by setting up a loop connected to the failure path of the step. However, you might find the
automatic retrial method more convenient.
Further, you can specify a time interval to wait between each attempt. This is useful in the case of
attempting to connect to a server that may be down.

Quiz
Which of the following is not a way to make a branch?

a. Use the success and failure paths leading out of the step.
b. Use a Refresh Variable step.
c. Use an Evaluate Variable step.
d. None of the above
Answer: b
There are two distinct ways of making a branch:
• You can use the success and failure paths leading out of each step.
• You can use an Evaluate Variable step. This performs a comparison on a variable and takes one
of two different paths depending on the result of the comparison.
The Refresh Variable step is not used to create a branch.

Quiz
Variable steps are created by dragging an object into the

package. This creates a reference to the variable.
a. True
b. False
Answers: a
Explanation: Variable steps are created by dragging an object (variable) into the package. This
creates a reference, or link, rather than a copy of the object. It means that modifying the original
variable will affect the behavior of the package.

Summary
In this lesson, you should have learned how to:

• Use Oracle Data Integrator packages to create a complete
workflow
• Create package steps of different types
• Execute a package
• Create package steps based on procedures, variables,
tools, and models
• Define complex workflows in ODI packages, involving
branches and loops
Summary
In this lesson, you learned about:
• Adding procedures to packages to create procedure steps. These are straightforward as there is
only one type of procedure step.
• Adding models, submodels, or datastores to packages. Here, you discussed three choices:
reverse engineering steps, static data check steps, and steps for reconfiguring journalization. Be
careful with these because they can make major changes to your models.
• Variable steps. You learned that you can declare, set or increment, refresh, and evaluate a
variable by selecting the appropriate type.
• Using variable steps to create complex package workflows. You also learned that there are two
different ways of branching: using the success and failure paths of any step, or using the
“Evaluate Variable” step type. By combining the “Set Variable” step with the “Evaluate
Variable” step, you can repeat steps in a loop.

Managing ODI Scenarios and Versions

Objectives

• Describe the purpose of ODI scenario
• Describe the properties of ODI scenario
• Generate and regenerate ODI scenario
• Execute ODI scenarios from different sources
• Prepare ODI scenarios for deployment
• Perform automated scenario management
• Describe ODI version management techniques
• Use Version Browser for version management
• Use Version Comparison Tool to monitor modification
between versions
• Describe methods of handling concurrent changes
Objectives
This lesson focuses on releasing your Oracle Data Integrator (ODI) projects for production.
The goals for this lesson are:
• To understand how to generate deployable scenarios from your ODI objects
• To know how to generate, execute, and export scenarios
• To release generated scenarios so that they can be put into production

Scenarios
Scenarios
The first section of this lesson describes the scenarios and how they allow you to release your work.

What Is a Scenario?
• A scenario is a frozen copy of the generated code, ready

for execution in any context.
• It is the form in which all work in ODI should be released.
What Is a Scenario?
Remember that an interface, procedure, or package can be modified at any time. A scenario is
created by generating code from such an object. It thus becomes frozen, but can still be executed on a
number of different environments or contexts. Because a scenario is stable and ready to be run
immediately, it is the preferred form for releasing objects developed in ODI.

Properties of Scenarios
• Scenarios are “compiled” ODI objects.

– Easily deployed
– Not editable
• Scenarios have a unique name and version.
– You can keep successive versions of the same scenario.
• Scenarios are generated from:
– Packages
– Interfaces, procedures, and variables
— With the Common Format Designer option
• Scenarios can be started on different contexts.
– The same scenario can be used in development, test,
production, or on different sites.
Properties of Scenarios
Scenarios are created by generating code from ODI objects. This process is similar to compiling a
program from source code. They are easily deployed on any repository and executed with an agent
having access to the repositories.
Like compiled programs, scenarios cannot be modified. A scenario that works today will work
tomorrow as well.
Because scenarios represent snapshots in the development of an object, they have a name and a
version. You can retain several versions of the same scenario. In ODI, the different versions of a
scenario are always displayed attached to the original object.
The most common way to create scenarios is to generate them from packages. However, you can also
create scenarios from interfaces, procedures, or even variables using the Common Format Designer
option.
Scenarios are still context independent. You can generate a scenario to load data into a sales
database, then run the same scenario in different contexts to load the sales databases for different
sites.

Managing Scenarios
Managing Scenarios
Now, you see how to perform some practical tasks with scenarios.

Scenario-Related Tasks
Scenario-related tasks include:

• Generating and regenerating
• Exporting
• Executing scenarios
– From the graphical user interface (GUI)
– From the command line
– From within ODI using OdiStartScen
– Scheduling
– Metadata Navigator
Scenario-Related Tasks
In the remaining lesson, you assume that you are generating a scenario from a package, which is the
most common situation. You learn how to generate scenarios and regenerate them if they change.
After you generate a scenario, you can export it to a file. This enables you, for example, to transfer it
to a remote site.
Finally, you learn how to execute scenarios, which can be done directly from the ODI GUI, from an
operating system command line, or using the Sunopsis API.
It is also possible to start scenarios using an external scheduler, using ODI’s built-in scheduling
feature, or from Metadata Navigator’s Web interface. However, these methods are not covered in this
lesson.

Generating a Scenario
1. Right-click the package that

you want to compile.
2. Select Generate Scenario.
3. Enter the scenario name and
version, then click OK.
4. If the package uses
variables, define which
variables to use as
parameters.
– Use All, None, or a
selection of variables.
– (Selective use) Select the
parameter variables.
Generating a Scenario
To generate a scenario for a package, perform the following:
1. Right-click the package.
2. From the context menu, select Generate Scenario.
3. Select a name and version for the scenario. You can choose any version numbering scheme you
want. However, the combination of name and version must be unique for this package.
- If there are variables in the package, you must specify which ones to use as parameters.
When you launch the scenario using schedules or from Metadata Navigator, ODI asks you
for the value of these parameters.
- You can choose to use all variables as parameters or none of them.
- If you want to specify which variables to use, select Selective Use.
4. Click OK. ODI generates the scenario. Depending on the complexity of the package, the
scenario generation may take a while.

Regenerating a Scenario
1. Right-click the scenario that you

want to regenerate.
2. Select Regenerate.
3. Click OK.
Regenerating a Scenario
Although you can store several versions of a scenario, at times you may want to regenerate an
existing scenario. Regeneration replaces the selected version of the scenario with a freshly generated
copy.
To do this, right-click the scenario and select Regenerate. The parameters that you previously defined
are used again. ODI generates the scenario. Again, this may take a while for complex scenarios.

Generation Versus Regeneration
• Regeneration:
– Overwrites the scenario
– Reattaches any schedules for the current scenario
• Generation:
– Preserves a history of scenarios
– Requires schedules to be redefined
Generation Versus Regeneration

The difference between generating a new version of a scenario and regenerating a scenario is as
follows:
• Regeneration always overwrites an existing scenario using the same name and version number.
However, the advantage is that any schedules that are attached to the old version of the scenario
are retained.
• Generation, on the other hand, preserves a history of old versions of the scenario. However, you
must redefine any schedules because they remain attached to the old version.

Executing a Scenario from the GUI
1. Right-click the
scenario that you
want to run.
2. Select Execute.
3. Set the session
parameters:
– Context
– Agent
– Log level
4. Click OK.
Executing a Scenario from the GUI

After a scenario has been generated, it has to be executed from ODI. You can do this in Designer or
Operator, as follows:
1. Right-click the scenario
2. Select Execute.
3. The session parameter window is the same as for executing any other kind of object. You
specify the context to run the scenario in, the agent that will run it, and the log level. A higher
log level means more information is retained in the execution log after the scenario completes.
4. Click OK to launch the session.

Executing a Scenario from a Command Line
• The shell script startscen starts an agent to execute one

scenario.
• You should configure the snpparams script first.
• Syntax:
startscen <Name> <Version> <context_code>
[<log_level>]
“[-v=<trace_level>]”
“[<variable>=<value>]”
• For example:
startscen loadsales 001 GLOBAL
Executing a Scenario from a Command Line

You can also execute a scenario directly from an operating system command line.
ODI provides a shell script, startscen, to execute one scenario. The shell script is called
startscen.bat for Windows platforms and startscen.sh for UNIX platforms. This script
launches a special kind of agent that runs the scenario and shuts down.
To use this script, you must first configure the snpparams script. This script tells the agent how to
connect to the repository where the scenario is stored.
To call the startscen script, you must identify the scenario you want to run with its name and
version. You must also provide the code for the context you want to run it in. You can also specify a
log level for retaining session information in the log after the execution, and a trace level, to write the
execution detailed trace to the Console. This trace is useful for debugging or support purposes.
Lastly, you can also supply values to any parameters used by the scenario.
In this example, you use startscen to launch version 001 of the scenario “loadsales.” You run
the scenario in the GLOBAL context. In the example, the variables or the optional trace levels are not
specified.

Executing a Scenario from a Project
• The Sunopsis API has a tool, OdiStartScen, to execute

scenarios.
• This tool is useful for starting scenarios from package
steps or procedures.
• You can achieve modular development with scenarios and
this tool.
– Develop a package to perform a common task.
– Generate a scenario from this package.
– Call the scenario from other packages using
OdiStartScen.
Executing a Scenario from a Project

It is possible to launch a scenario from within an ODI project. You can do this with the Sunopsis
API, by using the OdiStartScen tool.
Thus, you can launch a scenario from a package step or from within a procedure. This enables you to
achieve modular development—that is, you can reuse the logic in different packages.
To do this, develop a package that performs a common task, such as emailing an administrator if
errors are found. Generate a scenario from this package. Then, when you want to perform the task in
other packages, call the generated scenario with the OdiStartScen tool.

Exporting a Scenario
1. Right-click the scenario.

2. Select Export.
3. Specify:
– The export directory
– The export file name
(without .xml)
– To export child objects
(always set to true)
4. Click OK.
Exporting a Scenario
To export a scenario, perform the following:
1. Right-click the scenario.
2. Select Export from the context menu. The Export window appears.
3. Specify the directory where you want to export the scenario. You can use the browse button to
select the directory by navigating to it. Specify the file name to export the scenario to. The .xml
extension is automatically added to it. Select the Child components export check box. Always
do so; otherwise, steps that make up the scenario are not exported.
4. Click OK to begin the export.

Preparing for Deployment
Preparing for Deployment

You will now look at how to prepare scenarios for deployment. This is the final stage before the
production team deploys the scenarios.

Preparing Scenarios for Deployment
1. Test your packages, interfaces, and so on.

– Unit and integration testing
2. Generate or regenerate scenarios.
3. Test the scenarios.
– From the GUI and/or from the command line
4. Export the scenarios.
– For delivery on remote sites
5. Set up schedules.
– This can be done by the production team.
6. (With Advanced Version Management) Record a stable
version of your work.
Preparing Scenarios for Deployment

The basic process for preparing a scenario for deployment into a production environment is as
follows:
1. Test your packages or interfaces from within ODI. You should test that the individual interfaces
or procedures work, then test that they work together in a package.
2. Generate your scenarios. If you fix or update scenarios, you are probably regenerating, than
generating.
3. Test the scenarios. You can either execute them directly from the GUI or test them from a script
file.
4. Now that the scenarios are ready, you may want to export them for deployment at the remote
production sites.
5. The production team may then want to set up schedules to run the scenarios automatically at
regular intervals.
6. Lastly, if you have the Advanced Version Management option, you should define and record a
stable version of your work in the repository.

Automating Scenario Management
• ODI provides API tools to automate scenario production:

– OdiGenerateAllScen
– OdiExportScen
– OdiImportScen
– OdiDeleteScen
– OdiStartScen
• You can create packages to automate scenario
deployment.
Automating Scenario Management

To speed up the whole process, you can use various tools provided by the Sunopsis API. You can
combine these tools into packages or procedures.
• OdiGenerateAllScen generates or regenerates all scenarios in your project that match a
certain criteria.
• OdiExportScen exports a scenario that you generated.
• OdiImportScen does the opposite. It loads an exported scenario from an Extensible Markup
Language (XML) file into the repository. The last two tools are useful to automatically move
scenarios between repositories.
• OdiDeleteScen removes a generated scenario from the repository.
• Lastly, OdiStartScen, runs a scenario.
By creating packages that use one or more of these tools, you can set up powerful automatic scenario
delivery systems.

Scheduling the ODI Scenario
agentscheduler.bat –NAME=localagent

After a scenario is successfully created, you can now execute the scenario directly, use the scenario
within a package, or schedule the scenario in ODI. To schedule the scenario, you need to:
1. Enable the ODI Agent in scheduling mode (execute the command: agentscheduler.bat
–NAME=localagent)
2. Insert Scheduling for your ODI scenario
3. Schedule the scenario by setting appropriate execution time for your scenario

Scheduling the ODI Scenario (continued)

After your scenario is scheduled, update scheduling using the ODI Agent in Topology Manager.
1. In Physical Architecture, right-click your agent and select Edit.
2. Click the Update Scheduling button, then click OK in the Information window.

Overview of ODI Version Management

What Is Version Management?
• The following ODI objects can be versioned: Projects,

Folders, Packages, Interfaces, Procedures, Sequences,
Variables, User Functions, Models, Model Folders, and
Scenarios.
• Creating a version generates the XML definition of an
object.
• Versions can be restored into any Work repository.
• ODI provides the tool (Version Browser) to display
versions.
• Versions of ODI objects can be compared using the
Version Comparison Tool.
What Is Version Management?

A version is a backup copy of an object. It is checked in at a given time and may be restored later.
Versions are saved in the Master repository. They are displayed on the Versions tab of the object
window. The following objects in ODI can be versioned: Projects, Folders, Packages, Interfaces,
Procedures, Sequences, Variables, User Functions, and Models.
Creating a version creates the XML definition of the object, and then stores it in compressed form in
the Master repository version tables. Versions can then be restored into any connected Work
repository. ODI provides a Version Browser to display versions. Versions of ODI objects can be
compared by using the Version Comparison Tool.

Working with Object Flags
When an object in Designer is created or modified, a flag is

displayed in the tree view:
• Object status is inserted
• Object status is updated
Working with Object Flags

When an object in Designer is created or modified, a flag is displayed in the tree view on the object
icon to indicate its status:
• Object status is inserted
• Object status is updated
When an object is inserted, updated, or deleted, its parent objects are recursively flagged as updated.
For example, when a step is inserted into a package, it is flagged as inserted, and the package,
folder(s) and project containing this step are flagged as updated. When an object version is created,
the flags on this object are reset.

Creating Versions
Creating Versions
To create a version:
1. Select the object for which you want to check in a version. Right-click and select Version >
Create.
2. A window appears. In this window, the Previous Versions (>>) button expands the list of
versions already checked in. A version number is automatically generated in the Version field.
Modify this version number if necessary.
3. Enter the details for this version in the Description field. Click OK.
Note: When editing the object, the Versions tab provides a list of versions checked in, with the
checkin date and the name of the user who performed the checkin operation.

Restoring Versions
Note: Restoring a version cannot be undone. It

permanently erases the current object and replaces it with
the selected version.
3 3
Restoring Versions
To restore a version:
1. Select the object for which you want to restore a version. Right-click and select Version >
Restore. A window appears with the list of existing versions.
2. Select the version you want to restore and then click OK.
3. Click OK to confirm the restore operation.

Using Version Browser
2 Export version as an XML file
1 Restore version
Using Version Browser

To browse versions, ODI has a tool, the Version Browser, which is used to display the versions
stored in the repository.
1. In the Designer menu, select File > Version Browser.
2. Use the object type and object name drop-down boxes to filter the objects for which you want
to display the list of versions.
3. From the Version Browser, you can restore, export to XML file, or delete existing versions.
Note: The Version Browser displays the versions that existed when you opened it. Click the Refresh
button to view all the new versions created since then.

Using the Version Comparison Tool
• The Version Comparison Tool is graphical tool is to view

and compare two different versions of an object.
• The comparison results are displayed in two panes, and
the differences between the two compared versions are
color coded.
• Comparison results are organized in a tree view.
• The Version Comparison Tool can generate and print a
PDF report listing the differences between two particular
versions of an object. Unchanged (default)
• The following color code is applied: Deleted
Added/New
Modified
Using the Version Comparison Tool

The Version Comparison Tool provides the following features:
Color-coded, side-by-side display of comparison results: The comparison results are displayed in two
panes, side-by-side, and the differences between the two compared versions are color coded.
Comparison results organized in tree view: The tree view of the comparison tool displays the
comparison results in a hierarchical list of node objects in which expanding and collapsing the nodes
is synchronized.
Report creation and printing in PDF format: The Version Comparison Tool is able to generate and
print a PDF report listing the differences between two particular versions of an object.
Supported objects: The Version Comparison Tool supports the following objects: Project, Folder,
Package, Scenario, Interface, Procedure, Knowledge Module, Sequence, User Function, Variable,
Model, Model folder, and Solution.
Difference viewer functionality: This Version Comparison Tool is a difference viewer and is
provided only for consultation purposes. Editing or merging object versions is not supported. If you
want to edit the object or merge the changes between two versions, you have to make the changes
manually directly in the concerned objects.

Using the Version Comparison Tool (continued)
The differences are color highlighted. The following color code is applied:
• White (default): Unchanged
• Red: Deleted
• Green: Added/new
• Yellow: Modified (the value inside this field has changed)
Note: If one object does not exist in one of the versions (for example, when it has been deleted), it is
represented as an empty object (with empty values).

Opening the Version Comparison Tool
1
2
3
Modified
entries
Opening the Version Comparison Tool

• By selecting the object in the Projects tree view. From the Projects tree view in Designer, select
the object whose versions you want to compare.
- Right-click the object.
- Select Version > Compare.
- The Compare with window appears.
- Select the version with which you want to compare the current version.
- Click OK. The Version Comparison Tool opens.
• Via the Versions tab of the object
- In Designer, open the object whose versions you want to compare.
- Go to the Versions tab. The Versions tab provides the list of all versions created for this
object. Select the two versions you want to compare by keeping the Ctrl key pressed.
- Right-click and select Compare. The Version Comparison Tool opens.
• Via the Version Browser:
- In Designer, select File > Version Browser.
- Select the two versions you want to compare.
- Right-click and select Compare. The Version Comparison Tool opens.
The comparison window shows the differences between two versions: on the left pane the newer
version and on the right pane the older version of your selected object.

Handling Concurrent Changes
ODI provides two methods for handling concurrent changes:

• Concurrent Editing Check:
– Set this to true to prevent you from erasing the work
performed by another user.
– If another user has made changes, the object cannot be
saved.
• Object Locking:
– Automatically activated. A pop-up window appears to ask if
you want to lock the object.
– Manual locking
Handling Concurrent Changes

Several users can work simultaneously in the same ODI project or model. They may all be connected
to the same repository and so the changes they perform are considered as concurrent.
ODI provides two methods for handling these concurrent changes: Concurrent Editing Check and
Object Locking. These two methods can be used simultaneously or separately.
• Concurrent Editing Check: A user parameter, check for concurrent editing, can be set to true
to prevent you from erasing the work performed by another user on the object you try to save. If
this parameter is set to true, when saving changes to any object, ODI checks whether other
changes have been made to the same object by another user since you opened it. If another user
has made changes, the object cannot be saved, and you must cancel your changes.
• Object Locking:
- Automatic Object Locking. This mechanism is automatically activated. When an object is
opened in a user interface, a pop-up window appears to ask if you want to lock the object.
As long as an object is locked, only the user owning the lock can modify the object, such
as editing or deleting. Other operations, such as executing, can be performed by other
users, but with a warning. An object locked by you appears with a yellow lock icon. An
object locked by another object appears with

Handling Concurrent Changes (continued)
a red lock icon. When the editing window is closed, a pop-up window appears to ask if you want to
unlock the object.
Note that these windows are configured by the Lock object when opening and Unlock object when
closing user parameters.
When closing ODI, a window appears asking to unlock or save objects that you have locked or kept
opened. You can keep objects locked even if you are not connected to ODI. This allows you to
prevent other users from editing them in the meanwhile.
You can also manually manage locks on objects. To manually lock an object:
1. Select the object in the tree view
2. Right-click and select Locks > Lock.

Quiz
Which of the following is not true about ODI scenario?

a. Scenarios are created by generating code from ODI
objects.
b. Scenarios cannot be modified.
c. You can retain several versions of the same scenario.
d. You can run the same scenario from only one context.
Answer: d
Scenarios are context independent. You can generate a scenario to load data into a sales database,
then run the same scenario in different contexts to load the sales databases for different sites.

Quiz
You can always undo restoring a version of an object.

a. True
b. False
Answers: b
Explanation: Restoring a version cannot be undone. It permanently erases the current object and
replaces it with the selected version.

Summary

• Describe the purpose of ODI scenario
• Describe the properties of ODI scenario
• Generate and regenerate ODI scenario
• Execute ODI scenario from different sources
• Prepare ODI scenarios for deployment
• Perform automated scenario management
• Describe ODI version management techniques
• Use Version Browser for version management
• Use Version Comparison Tool to monitor modification
between versions
• Describe methods of handling concurrent changes

Enforcing Data Quality
with ODI

Objectives

• Describe why and when to enforce data quality
• List the different types of data quality business rules that
Oracle Data Integrator (ODI) manages
• Describe Data Quality System within ODI
• Describe how data quality is managed in an interface
• Implement flow control during the execution of an interface
• Implement static control after the execution of an interface
• Enforce constraints and review erroneous records
Objectives
This lesson is an overview of monitoring and improving your data quality using ODI. In this lesson,
you learn why you should enforce data quality, and in which situations. The lesson will also cover
the different types of rules that can be enforced with ODI and how to enforce these rules using the
various kinds of data quality control.

Data Quality
Why and When?
Data Quality
In the first few slides of this lesson, you get an answer to why and when you should enforce data
quality.

Why Data Quality?
• Data quality is often neglected.

– Development cost
– Overconfidence in the actual data
• Monitoring data quality is critical.
– Low-quality data propagates and contaminates your
information system (IS).
• Data integration cannot be separated from data quality.
Why Data Quality?

Companies often neglect monitoring and enforcing the overall quality of data processed by the
integration processes. There are two reasons for this:
• The development of data-cleansing operations may be deemed too expensive.
• The IS teams often consider that the information residing in certain applications must closely
conform to the defined business rules. This leads to the belief that any risk of incorrect data is
minimal.
Data quality concerns become even more critical when new applications are integrated in the IS.
Indeed, data—even “bad” data—propagates right across the IS. It may then “contaminate” other
applications unless a systematic and reliable approach to data quality is implemented.

When to Enforce Data Quality
• The IS can be broken into three subsystems:

– Source application(s)
– Data integration process(es)
– Target application(s)
• Data quality should be managed in all the three
subsystems.
• ODI provides the solution for enforcing quality in all the
three subsystems.
When to Enforce Data Quality

Assume that every IS can be broken down into a number of subsystems, the largest elements being
the source application(s) and the process(es) that transform and integrate data, and the target
application(s).
In such a system, data quality can, and should, be managed in all of these subsystems. In the
following slides, you learn how to achieve this by combining a number of approaches and technical
solutions.

Data Quality in Source Applications
• Data is extracted from the source application.

– Sources can also be targets in some processes.
• Quality is usually enforced at the application level.
– GUI, Storage (DBMS constraints)
• Events may create inconsistent data due to:
– Maintenance cycles
– Deficient control mechanisms
• Data may be unsuitable for propagation. Data quality
control is, therefore, important before integration.
Data Quality in Source Applications

In the context of ODI, source applications are the applications from which data is extracted by an
integration process. In this respect, it is important to note that the source application of one
integration process may also be the target application for a different process.
Data quality in source applications is usually checked by the application itself. This may be carried
out by surface checks at the graphical user interface (GUI) level. Also, internal business rules may be
enforced on the data that the source application manages before storing it permanently. This is the
case for DBMS constraints.
However, it is possible that events, such as maintenance cycles may produce inconsistent data on
these source applications. The control mechanisms mentioned above can also be deficient.
Consequently, you should not implicitly assume that the quality of the data contained in the source
applications is suitable for propagation through the IS.
It is, therefore, highly advisable to run control processes on the data in source applications to verify
the integrity and quality of the stored information before allowing it to be injected into the
integration processes.

Data Quality Control in the Integration Process
• Prevents poor data from being propagated across the IS.

– It is retained in the sources.
• “Data Quality Firewall:”
– Valid data passes through the firewall.
– Invalid data is rejected and stored in error tables.
– Rejected data can be analyzed or fixed.
– Fixed data can be processed and/or recycled.
Data Quality Control in the Integration Process

Controlling data quality as part of the integration process ensures that potentially poor quality data is
not propagated across the IS. Instead, it is retained in the source applications.
The idea behind such an approach is to implement a sort of a “data quality firewall.” This is an
integral part of the data integration process, allowing only validated data to pass through.
Conversely, any invalid data is blocked and stored in specific error tables, for analysis later and/or
recycling.

Data Quality in the Target Applications
• The target applications can be strategic.

– Data warehouse and data hub
– Data quality in these target applications is critical.
• Controls may be bypassed depending on the:
– Type of target application
– Integration approach
• Checking data quality after integration is important.
Data Quality in the Target Applications

In many integration situations, the target application is a data warehouse that is used as the basis of
reports and analytics. Alternatively, it may be a data hub/operational datastore, both of which are
particularly important for decision-making purposes.
The quality of data contained in these systems is, therefore, critical to the organization—any
discrepancy can have consequences that go well beyond the application itself.
Furthermore, depending on the type of the target application, and the data integration approach
implemented, the integrity and quality controls inherent to the target application may be bypassed. It
is, therefore, equally important to verify the data managed by the target application subsequently.
This process is similar to performing data control and verification in source applications.

Business Rules for
Data Quality
Business Rules for Data Quality

You will now list the different types of rules that can be enforced with ODI.

Data Quality Business Rules
• Are defined by designers and business analysts

• Are stored in the Metadata Repository
• May be applied to application data
• Are defined in two ways:
– Automatically retrieved with other metadata
— Rules defined in the databases
— Obtained by reverse engineering
– Manually added by designers
— User-defined rules
Data Quality Business Rules

ODI enables application designers and business analysts to define business rules that target data
quality maintenance. These rules are stored in the centralized ODI Metadata Repository. They may
be applied to the application data to guarantee the overall integrity and consistency of information in
the organization.
ODI enables data quality rules to be created in two ways:
• By automatically reverse engineering metadata from source application data. ODI detects
existing data quality rules defined at the database level (for example, foreign keys).
• It also enables application designers to define additional, user-defined rules in the repository.

From Business Rules to Constraints
• Deduplication rules:
– Primary keys
– Alternate keys
– Unique indexes
• Reference rules:
– Simple: column A = column B
– Complex: column A = function (column B, column C)
• Validation rules:
– Mandatory columns
– Conditions
From Business Rules to Constraints

The business rules for data quality can include:
• Deduplication rules (unique keys). Such rules can be used to identify and isolate inconsistent
data sets as shown in the following examples:
- “The list of customers with the same email address”
- “The list of products having the same item code and item family code”
- These rules are defined in ODI as primary keys, alternate keys, or unique indexes.
• Simple and complex reference rules. Examples of these are:
- “The list of customers that are linked to nonexistent sales reps”
- “The set of orders that are linked to customers that are marked as Invalid”
- These rules are defined in ODI as references.
• Validation rules. These rules enforce consistency at the record level. For example:
- “The list of customers with an empty zip code”
- “The list of Web prospect responses with an invalid email address”
- These rules are defined in ODI as conditions or mandatory columns.


In the following slides, you learn to enforce the different types of rules with ODI.

Data Quality System: Overview
Source Target
ORDERS
Integration process SALES
ERRORS
Static control is
LINES started by:
ERRORS
Static control is - Interfaces after
started: Flow control integration
- Automatically is started. - Packages
(scheduled) - By interfaces during - Manually
- manually CORRECTIONS execution
File
Error Recycling is performed by

Interfaces.
Data Quality System: Overview

You use a simple example of a source and one integration process pushing data to a target, to fit
together the concepts that you just discussed and form the data quality system.
First, data quality is enforced on the sources by using static control. This static control enforces rules
on the sources and isolates erroneous data into error tables. This control is triggered either manually
or automatically. It can be scheduled regularly.
The integration process integrates data from the sources to the target. The integration unit of ODI—
the interface—enforces data quality on the data flow by using flow control before the data is
integrated in the target. The rules enforced are those of the target. The invalid data is isolated into an
error table and not inserted to the target.
Lastly, you can perform static control on the data in the target. This operation can be launched by
interfaces after the integration stage—post-integration static control—or similarly to the controls on
the source.
Finally, interfaces recycle the erroneous data from the previous session into the flow. They are
inserted back into the flow and are revalidated against the rules.
Depending on the strategy adopted, these invalid records may be targeted by an automatic data
cleansing interface, or simply be edited and forwarded to the application end users to indicate the
entries in the original application that require corrective measures.

Static and Flow Controls: Differences
• Static control (“static data check”):

– Checks whether data contained in a datastore respects its
constraints
– Requires a primary key on the datastore
• Flow control (“dynamic data check”):
– Enforces target datastore constraints on data in the flow
– Requires an update key defined in the interface
– Enables recycling of erroneous data back into the flow
Static and Flow Controls: Differences

After discussing the similarities between the static and flow controls, you now differentiate the two
types:
• Static control operates on data that sits in static datastores.
- Because data is left in the datastores, this check provides only information. Thus, you can
think of it as a “static data check.”
- You can perform this check at any time, or you can trigger a static control automatically
after integration.
- You need to define a primary key on the datastore that is being checked.
- This control is suitable for enforcing data quality on sources and targets.
• Flow control enforces validity constraints during the course of integration.
- It operates on a temporary table that has been constructed to closely resemble the target
datastore. Thus, it ensures that the data respects the constraints of the target datastore.
- It does not need a primary key, but still needs a defined way of uniquely referring to the
individual rows.
- It also enables recycling of any errors back into the next execution.
- This control is suitable for enforcing quality on the integration process.

Data Quality Control: Properties
Static and flow checks:

• Can be triggered:
– By an interface (FLOW and/or STATIC)
– By a package (STATIC)
– Manually (STATIC)
• Require a Check Knowledge Module (CKM)
• Are monitored through Operator
• Copy invalid rows into the ERRORS table
– Flow control then deletes them from flow.
– Static control leaves them in datastores.
– The ERRORS table can be viewed from Designer or
any SQL tool.
Properties of Data Quality Control

Now that you know the types of constraints that make up the static and flow controls, you can see the
other general properties.
• Static and flow controls can be performed by interfaces. However, they take place at different
times.
• Only static control can be launched as a step in package.
• Similarly, only static control can be manually launched by the user in ODI.
• For both sorts, you must have an appropriate CKM defined either in the interface or in the data
model.
• The static and flow controls can be monitored through Operator. Here, you can see the result of
each individual task. These tasks check each of the constraints you have defined. Thus, you can
see how many rows failed each check.
• Both controls reject erroneous rows into the ERRORS table. You can see this table through the
Designer window. Alternatively, you can query it directly by SQL from another tool.

Synchronous Control
• “Quick” check
• Available on the Control tab
of the Constraint window
– For keys, references, and
conditions
• Useful to check whether a
rule is correct
• Requires a SQL-enabled
system
Start synchronous
control
Number of erroneous
rows
Synchronous Control
A synchronous option is available to perform a “quick” check of one constraint. This option is
available on the Control tab of the windows for keys, references, and conditions.
By clicking the Check button, you can perform a synchronous check on the constraint, which tells
you the number of rows that violate the constraint. Use this button whenever possible to check
whether your rule is correct. For example, if this check returns half of your rows as duplicates, you
probably have made a mistake.
You should remember that synchronous checks query the data server directly to get the number of
invalid rows. This feature works only with SQL-based systems. For instance, you cannot perform a
synchronous check on a file-based datastore. Also, note that, unlike a normal static check, the result
of a synchronous check is not saved anywhere.

Enforcing Data Quality with ODI

What Is Data Quality Control?
• Data quality control is a system built into ODI for enforcing

integrity constraints on data being integrated (flow control)
or already stored in datastores (static control).
• Data is checked against a set of constraints defined in the
ODI repository.
• Problematic data may be reviewed and fixed in ODI, and
recycled through the interface.
What Is Data Quality Control?

Data quality control is a fundamental feature built into ODI for enforcing constraints on data. Quality
control can happen before data is integrated, when it is called flow control. It can also happen after
the integration, on the datastores, when it is called static control.
In either case, the data is checked against a set of constraints you have defined. These are similar to
database constraints: primary keys, foreign keys, and data conditions. If the data does not pass the
quality control, it is moved to a separate table. You can then review and fix the problems in ODI, and
recycle the data through the interface.

What Is a Constraint?
• A constraint is a statement that defines the rules enforced

on the data in datastores.
• A constraint ensures the validity of the data in a given
datastore and the integrity of the model as a whole.
• Constraints on the target datastore are used in interfaces
to check the validity of the data before integration in the
target.
What Is a Constraint?
A constraint in ODI is a general term for rules that are enforced on data in datastores. Although
constraints are often duplicated by rules defined in databases, they act independently. They serve to
ensure the validity of data in a given datastore, and thus the integrity of the model as a whole.
Constraints defined on a target datastore can be used by interfaces to the check the validity of data.
These checks are generally carried out before integration into the target. This prevents invalid data
from ever reaching the target datastore.

What Can Be Checked?
Types of constraints:
• Uniqueness (primary/alternate key–PK/AK)
– Is my customer number a unique value?
– Do I have duplicated values in my invoice number field?
• Referential Constraint (foreign key–FK)
– Does the customer number in my INVOICE table correspond
to the customer number in my CUSTOMER table?
• Conditions (Check–CK)
– The driver’s license candidate must be older than 16 yrs.
– The date of the last update must be more recent than the
creation date.
• Mandatory Fields (Not null)
– The name field must not be null.
What Can Be Checked?

As mentioned in an earlier slide, a constraint in ODI refers to any rule for data quality that can be
enforced. So, what are the types of constraints?
Uniqueness constraints are often the most critical. These correspond to primary keys or alternate keys
in databases. A uniqueness constraint ensures, for example, that an ID number given to a customer is
not shared by any other customer. Similarly, it can check that the same number is not given to two
different invoices.
Referential constraints enforce relationships between data items and correspond to foreign keys. For
example, the customer number column in your INVOICE table must correspond to a valid customer
number in your CUSTOMER table.
Conditions are sometimes known as check constraints. These are simple rules that can be checked
only by looking at that row. For example, a candidate for a driving license must be older than 16
years. This can be checked only by looking at the relevant column. You can also compare between
several columns in a row. For instance, the last update must be more recent than the creation date.
Mandatory fields correspond to “NOT NULL” columns in certain databases. This is the simplest kind
of check: a given column passes if it contains any value other than NULL.

How to Enforce Data Quality in an Interface
The general process is as follows:

1. Enable Static/Flow Control.
2. Set the options.
3. Select the constraints to
enforce:
– Table constraints
– Not null columns
4. Review the erroneous
records.
How to Enforce Data Quality in an Interface

Having seen what data quality controls can do, you will now learn how to implement it in an
interface. Note that there are other ways of implementing quality controls. For example, you can run
static controls manually. For now, however, static control is referred to in the context of an interface.
There are a few subtle differences between executing static controls in interfaces, and in executing
them manually, or in other ways.
For this overview, you begin by defining the general steps. Assume that you have created the
constraints that will be enforced.
1. First, you enable flow control or static control for the interface on the Flow tab.
2. Then, you set the options for the Control Knowledge Module you chose on the Controls tab.
3. Lastly, you tell ODI which constraints you would like to enforce for the given datastore. This is
at the bottom of the Controls tab.
4. After execution, you should review the records that have been moved into the ERRORS table.
You can do this in Operator or in the Models view in Designer.

1. Enabling Static/Flow Control
for an Interface
1. Enabling Static/Flow Control for an Interface

The first step in this general process is to enable static control or flow control for an interface.

Setting Up Static/Flow Control
Three IKM options control how data quality constraints are

enforced by an interface:
• FLOW_CONTROL triggers a dynamic data check during
execution.
• STATIC_CONTROL triggers a static data check after the
interface.
– The CKM selected on the interface performs both checks.
• RECYCLE_ERRORS forces invalid data detected in the
previous executions to be recycled into the interface flow.
Setting Up Static/Flow Control

The basic options for static and flow controls are controlled by the Integration Knowledge Module
(IKM) in the interface. Thus, you click Target on the Flow tab to set these.
• To enable a dynamic data check, you set the FLOW_CONTROL option to “Yes.” The IKM
calls the selected CKM before inserting data into the target. This option removes invalid data
from the data stream.
• For a static data check, you set the STATIC_CONTROL option to “Yes.” Now the IKM calls
the selected CKM after inserting data into the target. This option does not remove invalid data
from the target datastore. It reports it in the ERRORS table.
• Finally, you can the set the RECYCLE_ERRORS option. This causes the bad data that was
detected on previous executions to be reused. Imagine that you run your interface with 100
rows of source data, and 10 errors are detected. These are moved to the ERRORS table. You run
the same interface again with the same data. The error rows are added to the input stream. This
means that there are 110 rows of input data now. If nothing has changed, there will be 20 bad
rows in the ERRORS table this time.

How to Enable Static/Flow Control
1. Click the Flow tab.

2. Select the target datastore.
– The IKM Properties
panel appears.
3. Set the FLOW_CONTROL
and/or STATIC_CONTROL
IKM options to “Yes.”
4. Set RECYCLE_ERRORS to
“Yes,” if you want to recycle
errors from previous runs.
How to Enable Static/Flow Control

The steps to enable static control or flow control for an interface are as follows:
1. Click the Flow tab of the interface.
2. Select the target. You now see the Properties panel for the IKM.
3. Change the values for either FLOW_CONTROL or STATIC_CONTROL to “Yes.” If there is
no option for FLOW_CONTROL, it is because your Staging Area is not on your target. Flow
control is not possible in that case.
4. You can also set RECYCLE_ERRORS to “Yes.” This will cause rows already in the ERRORS
table to be reused. If you never empty the ERRORS table, you will possibly be recycling the
same error lines many times.

2. Setting the Options
2. Setting the Options

After enabling the quality control, the next step is to set its options to define how it behaves.

How to Set the Options
1. Click the interface’s

Controls tab.
2. Select a CKM.
3. Set the CKM options.
4. Set the maximum
number of errors
allowed.
– Leave it blank to
allow an unlimited
number of errors.
– To specify a
percentage of the
total number of
integrated records,
select the % check
box.
How to Set the Options

To configure the options for your data quality checks, perform the following:
1. Click the Controls tab—this is used to configure all static or flow control checks that you
perform with this interface. You may have noticed that the workflow for setting up an
interface starts at the Definition tab on the left, and then moves slowly to the right across
Diagram, Flow, and onto Controls.
2. Select the CKM from the drop-down list; for example, for an Oracle server, select Oracle.
Remember to import the Knowledge Modules into your project before using them.
3. Set specific options in the Option list. These generally change minor characteristics of the
check. For example, if you may want the ERRORS table to be deleted altogether, set
DROP_ERROR_TABLE to “Yes.”
4. In the middle of this screen is the description of the CKM you have chosen. Click the name of
an option to see a description of that option.
5. Normally, when rows with errors are detected, they are moved into the ERRORS table, and the
processing continues. However, you can define a maximum number or proportion of errors.
Suppose that you have an interface that normally detects less than 10 errors. If it picked up
more than, say, 50 errors, something must be very wrong with the input data. Therefore, you
can set a limit to know immediately if there is a problem. You can also express this limit as a
percentage, by selecting the % check box. Note that a row can generate several errors, if it
violates several constraints.
At the bottom is the list of constraints to check. These will be covered in greater detail in the
following slides.

3. Selecting Which Constraints
to Enforce
3. Selecting Which Constraints to Enforce

The third step in setting up a quality control process is to select which constraints to enforce. You
probably noticed this area on the Controls tab. You will now use it to select the constraints that will
be enforced with flow control. Then, you will see how to select which constraints to check with static
control.

How to Select Which Constraints to Enforce
For flow control:

• For most constraints:
1. Click the Controls tab.
2. For each constraint you want
to enforce, select Yes.
• For Not Null constraints:
1. Click the Diagram tab.
2. Select the target datastore.
column that you want to check for
nulls.
3. In the column Properties panel,
select Not Null.
How to Select Which Constraints to Enforce

How you select which constraints to enforce depends on the type of constraint and on the type of
quality control. First, you select the constraints to be enforced during flow control. For most
constraints, you perform the following:
2. Select each constraint that you want to enforce, and select “Yes.”
Mandatory, or not null constraints, however, must be specified for each column of the target
datastore.
1. Click the Diagram tab, instead of the Controls tab.
2. Find the column in the target datastore that you want to make mandatory.
3. Now, select the Not Null check box.
Note: You can specify that a value is mandatory even if the database table accepts nulls.

How to Select Which Constraints to Check
For static Control:

• Find the relevant datastore
in the Models view
• For most constraints:
1. Double-click the constraint
under the Constraints node.
3. Select the Static check box.
• For Not Null constraints:
1. Double-click the column
under the Columns tree.
3. Select the Mandatory check
box.
How to Select Which Constraints to Check

You now select the constraints that are to be enforced during static control. To do so, perform the
following:
1. Locate the relevant datastore in the Models view.
2. For constraints, such as references and primary keys, double-click the constraint.
3. Click the Controls tab, and select the Static check box.
Mandatory, or not null constraints, however, must be specified for each column of the datastore.
1. To do this, double-click the name of the column under the Columns node.
2. Now, click the Controls tab.
3. Select the Mandatory check box.

Differences Between Control Types
Static control Flow control
Launched via Model Interface Interface
CKM Defined on Model Interface Interface
Options defined Model Interface Interface

on
Constraints Model Interface Interface

defined on
Invalid rows Possible Never Always

deleted
Differences Between Control Types

You have seen some of the differences in the way static control and flow control work. This is
because static control is a property of the model. Normally, you set your constraints on the model
first. Then, when you create your interface, these constraints are automatically copied.
This lesson focuses on data quality control in an interface. Therefore, you have not seen how to set it
up at the model level. However, you should know the differences, which are quite subtle.
The CKM that is used for a static check depends on how the static check is launched. For static
control launched at the end of an interface, it behaves like flow control: you choose the CKM on the
Controls tab of the interface. This is true also for defining other control options. If the static check is
launched manually, or by a package, the CKM and options defined on the model are used instead.
However, to select the constraints that are checked, you must define them on the model for static
control. The constraints that are selected in the interface window apply only to flow control.
There is also a difference in whether invalid rows are deleted from the source table. For flow control,
they are always deleted. For static control launched by an interface, they are never deleted. When
you launch static control manually or by a package, however, you have a choice.

4. Reviewing Erroneous Records
4. Reviewing Erroneous Records

After setting up the system of quality control, you now execute the interface to perform these checks.
The last step in the quality control process is to review erroneous records. These are the records that
were detected by the CKM you chose. They have been isolated in an ERRORS table.

How to Review Erroneous Records
First, execute your interface.

To see the number of records:
1. Click the Execution tab.
2. Find the most recent execution:
The number of errors
encountered by the interface is
displayed.
To see which records were rejected:
1. Select the target datastore
in the Models view.
2. Right-click and select Control >
Errors.
3. Review the erroneous rows.
How to Review Erroneous Records

To view the erroneous records, execute your interface, and then perform the following:
1. Click the Execution tab on the interface. Note that there are two subtabs. When you run your
interface from Designer, you will find it on the Direct Executions tab.
2. Locate the most recent execution. You may need to click the Refresh button to see it. You can
see the most recent execution by clicking the Start column. The number of errors is displayed
under the No. of Errors column. You can also use Operator to see this.
To see the records that were rejected, you must exit the interface window and then:
1. Select the target datastore from the Models view
2. Right-click and select Control > Errors
3. Review the erroneous rows
Note: It is recommended that you consider using the data quality tools and features in ODI. When
you create interfaces, consider enforcing constraints. These do not have to exist in the database.
Suppose that you regularly transfer detailed sales into a data warehouse. You would not expect to
have any NULLs in the source data. However, you have not defined in the data warehouse that the
sales cannot be NULL. You may still want to use ODI to enforce this rule. Thus, if some NULL
figures appear in the source data, you will know about it immediately.

Quiz
You can specify that a value is mandatory even if the database

table accepts nulls.
a. True
b. False
Answer: a
Explanation: Even a database table accepts nulls, you can specify a value as mandatory for the
purpose of ODI transformation.

Quiz
Business rules for the data quality can include:

a. Duplication rules (unique keys)
b. Simple and complex reference rules that are defined in
ODI as references
c. Validation rules that enforce consistency at the record level
d. All of the above
Answer: d
Explanation: All of the above are examples of business rules for data quality.

Summary

• Describe why and when to enforce data quality
• List the different types of data quality business rules that
ODI manages
• Describe Data Quality System within ODI
• Describe how data quality is managed in an interface
• Implement flow control during the execution of an interface
• Implement static control after the execution of an interface
• Enforce constraints and review erroneous records

Working with Changed Data Capture

Objectives

• Describe the purpose of Changed Data Capture (CDC)
with Oracle Data Integrator (ODI)
• Describe what types of CDC implementations are possible
with ODI
• Use CDC implementation techniques
• Perform journalizing
• Use the results of CDC
Objectives
This lesson is an overview of monitoring and improving your data quality using ODI. In this lesson,
you learn why you should enforce data quality, and in which situations. The lesson will also cover
the different types of rules that can be enforced with ODI and how to enforce these rules using the
various kinds of data quality control.

Why Changed Data Capture?
• CDC:
– Allow applications to process changed data only
– Load will only process changes since the last load
– Reduce the volume of data to be processed
• CDC is extremely useful for near real-time
implementations, synchronization, and Master Data
Management.
Why Changed Data Capture?

The purpose of CDC is to allow applications to process changed data only. CDC allows ODI to track
changes in source data caused by other applications. When running integration interfaces, ODI can
avoid processing unchanged data in the flow. Loads will only process changes since the last load.
The volume of data to be processed is dramatically reduced. CDC is extremely useful for near real-
time implementations, synchronization, and Master Data Management (providing processes for
collecting, aggregating, and distributing nontransactional data throughout an organization).

CDC Techniques
Multiple techniques are available for CDC:

• Trigger based: ODI will create and maintain triggers to
keep track of the changes.
• Logs based: ODI retrieves changes from the database logs
(Oracle, AS/400).
• Time stamp based: Processes written with ODI can filter
the data comparing the time stamp value with the last load
time (cannot process deletes)
• Sequence number: If the records are numbered in
sequence, ODI can filter the data based on the last value
loaded (cannot process updates and deletes).
CDC Techniques
There are number of CDC techniques:
• Trigger based: ODI will create and maintain triggers to keep track of the changes.
• Logs based: For some technologies, ODI can retrieve changes from the database logs (Oracle,
AS/400).
• Time stamp based: If the data is time stamped, processes written with ODI can filter the data
comparing the time stamp value with the last load time. This approach is limited because it
cannot process deletes. The data model must have been designed properly.
• Sequence number: If the records are numbered in sequence, ODI can filter the data based on
the last value loaded. This approach is limited because it cannot process updates and deletes.
The data model must have been designed properly.

Changed Data Capture in ODI
• CDC in ODI is implemented through a family of KMs: the

Journalization KMs.
• These KMs are chosen and set in the model.
• The developer can choose from the interface whether to
use the full data set or only the changed data.
Changed Data Capture in ODI

CDC is performed by journalizing models. Journalizing a model consists of setting up the
infrastructure to capture the changes (inserts, updates, and deletes) made to the records of this
model’s datastores.
CDC in ODI is implemented through a family of KMs–the Journalizing KMs. These KMs are chosen
and set in the model. When the journals are in place, the developer can choose from the interface
whether to use the full data set or only the changed data.

Journalizing Components
• Journals: Contain references to the changed records

• Capture processes: Captures the changes in the source
datastores either by creating triggers on the data tables, or
by using database-specific programs to retrieve log data
from data server log files
• Subscribers (applications, integration processes, and so
on): That use the changes tracked on a datastore or on a
consistent set
Journalizing Components
The journalizing components are:
• Journals: Where changes are recorded. Journals only contain references to the changed records
along with the type of changes (insert/update, delete).
• Capture processes: Journalizing captures the changes in the source datastores either by
creating triggers on the data tables or by using database-specific programs to retrieve log data
from data server log files. See the documentation on Journalizing Knowledge Modules (JKMs)
for more information about the capture processes used.
• Subscribers: CDC uses a publish/subscribe model. Subscribers are entities (applications,
integration processes, and so on) that use the changes tracked on a datastore or on a consistent
set. They subscribe to a model’s CDC to have the changes tracked for them. Changes are
captured only if there is at least one subscriber to the changes. When all the subscribers have
consumed the captured changes, these changes are discarded from the journals.

CDC Infrastructure in ODI
• Journal table: Created by the KM and loaded by specific

steps implemented by the KM. This table has the following
structure:
– Primary key of the table being checked for changes
– Time stamp to keep the change date
– A flag to allow for a logical “lock” of the records
• Views are created to join this table with the actual data.
CDC Infrastructure in ODI

CDC in ODI relies on a Journal table. This table is created by the KM and loaded by specific steps
implemented by the KM. This table has a very simple structure:
• Primary key of the table being checked for changes
• Time stamp to keep the change date
• A flag to allow for a logical “lock” of the records
A series of views is created to join this table with the actual data. When other KMs will need to select
data, they will use the views instead of the tables.

Simple Versus Consistent Set Journalizing
• Simple Journalizing enables you to journalize one or more

datastores. Each journalized datastore is treated
separately when capturing the changes (no consistency).
• Consistent set journalizing provides the guarantee of the
consistency of the captured changes (Consistency
Window).
Simple Versus Consistent Set Journalizing

Simple Journalizing enables you to journalize one or more datastores. Each journalized datastore is
treated separately when capturing the changes. Consistent set journalizing provides the guarantee of
the consistency of the captured changes in linked datastores. The set of available changes for which
consistency is guaranteed is called the Consistency Window.

Limitations of Simple CDC Journalizing: Example
• As changed data gets processed, more changes occur in

the source environment–data transferred to the target
environment may have missing references.
• Example: Process changes for orders and order lines
1. Load all the new orders in the target (11,000 to 25,000).
2. While these are being loaded, two new orders come in:
25,001, 25,002.
3. Then load the order lines: By default, all the order lines are
loaded, including order lines for orders 25,001 and 25,002.
4. The order lines for 25,001 and 25,002 are rejected by the
target database (invalid foreign keys).
Limitations of Simple CDC Journalizing: Example

One issue with CDC is that as changed data gets processed, more changes occur in the source
environment. As such, data transferred to the target environment may have missing references.
Example: Process changes for orders and order lines
1. Load all the new orders in the target (11,000 to 25,000).
2. While you load these, two new orders come in: 25,001 and 25,002. The last two orders are not
processed as part of this load, they will be processed with the next load.
3. Then load the order lines: By default, all order lines are loaded–including order lines for orders
25,001 and 25,002.
4. The order lines for 25,001 and 25,002 are rejected by the target database (invalid foreign keys).

Consistent CDC Journalizing
The mechanisms put in place by Consistent CDC will solve the

issues faced with simple CDC.
• Lock children records before processing the parent
records.
• When new parent records and children records come in,
both parent and children records are ignored.
Consistent CDC Journalizing

Consistent set journalizing provides the guarantee that when you have an ORDER_LINE change
captured, the associated ORDER change has been also captured, and vice-versa. Changes in
Consistency Window should be processed in the correct sequence (ORDER followed by
ORDER_LINE) by designing and sequencing integration interfaces into packages.
Although consistent set journalizing is more powerful, it is also more difficult to set up. It should be
used when referential integrity constraints need to be ensured when capturing the data changes. For
performance reasons, consistent set journalizing is also recommended when a large number of
subscribers are required.
Note: It is not possible to journalize a model (or datastores within a model) using both consistent set
and simple journalizing.

Consistent CDC: Infrastructure
• Processing Consistent Set CDC consists of the next four

phases:
– Extend Window: Compute the consistent parent/child sets
and assign a sequence number to these sets.
– Lock Subscriber: For the application processing the changes,
record the boundaries of the set of records to be processed.
– After processing the changes, unlock the subscriber.
– Purge the journal: Remove from the journal all the records
that have been processed by all the subscribers.
• These steps can either be implemented in the KMs or
done separately, as part of the Workflow management.
Consistent CDC: Infrastructure

Processing Consistent Set CDC consists of the next four phases:
• Extend Window: Compute the consistent parent/child sets and assign a sequence number to
these sets.
• Lock Subscriber: For the application processing the changes, record the boundaries of the set
of records to be processed (between sequence number xxx and sequence number yyy). Note that
changes keep happening in the source environment. Other subscribers can be extending the
window while you are processing the data.
• After processing the changes, unlock the subscriber (record the value of the last sequence
number processed).
• Purge the journal: Remove from the journal all the records that have been processed by all
subscribers.
Note: All these steps can either be implemented in the Knowledge Modules or done separately, as
part of the Workflow management.

Setting Up Journalizing
1. Set the CDC parameters.

2. Add the datastores to the CDC.
3. For consistent set journalizing, arrange the datastores in
order.
4. Add subscribers.
5. Start the journals.
Setting Up Journalizing
This is the basic process for setting up CDC on an ODI data model. Each of these steps is described
in more detail below.
1. Set the CDC parameters.
2. Add the datastores to the CDC.
3. For consistent set journalizing, arrange the datastores in order.
4. Add subscribers.
5. Start the journals.

Setting CDC Parameters: Example
Set journalizing
mode.
3
1
4
Set Journalizing
KM.
Setting CDC parameters

This includes selecting or changing the journalizing mode and JKM used for the model. If the model
is already being journalized, it is recommended that you stop journalizing with the existing
configuration before modifying the data model journalizing parameters.
1. Import correct JKM for your model.
2. Edit the data model you want to journalize, and then click the Journalizing tab. Select the
journalizing mode you want to set up: Consistent Set or Simple.
3. Select the Journalizing KM you want to use for this model. Only Knowledge Modules suitable
for the data model’s technology and journalizing mode, and that have been previously imported
into at least one of your projects appear in the list.
4. Set the Options for this KM. Refer to the Knowledge Module’s description for more
information about the options.
5. Click OK to save the changes.

Arranging the Datastores in Order for Consistent
Set Journalizing: Example
Arranging the Datastores in Order for Consistent Set Journalizing: Example

You only need to arrange the datastores in order when using consistent set journalizing. You should
arrange the datastores in the consistent set into an order which preserves referential integrity when
using their changed data. For example, if an ORDER table has references imported from an
ORDER_LINE datastore (ORDER_LINE has a foreign key constraint that references ORDER), and
both are added to the CDC, the ORDER datastore should come before ORDER_LINE. If the
PRODUCT datastore has references imported from both ORDER and ORDER_LINE (both ORDER
and ORDER_LINE have foreign key constraints to the ORDER table), its order should be lower still.
To arrange the datastores in order (consistent set journalizing only):
1. Edit the data model you want to journalize, then click the Journalized Tables tab.
2. If the datastores are not currently in any particular order, click the Reorganize button. This
feature suggests an order for the journalized datastores based on the data models’ foreign keys.
Note that this automatic reorganization is not error-free, so you should review the suggested
order afterwards.
3. Select a datastore from the list, then use the Up and Down arrows to move it within the list.
Repeat this step until the datastores are ordered correctly, then click OK to save the changes.
Changes to the order of datastores are taken into account the next time the journals are started.
Note: If existing scenarios consume changes from this CDC set, you should regenerate them to take
into account the new organization of the CDC set.

Adding a Subscriber: Example
1
2
Adding a Subscriber: Example

For all the following steps, right-click a table to process just that table, or right-click the model to
process all the tables of the model:
1. Add the table to the CDC infrastructure: Right-click a table and select Changed Data Capture >
Add to CDC. For consistent CDC, arrange the datastores in the appropriate order (parent/child
relationship). In the model definition, click the Journalized Tables tab and click the Reorganize
button.
2. Add the subscriber (The default subscriber is SUNOPSIS). Right-click a table and select
Changed Data Capture > Subscriber.
3. Enter the subscriber name. Click the Add button, then click OK.
To start the journals: Right-click a table and select Changed Data Capture > Start Journal.

Starting Journal: Example
Starting Journal: Example

Starting the journals creates the CDC infrastructure if it does not exist yet. It also validates the
addition, removal, and order changes for journalized datastores.
To start the journals:
1. Select the data model or datastore you want to journalize. Right-click and select Changed Data
Capture > Start Journal if you want to start the journals (or Changed Data Capture > Drop
Journal if you want to stop them).
2. Select the subscriber, and then click OK. Click OK to start the session.
A session starts or drops the journals. You can track this session from the Operator.
Note: Stopping the journals deletes the entire the journalizing infrastructure and all captured
changes are lost. Restarting a journal does not remove or alter any changed data that has
already been captured.

Journalizing Status
• OK: Journalizing is active for this datastore in the current

context, and the infrastructure is operational.
• No Infrastructure: Journalizing is marked as active, but no
appropriate journalizing infrastructure was detected in the
current context. Journals should be started.
• Remnants: Journalizing is marked as inactive in the model,
but remnants of the journalizing infrastructure such as the
journalizing table have been detected.
Journalizing Status
Datastores in models or interfaces have an icon marker indicating their journalizing status in
Designer’s current context:
• OK: Journalizing is active for this datastore in the current context, and the infrastructure is
operational for this datastore.
• No Infrastructure: Journalizing is marked as active in the model, but no appropriate
journalizing infrastructure was detected in the current context. Journals should be started. This
state may occur if the journalizing mode implemented in the infrastructure does not match the
one declared for the model.
• Remnants: Journalizing is marked as inactive in the model, but remnants of the journalizing
infrastructure such as the journalizing table have been detected for this datastore in the context.
This state may occur if the journals were not stopped and the table has been removed from
CDC.

Viewing Data/Changed Data: Example
• In the model, right-click the table name and select Data to

view the data or Changed Data Capture > Journal Data to
view the changes.
• From the interface, click the caption of the journalized
source table and select or deselect Journalized data only
to view only the changes or all the data.
Viewing Data/Changed Data: Example

Data and changed data can be viewed from the model and from the interfaces.
In the model, right-click the table name and select Data to view the data or Changed Data Capture >
Journal Data to view the changes.
The changed data displays three extra columns for the changes details:
• JRN_FLAG: Flag indicating the type of change. It takes the value I for an inserted/updated
record and D for a deleted record.
• JRN_SUBSCRIBER: Name of the subscriber
• JRN_DATE: Time stamp of the change
Journalized data is mostly used within integration processes. Changed data can be used as the
source of integration interfaces. The way it is used depends on the journalizing mode.
Note: From the interface, click the caption of the journalized source table and select or deselect
Journalized data only to view only the changes or all the data.

Using Changed Data
• Journalizing filter in interface

• KM option
SYNC_JRN_DELETE
Setting the Journalizing

filter option
Setting the Journalizing

filter option
Using Changed Data

Using changed data from simple journalizing consists of designing interfaces using journalized
datastores as sources.
• Journalizing filter option: When a journalized datastore is inserted into an interface diagram,
a Journalized Data Only check box appears in this datastore’s property panel.
- When you select this box, the journalizing columns (JRN_FLAG, JRN_DATE, and
JRN_SUBSCRIBER) become available in the datastore.
- A journalizing filter is also automatically generated on this datastore. This filter will
reduce the amount of source data retrieved. It is always executed on the source. You can
customize this filter (for instance, to process changes in a time range, or only a specific
type of change).
• Knowledge Module Option:
- When processing journalized data, the SYNC_JRN_DELETE option of the Integration
Knowledge Module should be set carefully. It invokes the deletion from the target
datastore of the records marked as deleted (D) in the journals and that are not excluded by
the journalizing filter. If this option is set to No, integration will only process inserts and
updates.
Note: Keep in mind that only one journalized table can be used per interface. Using changed data in
consistent journalizing is similar to simple journalizing regarding interface design. It requires extra
steps before and after processing the changed data in the interfaces, in order to enforce changes

Using Changed Data (continued)
consistently within the set. For more details about processing change data in interfaces with
consistent journalizing, refer to Oracle® Data Integrator User’s Guide 10g Release 3 (10.1.3).

Quiz
Simple journalizing provides the consistency of the captured

changes in linked datastores.
a. True
b. False
Answer: b
Explanation: Each journalized datastore is treated separately when capturing the changes and does
not provide the guarantee of the consistency of the captured changes in linked datastores.

Quiz
The structure of the Journal table includes:

a. The primary key of the table being checked for changes
b. The time stamp to keep the change date
c. A flag to allow for a logical “lock” of the records
d. All of the above
Answer: d
Explanation: All of the above are the features of the Journal table structure.

Summary

• Describe the purpose of CDC with ODI
• Describe what types of CDC implementations are possible
with ODI
• Use CDC implementation techniques
• Perform journalizing
• Use the results of CDC

Administering ODI Resources: Advanced
Topics

Objectives

• Describe the concept of open tools
• Use open tools with Oracle Data Integrator (ODI)
• Develop your own open tools
• Use ODI Security Manager to set:
– Security policy
– Password policy
– User parameters
Objectives
This lesson provides an overview of monitoring and improving your data quality using ODI. In
this lesson, you learn why you should enforce data quality, and in which situations. The lesson
will also cover the different types of rules that can be enforced with ODI and how to enforce
these rules using the various kinds of data quality control.

Using Open Tools

What Are Open Tools?
• Are an extensible platform for developing customized ODI

tools in Java
– Customers can develop their own tools.
– Third parties can distribute specific tools.
• Can be used in the same way as ODI standard tools
– In packages, procedures, and Knowledge Modules (KMs)
• Are delivered as a Java package containing:
– At least a Java .class file
– Other resources, such as icon files
• Have Java capabilities:
– Operating system interaction, data or file handling, user
interaction, and so on
What Are Open Tools?

Open tools are an extensible platform for developing customized ODI tools using Java. With this
platform, customers can develop their own tools and third parties can distribute tools for specific
needs. Open tools can be used in the same way as standard ODI tools in packages, procedures,
and Knowledge Modules.
Open tools are provided as Java packages. They contain at least one Java class that implements
the oracle.odi.sdk.opentools.IOpenTool interface. An open tool package should also contain
resources that include two icons used to represent the open tool in the ODI user interface.
Because they are developed in Java, open tools can interact with the operating system,
manipulate data or files, provide a new user interaction, and much more.
Open tools are customizable objects. You can create your own open tools. This is discussed later
in this lesson.

Installing Open Tools
To install an Open Tool, perform the following steps:

1. Close all Oracle Data Integrator windows. New open tools
are taken into account only at the startup of Oracle Data
Integrator.
2. Copy the compressed Java package into the /plugins
subdirectory of ODI.
3. Start Designer.
4. From the File menu,
select Add/Remove Open Tools.
Installing Open Tools

Installing open tools involves adding a new open tool. You may also want to remove an open
tool. To install an open tool, perform the following steps:
1. Close all ODI windows before you continue. ODI detects new open tools only at startup.
2. Copy the compressed Java package into the /plugins subdirectory of ODI.
3. Launch Designer. The open tools that were added can now be taken into account by ODI.
4. To add the open tools, from the File menu, select Add/Remove Open Tools.
5. The Add Open Tools window appears. In this example, you add the Open Tool called
SimpleMessageBox, which opens a Java window displaying a specified message.

Note
• The .jar file must be installed on every ODI installation.

• Adding an Open Tool in Designer needs to be done only
once per Master repository.
• The Open Tool SimpleMessageBox is delivered with ODI.
You find the corresponding Java class in
oracledi\demo\plugins\src\com\myCompany\suno
psisOpenTools.
Note
The .jar file must be installed on every ODI installation, including the agents, whereas adding
an Open Tool in Designer needs to be done only once for a given Master repository.
The Open Tool SimpleMessageBox is delivered with ODI. You find the corresponding Java
class in the demo\plugins\src\com\myCompany\sunopsisOpenTools
subdirectory of ODI. The Open Tool SimpleMessageBox opens a message box displaying the
message you have specified. You use this Open Tool in the following examples. Now add the
SimpleMessageBox to your project.

Adding a New Open Tool
Two possibilities to add an existing Open Tool:
1
If you know the name of the Open Tool’s 2
Java class, you can enter it directly in You can also use the Search option to
the “Open Tool class name” edit box. find existing open tools. Click Find in
the classpath. A new window opens.

Add an existing Open Tool to your project in one of two ways:
• Enter the name of the class in the Open Tool class name edit box. (You must know the
name of the Open Tool’s Java class.)
• If you do not know the exact name and spelling of the Java class, you can use the Search
option to find existing open tools. Click “Find in the classpath,” and a new window opens.

Search options:
You can browse for the name of

the Open Tool’s Java class.
Or, you can search for the
class by name. Enter part of
the name in the text field.
Select the Open

Tool’s Java class.
Click OK to confirm
your choice.
Adding a New Open Tool (continued)

In this new window, you can choose between two search options:
• Browse for the name of the Open Tool’s Java class in the tree menu.
• Narrow the scope of your search by entering part of the Java class name in the text field.
ODI automatically reduces the number of the displayed files in the tree menu to the Java
classes that match your entry. After you have found the Open Tool’s Java class, select it
and click OK to confirm.
Note that all Java classes currently available to ODI are shown in this list. This means that those
that are not open tools are also displayed. You must know the name of your class to add the
Open Tool. Note also that an Open Tool name cannot start with Snp or Odi. An Open Tool with
a name starting with these strings is ignored.

Add the existing Open Tool:
3
Click Add Open Tool.

After clicking OK, you return to the Add Open Tools window. Now, the name of your open
tools’ Java class appears in the Open Tool class name edit box. Click Add Open Tool to finally
add it to your project.

Note: Restart ODI Designer to take the changes into the

account.
Click Tools. Open Tool syntax Provider
Version number
4
Description Click OK

Now check whether the Open Tool has been correctly added. Note that you should now restart
Designer to take the changes into account.
When an Open Tool is added, ODI verifies that the Open Tool is located in the specified
classpath. If the Open Tool is found at the indicated location, the Add Open Tools window
should display the icons you supplied with a brief description of the Open Tool.
It should also determine the syntax to be used by the Open Tool, and contain information about
the provider and the version number of the Open Tool. If all these elements are displayed, your
Open Tool has been correctly added. Click OK to save and close the window.

• If the Open Tool is not found, the following error message

is displayed:
Error message
:
Note: Change the classpath or move the Open Tool to the right
directory.

What happens if the Open Tool is not found by ODI?
The Add Open Tools window displays the error message shown in the slide. In this case, you
should either change the classpath or move the Open Tool to the right odi/plugins directory.

Removing an Open Tool
To remove an Open Tool, go to the Add Open Tools window:
1
Select the name of the Open
Tool that you want to delete.
2
Click Delete.
Removing an Open Tool

To remove an Open Tool, go to the Add Open Tools window and select the name of the Open
Tool you want to delete. Then, click Delete. ODI deletes the Open Tool’s Java classes from the
odi/plugins directory.

Using Open Tools in a Package: Example
In a package, open tools are used the same way as other tools:
1
In Toolbox, select the tool that you
want to use. Open tools are listed
under the Plugins group.
2
3 Click the diagram and a
You can now set the parameters for step corresponding to
the selected tool in the Properties your tool is created.
panel.
Using Open Tools in a Package

In a package, open tools are used in the same way as other tools. You have to create a tool step.
To insert an ODI Open Tool step, perform the following:
1. From Toolbox, select the tool that you want to use. In the slide example, it is the
SimpleMessageBox. Notice that open tools are listed under the Plugins group.
2. Click the diagram, and a step corresponding to your tool appears.
3. Double-click the step icon in the diagram. The Properties panel opens.
4. On the General tab of your Properties panel, enter the name of the step, and enter or select
the appropriate values for the parameters of the tool.
The next steps are the same as for ordinary tool steps.
Note: When you click Execute, and if the Open Tool has been correctly implemented in the
package, the message box shown in the slide should appear.

Using Open Tools in a Procedure or in a KM:
Example
Create a procedure command line.
1
Enter the name of the
procedure command line.
2
Select Sunopsis API as
the technology.
3
Create the command line
using the Expression Editor.
The syntax is the same as for
the command in a package. 4
Click OK.
Using Open Tools in a Procedure or in a KM

You have seen how to use an Open Tool in a package. You now see how to use an Open Tool in
a procedure or in a Knowledge Module. Because the steps to follow when you are using an Open
Tool in a KM are the same as for open tools in a procedure, only the guidelines for the procedure
environment are discussed here.
To use an Open Tool in a procedure or in a KM, perform the following steps:
1. Create a procedure command line. For this, click the Details tab of the procedure and click
Add to add a procedure command line. A new window opens.
2. In this window, enter the name of the procedure command line on the Definition tab. Then,
select Sunopsis API as the technology.
3. Create the command line. Use the same syntax as you would in a package.
It is recommended that you use the Expression Editor to create the command.
4. Click OK to confirm your entries and close the window.

Using Open Tools in a Procedure or in a KM:
Example
Execute the procedure:
Click Execute.
Using Open Tools in a Procedure or in a KM (continued)

Now, you can execute the procedure by clicking Execute.

Developing Your Own Open Tools

Developing Your Own Open Tools: Example
Example: SimpleMessageBox
The source code is available in the demo/plugins/src
directory.
SimpleMessageBox "-TEXT=<text message>" "-TITLE=<window
title>"
1. Define the syntax.
2. Create two icons (1616 and 3232 - .gif format).
3. Create and implement the class.
4. Compile the class and create a package with the two icon
files.
5. Install the Open Tool as described in the section titled
“Using Open Tools.”
Developing Your Own Open Tools: Example

The following explanation covers the development of a basic open tool. Note that the steps
described here do not take place in ODI but in your favorite Java tool. Use the example of
SimpleMessageBox again. The source code for this class is available in the
demo/plugins/src directory.
To develop your own open tool, perform the following steps:
1. Define the syntax. In this example, the open tool is called:
SimpleMessageBox “-TEXT=<text message>” “-TITLE=<window title>”
2. Create two icons in .gif format: a small 1616 icon and a bigger 3232 icon; otherwise,
the default icons are used.
3. Create and implement the class. Implementation is discussed in detail later.
4. Compile the class and create a package with the two icon files.
5. Install the open tool.

Developing Your Own Open Tools: Implementing
the Class
1. Naming the package
Create a package containing the open tool’s class and
name it appropriately. The package name is used to
identify the open tool when installing it.
package com.myCompany.OpenTools;
Developing Your Own Open Tools: Implementing the Class

The implementation of the open tool’s Java class starts with creating a package containing the
open tool’s Java class. It is important to attribute a descriptive name to the package because the
package name is used to identify the open tool when it is installed. An example for a package
with a self-explanatory name is: com.myCompany.OpenTools;.

the Class
2. Two ways to declare the class:
a. Extending an existing class
— For conversion into an open tool
— Implement the IOpenTool interface directly on the existing
class.
b. Developing a new class
— Extends the OpenToolAbstract abstract class
— Contains additional helper methods for working with parameters
public class SimpleMessageBox extends OpenToolAbstract {
Developing Your Own Open Tools: Implementing the Class (continued)

Now that you have created and named the package, you have to declare the class. There are two
basic approaches for this:
• Extending an existing class that you want to convert into an open tool. In this case, you
should implement the IOpenTool interface directly on the existing class.
• Developing a new class. In this case, it is easiest to extend the OpenToolAbstract abstract
class. This also contains additional helper methods for working with parameters.
In the slide example, the SimpleMessageBox class is public and extends the OpenToolAbstract
abstract class:
public class SimpleMessageBox extends OpenToolAbstract {

the Class
3. Open tool SDK packages to import
import oracle.odi.sdk.opentools.IOpenTool;
import oracle.odi.sdk.opentools.IOpenToolParameter;
import oracle.odi.sdk.opentools.OpenToolExecutionException;
import oracle.odi.sdk.opentools.OpenToolAbstract;
import oracle.odi.sdk.opentools.OpenToolParameter;
Abstract
Class used for class you
parameters extend
In this particular example, you need an additional package:

import javax.swing.JOptionPane;

Almost every open tool needs to import the following open tool software development kit (SDK)
packages:
• The import oracle.odi.sdk.opentools.IOpenTool interface must be implemented
by an open tool class. It provides methods to get the description, icon, provider, syntax,
and version of the open tool, as well as the list of parameters it takes. It must also provide
the execute() method.
• The import oracle.odi.sdk.opentools.IOpenToolParameter interface must be
implemented in order to use an object as a parameter of an IOpenTool. It specifies methods
for setting and retrieving the name, code, current value, and help text for a parameter, as
well as whether it is mandatory or not.
• The oracle.odi.sdk.opentools.OpenToolExecutionException package is the
base abstract exception class for non-run-time exceptions thrown by ODI Open Tool
objects.
• oracle.odi.sdk.opentools.OpenToolAbstract is the abstract class that you
extend for the open tool. It implements one additional helper method allowing the current
value of a parameter specified by the parameter code to be retrieved.

• The class you use for parameters is
oracle.odi.sdk.opentools.OpenToolParameter. This class provides a basic
implementation for IOpenToolParameter and can be used to define parameters for the
IOpenTool objects.
• In this particular example, you also need to import the javax.swing.JOptionPane
Swing package for the GUI elements of the message box. Note that this package is not
delivered with ODI.

the Class
4. OpenToolParameter objects
Add an array of OpenToolParameter objects to:
– Define the parameters’ name, syntax, and description
– Store the parameters’ values
private static final IOpenToolParameter[] mParameters = new

IOpenToolParameter[]
{
new OpenToolParameter("-TEXT", "Message text", "Text to
show in the messagebox (Mandatory).", true),
new OpenToolParameter("-TITLE", "Messagebox title", "Title
of the messagebox.", false)
};

Note that the following step is required only for open tools having parameters. If you are using
an open tool without parameters, you can skip this step.
After importing the Open Tool SDK packages, add a property to store the OpenToolParameter
objects. This is used both to define them for the syntax and to retrieve the values of the
parameters from the eventual user. It is easiest to define the parameters of the open tool with a
static array. This array should be private because it will be accessed via an accessor function.
The four parameters passed to the OpenToolParameter() constructor are as follows:
• The first parameter represents the code of the parameter, including the initial hyphen. It is
critical that this code corresponds to the syntax returned by getSyntax().
• The second parameter is the user-friendly name, which is used if the user is using the GUI
to set parameters.
• The next parameter is a descriptive help text.
• The last parameter indicates whether the OpenToolParameter is mandatory or not.

the Class
Note: ODI does not enforce the mandatory flag on
parameters. Your class must be able to handle any
combination of parameters being provided.
• You must implement the getParameters() accessor
function to retrieve the parameters:
public IOpenToolParameter[] getParameters()

{
return mParameters;
}

Note that ODI does not enforce the mandatory flag on parameters. Your class must be able to
handle any combination of parameters being provided. To retrieve the parameters, you must
implement the getParameters() accessor function as follows:
public IOpenToolParameter[] getParameters()
{
return mParameters;
}

Open Tools at Run Time

During the installation:

• ODI instantiates the class and calls the following methods:
– getDescription()
– getProvider()
– getIcon()
– getVersion()

Start with the run-time behavior of open tools at installation time. When the user installs an open
tool, ODI instantiates the class and calls the getDescription(), getProvider(),
getIcon(), and getVersion() methods to retrieve information about the class.

Open tools used in a package, a procedure, or KM

The class is instantiated to call the methods:
• getDescription()
• getProvider()
• getIcon()
• getVersion() Called to retrieve the code name
and default arguments
• getSyntax()
• getParameters() Called to display the list
of arguments
Open Tools at Run Time (continued)

When an open tool is used, irrespective of the environment (package, procedure, or KM), ODI
instantiates the class to call the following methods: getDescription(), getProvider(),
getIcon(), getVersion(), getSyntax(), and getParameters().
getSyntax() is called to retrieve the code name of the open tool and its default arguments.
The getParameters method is called to display the list of arguments to the user.

Open tools during execution:

• Each time the open tool is executed in a package or
procedure, the class is instantiated again—it has no
persistence after its execution.
• The execute() method is called only once.
Open Tools at Run Time (continued)

At execution time, the class is instantiated again—it has no persistence after its execution. The
execute() method is called only once. This behavior is for open tools in packages, procedures,
and KMs.

Reference Information
• The Javadoc of the open tools’ SDK is delivered with the

documentation in the /doc/sdk/opentools directory.
• You can find the open tool examples in the
/demo/plugins directory.
• See Oracle Data Integrator Tools Reference for further
details about open tools.

Setting Up ODI Security

Introduction to Security Manager
Menus
Toolbar
Tree views

Using the Security Manager module, you can manage security in ODI. The Security Manager
module allows users and profiles to be created. It is used to assign user rights for methods (edit,
delete, and so on) on generic objects (data server, data types, and so on), and to fine-tune these
rights on the object instances (Server 1, Server 2, and so on).
The Security Manager module stores this information in a Master repository. This information
can be used by all the other modules.
• The Menu contains pull-down menus to access the following features:
- Import/Export
- Wizards
- Display options
- Open modules or tree views
- Change the user’s password and options
• The Toolbar lets you:
- Open other modules
- Refresh the tree views
- Open the online help
• Security Manager objects available to the current user are organized into the following tree
views:

Import profile.
Introduction to Security Manager (continued)

- The objects, describing each ODI elements type (datastore, model, and so on)
- The users profiles, users, and their authorizations
It is possible in each tree view to perform the following operations:
- Insert or import root objects to the tree view by clicking the appropriate button in the
frame title.
- Expand and collapse nodes by clicking them.
- Activate the methods associated to the objects (Edit, Delete, and so on) through the
pop-up menus.
- Edit objects by double-clicking them or by dragging them on the Workbench.
• The Workbench: The windows for the object being edited or displayed appear in the
Workbench
Note: Each tree view appears in floatable frames that may be docked to the sides of the main
window. These frames can also be stacked up. When several frames are stacked up, tabs appear
at the bottom of the frame window to access each frame of the stack. Tree view frames can be
moved, docked, and stacked by selecting and dragging the frame title or tab. To lock the position
of views, select Lock window layout from the Windows menu. If a tree view frame does not
appear in the main window or has been closed, it can be opened using the Windows > Show
View menu.

Overview of Security Concepts
Objects, instances, and methods:

• Object: The representation of an element that can be
handled through ODI (agents, models, datastores)
• Instance (object instance): Is attached to an object type
(an object). For example, the MY_PROJ_1 project is an
instance of the project object type.
• Method: Type of action which can be performed on an
object
• A profile represents a generic rights model for working with
ODI. An authorization by profile is placed on an object’s
method for a given profile.
• User: An ODI user that corresponds to the login name
used for connecting to a repository
Overview of Security Concepts

• An object is a representation of an element that can be handled through ODI (agents,
models, datastores, and so on). The objects are the visible part of ODI object components
(Java classes). It is necessary to bring together the notions of object and object instance (or
instances), which in ODI are similar to object-oriented programming notions.
• An instance (object instance) is attached to an object type (an object). For example,
MY_PROJ_1 is an instance of the project object type. Similarly, another instance of a
project-type object is YOUR_PROJ_2.
• A method is a type of action which can be performed on an object. Each object has a series
of methods that are specific to it. The notion of method in Data Integrator is similar to the
one in object-oriented programming.
• A profile represents a generic rights model for working with ODI. One or more profiles
can be assigned to a user. An authorization by profile is placed on an object’s method for a
given profile. It allows a user with this profile to be given—either optionally or
automatically—the right to this object via the method. The presence of an authorization by
profile for a method, under an object in the tree of a profile, shows that a user with this
profile is entitled (either optionally or automatically) to this object’s instances via this
method. The absence of authorization by profile shows that a user with this profile cannot,
in any circumstance, invoke the method on an instance of the object.

Overview of Security Concepts (continued)
• A user in the Security Manager module represents an ODI user and corresponds to the
login name used for connecting to a repository. A user inherits the following rights:
- The profile rights he/she already has
- Rights on objects
- Rights on instances
An authorization by the user is placed on a method of an object for a given user. It allows
the user to be given, either optionally or automatically, the right to this object via the
method.
Note: Objects and methods are predefined in ODI and should not be changed.

Defining Security Policies
1. Create appropriate profiles for your working methods, and

give them generic rights to objects.
2. Create the users.
3. Give the users the generic profiles.
4. Optionally, you can define a password policy to encourage
users to use a secured password.
Defining Security Policies

To define a security policy:
1. Create appropriate profiles for your working methods, and give them generic rights to
objects. You may use the generic profiles provided in ODI.
2. Create the users.
3. Give the users the generic profiles.
4. You can also define a password policy to encourage users to use a secured password.

Creating Profiles
1
2
Creating a New Profile

To create a new profile:
1. Select Profiles to display the tree. Right-click and select Insert profile.
2. Enter the name. Click OK.
The profile is displayed in the tree.
Note: To delete a profile:
1. Select the profile to be deleted.
2. Right-click and select Delete. Click OK.
The profile disappears from the tree.

Creating Users
Creating a New User

To create a new user:
1. Select Users.
2. Right-click and select Insert User.
3. Enter the name, the initials, and the user’s password (by clicking the “Enter a password”
button).
4. Click OK.
The user is displayed in the tree.
Note: To delete a user:
1. Select the user to be deleted.
2. Right-click and select Delete.
3. Click OK.
The user disappears from the tree.

Assigning Profile to a User
1
2
Assigning a Profile to a User

To assign a profile to a user:
1. Expand the tree to display the user you want to assign the profile to.
2. Select the profile you want to assign, then drag and drop it onto the user in the tree.
3. Click Yes.
The profile is assigned to the user.
Note: To remove a profile from a user:
1. Expand the tree to display the profile you want to delete, under the user branch.
2. Select the profile (under the user) to be deleted from the tree.
4. Click OK.
The profile is removed from the user.

Assigning an Authorization by Profile or User
Select the method you want to assign, then drag and drop it
onto the user or the profile.
Assigning an Authorization by Profile or User

To assign an authorization by profile or by user:
1. Expand the tree to display the user or the profile you want to assign the authorization to.
2. Under the object select the method you want to assign, then drag and drop it onto the user
or the profile.
3. Click OK.
The authorization is assigned to the user or the profile.
To assign authorizations on all the methods of an object to a profile or a user:
1. Expand the tree to display the user or the profile you want to assign the authorization to.
2. Select the object to which you want to assign all the methods, then drag and drop it onto
the user or the profile.
3. Click OK.
The authorizations on all the methods are assigned to the user or the profile.
To delete an authorization by profile or user:
1. Select the method you want to delete under the user or profile branch.
3. Click OK.
The authorization is removed from the user or the profile.

Defining Password Policies
1
3
5
4
2
Defining the Password Policy

The password policy consists of a set of rules applied on user passwords. This set of rules is
checked when the password is defined by the user.
To define the password policy:
1. In Security Manager, select File > Password Policy. The Password Policy window appears.
In this window, a list of rules is displayed.
2. Click the Add a rule button. A new rule definition window appears. A rule is a set of
conditions that are checked on passwords.
3. Set a name and a description for this new rule.
4. Add conditions on the password value or length. You can define, for example, a minimum
length for the passwords from this window.
5. Select if you want at least one condition or all of them to be valid to consider that the
password meets the rule. Click OK.
6. Add as many rules as necessary, and select the check boxes of the rules that you want
active in your current policy. Only the passwords meeting all the rules are considered as
valid for the current policy.
7. You can also define a period of validity for the passwords. Passwords older than this
number of days will automatically expire. The users will have to change them. Click OK to
update the password policy.

Setting User Parameters
Setting User Parameters

ODI saves user parameters such as default directories, windows positions, and so on. User
parameters are saved in the userpref.xml file in /bin.
To set user parameters:
1. Select User Parameters from the File menu.
2. In the Editing User Parameters window, change the value of parameters as required.
3. Click OK to save and close the window.
Note: A list of the possible user parameters is available in the reference manual.

Quiz
If the Add Open Tools window displays the error message

provided below, you should either change the classpath or
move the Open Tool to the right odi/plugins directory.
a. True
b. False
Answer: a
Explanation: If the Open Tool is not found by ODI, the Add Open Tools window displays the
error message. In this case, you should either change the classpath or move the Open Tool to the
right odi/plugins directory.

Quiz
Which of the following statements regarding ODI security

concepts is not true?
a. The objects are the visible part of ODI object components
(Java classes).
b. A method is a type of action which can be performed on an
object. Each object has a series of methods that are
specific to it.
c. An authorization by a user is placed on a method of an
object for a given use.
d. Objects and methods can be changed in ODI.
Answer: d
Explanation: Objects and methods are predefined in ODI and should not be changed.

Summary

• Describe the concept of open tools
• Use open tools with ODI
• Develop your own open tools
• Use ODI Security Manager to set:
– Security policy
– Password policy
– User parameters

Using Web Services and Integration of Oracle
Data Integrator with SOA

Objectives

• Identify the different types of Web services
• Generate, deploy, and test data services
• Use public Web services with Oracle Data Integrator (ODI)
• Configure data services
• Install and use public Web services
• Execute a scenario using public Web services
• Invoke a public Web service using the
OdiInvokeWebService tool
• Implement integration of ODI with Service-Oriented
Architecture (SOA)
Objectives
The aim of this lesson is to provide an understanding of the Web services created and used in ODI.

Web Services in Action
Integration
process
Source Target
Third-party J2EE Third-party

Web service
application
Web Services
Port
Business Container
processes SOAP runs Operation
Data Service
Start
SOAP SOAP
Public Web scenario
ESB Service ODI Agent
OdiInvokeWebService
tool
Repository
Web Services in Action

This gives you an overview of how the different types of Web services can interact.
You see a simple setup with the data service and the public Web service deployed in a Web services
container (a Java 2 Platform, Enterprise Edition [J2EE] application server), and the
OdiInvokeWebService tool.
The data service and public Web service components are invoked by a third-party application,
whereas the OdiInvokeWebService tool invokes a third-party Web service. First, take a look at the
data service. It provides access to data in datastores (both source and target datastores).
The public Web service commands the ODI Agent to connect to the repository and to start a
scenario—in the slide example, an integration process. Finally, the OdiInvokeWebService tool
invokes a specific operation on a port of the third-party Web service. Thus, you can, for example,
access data in datastores.

Two Types of Web Services
The ODI Public Web services and Data services are two
different types of Web services:
Public Web Services:

Enable you to access ODI features
through Web services
Data Services:
Are generated by ODI to give
you access to your data through Web services
Two Types of Web Services

ODI public Web services and data services are two different types of Web services. Do not confuse
between them. ODI public Web services enable you to access the ODI features through Web
services, whereas the data services are generated by ODI to give you access to your data through
Web services.

Using Data Services

What Are Data Services?
• Data services are specialized Web services.

• They provide access to:
– Data in datastores
– Captured changes in these datastores using the Changed
Data Capture (CDC) feature
• They are automatically generated by ODI and deployed to
a Web services container.
What Are Data Services?

Data services are specialized Web services that provide access to data in datastores, and to the
captured changes in these datastores using the CDC feature. These Web services are automatically
generated by ODI and deployed to a Web services container—typically, a Java application server.

Generation of Data Services
• Data services are automatically generated by ODI.

• You can generate the Java classes that expose the
datastore’s data as a data service from a datastore or a
model, by using a Service Knowledge Module (SKM).
• You can automatically compile and deploy these Java
classes to a Web services container.
Oracle DI J2EE
Web services
Datastore
Java classes container
Generation Data service Data service
SKM
Generation of Data Services

ODI automatically generates the data services from a datastore or a model. This generation can be
customized by using SKM. The resulting data service is presented in the form of a Java package. You
can automatically compile and deploy these Java classes to a Web services container. ODI supports
the J2EE application server Axis2.

Data Services in Action
Third-party applications can invoke data services.

1
As data services do not contain
connection information for
sources and targets…
J2EE
Third-party
Web services Datastore
application
container
Business JDBC
processes SOAP Data service
Data sources
ESB
3
These data sources contain the connection
2 properties required to access data, and must
…they make use of data sources correspond to data servers defined within the
defined within the Web services ODI topology.
container or on the application server.
Data Services in Action

Third-party applications can invoke data services using Simple Object Access Protocol (SOAP).
Note that after it is deployed, the data service is independent of ODI (both of the agent and the
repository). It is also important to know that the data services generated by ODI do not contain
connection information for sources and targets. For this reason, they make use of the data sources
defined within the Web services container or on the application server. These data sources do contain
the connection properties required to access the data in datastores using Java Database Connectivity
(JDBC), provided that they correspond to the data servers defined within the ODI topology.

Setting Up Data Services
Before getting started:

• You should have configured your Web services container
and the application server
• Install the driver files (.jar or .zip) for your data source
in the appropriate directory for your application server

Before setting up data services, you should check whether your Web services container and the
application server are configured.
Another prerequisite is that you should have installed the driver files (.jar or .zip) for your data
source in the appropriate directory for your application server.
For example: You install the driver files in the /common/lib directory if you are using Tomcat and
the ORACLE_HOME/j2ee/home/applib directory if you are using Oracle Application Server
Containers for J2EE (OC4J).

Setting up data services involves the following stages:

1. Setting up data sources in a Web services container
2. Configuring the topology to declare the Web services
container
3. Setting up the model to declare datastores and columns
for data services
4. Generating, deploying, and testing data services
Setting Up Data Services (continued)

You set up data service using the following procedure:
1. Set up the data sources in a Web services container.
2. Declare the Web services container in the topology because all physical data servers need to be
defined in ODI.
3. Set up the model to configure options for the data services at the datastore and column level.
4. Configure the generation and deployment of the data services, and then test the data services.
The next few slides discuss this procedure in more detail.

1. Setting Up Data Sources in a Web Services
Container: Example
1 2
Select Axis2.
Enter JDBC URL and test
connection.
3
4
1. Setting Up Data Sources in a Web Services Container

You create the JDBC data source pointing to the data server you want to access.
For OC4J, you define the data source as follows:
1. Connect to the OC4J Enterprise Manager Application Control. On the Administration tab,
select Services > JDBC Resources, and click “Go to task.”
2. In “Create the Connection Pool” section, select the Axis2 application and New Connection
Pool. Enter in the fields for the JDBC data source.
3. Click Create in the Data Sources section and select the Axis2 application and Managed Data
Source.
4. Enter in the fields for the JDBC data source and click Finish to complete data source setup.
For more information about OC4J, see the Oracle Application Server 10g (10.1.3) How-To’s Web
site using the following URL:
http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.html

1. Setting Up Data Sources in a Web Services
Container: Example
• Make a reference to the data source in your Web services
container’s WEB-INF/web.xml file.
• Restart your Axis2 application to take the new data
sources into account.
...
<resource-ref>
<description>Data Integrator Data Services on OracleSource
</description>
<res-ref-name>jdbc/OracleSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
1. Setting Up Data Sources in a Web Services Container (continued)

The next step in setting up data sources in a Web services container is the same for Tomcat and
OC4J. It consists of making the reference to the data source in your Web services container. For this,
indicate in your Web services container’s WEB-INF/web.xml file the name of the data source in the
res-ref-name tag. Note that this should be the same data source as previously defined in the name
tag of the META-INF/context.xml file.
Note the example of the path to the web.xml file:
E:\OC4J\j2ee\home\applications\axis2\axis2\WEB-INF\web.xml

2. Configuring the Topology
• Declare the Web services container as a data server in the

topology to let ODI deploy data services on it.
• Three deployment modes are supported for data services:
– Copying files directly onto the server, if you have file
access to the server
– Uploading onto the server by FTP
– Uploading with the Web Service Upload method that is
supported on the Axis2 server
• The next steps in the configuration of the Web services
container depend on the deployment mode you choose.
2. Configuring the Topology

Now that you have set up the data sources in the Web services container, move to the next step of
setting up data services: configuring the topology.
Every Web services container used in ODI must be declared as a data server. Otherwise, ODI cannot
recognize it. Declare the Web services container as a data server in the topology to let ODI deploy
data services on it.
Note: Be careful not to confuse the Web services containers and the servers containing the deployed
data. Although both are declared as data servers in ODI, the former do not contain any data, and
serve only to host the deployed data services.
Web services containers declared in ODI have one of three modes for deploying data services:
• The first deployment mode is copying files directly onto the server. You can use this mode only
if you have file access to the server.
• The second deployment mode consists of uploading onto the server by FTP.
• The third deployment mode, uploading with the Web Service Upload method, is supported only
on the Axis2 server.
The next steps in the configuration of the Web services container depend on the deployment mode
you choose.

2. Configuring the Topology: Example
To configure the Web services container:

1. In Topology Manager’s Physical
Architecture view, select the
Axis2 technology.
2. Right-click and
select Insert Data Server.
3. If you are using a different
Web services container,
choose the
appropriate technology
instead.

2. Enter in the following fields on the Definition tab:

Name: Name of the data server as it
appears in ODI
Base URL for published services:

http://<Host>:<HTTP port>/axis2/services
File copy: Specify the directory in the

application server that will receive Web
services.
Web Service Upload: Specify the root

URL for the Axis2 application—typically,
http://<Host>:<HTTP port>/axis2/axis2-
admin/—as well as the username and
password of the Axis2 administrator.
FTP Upload: Specify the FTP URL of the Click OK.

deployment directory as well as the
username and password.
2. Configuring the Topology: Example (continued)

Click the Definition tab and enter values in the following fields:
• Name: This is the name of the data server as it appears in ODI.
• Then, enter the base URL for published services. It should correspond to the following syntax:
http://<Host>:<HTTP port>/axis2/services
Select the deployment mode.
Note that, if you select File copy, you have to specify the directory of the application server into
which Web services will be saved.
If you choose Web Service Upload mode, indicate the root URL for the Axis2 application, usually in
the following form: http://<Host>:<HTTP port>/axis2/axis2-admin/. Indicate also the username and
password of the Axis2 administrator.
FTP Upload mode requires the following entries: the FTP URL of the deployment directory and the
username and password of a user with rights to write in this directory.

3. Create the physical and the logical schema.
Click the Context tab

to create the logical
schema.
Define one logical schema

for each context in which Enter the name of the
you will deploy the data logical schema.
services.
Click OK.
2. Configuring the Topology: Example (continued)

Configuring the topology also involves creating the physical and logical schema.
In the left window, you can create the physical schema for your Web services container.
Note: You need to define only one physical schema per Web services container. On the Context tab,
you can create the logical schema. Click Add logical schema to define a logical schema. Note that
you need to define one logical schema for each context in which you will deploy the data services.
Finally, click OK to save your entries.

3. Setting Up the Model
Before configuring a model for the data services, ensure that:

• The datastores that you want to deploy are correctly
defined and accessible
• You have imported the appropriate Service Knowledge
Module (SKM) into one of your projects
• The topology is configured

Before configuring a model for the data services, ensure that the datastores you want to deploy are
correctly defined (such as by reverse engineering) and accessible.
You should also check whether you have imported the appropriate SKM into one of your projects.
The SKM contains the necessary code template used for the generation of data services. Before you
proceed with setting up the model for your data services, you must have configured the topology.

This operation involves the following steps:

1. Setting up a model to use data services
2. Configuring options for data services at the data
store level
3. Configuring data service options at the column level
3. Setting Up the Model (continued)

The basic process for setting up a model to use data services is as follows:
1. First, you set up a model for the data services.
2. Next, you configure the options for your data services at the datastore level, and then configure
the data service options at the column level.
The next few slides discuss how these steps are implemented in ODI.

3. Setting Up the Model: Example
1. Set up a model to use the data services.

Open the model and click the Services tab.
On the Application Server tab,
select the Web services
container that you set up.
Enter the namespace that will

be used in the generated
WSDL.
Enter the package name used to name

the generated Java package that contains
your Web service. Generally, this is of the
form:
com.<company name>.<project name>

To set up a model for the data services, perform the following:
1. Open the corresponding model and click the Services tab.
2. On the Services tab, you can specify the parameters for your data services.
3. First, select the Web services container that you set up on the Application Server tab. In the
slide example, it is the application server named MonAxis2.
4. Next, set the namespace that will be used in the generated Web Services Description Language
(WSDL) file.
5. Then, specify the package name used to name the generated Java package that contains your
Web service. Generally, this is of the form: com.<company name>.<project name>.

1. Set up a model to use data services.

In the data source name
field, copy and paste the
name of the data source that
you defined for the server
when setting up the data
sources and prefix it with
java:/comp/env/.
Define the name of the

data service.
Select an SKM from the list,

and set its options. Note that
only SKMs imported into the
projects appear here.
3. Setting Up the Model: Example (continued)

In the Name of data source field, copy and paste the name of the data source that you defined for the
server when you set up the data sources. This name should be prefixed by java:/comp/env/.
Then, define the name of the data service. Note that this name is used only for the data service
operating at the model level. You can also define a data service name for each datastore—this is
discussed later in this lesson.
On the Service KM tab, select an SKM from the list, and set its options. Refer to the description of
the SKM for more information. Note that only those SKMs that have been imported into projects
appear in the list.

2. Configure the data services options for datastores.
On the Services tab of

the Model, click the
Deployed datastores tab.
Select the datastores that

you want to expose as a
Web service. For each one,
specify a data service name
and the name of the
published entity.
Click OK to save your

changes.

On the Services tab of the Model:
1. Click the Deployed datastores tab.
2. Select the datastores that you want to expose as a Web service.
3. Specify the name of the data service and the name of the published entity for each datastore.
4. Click OK to save your changes.

2. Configure the data services options for datastores.

• Alternative method: Open the datastore and click the
Services tab.
Select “Deploy as Data
Service” if you want the
datastore to be deployed.
Enter the data service name

and the name of the
published entity for the
datastore.

changes.

There is an alternative method for configuring the data service options at the datastore level:
1. Open the corresponding datastore and click the Services tab.
2. On the Services tab, select “Deploy as Data Service” if you want this datastore to be deployed.
3. Enter the name of the data service as well as the name of the published entity for the datastore.
4. Click OK to save your changes. Repeat this procedure for each datastore that you want to
expose as a Web service.

3. Configure the data services options at column level.

– You can specify the permitted operations for each column—
for example, prevent a column from being modified via data
services.
– Open the column and click the Services tab:
Select the operations that

you want to allow: INSERT,
UPDATE, or SELECT.

changes.

You have now seen how to configure the data services options at the datastore level. Now configure
the data services options at the column level. To configure options at the column level means to
specify the permitted operations for each column. One important use of this feature is to lock a
column to avoid modifications via the data services.
Therefore, open the column and click the Services tab. Now you can select the operations that you
want to allow: INSERT, UPDATE, or SELECT. To save your changes, click OK.

4. Generating, Deploying, and Testing Data
Services: Example
To generate data services for a model:
Select the model for which you
want to generate the data
services.
Specify the path to store the

generated data service.
Specify the context. Right-click and select

Generate Service.
Choose one or more generation phases.
4. Generating, Deploying, and Testing Data Services: Example

Now, that you have set up a model and configured the options for the data services, you can start
generating the data services.
To do so, select the model or datastore for which you want to generate the data service and right-
click and select Generate Service. The generation configuration window opens.
In the generation configuration window, perform the following:
1. Specify the path of the folder where the generated data service will be saved. ODI places the
generated source code and the compiled Web service in this folder. Note that this directory is a
temporary location that can be deleted after generation.
2. Specify the context bearing in mind that the choice of a context determines to which physical
Web services container the data service is deployed.
3. Select the generation phases. For normal deployment, all three phases should be selected. The
three generation phases are: generation, compilation, and deployment.
- The generation phase deletes everything in the directory. It generates .java files by
using the SKM. However, it may be useful to perform the generation phase only when
testing new SKMs, for instance.
- The compilation extracts the Web service framework and compiles the .java files

4. Generating, Deploying, and Testing Data Services: Example (continued)
- into .class files.
- The deployment phase generates a Java package (.aar) from the compiled files and
copies the package to the deployment target, according to the chosen deployment method.
• Click OK to validate your entries.

4. Generating, Deploying, and Testing Data
Services: Example
It is also possible to click Generate and

deploy on the Services tab in the Model
window.
This opens the generation configuration
window shown in the previous slide.
4. Generating, Deploying, and Testing Data Services: Example (continued)

There is an alternate method for executing the generation and deployment of data services.
It is also possible to go to the Model window and click Generate and deploy on the Services tab. This
opens the generation configuration window shown in the previous slide.

Testing Data Services: Example
• The easiest way to test the generated data services is to

right-click a datastore in the Models view and select Test
Web Service.
• You can also use the interface for
the OdiInvokeWebService ODI tool
to test the generated data service.

After you set up the data service, there are several ways to test it. The easiest is to right-click the
datastore that you expose as a data service in the Models view and select Test Web Service. Clicking
Test Web Service opens a new window.
Another way to test your generated data service is by using the ODI tool OdiInvokeWebService. This
tool is discussed in detail later.

The Test Web Service window: 5 Click Invoke Web

Service to perform the
Choose the appropriate Web service call.
WSDL location.
1
Select the appropriate
port type.
2 4
Complete the fields
for the SOAP
request and press
Enter to confirm the
3 entries.
Select the data service

operation that you want to
be executed on the
datastore from the list.
Testing Data Services: Example (continued)

The new window is the Test Web Service window.
1. To test your Web service, enter or choose the appropriate WSDL location of your Web service.
2. Then, select the appropriate port type to connect to it. Note that the WSDL and the port are set
by default.
3. In the lower-left region of the window, you find a list containing the operations provided by the
data service for the selected port. From this list, select the data service operation that you want
to be executed on the datastore. A second tab displays the HTTP request options.
4. In the lower-right region, the SOAP editor displays the Web service request and response. Enter
in the fields for the SOAP request and press Enter to confirm your entries. To perform the Web
service call, click Invoke Web Service.
You now learn how to apply this in a concrete example.

The Test Web Service window: Example

1
In this example, you

want to manipulate a
single entity: access
the record of one
specific customer.
2
Indicate the CUSTID of
the customer and
press Enter to confirm
the entries.
3
Finally, click Invoke
Web Service.

In the example, you want to manipulate a single entity, meaning that you want to access the record of
one specific customer. You use the getSrcCustomer operation. Select this operation from the
list, then indicate the primary key (here, the CUSTID) in the corresponding field of the SOAP editor.
Press Enter to confirm your entry. Next, click Invoke Web Service.

The Test Web Service window: Example
The response is displayed

in the right pane of the
SOAP editor.

Your Web service response is displayed in the right pane of the SOAP editor. The record of the
customer with the CUSTID 103 is returned. Your data service is working correctly.

Using Public Web Services

You have now seen how to generate, deploy, and test the data services.
The next topic in this lesson is “Public Web Services.”
• First, you are introduced to the concept of public Web services.
• Then, you learn how to install and use public Web services—especially to execute a scenario
using public Web services.
• In this context, you also learn how to define a SOAP request and response.

What Are Public Web Services?
• ODI public Web services are Web services that enable

users to leverage ODI features in a Service-Oriented
Architecture (SOA).
• A public Web service allows applications to trigger
transformation developed with ODI through a secured Web
service. This Web service can be deployed in any Web
services container.
What Are Public Web Services?

ODI public Web services are Web services that enable users to leverage ODI features in an SOA.
They provide operations, such as starting a scenario.
A public Web service allows applications to trigger transformation developed with ODI through a
secured Web service. This Web service can be deployed in any Web services container, typically a
Java 2 Platform, Enterprise Edition (J2EE) application server.

Public Web Services in Action
Repository
A third-party application can call data Model (Metadata)1
1 transformations developed with ODI
through a Web service.
Third-party J2EE
application
Web services
container Start scenario
Business
processes SOAP Public Web
ODI agent
Service
2
ESB Source
Sybase Target Oracle
Public Web services Integration
provide operations such ORDERS process
as Starting a Scenario. SALES
LINES
This Web service

3 commands an agent to
connect to a given Work CORRECTIONS Scenario
File
repository and start a integration sales statistics
specific scenario.
Public Web Services in Action

Now look at public Web services in action.
Public Web services are invoked by a third-party application. This application calls the data
transformations developed with ODI through public Web service.
Public Web services provide operations, such as Starting a Scenario. To start a scenario, the public
Web service commands the ODI agent to connect to the repository and to start a scenario—in the
slide example, an integration process.

Installing Public Web Services
• Public Web services can be deployed in any Web services

container (typically, a Java application server).
• A public Web service is provided as an Axis2 Archive File
(.aar).

Installing Public Web Services
• In Axis2, go to the Administration page. A public Web

service is provided as an Axis2 Archive File (.aar).
• Browse for the ODI Web services odi-public-ws.aar
file. It is located in the /tools/web_services/ directory
of the ODI installation directory.
1
Installing Public Web Services (continued)

To install the ODI public Web services on Axis2, perform the following:
1. Go to the Administration page in Axis2.
2. Click Upload Service and browse for the ODI Web services odi-public-ws.aar file. You
find it in the /tools/web_services/ directory of the ODI installation directory. After you
find it, select it and click Upload. Axis2 uploads ODI Web services and you can now see the
ODI public Web services in the Axis2 Available Services list.

Executing a scenario using a public Web service:

• You can run a scenario from a Web service using ODI
public Web services.
– Web service name: OdiInvoke
– Port: invokeScenario
• The OdiInvoke Web service commands an agent to
connect to a given Work repository, and start a specific
scenario.
• The parameters are similar to the ones used when
executing a scenario from an operating system (OS)
command.

ODI public Web services enable you to run a scenario from a Web service. To execute a scenario
using a Web service, you can invoke the Web service named OdiInvoke. The port to use is called
invokeScenario. This Web service commands an agent to connect to a given Work repository, and to
start a specific scenario. Note that the agent must be accessible from the Web service container host,
and it must have access to the repositories.
The involved parameters are similar to the ones used when executing a scenario from an OS
command. A simple SOAP request for this Web service is provided next.

A Simple SOAP Request for the OdiInvoke
Web Service: Example
Defining the Master repository connection:
Username for the schema of the
<invokeScenarioRequest>
database containing the Master
<invokeScenarioRequest>
repository Name of the JDBC driver
<RepositoryConnection>


<JdbcDriver>oracle.jdbc.driver.OracleDriver</JdbcDriver>
<JdbcUrl>jdbc:oracle:thin:@localhost:1521:xe </JdbcUrl>
<JdbcUser>snpm1</JdbcUser>
<JdbcPassword>password</JdbcPassword> URL of the data server
<OdiUser>SUPERVISOR</OdiUser> hosting the repository
<OdiPassword>SUNOPSIS /OdiPassword>
<WorkRepository>WORKREP1</WorkRepository>
Data server password for
</RepositoryConnection> the database user
A Simple SOAP Request for the OdiInvoke Web Service: Example

Take a look at a simple SOAP request for the OdiInvoke Web service.
The SOAP request defines several parameters: the Master repository connection, the scenario, the
context, the synchronization mode, and the agent.
In the first part, the Master repository connection is defined by the name of the JDBC driver and the
JDBC URL.
The JDBC driver (JDBC 1 type 4) is used to access the technology hosting the repository. The JDBC
URL specifies the path of the data server hosting the repository. You have to indicate this path as
follows: jdbc:oracle:thin:@<IP address or name>:<listener port>:<SID>.
To define the connection of the Master repository, you also need to indicate the OdiUser with its
OdiPassword, and the Work repository containing the scenarios to be executed. The ODI username
and its password are needed to connect to the Work repository. The rights of this specific user will be
used to execute the scenario. If this user has no rights on the context, the execution will not work.

Note
• The Web service accepts passwords in a plain text format.

It is strongly recommended that you use secured protocols
(HTTPS) to invoke Web services over a nonsecured
network.
• The entire Repository Connection structure is not
mandatory if the agent is connected to the Work
repository.
– For a Scheduler Agent, for example, the agent has all the
repository connection information.
Note
There are two important notes to keep in mind concerning the definition of the Work repository in a
SOAP request:
• The first one is about the protocols invoking the Web services: The Web service accepts
passwords in a plain text format. Therefore, it is strongly recommended that you use secured
protocols (HTTPS) to invoke Web services over a nonsecured network.
• The second one is about the Repository Connection structure: If the agent is connected to the
Work repository, the entire RepositoryConnection structure is not mandatory. For a Scheduler
Agent, for example, the agent has all the repository connection information. In this case, only
the ODIUser and ODIPassword parameters are required.

A Simple SOAP Request for the OdiInvoke
Defining the scenario, the context, and the synchronization
mode:
<Command>

<ScenName>LOAD_DW</ScenName> Name of the scenario
<ScenVersion>001</ScenVersion>
Version of the scenario
<Context>GLOBAL</Context>
If the version specified is –1, the latest
<SyncMode>1</SyncMode> version of the scenario is executed.
</Command>
Execution context of the scenario
<Agent>
 mode used for
Synchronization
<Host>localhost</Host> the scenario execution
<Port>20910</Port> Network name or IP address of the machine
</Agent> on which the agent is running
</invokeScenarioRequest> Listening port used by the agent. By
</invokeScenarioRequest> default, this port is 20910.
A Simple SOAP Request for the OdiInvoke Web Service: Example (continued)
The SOAP request defines the scenario with the parameters ScenName, the name of the scenario, and
ScenVersion, indicating the version of the scenario. Note that, if the version specified is –1, the
latest version of the scenario is executed.
You also need to indicate the context for the execution of the scenario.
The synchronization mode (SyncMode) is used for the scenario execution and has an effect on the
response. If the synchronization mode equals 1, you have chosen the synchronous mode. The
response is returned after the session is completed and the response reflects the execution result.
If the synchronization mode equals 2, you have chosen to execute the scenario in asynchronous
mode. In this case, the response is returned after the session is started. This means that the response
only reflects the fact that the session was correctly started.
The last component that is described in the SOAP request is the agent that executes the scenario.
For the Host parameter, you have to indicate the network name or IP address of the machine on
which the agent is running. For the Port, specify the listening port used by the agent. Note that, by
default, this port is 20910.

A Simple SOAP Response for the OdiInvoke
The SOAP response returned by the scenario execution with
SyncMode=1:
<odi:invokeScenarioResponse
xmlns:odi="xmlns.oracle.com/odi/OdiInvoke">
Boolean (true or false) indicating
<odi:CommandResultType> whether the session was started or not
<odi:Ok>true</odi:Ok>
<odi:SessionNumber>1148001</odi:SessionNumber>
</odi:CommandResultType> Unique ID number for the session
in the repository
</odi:invokeScenarioResponse>
A Simple SOAP Response for the OdiInvoke Web Service: Example (continued)
In this slide, you have the SOAP response for the OdiInvoke Web service returned by the scenario
execution in synchronous mode.
The odi:Ok parameter indicates whether the session was started or not. It is a Boolean value.
odi : SessionNumber is a unique ID number attributed to the session in the repository.
You have now seen how to define a simple SOAP request and how to interpret the corresponding
response.

Invoking Web Services
Invoking Web Services

This section shows you how to invoke Web services.

OdiInvokeWebService Tool
• The OdiInvokeWebService tool can invoke any third-party

Web service.
• It can be used in the tool step of a package or in a
Knowledge Module.
• It can save the response in an Extensible Markup
Language (XML) file that can be processed with ODI.
ODI provides the OdiInvokeWebService tool to invoke Web services. With this tool, you can invoke
any third-party Web service. The OdiInvokeWebService tool can be used in the tool step of a package
or in a Knowledge Module. The response of the Web service request is written and saved to an XML
file that can be used in ODI.

OdiInvokeWebService in action
OdiInvokeWebService invokes a specific
operation on a port of the Web service.
1 2 The Web Services Description Language
(WSDL) file URL must be provided.
The OdiInvokeWebService tool
sends a client request to the
Web service via HTTP or
HTTPS protocols.
Web service
SOAP Requests/invokes Port

OdiInvokeWebService Operation
SOAP Response
XML 3
4 The response is written to an XML file that The response is written
can be processed with ODI. to a SOAP file.
OdiInvokeWebService Tool (continued)

Take a look at the OdiInvokeWebService tool in action.
1. To invoke a Web service, the OdiInvokeWebService tool sends a client SOAP request to the
Web service via HTTP or HTTPS protocols.
2. OdiInvokeWebService invokes a specific operation on a port of the Web service. Note that the
URL of the WSDL file must be provided here.
3. Then, the response is written to a SOAP file.
4. Finally, the response is written to an XML file that can be processed with ODI.

Invoking a Web Service: Example
1. Create an OdiInvokeWebService tool step in a package.

Another way to invoke Web services is by using the OdiInvokeWebService tool to create a tool step
in a package. To create an OdiInvokeWebService tool step, open the package where you want to
create a tool step and click the Diagram tab. From the toolbox, select the OdiInvokeWebService tool.
Click the diagram—a step corresponding to your tool appears. Click “Free choice” to be able to edit
the step, then click the step icon in the diagram to open the Properties panel.

2. Define the parameters in the Properties panel.
1 On the General tab,

enter the name of the
step.
To define the values for the

Web service invocation and
the request file parameters,
click Advanced. A new 3
window opens.
Or, enter the values directly

in the Properties panel.
2
Enter or select the appropriate
values for the result file
parameters of the tool.
Invoking a Web Service: Example (continued)

In the Properties panel, define the parameters for the Web service invocation. You notice that the
next steps are similar to testing data services.
To define the parameters:
1. Enter the name of the step on the General tab.
2. Enter or select the appropriate values for the result file parameters of the OdiInvokeWebService
tool.
3. Define the values for the Web Service invocation and the request file parameters. You can do
this either by clicking Advanced and a new window opens (this is the recommended way) or by
entering the values directly in the Properties panel.
Notice the window that opens when you click Advanced; it is the OdiInvokeWebService Advanced
Editor window.

3. Configure the OdiInvokeWebService tool step in a

package.
1
2
Enter the location
Click “Connect
of the WSDL. to WSDL.”

In the OdiInvokeWebService Advanced Editor window, enter or select the location of the WSDL for
the Web service you want to invoke. You can use either a URL for a WSDL that has been deployed
to a server (for example, http://host:8080/axis2/services/WSCustomer?wsdl) or a local file location
(for example, C:/DataServices/WSCustomer.wsdl).
Then, click “Connect to WSDL.” ODI establishes the connection to the WSDL.

3. Configure the OdiInvokeWebService tool step in a

package.
Choose a port. 5 Click Invoke Web Service to
immediately invoke the Web service
for testing purposes or directly click
3 OK to save the parameters.
6
Enter the fields for the
SOAP request and press
Enter to confirm the entries.
4
Select the operation
from the list.

In the OdiInvokeWebService Advanced Editor window, choose a port. Then, select the operation that
you want to invoke from the list. Now, enter the fields for the SOAP request and press Enter to
confirm the entries. Next, click Invoke Web Service if you want to immediately invoke the Web
service for testing purposes or directly click OK to save the parameters. You have now created an
OdiInvokeWebService tool step in a package.

4. Check the result of the OdiInvokeWebService invocation.
Source panel
SOAP Editor
panel

Check if OdiInvokeWebService was invoked successfully. Use either the SOAP Editor panel or the
Source panel.

Processing a Web Service Response
• When OdiInvokeWebService is used to call a Web service,

the response is written to an XML file
• Guidelines for processing the response file with ODI:
1. Use the Export Response XSD option.
2. Create an XML model for the SOAP response.
3. Use regular ODI interfaces.

When the OdiInvokeWebService tool is used to call a Web service, the response is written to an XML
file. This response file can be processed with ODI. Processing this file can be done by performing the
following steps:
1. Use the Export Response XSD option.
2. Create an XML model for the SOAP response.
3. Use regular ODI interfaces.
This procedure for processing the Web service response is discussed in more detail in the next slide.

1. After invoking the Web service, use the Export Response

XSD option to get the description of the response, enabling
the export of the XML schema and reverse engineering.
1
Click Export Response
XSD.
2
Enter the export directory
and the character encoding.
3
Click OK to save.
Processing a Web Service Response (continued)

The first step consists of using the Export Response XSD option.
The Export Response XSD option generates the description of the response file. This description
enables the export of the XML schema and reverse engineering.
You can use this option after invoking the Web service.
To apply the Export Response XSD option, click Export Response XSD and the Export Response
XSD window opens. In this new window, enter the export directory, and the character encoding for
your XML description and the target file. Click OK to save.

2. Create an XML model for the SOAP response, based on

this XML schema file, and reverse engineer the XML
Schema Definition (XSD) to have your model structure.
ODI inserts specific references and primary key constraints
in the XML model.
3. You can now process the information from your response
using regular ODI interfaces. This XML file is used as a
source or target for an interface.
Processing a Web Service Response (continued)

For the second step, create an XML model for the SOAP response.
The XML model is a set of datastores, with each datastore representing an entry level in the XML
file based on this XML schema file.
Next, reverse engineer the XSD to have your model structure. ODI automatically inserts specific
references and primary key constraints in the XML model.
Note that each XML file is defined as a model in ODI. It is recommended to use model folders to
arrange them.
The third step consists of processing the Web service response. You can now process the information
from your response using regular ODI interfaces. The interfaces will use this XML file as a source or
a target.
Note: For more information about this topic, see Creating and Reverse Engineering a Model for an
XML file in the Oracle Data Integrator User's Guide 10g Release 3 (10.1.3).

Integration of ODI with SOA

ODI with SOA: Example 1
Product Call Web

Mgmt Process service.
(BPEL)
2 ODI Bulk Data

Service
1 Update data.
ODI
Operational Agent
database SQL
products
Data
3 warehouse
Finance Data Join
WS, XML 4
Service Discounts
(BPEL)
Oracle Data Integrator with SOA: Example 1

In this example, you see an ODI data load that is controlled by SOA processes and uses Web services
as well as databases as sources.
1. In this example, a business process in the product management department is changing data in
the product table of the operational database. This data needs to be propagated to the data
warehouse with minimal delay.
2. The process calls an ODI bulk data service to initiate a load based on the changes since the last
load.
3. The ODI Agent executes a scenario based on a package that first calls a data service from the
finance department to obtain price discount information.
4. Then, this service joins this information with the changed product data from the operational
database. The joined and transformed data is stored in the data warehouse.

Creating an ODI Error Hospital with BPEL Human Workflow

1. Develop an ODI XML to DB transformation using an
interface with ODI Constraint and CKM.
2. Develop a BPEL process for invoking ODI from SOA and
generating human workflow tasks.
3. Create an ODI package to execute interface and invoke
the Web service.
1 2
3

Creating an ODI Error Hospital That Uses BPEL Human Workflow
For enterprise SOA deployments, there is almost always a need for enterprise data extraction,
loading, transformation, and validation. By leveraging the native SOA architecture within ODI, you
can take advantage of ODI to perform the ELT. ODI provides the ability to validate data during the
load to the target using ODI constraints or database constraints. When this data is checked against a
constraint using Flow Control, any errors that are found are not loaded to the target but are loaded to
an errors table that is created and managed by ODI. Each row of this table represents a record that
did not pass a constraint; the row also has a message column that explains why the record was
rejected. This table can be edited within ODI Designer or any other tool that can edit relational
tables. However, this is not always a convenient way for the end user or business user to edit the data.
Any rows that do not pass the constraint will be loaded to the error table on the target database. The
ODI Scenario will be executed, and after the ODI ELT process is completed, the ODI Scenario will
then call back to a BPEL Web service to notify of any errors during the load. The BPEL process will
import the errors and manage them using BPEL Human Workflow tasks. A user can then use BPEL
Worklist to update bad records. On subsequent executions of the ODI Scenario, the updated records
are recycled into the ELT process. The records that pass the constraint are loaded into the target, and
the error record is in the error table.

Oracle Data Integrator with SOA: Example 2 (continued)
Since ODI manages the error table, you do not have to write any code to recycle the errors or to delete
the updated records when they are loaded successfully. Thus you have to implement the following
steps:
1. First you need to build an ODI Scenario that will validate data during the load to the target
using ODI constraints or database constraints. This ODI Scenario will then call back to a BPEL
Web service to notify of any errors during the load.
2. You need to create a BPEL process that will import the errors and create BPEL Human
Workflow tasks. A user can then use BPEL Worklist to update records that contain such errors.
3. Finally, you need to create an ODI package to execute the Interface and call Web service that
executes the BPEL process.

Example 2: Creating an ODI Error Hospital with
BPEL Human Workflow
1. Develop an ODI XML to DB transformation using an
interface with ODI constraint.
Example 2: Creating an ODI Error Hospital with BPEL Human Workflow

1. Create a model and set up an ODI constraint that you need to enforce.
2. Create a new interface to load the source XML file to the RDBMS target.

BPEL Human Workflow
1
3
Example 2: Creating an ODI Error Hospital with BPEL Human Workflow (continued)
Create the BPEL process that will import data errors from the error table. The BPEL process will
then create the Human Workflow Tasks from the error records. In the next steps, you will build a
new BPEL process to track the errors for each execution of the ODI package and present them to a
user for review. The user will be able to update each of the fields and correct any errors so that on the
next execution of the ODI package, the corrected rows are inserted into the target. In this example,
JDeveloper is the tool that you use to build the BPEL process and deploy it to the application server.
1. Create a New Project for the BPEL process.
2. Create and configure the connection to ODI data source.
3. Invoke database adapters to read errors and write error corrections back to the error table.

BPEL Human Workflow
4. Add Human Task to your BPEL process.
5. Configure the Human Task parameters.

BPEL Human Workflow
3. Deploy the BPEL process, create, and execute the ODI
package.
1. Deploy the BPEL process to Application server.
2. Create the ODI package to execute the interface and invoke the Web service.
3. Execute your ODI package.

BPEL Human Workflow
Monitor execution of the BPEL process and complete the
human task.
2
1
Monitor execution of the BPEL process from the BPEL console, and complete the human task:
1. Using Oracle BPM Worklist application, perform an action on the human task to correct errors.
2. Return to the BPEL Console page and refresh the browser. The process has now updated and
you see that it has progressed past the Error Hospital Human workflow activity. Click the
Invoke_Corrections activity to see the data that the error table has been updated with.
Note: You should now have a fully functional ODI to BPEL Human Workflow Error Hospital. If you
rerun your ODI Scenario now, the corrected errors are picked up and resubmitted to the target table.

Quiz
When you declare the Web services container as a data server

in the topology, you have to define one physical schema and
one logical schema for each context per Web services
container.
a. True
b. False
Answer: b
Explanation: You need to define only one physical schema per Web services container. On the
Context tab, you need to define one logical schema for each context in which you will deploy the
data services.

Quiz
If you have chosen to execute the scenario with the

synchronization mode equals 2, then:
a. The response is returned after the session is started
b. The response is returned after the session is completed
and the response reflects the execution result
c. The response is returned after the session is terminated
d. The response is never returned
Answer: a
Explanation: If the synchronization mode equals 2, you have chosen to execute the scenario in
asynchronous mode. In this case, the response is returned after the session is started. This means that
the response only reflects the fact that the session was correctly started.

Summary

• Identify the different types of Web services
• Generate, deploy, and test data services
• Use public Web services with ODI
• Configure data services
• Install and use public Web services
• Execute a scenario using public Web services
• Invoke a public Web service using the
OdiInvokeWebService tool
• Implement integration of ODI with SOA

Oracle ODI 12c Student Guide 2

Uploaded by

Copyright:

Available Formats

You might also like

Oracle ODI 12c Student Guide 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle ODI 12c Student Guide 2

Uploaded by

Copyright:

Available Formats

Oracle Data Integrator:

Administration and Development

Phillip Scott Trademark Notice

2 Administering ODI Repositories and Agents

3 ODI Topology Concepts

4 Describing the Physical and Logical Architecture

5 Setting Up a New Project

6 Oracle Data Integrator Model Concepts

7 Organizing ODI Models and Creating Datastores

8 ODI Interface Concepts

10 Interfaces: Monitoring and Debugging

11 Designing Interfaces: Advanced Topics

12 Using ODI procedures

13 Using ODI Packages

14 Managing ODI Scenarios and Versions

16 Working with Changed Data Capture

17 Administering ODI Resources: Advanced Topics

Appendix A: Practices and Solutions

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

After completing this lesson, you should be able to:

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

Oracle Data Integrator: Administration and Development 13 - 2

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

Oracle Data Integrator: Administration and Development 13 - 3

• A package is an organized sequence of steps that makes

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

Oracle Data Integrator: Administration and Development 13 - 4

1. Create and name a blank package.

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

How to Create a Package

Oracle Data Integrator: Administration and Development 13 - 5

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

1. Creating and Naming a Package

Oracle Data Integrator: Administration and Development 13 - 6

1. Navigate to the project and folder where you want to

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

How to Create and Name a Package

Oracle Data Integrator: Administration and Development 13 - 7

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

Oracle Data Integrator: Administration and Development 13 - 8

Hide/show Execute package

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

Package Diagram Toolbar

Oracle Data Integrator: Administration and Development 13 - 9

Oracle Data Integrator: Administration and Development 13 - 10

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

2. Adding Steps to the Package

Oracle Data Integrator: Administration and Development 13 - 11

• The two most common package steps are:

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

Oracle Data Integrator: Administration and Development 13 - 12

1. Expand the project and folder

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

How to Create an Interface Step

Oracle Data Integrator: Administration and Development 13 - 13

• ODI tools are macros that provide useful functions to

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

What Is an ODI Tool?

Oracle Data Integrator: Administration and Development 13 - 14