Oracle Data Integrator (ODI) Reviews

I'm not very comfortable with ODI, but it is one of the Oracle product that we use. I know the interfaces and that it's used for financials. The ODI client can be configured so that Excel data can automatically be pumped into Oracle Forms directly.

It requires a client, which I don't think is the best way to go about connecting data. Basically, you need to establish a connectivity between the client and the database, so when you launch something through Reports, in can be shown in the Excel.

Also, I think they should have something like Google Docs, where an engine opens up a document directly instead of having to depend on a client for connectivity. That would make working with it much more efficient and better.

If you are applying it on more clients, it becomes a thick client because to have the client installed, it needs memory from the desktops. This slows down deployment.

If it has a client that demands more thick clients than thin clients, that means that you need to give more memory and more CPU for your desktops that are also using those same resources.

We haven't had problems with scaling it.

I wasn't involved in the implementation, but I haven't heard that it was particularly complex.

I believe we implemented it with our in-house team.

In my opinion the notable difference between ODI 10 and ODI 11 is the possibility to keep multiple interfaces open at the same time. This makes it very comfortable to work with. Another technical feature that I like, is the possibility to create a dataset. This is the Oracle set operator inside the interfaces such as UNION, INTERSECT, MINUS. It has a friendly interface where you can see all tools very clearly because the designer tab shows the operator, topology and security workflow together and you can access them at the same time without any problems.

With ODI 11, I have spent time developing different interfaces at the same time instead of developing them one by one. ODI doesn't have an interpretable language in its architecture, so if you know Oracle you can write mapping SQL statements that you need for getting the data. This allows you me to have a greater adaptability.

I would like more different tools of transformation. In the current version I have only worked with lookup and filter, and sometimes is not good enough for what I use it for.

I've been using it for seven months.

There were no issues with the deployment.

We had issues with the early versions but lately the product is performing well.

It's been able to scale for our needs.

Oracle provides good support for this tool.

The initial implementation was simple, and there are no issues to report.

I tried PowerCenter a few months before Oracle Data Integrator. I wanted to try the Oracle ETL to compare it with the tools of PowerCenter.

ODI is a great ETL tool that you can use for implementation. It’s not complicated to use, and with knowledge of SQL and PLSQL you can customize it a lot.

• Direct infusion of statements to the database, which allows the full use of database capability
• Ease of creating data flow and transformation
• Flexibility on technology on transformation

My customers started to increase their ETL performance with great margins. This was especially the case when ODI was used with Exadata, which allows each statement to be executed much faster.

The main problem with ODI is that you have to create each step of the transformation as a new interface. A big data flow can have more than 100 interfaces, which can make it difficult to trace the data. However, in v12, this approach changed to become more flexible.

Another complaint is with the user interface performance -- as the work repository gets bigger, issues arise.

I've used it for seven years now.

We have had no issues with the deployment.

There have been no stability issues.

It has been able to scale for all our needs.

7/10

I have a lot of experience on Oracle environments. I've started to have projects with my client using Oracle solutions. In my experience, ODI is a tool that is 100% compatible with all Oracle environments.

I can say that the level of complexity of the initial setup is medium. It is not straightforward because each customer may need specific logic on ETL approaches, so this means that your Knowledge Modules are mostly customized. Although except after the first installation and environment definitions, it is pretty easy to do after that.

I am a part of a vendor team. I think the most important thing is to decide where to reside this tool and its agent. This architectural question will help in the future to execute ETL processes. Secondly, the naming standards of all projects, immediate tables, Knowledge Module and folder names etc. are pretty important. Thirdly, versioning is crucial. All these standards should be done at the beginning of your use.

The product has a wide range of options on licensing.

The Knowledge Module is the heart of this solution. If you have nicely written Knowledge Modules, then you will not have any performance issues. The language should be kept as common as possible and all in one solution. You can write in many different languages, but the maintenance will need a wide variety of knowledge in the future. This can be very tricky in the long term. Do not forget to clean temporary tables after each execution of ETL. Otherwise, the database will be full of unnecessary data.

The EL-T approach that will first load into the target dataserver before doing the transfer is a great architecture improvement compared to standard ETL tools that use a staging area and usually process the data in Java. With ODI, almost all the job is pushed down on the underlying technology, for instance the Oracle database or the Spark server.

The Knowledge Module approach provides an easy and reusable way to create our own integration strategies. It's easy to create these Knowledge Modules to connect to new technologies, for instance.

ODI is really the tool for any kind of integration because it speaks the language of the technology we connect. We can work with RDBMS but also in Hadoop, cloud services, flat files, web services, etc.

Thanks to the flexbility of the tool, we could build 3 mappings using variables and the substitution API in replacement of 300 mappings in Oracle Warehouse Builder. It's much easier to maintain!

- Development Lifecycle

- native REST integration

- Easier security

5 years

A bit unstable and buggy in the 12.1.2 release, but most of it is fixed in 12.1.3, so I would definitely recommend to jump to that version.

I used Oracle Warehouse Builder (OWB) which is now at the end of its life. ODI is much more flexible and has the great advantage to be able to connect to a lot of different source or target technologies.

It was quite straightfoward.

We did a migration for Oracle Warehouse Builder to Oracle Data Integrator 12c using the migration tool provided by Oracle. And I've to say I'm surprised to see a migration tool working so well!

In-house

Heterogeneous technologies can be integrated with ODI, including the latest web services.

I feel that Oracle provides users with the best functionalities from ODI by constantly improving the functionalities in all areas.

Any IT company that relies on data coming from its clients or internal users requires data maintenance. All that collected data should be able to provide insight into the various behaviors of the clients across different platforms. For us, ODI has been key in collecting, transforming, and storing information from our various sources.

The two areas that I see for improvement would be the UI and the procedures for accessing it.

I have been using ODI for the last seven years starting with 10g. In my experience, Oracle has spent a lot of effort in improving the tool.

I never faced issues with the deployment since 11g. Oracle has made very good improvements in terms of the deployment. DBA objects take more time than the code deployment, which are the easiest and quickest ones. There is no room for errors when we have an environment in production.

We have had no issues with the stability.

There have been no issues scaling it.

5/10 - Technical support needs to be improved.

I haven't used any other solutions since this product has the potential to provide a solution for any complex requirement.

It's straightforward to set up.

We implemented it through a vendor.

I definitely recommend using this for any data warehouse project.

It's highly flexible, and can interface with almost any technology. One of the best ETL tools.

It has streamlined and automated data loads, and exports from our ERP system to our finance data warehouse and to Hyperion Essbase. The post-data load tie-back to the source system was also performed using this tool. The tool has also made metadata management more efficient, and automated the process from relational source to Hyperion Essbase.

I've used it for four years.

No issues encountered.

It used to crash with large datasets.

I've never had to contact them.

This is the only ETL tool I have used and never found a need to look for another. It met all our needs.

Straighforward except for DBA involvement during installation for schema creation.

The implementation was done in-house.

It's a great product.

I'm a technical manager and we provide technical services to our customers. We are partners with Oracle. 

This product helps our customers achieve their goals and objectives.

The best feature of this solution is the documentation. Everything is set out clearly with step-by-step instructions.  

I think Oracle should add more functions to improve optimization. Automation should be improved to enhance the product. Some of our customers carry out data comparisons between Oracle and other features and Oracle is lacking in some of those tools and features.

The stability and performance are good and our customers use the solution on a daily basis. 

The scalability is good, we have around 100 users. 

The initial setup really depends on the situation so it can sometimes be more complicated. When it comes to implementation, a deployment will usually take around 40 days and up to six engineers. 

I rate this solution seven out of 10.