first and second
blog post in this series we have covered many of the UI changes made in ODI
12c. In this third blog post we will finish describing some of the improvements
made at the Mapping level.
A couple of changes were made in how you set the
Journalization (CDC/Changed Data Capture) settings in Data Integrator 12c. To
access the ‘Journalized Data Filter’ field you now have to click on a source
datastore in the Logical tab of a Mapping and then select the Journalizing
panel in the Properties window. You can define the journalization filter there:
The Journalized Data Only checkbox which was previously
found in the Diagram tab of an Interface is now available on the Physical tab
of a 12c Mapping. To access it, select your Deployment Specification, click on
the source datastore and then select the General panel in the Properties
window. The Journalized Data Only checkbox is listed at the bottom of this
panel, once checked it will move to the top of the panel.
In ODI 12c you can specify an Integration Type for your
target datastore, this will filter the list of Integration Knowledge Modules
available to you in the Physical tab of your Mappings. You can pick one of the following
values: None, Control Append, Incremental Update or Slowly Changing Dimension.
The default setting is Control Append (Insert), set it to a
different value to see other IKM types such as Update or Merge.
Setting the Loading Knowledge Modules and Integration
To set a Loading Knowledge Module in ODI 11g you had to
click on the Source Set boxes and then select an LKM in the Loading Knowledge
Module drop-down list.
In ODI 12c you now have to click on the Access Point which
corresponds to your source. The corresponding Access Point will typically be
found in the Staging Area execution unit and can be recognized by its name which
ends with the suffix ‘_AP’. In the following screenshot the source file
Datastore is called SRC_SALES_PERSON, to define its LKM I click on its Access
Point SRC_SALES_PERSON_AP located in my Staging/Target execution unit. Then I
can use the Loading Knowledge Module panel in the Properties window to select
the appropriate LKM.
Similarly selecting an Integration Knowledge Module in 11g was
done by clicking on the Target box and then using the Integration Knowledge
Module drop-down list.
In ODI 12c you can now simply click on one of your Target
datastores in the Physical tab of a Mapping and then use the Integration
Knowledge Module panel in its Properties window.
Using Multi-technology IKMs
Multi-technology IKMs such as the IKM SQL to File Append are
typically used when the Staging Area is not located on the Target technology of
a given Mapping. In such cases data has to flow between the Staging and Target
servers and a multi-technology IKM can be leveraged to do so. They are also
useful when implementing ODI using an old school ETL architecture.
To be able to select multi-technology IKMs in ODI 12c you
have to first set the LKM to LKM SQL Multi-Connect on your Access Point(s). If
you don’t see them after their import operation is most likely because you are
not using the LKM SQL Multi-Connect yet.
Finally you can click on your target datastore and select
the multi-technology IKMs you have imported in your project using the
Integration Knowledge Module panel:
ODI 12c is using a flow-based declarative design approach
which offers more flexibility and capabilities when compared to the ODI 11g
Interface design. For example, ODI 12c Mappings now support multiple targets
and have Mapping Components such as Pivot or Aggregate which were not
One of those new Mapping Component called Dataset brings
back some of the ODI 11g design elements into ODI 12c Mappings and is very
similar in nature to a Dataset (source area) found in an 11g Interface. Datasets are
very useful to group sources together and can provide a better Mapping
readability. Creating joins, filters and lookups inside a Dataset is done in a
similar fashion as in ODI 11g.
Here is an example of a Mapping using a Dataset Component in
ODI 12c, the 3 source datastores are grouped inside a Dataset named Default:
Here is the same example without using a Dataset component,
none of the sources are grouped:
Set-based operations such as Minus, Union etc. were
performed using multiple Datasets in ODI 11g, each Dataset being linked to each
others with a set operation. In ODI 12c Datasets are not required anymore to
perform set-based operations instead a new Set Component is provided in the
Mapping Components palette.
/ Reusable Mappings
Temporary Interfaces were useful in ODI 11g to nest an
Interface into another one and generate a sub-select query to optimize
performance and avoid staging the data into physical tables. ODI 12c takes the
concept to the next level with Reusable Mappings which replace Temporary
In a Reusable Mapping you can encapsulate transformation
logic that you are going to reuse in multiple places therefore avoiding
duplicating the same code. This logic can be designed using existing Datastores
along with Mapping Components but you can also provide a generic Input or
Output signature which significantly expands the possibilities of reusing code
snippets across various Mappings.
Note that it is not possible to design a target table on the
fly in ODI 12c, any table/datastore has to first be defined at the Models
Similarly to ODI 11g it is possible to add a Reusable
Mapping into a “standard” Mapping and prevent staging the data by generating a
This concludes this blog series about user interface and terminology enhancements made in ODI 12c. Be sure to check out the previous blog posts in this series: Part 1, Part 2.