User Interface and Terminology Changes in ODI 12c - Part 3
By Julien Testut-Oracle on May 09, 2014
In the 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 Knowledge Modules
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 previously available.
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.
Temporary Interfaces / 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 Interfaces.
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 level.
Similarly to ODI 11g it is possible to add a Reusable Mapping into a “standard” Mapping and prevent staging the data by generating a sub-select query.