The document outlines the steps for migrating an Oracle Warehouse Builder (OWB) project to Oracle Data Integrator (ODI). The 5-step process includes: 1) Assessment to analyze the OWB project and define conversion criteria, 2) Conversion of OWB mappings and flows to ODI, 3) Acceptance testing in a test environment, 4) Pre-production testing, and 5) Going live in production. Key tasks involve generating conversion reports, deciding on the ODI topology and configuration, automatically converting OWB components in D&T's center, testing, and tuning performance. The goal is to validate the converted ODI project before replacing the OWB system.
Database & Technology has developed a solution known as the OWB2ODI Converter to reduce the times and costs for migrating from Oracle Warehouse Builder to Oracle Data Integrator to a minimum.
The OWB2ODI Converter is a semi-automatic tool for converting OWB projects into ODI projects. The tool was specifically designed to recreate the logic implemented in the OWB project in the new logic of the ODI project, while keeping the semantics and functions implemented in the initial project unchanged.
Tests carried out on company projects showed that the time required for migration was drastically reduced by using the OWB2ODI Converter.
After a careful analysis of the results, it became clear that the benefits gained from using the OWB2ODI Converter tool, rather than manual conversion, increase in proportion to the size and complexity of the project.
What Oracle Warehouse Builder to Oracle Data Integrator migration service consists of and how it's carried out.
Hear about all the benefits it generates for companies.
The Time is Now! Migrating from OWB to ODI 12cStewart Bryson
Prior to the introduction of Data Integrator (ODI), Oracle had another data integration tool: Warehouse Builder (OWB). Usually positioned as an ETL tool, OWB excelled in environments with a strong footprint in the Oracle Database. Oracle's statement of direction has been clear: to deliver a unified data integration platform, combining the best from both tools into a true world class product. With ODI 12c, that day has arrived.
In this presentation, I’ll demonstrate the features available for migrating from OWB to ODI 12c. I’ll also describe a phased approach for doing a “right-time” conversion to ODI 12c, which involves migrating bite-sized chunks of OWB processes over to ODI when that migration adds legitimate value for the customer.
It is the fact that Oracle Warehouse Builder (OWB) released the latest major version and final state. But business requirements are rapidly increasing. New applications are implemented in source systems and as a result new reports and new subject areas are needed urgently. It is needed to implement new features for growing business needs into our data warehouses. Resources are limited and conversion should be done as soon as possible.
In this presentation, see the most convenient methods to migrate from Oracle Warehouse Builder to Oracle Data Integrator with agile methodology without interrupting on going daily jobs as well as understanding of Oracle's OWB2ODI migration utility.
The Time is Now: Migrating from Oracle Warehouse Builder to Oracle Data Integ...Stewart Bryson
Prior to the introduction of Data Integrator (ODI), Oracle had another data integration tool: Warehouse Builder (OWB). Usually positioned as an ETL tool, OWB excelled in environments with a strong footprint in the Oracle Database. Oracle's statement of direction has been clear: to deliver a unified data integration platform, combining the best from both tools into a true world class product. With ODI 12c, that day has arrived.
In this presentation, I’ll demonstrate the features available for migrating from OWB to ODI 12c. I’ll also describe a phased approach for doing a “right-time” conversion to ODI 12c, which involves migrating bite-sized chunks of OWB processes over to ODI when that migration adds legitimate value for the customer.
Oracle Warehouse Builder to Oracle Data Integrator 12c Migration UtilityNoel Sidebotham
As Oracle Warehouse builder nears the end of extended support; customers need to consider their migration options.
In this webex we'll be discussing this topic and aim to answer questions like Which tool should I use for new projects? What should be done with existing implementations? And why should I migrate to ODI?
In this session You will learn about –
• Oracle Data Integrator 12c, concepts and features
• The OWB2ODI migration utility
• How to successfully migrate OWB projects to ODI
• You will hear about customer success stories
• New features of ODI 12c that are getting ETL developers excited including Big Data and Hybrid Cloud support.
Database & Technology has developed a solution known as the OWB2ODI Converter to reduce the times and costs for migrating from Oracle Warehouse Builder to Oracle Data Integrator to a minimum.
The OWB2ODI Converter is a semi-automatic tool for converting OWB projects into ODI projects. The tool was specifically designed to recreate the logic implemented in the OWB project in the new logic of the ODI project, while keeping the semantics and functions implemented in the initial project unchanged.
Tests carried out on company projects showed that the time required for migration was drastically reduced by using the OWB2ODI Converter.
After a careful analysis of the results, it became clear that the benefits gained from using the OWB2ODI Converter tool, rather than manual conversion, increase in proportion to the size and complexity of the project.
What Oracle Warehouse Builder to Oracle Data Integrator migration service consists of and how it's carried out.
Hear about all the benefits it generates for companies.
The Time is Now! Migrating from OWB to ODI 12cStewart Bryson
Prior to the introduction of Data Integrator (ODI), Oracle had another data integration tool: Warehouse Builder (OWB). Usually positioned as an ETL tool, OWB excelled in environments with a strong footprint in the Oracle Database. Oracle's statement of direction has been clear: to deliver a unified data integration platform, combining the best from both tools into a true world class product. With ODI 12c, that day has arrived.
In this presentation, I’ll demonstrate the features available for migrating from OWB to ODI 12c. I’ll also describe a phased approach for doing a “right-time” conversion to ODI 12c, which involves migrating bite-sized chunks of OWB processes over to ODI when that migration adds legitimate value for the customer.
It is the fact that Oracle Warehouse Builder (OWB) released the latest major version and final state. But business requirements are rapidly increasing. New applications are implemented in source systems and as a result new reports and new subject areas are needed urgently. It is needed to implement new features for growing business needs into our data warehouses. Resources are limited and conversion should be done as soon as possible.
In this presentation, see the most convenient methods to migrate from Oracle Warehouse Builder to Oracle Data Integrator with agile methodology without interrupting on going daily jobs as well as understanding of Oracle's OWB2ODI migration utility.
The Time is Now: Migrating from Oracle Warehouse Builder to Oracle Data Integ...Stewart Bryson
Prior to the introduction of Data Integrator (ODI), Oracle had another data integration tool: Warehouse Builder (OWB). Usually positioned as an ETL tool, OWB excelled in environments with a strong footprint in the Oracle Database. Oracle's statement of direction has been clear: to deliver a unified data integration platform, combining the best from both tools into a true world class product. With ODI 12c, that day has arrived.
In this presentation, I’ll demonstrate the features available for migrating from OWB to ODI 12c. I’ll also describe a phased approach for doing a “right-time” conversion to ODI 12c, which involves migrating bite-sized chunks of OWB processes over to ODI when that migration adds legitimate value for the customer.
Oracle Warehouse Builder to Oracle Data Integrator 12c Migration UtilityNoel Sidebotham
As Oracle Warehouse builder nears the end of extended support; customers need to consider their migration options.
In this webex we'll be discussing this topic and aim to answer questions like Which tool should I use for new projects? What should be done with existing implementations? And why should I migrate to ODI?
In this session You will learn about –
• Oracle Data Integrator 12c, concepts and features
• The OWB2ODI migration utility
• How to successfully migrate OWB projects to ODI
• You will hear about customer success stories
• New features of ODI 12c that are getting ETL developers excited including Big Data and Hybrid Cloud support.
UKOUG Tech 15 - Migration from Oracle Warehouse Builder to Oracle Data Integr...Jérôme Françoisse
Oracle Data Integrator is the strategic Data Integration tool replacing Oracle Warehouse Builder, offering more flexibility and supporting more technologies. Based on the Eurocontrol – the European Organisation for the Safety of Air Navigation – story, we will review a migration from Oracle Warehouse Builder to Oracle Data Integrator using the migration utility and custom scripting. After looking at the roadmap and the architecture used, we will see how to automatically migrate supported components how to handle the remaining ones and what needs to be fine-tuned. Finally we will talk about the testing, the challenges, the risks and the lessons learnt so you will be ready to successfully achieve such a migration for your company.
Oracle JavaScript Extension Toolkit Web Components Bring Agility to App Devel...Lucas Jellema
In this slidedeck learn how Oracle JavaScript Extension Toolkit web components enable a higher level of productivity, agility, and maintainability of rich client web applications. The reusable components can be shared across pages, applications, and teams—and even across the global community. The components can be developed separately from the applications that consume them and can be deployed and updated independently. They are also well-suited to be used as the user interface for a microservice that is mashed up in a larger web application or portal. Learn the why and how of Oracle JavaScript Extension Toolkit web components, tooling to use for productivity and agility, and a proven approach for microservice UI implementation.
Maintenance Plans for Beginners | Each of experienced administrators used (to some extent) what is called Maintenance Plans - Plans of Conservation. During this session, I'd like to discuss what can be useful for us to provide functionality when we use them and what to look out for. Session at 200 times the forward-300, with the opening of the discussion.
Oracle Data Integrator 12c - Getting StartedMichael Rainey
I think it’s time for a fresh look at Oracle Data Integrator 12c. What is ODI? How has it evolved over the years and where is it going? And, of course, how do you get started with Oracle Data Integrator? I plan to share what I love about ODI, how to get started building your first ODI project, and what makes Oracle Data Integrator 12c the premier ETL and data warehousing tool on the market. It’s time to get back to the basics!
Presented at UTOUG Training Days 2017.
How to Handle DEV&TEST&PROD for Oracle Data IntegratorGurcan Orhan
Most of us have development teams apart from test and operation teams using the different repository environments. And there are generally 3 different ODI installations and repositories which each of the teams use separately. Chaos is usually expected and happened who will test which development and what to deploy into production.
In this session hear how ODI can handle your development hierarchy with ease of usage and in simplified/synchronized way for successful deployments.
A simple project will be built up and will be enlarged to enterprise level step by step.
JDBC Next: A New Asynchronous API for Connecting to a Database Yolande Poirier
This new API is completely nonblocking. It is not intended to be an extension to, or a replacement for, JDBC but, rather, an entirely separate API that provides completely nonblocking access to the same databases as JDBC.
My OOW13 presentation around Oracle Enterprise Manager 12c, Oracle Database 12c, and You. This presentation explains what manageability is there for DB12c in OEM12c.
UKOUG Tech 15 - Migration from Oracle Warehouse Builder to Oracle Data Integr...Jérôme Françoisse
Oracle Data Integrator is the strategic Data Integration tool replacing Oracle Warehouse Builder, offering more flexibility and supporting more technologies. Based on the Eurocontrol – the European Organisation for the Safety of Air Navigation – story, we will review a migration from Oracle Warehouse Builder to Oracle Data Integrator using the migration utility and custom scripting. After looking at the roadmap and the architecture used, we will see how to automatically migrate supported components how to handle the remaining ones and what needs to be fine-tuned. Finally we will talk about the testing, the challenges, the risks and the lessons learnt so you will be ready to successfully achieve such a migration for your company.
Oracle JavaScript Extension Toolkit Web Components Bring Agility to App Devel...Lucas Jellema
In this slidedeck learn how Oracle JavaScript Extension Toolkit web components enable a higher level of productivity, agility, and maintainability of rich client web applications. The reusable components can be shared across pages, applications, and teams—and even across the global community. The components can be developed separately from the applications that consume them and can be deployed and updated independently. They are also well-suited to be used as the user interface for a microservice that is mashed up in a larger web application or portal. Learn the why and how of Oracle JavaScript Extension Toolkit web components, tooling to use for productivity and agility, and a proven approach for microservice UI implementation.
Maintenance Plans for Beginners | Each of experienced administrators used (to some extent) what is called Maintenance Plans - Plans of Conservation. During this session, I'd like to discuss what can be useful for us to provide functionality when we use them and what to look out for. Session at 200 times the forward-300, with the opening of the discussion.
Oracle Data Integrator 12c - Getting StartedMichael Rainey
I think it’s time for a fresh look at Oracle Data Integrator 12c. What is ODI? How has it evolved over the years and where is it going? And, of course, how do you get started with Oracle Data Integrator? I plan to share what I love about ODI, how to get started building your first ODI project, and what makes Oracle Data Integrator 12c the premier ETL and data warehousing tool on the market. It’s time to get back to the basics!
Presented at UTOUG Training Days 2017.
How to Handle DEV&TEST&PROD for Oracle Data IntegratorGurcan Orhan
Most of us have development teams apart from test and operation teams using the different repository environments. And there are generally 3 different ODI installations and repositories which each of the teams use separately. Chaos is usually expected and happened who will test which development and what to deploy into production.
In this session hear how ODI can handle your development hierarchy with ease of usage and in simplified/synchronized way for successful deployments.
A simple project will be built up and will be enlarged to enterprise level step by step.
JDBC Next: A New Asynchronous API for Connecting to a Database Yolande Poirier
This new API is completely nonblocking. It is not intended to be an extension to, or a replacement for, JDBC but, rather, an entirely separate API that provides completely nonblocking access to the same databases as JDBC.
My OOW13 presentation around Oracle Enterprise Manager 12c, Oracle Database 12c, and You. This presentation explains what manageability is there for DB12c in OEM12c.
Migration of Two Million Records with Zero Downtime for a Global Financial Or...Kovair
Download link - https://www.kovair.com/case-studies/migration-of-two-million-records-with-zero-downtime/
A major global financial organization in Washington D. C., USA were using Microfocus ALM to manage their requirements and QA activities. Based on organization-wide changes in their internal software development processes and policies, customers decided to move from Microfocus ALM to Microsoft Azure DevOps Server. This raised the need for migrating the existing data of Microfocus ALM to Azure DevOps to streamline the organization-level process. Moreover, some of the bigger groups like PLM and the International Finance team used Azure DevOps for internal processes. Thus, consolidation of data into Azure DevOps became a necessary approach. The organizations maintain their releases and deployments through the Azure DevOps pipeline. For migrating over 2.2 million records from Microfocus ALM to Azure DevOps, initially, the customer approached a very large reputable Services company which eventually failed to perform the migration successfully. After that, this project was assigned to Kovair.
Implementing Oracle E-Business suite for Tesla motor company .docxAASTHA76
< Implementing Oracle E-Business suite for Tesla motor company >
<PMGT 699-92- O-2019/Spring - Applied Project Management >
Prepared By
<Govind Rao Kurupathi>
<2/10/2019>
1. Executive Summary
1.1 ..Introduction………………………………………………………………………
1.2 .. Purpose………………………………………………………………………….
1.3 .. Scope……………………………………………………………………………
2. Project Overview
2.1Project Description
2.2Problem Statement
2.3Goals
2.4Project Background
2.5Product Objectives
2.6 ..Business Objectives……………………………………………………………..
2.7 ..Milestones……………………………………………………………………….
2.8Assumptions, Constraints and Dependencies
2.9Project Deliverables
2.10.. Project Success Criteria ………………………………………………………..
2.11..Schedule and Budget Summary
2.12..Evolution of the Plan
2.13..References
2.14Definitions and Acronyms
3. Stakeholder Register
4. Schedule
4.1 ..Purpose/Overview………………………………………………………………..
4.2 ..Schedule Baseline……………………………………………………………….
4.3 .. Schedule Control…………………………………………………………………
5. Resource Plan
5.1 .. Overview/Purpose of the Resource Section ……………………………………
5.2 ..Resourcing Strategy & Assumptions….………………………………………….
5.3 .. Resourcing Development………………………………………………………..
6. Risk Management Plan
6.1 .. Purpose/Overview………………………………………………………………
6.2 .. Risk Identification………………………………………………………………
6.3 ..Risk Analysis……………………………………………………………………
6.4 Risk Monitoring Plan …………………………………………………………….
7. Communications Plan
7.1..Overview
7.2..Communication Message and Delivery
7.3..Communications Guidelines
7.4.. Escalation Process
8. Procurement
9. Cost
9.1..Introduction
9.2.. Estimate Cost
9.3..Contingency reserve project purpose or justification
9.4..Budget
9.5..Project and Monitoring
9.6.. Project Reports
9.7..Cost Change Control
9.8..Project Budget
9.9..Microsoft Performance Report #1
9.10..Microsoft Performance Report #2
10. Integrated Change Control
1.Executive Summary Introduction
Tesla, Inc. is an American automotive and energy company based in Palo Alto, California. The company specializes in electric car manufacturing and, through its SolarCity subsidiary, solar panel manufacturing.
Real Tech Inc is an Oracle implementation specialist and an Oracle platinum partner. Tesla has awarded Real Tech Inc to implement the e-business suite of applications in its headquarters situated in Freemont, California. The suite of applications contains modules like Inventory management, Order management, Discrete manufacturing (Work In the process, Bills of materials) and financial modules (Accounts payable, receivable, Fixed assets and general ledger). The duration of the project is estimated to be 1 year (on the higher side). The team consists of 6 functional consultants, one database administrator, one Project Manager, one ERP practice head.
1.1 Purpose
The purpo.
Odoo Migration Services from Pragmatic: Helps your Business become more Effic...NajmuddinMerchant
Read More >> https://blog.pragtech.co.in/odoo-migration
Important as it may, migrating your old Odoo versions to the newer and better ones is quite a tedious and complex task. One misstep and it can cascade to disrupt the whole framework.
This is why having a good Odoo migration company by your side is so important. And this is why hundreds of businesses entrust us for Odoo migration.
As one of the growing Odoo ERP companies, Pragmatic Techsoft is here to help you migrate from Odoo old versions to a new and better version. Not just Odoo, we can help you to migrate from your legacy ERP to Odoo ERP as well.
MS Office install has required the removal of the previously installed version of your Office product on the device or system. Office 365 and other subscription offers the various features, which you do not get when you do not purchase the Office product. The office can be used free, as MS provides the trial versions of every tool. VISIT HERE: Office setup TODAY.
Migrating from oracle soa suite to microservices on kubernetesKonveyor Community
Watch presentation recording: https://youtu.be/cxH6WjDZc2c
In this session, we’ll explore how Randoli helped a Postal Technology company migrate their payment gateway applications off Oracle SOA Suite to Camel/Springboot on Kubernetes.
The primary drivers for the migration were: move to cloud-native technologies in keeping with the organizational digital transformation mandate; move away from an outdated centralized platform to a decentralized architecture for efficiency, scalability, and manageability; and very high licensing costs of the existing platform.
We’ll discuss:
- The high-level approach we took during the migration including architecture and design decisions.
- How we used Camel/Springboot to implement the services.
- Why and how we used Drools for implementing business rules.
- The test-driven approach using Camel testing framework and how it helped reduce issues.
- CI/CD and build process on Kubernetes.
- How we tackled logging, monitoring, and tracing challenges.
Presenter: Rajith Attapattu, Managing Partner & CTO @ Randoli Inc.
MV2ADB - Move to Oracle Autonomous Database in One-clickRuggero Citton
Move to Autonomous Database (MV2ADB) is a new tool is permitting the load data and migration from “on premises” to Autonomous Database Cloud leveraging on Oracle Data Pump and within one command. You can save your data to your Cloud Object Store and to load them to Autonomous Database Cloud using “mv2adb”.
Similar to Migration-service-from-OWB-to-ODI-D&T (20)
2. 2 OWB to ODI migration service
Table of contents
The Conversion Process in Five Steps...............................................................................................4
Step 1: Assessment......................................................................................................................4
Task 1 – Generate a Conversion Assessment and Statistics Report..................................5
Task 2 – Decide on exceptions handling..............................................................................6
Task 3 – Define the topology.................................................................................................6
Task 4 – Compare the possible conversion modes.............................................................7
Task 5 – Define the Knowledge Modules..............................................................................7
Task 6 – Decide on configuration management..................................................................8
Step 2: Conversion.......................................................................................................................8
Task 7 – Convert the OWB Mappings and OWB Process Flows...........................................9
Task 8 – Execute formal tests.............................................................................................11
Task 9 – Generate the ODI project’s metadata..................................................................11
Step 3: Acceptance Test.............................................................................................................11
Task 10 – Set up the ODI Test Environment.......................................................................12
Task 11 – Execute acceptance tests...................................................................................12
Task 12 – Tune the new ODI project’s performance..........................................................12
Step 4: Pre-production Test......................................................................................................12
Task 13 – Set up the (parallel) ODI Production Environment...........................................13
Task 14 – Execute additional verification tests.................................................................13
Task 15 – Verify the performance.......................................................................................13
Step 5: Production.....................................................................................................................14
Task 16 – Clean up the Production Environment..............................................................14
Task 17 – Switch from OWB to ODI.....................................................................................14
Summary...........................................................................................................................................15
For more information.......................................................................................................................15
3. 3OWB to ODI migration service
Management Summary
In its latest Statement of Direction, Oracle
announced that OWB would not be supported
anymore beyond release 12 of the Oracle data-
base. Therefore, all OWB installations need to be
migrated before 2017.
Read the Statement on the Oracle website.
Oracle Data Integrator (ODI) is Oracle’s new
strategic product for high-performance, flex-
ible and heterogeneous data integration.
The main benefit of a conversion to ODI, is that the basic
OWB functionality remains available in ODI. So, by migrat-
ing your OWB project to ODI, you won’t lose your previous
investments in OWB.
Tomakesurethatthisconversionprocessrunsassmoothly
as possible, with a minimum of manual intervention, D&T
(Data & Technology) offers a complete OWB to ODI conver-
sion service using its intelligently automated OWB2ODI
conversion tool.
After an initial analysis of your OWB .mdl export file and
a joint assessment meeting, the OWB project, including
its metadata, will be converted to ODI, tested at D&T’s
Services Centre, customized where required, tested in
your own environment and, finally, successfully rolled out
to production.
Our service is fast and complete, and works for all OWB
and ODI versions as well as for all O/S platforms. It includes
the migration, the reworking and the customization of the
OWB mappings and process flows in ODI, for a fixed time-
frame and a fixed price.
In the remaining of this document, we will describe more
in detail the different steps of the conversion process.
4. 4 OWB to ODI migration service
The Conversion Process in Five Steps
The conversion process is split up into 5 main steps:
Before we can start we need the client to provide us with an OWB .mdl file export. This .mdl file export must contain all
project Locations, the Configuration (if it is different from default), all mappings and process flows in validated state,
and all dependencies.
Step 1: Assessment
The objective of this first step is to define the project’s framework, to evaluate the consistency of the original OWB
project and to define the conversion criteria. This step can be subdivided into the following tasks:
Task 1: Generate a Conversion Assessment and Statistics Report
Task 2: Decide on exceptions handling
Task 3: Define the topology
Task 4: Compare the possible conversion modes
Task 5: Define the Knowledge Modules (KM)
Task 6: Decide on configuration management
1 2 3 4 5
Oracle Data IntegratorOracle Warehouse Builder
Assessment Conversion Acceptance
test
Pre-production
test
Production
5. 5OWB to ODI migration service
Task 1 – Generate a Conversion Assessment and Statistics Report
The Conversion Analyzer will use the provided .mdl file to perform a series of operations.
First of all, it will analyze whether there are any special operators for which essential customizations are required. For
example, in ODI 11g consider the case of the splitter operator that allows the flow to direct itself towards several targets
in the same mapping. This operator has to be carefully managed because the Oracle Data Integrator does not allow a
mapping flow to end in multiple targets. In this case, it generates as many interfaces as the Oracle Warehouse Builder
operator targets. Note that ODI 12c does not have this problem.
Next, it will analyze each mapping, starting from the target operator and ending on the leftmost operator, ensuring the
entire mapping structure and its related operators remain unchanged. When the analysis is finished, the Conversion
Analyzer will generate a report on the OWB process flows and mappings.
TOP: Process flow report, BOTTOM: Mappings report
6. 6 OWB to ODI migration service
After the generation of the report, D&T will set up a meeting with the client to discuss the generated Conversion
Assessment and Statistics Report. Together, they will perform tasks 2 and 6 concerning the procedural and managerial
decisions.
During this meeting, the client and D&T will also compile the “Roles and Responsibilities Matrix” for each task within the
conversion process. Tasks 2 to 6 cover the different decisions that need to be taken.
Task 2 – Decide on exceptions handling
This task is dedicated to deciding on how to manage (work-around or manual conversion) any possible case that cannot
be automatically converted to ODI using the OWB2ODI Converter
For example, a particular OWB operator in a mapping, a particular OWB activity or a particular transition condition in a
process flow, or an external workflow layer (not in OWB) used to execute the OWB project’s components.
These are extremely rare contingencies, as most OWB components will be automatically converted.
Task 3 – Define the topology
In ODI, the definition of the topology, the logical architecture, and the physical architecture are necessary to indicate
where the data are physically located.
The OWB2ODI Converter will analyze the OWB Repository Metadata to collect the following information: the technology,
the machine where the data is located, and the database schema and/or file metadata.
ODI was developed to operate with any database technologies available (Oracle, DB2, Teradata, SQL Server, and many
others). ODI provides the ability to refer to a database schema/user by its logical form. The logical user or logical schema
is an abstract reference to a physical schema, which is defined within ODI as a real user in a specific database technology.
Logical schemas and physical schemas are related through contexts. For example, the BUDGET logical schema may
be associated with the BUDGET physical schema in the ORCL database through the CTX_BUDGET_ORCL context, etc.
All this is configured in ODI’s topology section, which contains all the information needed to switch between the logical
and physical side.
The OWB2ODI Converter only works on logical schemas because the pointers to physical schemas are configured in the
topology, and the context is assigned either at runtime or when “conversions” are executed. The result of that process
shows how easy it is to generate a technology-independent code. As long as the right context is set up, everything will
work properly.
Note: a logical schema is always associated with its own technology, although it can be easily moved to another one by
deleting it from the old platform and building it on the new one.
This meeting and the decisions taken are essential for the success of the conversion. They are the foun-
dation upon which the entire conversion project will be built.
7. 7OWB to ODI migration service
Task 4 – Compare the possible conversion modes
This task is dedicated to providing the client with a detailed explanation of the conversion mode of every OWB
component.
The OWB2ODI Converter can convert the following:
• For ODI 11g: OWB mappings into ODI interfaces and ODI packages
• For ODI 12c: OWB mappings into ODI mappings and ODI packages
• OWB process flows logic into ODI native tools, ODI packages, ODI procedures and ODI load plans (available since
ODI v.11.1.1.5).
Task 5 – Define the Knowledge Modules
ODI’s capabilities to handle any RDBMSs are represented by its Knowledge Modules (KMs).
The OWB2ODI Converter has a specific console to set parameters and options related to the use of these KMs. This is a
very important task, as the correct definition of these KMs will affect the performance of the ODI project.
The following example shows how the OWB2ODI Converter can be customized in order to choose the KMs best suited
to your technology and needs.
Customized KMs can also manage other aspects such as: ANALYZE on target table, the maximum number of allowable
errors on target table, loading HINT, selecting HINT, …
Knowledge Module Source Tech Target Tech Type of loading
Default Operating
Mode
Oracle SQLLDR ORACLE ORACLE INSERT SET BASED
Oracle Incremental
Update
ORACLE ORACLE UPDATE SET BASED
D&T Custom KM ORACLE ORACLE INSERT/UPDATE SET BASED
DSNTIAUL DB2 DB2 TRUNCATE/INSERT SET BASED
Client Custom KM DB2 DB2 INSERT/UPDATE SET BASED
FAIL OVER
ROW BASED
… … … … …
Example of a customized KMs selection grid
8. 8 OWB to ODI migration service
Task 6 – Decide on configuration management
The last subtask of this step, but certainly not the least important one, is to decide on the operative protocol to be
applied during the conversion period.
To obtain best results, it would be opportune to freeze any maintenance activity on the OWB project to be converted.
The ideal scenario would be to:
• roll out every OWB project undergoing modification into the client’s production environment,
• align each of the client’s environment (development, test and production), and
• freeze any maintenance activity.
The client has to decide if freezing maintenance activity is possible or not. If not, D&T needs to know how the client
intends to execute configuration management of the OWB project to be converted.
Also during this task, the “fixing protocol”, which is the management process (roles, responsibilities, actions, etc.)
needed to fix any bugs identified during the acceptance test task, must be defined.
Step 2: Conversion
The second step is the actual conversion step. The objective of this step is to convert the original OWB project into a new
ODI project and to generate the new ODI project’s metadata to be imported into the client’s ODI repository.
This step can be subdivided into the following tasks:
Task 7: Convert the OWB Mappings and OWB Process Flows
Task 8: Execute formal tests
Task 9: Generate the ODI project’s metadata
9. 9OWB to ODI migration service
Task 7 – Convert the OWB Mappings and OWB Process Flows
This is the core task of the entire conversion process and it is executed by D&T’s Services Centre.
Before starting the task, the following should be carried out:
• supply a definitive .mdl file aligned with the latest OWB project version,
• supply a DB schema export aligned with the latest OWB project version, and
• freeze any maintenance activity related to the OWB project to be converted.
Based upon the decisions taken concerning the topology (Task 3 “Topology definition”), D&T’s Services Centre will carry
out the ODI topology setting in its internal conversion environment.
Next, all mappings will be analyzed and a first transformation will be applied whenever specific operators are found.
This is an essential process in order to guarantee the proper functioning of the new Oracle Data Integrator flow, while
keeping the semantic flow unchanged.
This task is performed automatically by the OWB2ODI Converter. Carrying out this process manually, would not only be
costly and time-consuming, but also the risk of introducing new mistakes due to haste or technical misunderstandings
would be very high.
Once the additional mappings are “normalized”, recursive techniques are used to generate the operator’s tree of each
mapping. The tree is redrawn and each operator involved is transformed according to the new Oracle Data Integrator
semantic. The correct topological information is maintained, taking into account the possible overruling of the location
using a database of links or different schemas.
From a conceptual point of view, OWB and ODI are similar, but they do not have equivalent features and have profound
and significant differences. Therefore, the OWB2ODI Converter does not handle some of the OWB components because
they are rarely used, because they do not have a corresponding ODI function or because the conversion would be too
complex, ineffective or inefficient.
The following table indicates which OWB components are automatically converted by the OWB2ODI Converter and
which ones need to be converted manually.
OWB mapping: converted operators
Aggregator Joiner Sorter
Constant Mapping input/output parameter Mapping Splitter
Deduplicator (Distinct) Match-Merge Table
Expression Materialized View Transformation
External Table Pivot/Unpivot View
Filter Pre/Post mapping process Anydata Cast (since 11.1)
Flat File (File multi-record) Sequence
Key Lookup Set Operation Table Function
10. 10 OWB to ODI migration service
Since ODI does not have a “warning status”, the OWB “warning transition condition” is handled depending on each
client’s specific needs. This is a possible topic to be covered in the assessment meeting.
The OWB “Fork activity” is converted by using the ODI “Load plan” feature that is only available from ODI v.11.1.1.5
onwards. Therefore, in order to manage and convert all of the most used and useful activities in the Process Flow, we
need an ODI version that is equal or greater than ODI v.11.1.1.5.
OWB mapping: unhandled operators
Dimension Expand object Pluggable mapping
Cube Varray iterator Queue (11.2)
Construct Name and address Subquery filter (11.2)
Data generator LCR cast/splitter (11.2)
OWB process flow: converted activities
Data auditor FTP And / Or
Mapping Manual End
Subprocess Notification End Loop
Transform Set status For Loop
Assign SQLplus While Loop
Email User-defined Fork
File Exists Wait Route
OWB process flow: converted transition conditions
Success Error Complex
OWB process flow: unhandled activities
Web services (11.2) EJB / Java class (11.2) OMB plus (11.2)
OWB process flow: unhandled transition conditions
Warning* Extended
11. 11OWB to ODI migration service
Task 8 – Execute formal tests
When the conversion is done, the first formal non-regression tests are executed at D&T’s Services Centre on empty data
structures. At this stage, the test only concerns the format correctness of the new ODI project, as no data are available
for a real test run.
Task 9 – Generate the ODI project’s metadata
The last task of the conversion step is dedicated to the generation of the new ODI project’s metadata. These metadata
will be included in the .xml files that will be delivered to the client.
Step 3: Acceptance Test
Once everything has been tested successfully at D&T’s, it is time to test the ODI mappings and load plan in the cli-
ent’s Test Environment. The objective of this step is to compare the results of the new ODI project results (in the Test
Environment) with the results of the current OWB project (in the Production Environment) and to fine-tune the new ODI
project’s performances.
This step can be subdivided into the following tasks:
Task 10: Set up the ODI Test Environment
Task 11: Execute acceptance tests
Task 12: Tune the new ODI project’s performance
12. 12 OWB to ODI migration service
Task 10 – Set up the ODI Test Environment
First the Test Environment needs to be set up. This includes:
• installing the OWB product,
• installing the ODI product,
• copying the OWB project’s components,
• importing the .xml files supplied by D&T’s Services Centre into the ODI repository, and
• copying the production databases twice: one copy for the OWB project and another copy for the ODI project.
Task 11 – Execute acceptance tests
Next, the ODI project will be tested to ensure that there are no regression issues.
Concretely, a complete parallel run of the two projects will be executed and, next, the respective results will be com-
pared to verify their matching. Each incorrect result will be investigated to determine the relative causes.
The “fixing protocol” established during the initial assessment meeting (Task 6 of the Assessment step) will be applied
for each problem detected.
Task 12 – Tune the new ODI project’s performance
The last task of this Acceptance Test step consists in fine-tuning the ODI project’s performances in collaboration with
the client’s Database Administrator.
Step 4: Pre-production Test
If the tests in the Test Environment are successful, we will start the tests in a Pre-Production Environment.
The objective of this step is to ensure the same level of correctness in the Production Environment as in the Test
Environment.
Also, the ODI project performances (in the Pre-production Environment) will be once again compared with the original
OWB project (in Production environment). If required, additional fine-tuning will be done.
This step can be subdivided into the following tasks:
Task 13: Set up the (parallel) ODI Production Environment
Task 14: Execute additional verification tests
Task 15: Verify the performance
13. 13OWB to ODI migration service
Task 13 – Set up the (parallel) ODI Production Environment
During this task, a parallel Pre-production Environment is set up.
Task 14 – Execute additional verification tests
Theoretically, this is a redundant step. However, experience teaches us that a parallel production run must be carried
out in order to locate any possible problems that may affect the production environment (configuration, privileges,
missing patches, etc.).
The outcome results of the two projects are compared once again.
Task 15 – Verify the performance
Theoretically, this is also a redundant task. But here again, experience teaches us that it is a good idea to also compare
once again the performances.
14. 14 OWB to ODI migration service
Step 5: Production
In this final step, the original OWB project and its dependencies (OWB installation, DB schema, etc.) will be removed
from the Production environment, and the scheduling tool will be switched from the original OWB project to the new
ODI project.
This step can be subdivided into the following tasks:
Task 16: Clean the production environment
Task 17: Switch from OWB to ODI
Task 16 – Clean up the Production Environment
The cleaning consists of deinstalling OWB, deleting the DB schema and removing any other software components that
are unnecessary to run the new ODI project.
Task 17 – Switch from OWB to ODI
Finally, the last task in the conversion process consists of physically switching from the old OWB project to the new ODI
project.