Oracle Data Integrator (ODI) Reviews

Our main use case is getting data from operational systems. We are integrators and implement this solution for our customers. I'm the company's director of analytics.

This is a stable and comprehensive solution. 

The initial setup could be easier and it would be helpful if they'd reduce licensing costs.

I've been using this solution for more than 10 years.

The solution is stable. 

The solution is scalable. 

Customer service is reasonable. 

The initial setup is not that straightforward, you have to know how it works to deploy and implementation takes several months. We use managers or admins for deployment. 

We pay an annual license fee and this product is more expensive than other solutions on the market. 

I rate this solution eight out of 10. 

Very large and complexes environments implementation, 10000+ users with 24x7 global operation and multiple EPM tools working in sync.

For the EPM environment, the ODI is the key to transforming a good project into a great project. With ODI, we can make all the EPM tools work together as one and we can create a puzzle that will increase the performance and capability of all EPM tools. We can have an integrated environment and decrease the close time from two days to one hour.

It's the best tool for data integration. It can do anything you want, but the only downside is that you need to know what you are doing. You can take 10 times longer to do the same thing if you don't know how to use the tool.

You have to know how to change the KM, how to use the dynamic coding, how to create dynamic models, and so on. In a lot of places, I see people using ODI wrongly, but the good thing about the tool is that isn't hard to fix common mistakes. With this you can improve performance, and in some cases, more than 10 times.

Right now, we have two very different GUIs - 11g and 12c. 11g is faster to develop than 12c as it takes more steps to do exactly the same as 11g, but you have a lot of things that you need to do yourself.

12c implemented some things for which you have to use some specialized code automatically, like parallel data load, but it is slower to develop. For me, the best thing would be to merge the GUI from 11g into the capabilities of 12c.

More than 12 years.

There were issues mainly because of a Java memory leak.

We have had no issues with scaling it for our needs.

The technical support for EPM is bad. I don't remember anytime that the service support helped me with something. The problem is bigger when you have an environment with more than one product like Hyperion Planning and ODI.

This happens because the products have different owners within Oracle and then different supports, and because of this, if you open a trouble ticket of loading data to planning and you say the words ODI, you'll be pushed around the two separate support teams indefinitely, even if your company has an Oracle support director just for you.

Neutral

The bigger the environment, the bigger the challenge is you need to face. Maybe one day Oracle will integrate all their tools. It'll be easier, and the good thing is that I saw a lot of improvements over the years.

All tools are expensive, but I think ODI is the most expensive since it depends on your sources and target databases. I think the best way to go is by doing packages and try to include free tools (if you buy Planning you have an ODI for BI licenses for free) or try to get discounts from your Oracle supplier. It's always good to explore what could happen if you get another tool or hardware together. Sometimes, you get more for less than if you get just one tool. Just be careful to not buy things that you won't use.

I'm a consultant and my only evaluation was on the database. I decided on Oracle because of the database and during my career, their other tools are starting to come naturally.

Because Oracle products are development frameworks, your final results are as good as the people that implemented it. Make sure that your implementation team is the best it could be, at least for the first implementation. If something is implemented incorrectly at the start, it'll cost you a lot more to fix than to build a new system from scratch. Sometimes it can be so badly designed that it is impossible to fix.

I've been working on implementations for 21 years and I have seen bad implementations everywhere. In fact, I have seen the same tools implemented in the same team by two different people, with one being a success and the other a failure. In the same company, one department says that the tool does not work for them and another says that the tool is the best. The only difference was the implementer. Make sure you get a good team to implement it. The tool has its flaws but most of time (99%) it is the implementer's fault that you have a bad or slow model.

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. 

I have used ODI to improve run-times of many corporations' overall integration run-times. Corporations on a daily basis run integration jobs which normally take five hours or more. I have seen these jobs become hourly jobs because of the time reduction they received with ODI's involvement.

The Knowledge Module (KM) is my favorite feature of ODI. This is where I learned how to use variables to make jobs dynamic. I took that knowledge and created a KM that would go into iTunes and pull the sales of eBooks. Making something that is reusable, like a KM, is important to not only reduce build time but also maintenance in the future.

Error handling can always be improved with ODI. A lot of the errors are generic, but I will say that with a little experience, you can decipher the errors to help you fix them. In fact, I find myself not using the debugger that came out with 12c, just because I have learned to read "ODI-login-eze."

If there was a way to keep the basic user from creating a monster SQL that kills a system on execution, that would be great as well.

I have used it for 10 years. It's hard to believe it has been that long, but time flies when you have fun -- and I actually have fun when developing integration solutions. I started out on 10g and was able to quickly pick up on the ELT model after working with ETL for years before that. I was one of the first to install 11g on Red Hat. The main reason for the upgrade to 11g was purely looks as there were very little actual enhancements beside a couple of tools.12c was a major overhaul. I love working with 12c as it's now a flow-based tool but still ELT. It brings me back to the days of Hyperion Application Link (HAL), except that 12c isn't slow.

Stability is good, better than 10g and 11g.

Scalability-wise, 12c is the best in it's class. I could hand 12c to any size client and they would be fine developing and maintaining it.

I think that you get more than the regular Oracle support when you are working with ODI. Even the "First Responders" have a very wide knowledge on the product. This is a pleasant change from some of the other products for which you get the person who asks if your computer is plugged in.

I work on all the other integration products as well as ODI. In fact, I had to compare all the integration products (ODI, SSIS, HAL, Informatica, DataStage) when we were trying to decide on the strategic direction for the major bank that I was working for. HAL was being sunset, so easy decision there. DataStage cost a lot to host and was hard to develop in. Informatica was not installed anywhere in the corporation so the knowledge base for us wasn't there, so it got the boot too. It really came down to SSIS and ODI. We had a lot of SSIS knowledge and I was the only ODI developer. I took someone who never seen SSIS and ODI before, but had basic database knowledge, sat them in front of a computer, and gave them a day course on both. To be fair, after each course they had them create a job to do the same load. Results were clear and ODI won hands-down. ODI won out because of price, support, and speed/ease of development.

In 12c, they have made the setup so much more simple then what it used to be. The interface to do the setup walks you through every setup step.

I have been on both sides of the fence for this question. I would always have a vender do the install if you have never used the product before. There are a lot of little tweaks that can be made that takes experience with the tool to know these tweaks. If you have had the product for over a year, I would say, that in-house would be ok. Just make sure that if you have to remediate the install that you involve Oracle in that process so you make sure that all the parts get cleaned up properly otherwise the reinstall could be problematic.

The ROI on this tool is dependent on if it is implemented properly. When done properly your ROI is very quick. Most client however block the ability to have this setup properly. However the Cloud version is helping us as consultant show the client how powerful this setup can be.

I would say that you need to pay attention to the licensing to make sure that you are not paying to much. Normally, the licensing can be your friend if you don't need ODI for anything complex. You can switch ODI to go back to ETL if you don't want to spend that much money. Thin about it this way, if you are charged for only where it translates the data, then put a 4-core Red Hat in the middle of everything. Force your jobs to translate only on the Red Hat server. Your 1 million dollar implementation just went to 200k -- you're welcome. The caveat with the ETL setup is that the processing is slower per job -- you're not welcome. Again, ask yourself, what do I really need this for?

Know what you are getting into.

If you are going to use a firm to build out a solution, ask for a Proof of Concept and ask them to show you how flexible it can be. If they can't quickly come up with something, be wary. Don't just go with someone that is cheap, you get what you pay for.

This snapshot is to turn on automapping. This is a very useful function to have on when developing. This will make the magic happen when you connect a source and a target together. This is not in the documentation, so good luck finding how to turn it on if you haven't used it before.

We have been using Oracle Data Integrator for populating Financial Services Data Warehouse. Data extraction is done into a staging area from different source systems and then this data is validated and certain quality checks have been performed here. We used Oracle Data Integrator data quality checks builtin capability to perform these different data quality checks. Then data is consolidated and transformed into the staging area and finally gets landed into the data warehouse. I also used this for generating data hand-offs for other applications.

Oracle Data Integrator offers a declarative style ETL development, where you mainly use pre-built knowledge modules for doing integration tasks. As a developer, you don't need to focus on how part of the integration, you only focus on what to do. You just need to configure certain components as per your requirements and underlying execution plan and code is generated for you. For every technology there are knowledge modules available, the best optimal code is generated which eventually gets executed on database level. Our developers created best performing ETLs with very little effort leveraging this feature.

There are number of valuable features in this tool: 

• Declarative design 
• Client-server architecture model.
• Very good user access model
• Pre-built user profiles defined that give you control for access management
• Very good logging and execution logs feature which gives you complete detail of executions and you can query these in a different manner.

All ETL code is stored in repositories in underlying database schemas. The number of users can access and work on the same solution using a client tool. So distributed teams can work on this tool in an efficient manner. 

There are certain things where it can be improved. Initial solution setup seems a bit complex at the start, it should be improved because it becomes bit tough for a novice to get started on this. Sometimes error description is not helpful to understand the problem it gives some generic type of errors which are at times not that helpful to understand the underlying root cause of the issue. 

Error descriptions should be easy and specific to actual problems rather than generic lengthy descriptions. Also, another main feature that should be readily available is that there should be a source component available that can extract data from a source based on the custom query rather than giving a source data store only in the mapping. 

I have been using Oracle Data Integrator for five years. 

Good.

It's very good.

Whenever we needed Oracle Technical Support, we're able to get it in timely fashion and most of the time has been good to help in resolving the problems.

I didn't switch any tool. I'm a professional developer and my tool selection is based on client requirements. I've used both SSIS and ODI for different clients.

The initial setup is a bit complex as it needs some repo schema setup and agent setup.

We did it at our own.

Excellent.

ODI has bit on higher end in setup and pricing but it has more power as well. So it depends on your use. 

No, my selection was based on client's choice.

I think different tools have their own pros and cons, so it all depends on your overall needs.

We use this solution for Data Integration in Data warehouse projects.

This automation using Knowledge Modules has improved our organization.

The most valuable feature that we use is the Knowledge Modules.

The performance of the user interface is in need of improvement.

Our primary use for this solution is a data integration and merging tool. It easily connects to many databases like MySql, SQL Server, etc. It's completely user-friendly. We can easily manage packages, ETL, and Procedures.

Before adopting this solution we used to work hard. We now feel better because our manual work is completely over. 

We can easily create ETL processes and schedules. We can check logs on a daily basis. It handles multiple routines very smartly.

Overall the product is fine, but sometimes its reports unknown errors while we compile ETL scripts.

My impressions are good in terms of the stability.

I find that the scalability of this solution is good.

Interaction with technical support is not my area.

Before this solution, we were using SQL Server.

I think that the initial setup is amazing.

We used a completely internal team to implement this solution. 

We found that the cost compared to other integration tools is a little high, but the solution works great.

We evaluated SQL Server prior to choosing this solution.

Several projects benefited from the ODI data integration capabilities such as Loading OLTP system's data to Data warehouses, pulling data from cloud-based databases and loading to on-premises DW, for example: extracting data from a SQL server which is based on Azure infrastructure. 

Perform data integration from cloud to cloud.

Data migration between OLTP systems. 

Event-based integration such SOA, for example, BPEL performed calls of ODI scenarios based on EBS events.

All projects where I have implemented ODI solution highly benefited of high data volume integration.

There are several very important features that we use daily.

• All our systems can be widely integrated by ODI, such as transactional systems, our data warehouses, and B2B integration.
• ODI is really powerful for BI projects with traditional star-schema loads. For example, we integrated Salesforce to an Oracle data warehouse with it.ODI is a platform agnostic, you may have any data source and any target to integrate and ODI will enable you to connect.
• It facilitates real-time data replication from Microsoft SQL Server to an operational database sitting on Oracle Database.
• It provides for legacy systems integration. It integrates any SQL server database.

There is always room for improvement, even when something is really good, but I think ODI is one of the best ETL tools in the market. However, I've always waited for the web service feature to be improved in next versions, so at last the 12C version the web service has been improved, some of the limitations of the 11g version were solved. Also, it would be really good if Oracle considered enabling the tool to integrate with some other platforms that are deprecated simply for commercial reasons, although it looks like the cloud option offers some extra connectors (for example, in Salesforce CRM).

I've never had any issues with stability.

I haven't had any issues with scalability.

Technical service is a 6, and Oracle needs to improve this.

Besides ODI I have used SSIS and Power Center Informatica, both are similar and typical ETL tools, ODI up until 11g version had some differences, for example in ODI 11g we call the integration object as"Interface" wheres in  Informatica it is called "Mappings" which has been implemented in the ODI 12c version.

I still could see the Oracle solution being more robust and more logical, not to mention when it comes to customization, in ODI I felt more freedom to develop and customize the built-in code and designer objects such as the models, interfaces, for example, you can run updates in the repository tables"SNP's".

Also, ODI handles high data volume more efficiently, of course, your database must be well tuned a good hardware helps a lot. The other difference is that you have more flexibility to manage the ODI metadata since everything is based on database .

Getting the right JDK during agent config on Solaris was challenging on one occasion. It needs a Solaris expert to do this but in general when one knows the bits and pieces of the tool it should be straight forward .

I was usually part of the implementation team to implement the product .

oracle would better provide these kind of information .

The setup of the environment requires experts on site, but it is very worth it since at first for customers it can be quite complex. The vendor needs to enable the customer on a frequent basis during implementation, but the results are great.