Convergence of Oracle Data Integration and Oracle Warehouse Builder improves speed and execution

Oracle’s convergence of its Data Integrator and Warehouse Builder is making things easier and smoother for users. Now you can combine previous OWB processes with ODI design for new steps in a data warehouse, as well as migrate your OWB work for further commissioning to use only ODI, or you can continue using OWB for your current projects.

The realignment was completed with the release of OWB 11g Release 2 and ODI 12c. Two new benefits of this convergence include:

  1. A more visual declarative design approach based on reusable code templates.
  2. A clear migration path from OWB to ODI.

Now users can do a quick and simple migration from OWB to ODI 12c. (See Figure 1)

xbi-blog-aleksei-image-1-png-pagespeed-ic-hnqhm5-bqf

Figure 1

Declarative design approach is getting better

In ODI 12c, Oracle has introduced “Declarative Flow-Based User Interface”. This means you can now create data flows (interfaces were re-named to mappings) that combine two approaches: the visual approach of Mappings and Operators that we already know from OWB, and the powerful declarative design approach users really like in ODI. With this new paradigm you essentially get the best of both worlds. For simple requirements I recommend sticking to the traditional ODI approach. However, when you have complex requirements – e.g. you need to pre-aggregate data or
filter a record set based on the application of an analytic function – then the new feature comes in handy. Source  and target data tables can now be dragged and dropped to the same canvas. Moreover, all objects have IN and OUT connectors making it possible to use multiple targets within the same mapping as the OUT connector to be mapped to many IN connectors. The split component may be used to direct rows to the desired destination based on particular conditions. And speaking of the split option – a new components panel has been added, containing operations like join, filter, lookup or split to simplify mapping creation. (See Figure 2)

xbi-blog-aleksei-image-2-png-pagespeed-ic-xoxq4pqmac

Figure 2

The introduction of OWB style mappings should also facilitate the migration from Warehouse Builder to ODI 12c. Both tools use a flow-based design based on components on a palette and many of the components in ODI are the same or similar to those in OWB. The list is smaller in ODI (See Figure 3), as other elements in the ODI architecture, which can now be used for your
development, —including the topology and the KM framework— reduce the number of individual components required.

xbi-blog-aleksei-image-3-png-pagespeed-ic-jjqjoyomre

Figure 3

OWB to ODI 12c migration

With its 12c release, ODI appeals to both the database and tool-oriented crowds. Besides delivering an impressive new release with major advancements in data integration functionality, ODI 12c has added capabilities for OWB customers looking to make the switch to ODI. There are two approaches to make the move from OWB to ODI 12c: migration or integration. First let’s look at migration. A new OWB to ODI migration utility allows you to convert a subset of your OWB development artifacts into comparable ODI artifacts, and a new feature called OWB Runtime Integration allows ODI agents to orchestrate and execute OWB processes.

Using OWB and ODI run time integration

The run time integration of OWB and ODI can be a first step toward aligning with Oracle’s data integration strategy. You can run the two products side-by-side while starting new developments in ODI 12c and also migrate OWB Mappings into ODI Mappings using the migration utility.

Additionally, it is now possible to define a connection from ODI 12c to an OWB workspace in Topology Navigator. Storing the connection and credential details in the ODI repository allows
developers to invoke OWB processes in packages with the OdiStartOwbJob tool. It also allows developers and operators to monitor the execution of OWB processes in ODI Studio, ODI Console or Enterprise Manager along with the rest of the ODI jobs.

OWB to ODI migration utility

ODI 12c supports an easier mapping between OWB 11gR2 concepts and objects and their ODI 12c (12.1.2) counterparts. A migration utility is provided that automatically translates many OWB objects and mappings into their ODI equivalents. The migration utility requires:

  • ODI patch 17053768
  • ODI 12.1.2.0.1 bundle patch (patch number 17836908)
  • OWB patch 17830453

For more information about the migration utility, see migrating from OWB to ODI (www.oracle.com).  This command-line utility uses command-line options combined with a configuration file to specify the objects you want to migrate, as well as specific configuration options associated with those objects. It doesn’t migrate everything. Some of the noteworthy items that are not migrated include:

  • Dimensional modeling metadata and any mappings that use that metadata, including dimensions and cubes
  • Process flows
  • Configurations
  • Data quality, data profiles and data auditors

Process flows should be noted specifically. If you choose to migrate an entire project to ODI, you will only have the mappings and the metadata associated with them when the migration is complete. So you will need to use ODI packages, load plans or both to develop a new orchestration strategy post-migration. In many cases, this is no minor piece of work.

The Migration Utility has three run modes:

  • FAST_CHECK which performs a read-only check of the OWB repository and reports back the items than can and cannot
    be migrated.
  • DRY_RUN which performs a migration to ODI using the ODI 12c SDK, but does not perform a commit at the end of the
    process.
  • RUN (Default) which executes the migration and commits migrated objects to the target ODI 12c repository. The
    run mode is specified in the migration configuration parameter.

Let’s have a look at an individual OWB mapping and see what the migration utility provides on the other end. In Figure 4 below you see a source OWB mapping for loading a data warehouse from external tables based on flat files.

xbi-blog-aleksei-image-4-png-pagespeed-ic-n8wjwc7htw

Figure 4

In Figure 5 below, you can see the mapping loading sales data that looks identical to what was in OWB. The data store representing the external table is still the source, and the data is split and written to multiple targets.

xbi-blog-aleksei-image-5-png-pagespeed-ic-k1aqotdmx

Figure 5

Overall, Oracle has done a good job of merging OWB and ODI operations. Users who have been waiting for this will be happy with both speed and execution. At Coherent Solutions we have been able to start developing new components and requests on ODI by reusing some migrated processes from OWB as steps of new processes.