Oracle Data Integrator (ODI) Reviews

The most important aspect of the product is the ability to work with almost any data source or target. I can readily develop processes that use relational, file, XML, JMS messaging, web and big data sources or targets.

I can control the style of integration through "knowledge modules", and if they don’t do exactly what I want. I can write my own or customize the Oracle supplied ones.

The ability to execute third-party (or in-house developed) Java code by installing JAR files allows a great deal of flexibility; for example, I can add custom processors to do access web APIs that use token based authentication.

Another key feature is that we do not need to pass our data through some form of ETL engine hosted on a server; in some cases for example transforming data within a data warehouse all of the processing is done in single SQL queries thus reducing network traffic.

Finally, the rich SDK supplied with ODI allows developers to create virtually any form of development or deployment automation.

It allows a single skill set to handle virtually all of the data transport and transformation needs of a company. It moves the ETL processing to where the data resides and saves network traffic and the need for dedicated transformation engines - hardware that needs to be purchased, managed and supported.

There needs to better support of external version control software, currently only SVN is present, but I hear the GIT is planned in future patch.

From a DevOps point of view it would be useful to add better separation between ‘code’ and ‘executable’ exports, at the moment a piece of code will contain the embedded executable which bloats any source control objects (this may only be relevant to those the develop their own source and code control processes).

I've been using it for the last 10 years.

We've had no issues with deployment.

12cR2 is a new version, and there are a few issues with stability, but I expect most to be resolved in the first patch.

There have been no issues with the scalability.

I rarely engage with support.

As an independent consultant, I work with other ETL products, and switching is requirement of my employers. However, of the products I used recently (Informatica and Talend), I feel ODI gives me the most flexibility.

Set up of ODI Studio and the ODI repository is relatively simple, it is all done through a single JAR file executable. The complexity comes when you need to create ODI agents - there are three flavors of agent and the best choice of agent will depend on your agent management needs and infrastructure. The ODI agent executes ODI code and interacts with the host OS, typically one agent is sufficient, but more may be needed.

The licensing model has changed a few times over the years - read the Oracle price list or speak to sales.

Plan your ODI infrastructure, especially where data is transformed to ensure you get the best balance between license costs and performance. Get your developers trained in best practices so that avoid unnecessary pit falls.

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.

It allows us to use many languages to develop and to integrate practically all the technologies of the Oracle suite as well as those from non-Oracle vendors.

My organization develops solutions using all the Oracle EPM products, and ODI has helped us to integrate all the different technologies.

I think that the product as an overall solution is good. I would only point out some minor bugs or glitches in the development interface (ODI studio), but I do not think that any of them are worthy to be reported here.

There are some difficulties in moving a repository from an environment to a different one due to the internal numbering through which ODI references the objects belonging to a repository. This often causes troubles in the porting, and for this reason you always must pay attention during this operation.

I encountered many problems with the ODI web agent (service that actually executes all the integration tasks) in the 11g version, which was not stable. For this reason, I always suggest using the standalone agent instead of the web one, mostly due to the fact that they do not have significant differences.

Scaling issues depend mostly on the tools that ODI uses to integrate the technologies. For example, if the number of records inside a table, which is the source of an integration task, increase greatly, the performance of the ODI integrating flows may degrade a lot. Their tuning, by the way, depends on the database (i.e. table partitioning, indexes or hints).

I only experienced once the customer service provided by Oracle on ODI and was supported by capable and helpful people.

The level of technical support is quite good. Apart from the first approach used to identify if the problem you are pointing out is a real issue or not, the second level support is really efficient and comprised of competent and clever people.

The initial setup is not really easy. To use ODI you must:

• Install the ODI studio (client)
• Create and configure a master and a work repository to develop on them, being sure that they can reach the database schemas you’ll work on (relational structures involved in the integration)
• Install and configure an agent (if you need to communicate with more than a server and to schedule integration tasks), choosing properly where you need it and opening all the communication doors to allow it to reach all the parts of your architecture

I implemented it with an in-house team, since my company is a consultancy and also an Oracle partner.

Even if ODI allows implementing a very smart solution with an high level of customization, I think that keeping the model of what you are developing as simple as possible is always the best choice. This is due to its future maintenance. Keep in mind that, even if you may be a very keen developer and you can propose the best and most parametric solution ever, if another (less expert) person inherits the responsibility of what you have developed, they may encounter difficulties in solving problems. For this reason, the easier you keep the complexity or technicalities of what you have created, the better it is.

This is also valid for performance - one of the basic rules of the informatics development is “divide et impera”, which means that you should always try to create “objects” as small as you can to improve performance and to be able to identify quickly where a problem is.

Being an ODI developer, I never had to pay for this product. I know that the pricing/licensing is not really low, but the product is really good.

I tried many integration tools, both Oracle and other vendors. I think that ODI is one of the most complete and open solutions, since it can work with almost any technology and it gives you the ability to develop the same solution in a wide variety of ways depending on the one you prefer.

Always keep in mind that ODI offers a huge number of solutions to any task you are developing. There is not a best practice in solving a problem; being able to identify the best solution for your particular problem is up to you and it may also be difficult to identify. This does not mean that the solution you have in mind is not correct.
Always try to maintain an ordered environment, keeping only what you really need, and perhaps organizing the items in different projects or folders, or even different work repositories.

The user interface for the data integrator tool is probably the most valuable piece. I'm a relatively newcomer to the ODI. We opted to use ODI instead of Informatica. Relatively, I do not have a lot experience with a lot of VARs, but I've been able to understand a lot more about the direction Oracle is heading through the tool. It was very intuitive. It helps to have a good background in data manipulation, but it's very intuitive and has given a good appreciation of what the tool can do.

We use ODI to extract and transform data to load into our data warehouse from our source system, which is Oracle EBS. We have found that it's very efficient; very fast. We can easily customize and review even out-of-the-box analytics that came with Oracle. We’re able to easily go in and modify and correct any anomalies that we have.

Perhaps more learning resources related to ODI would be helpful. I'm not sure if that's what restricted the buy-in. Even though the product has been out for 4-5 years, there are still a lot of people who aren't using it or have opted to stay with Informatica. It could be because there aren't enough self-study or self-research resources related to the product. That surely could be improved in the near term.

We've had it implemented for two years.

Any stability issues I've had, have been related to the data itself. It really depends on how whomever has implemented the product. If it stands up, it works well.

We get very good and very timely response from technical support. Maybe, we just don't have very complicated questions, but we get very, very good response; very quick answers.

We decided to move away from Informatica after we attended an Oracle conference about three years ago. We learned a lot more about where Oracle was going with it. One of the key reasons was not just moving forward with the newer technology; it was also because of the compatibility with the applications we use versus the applications that were available in Infomatica.

We have the capability to extend it to other data sources, all of the non-standard data sources. We don't have to build out huge data structures in order to feed them in through Infomatica. We can read Excel spreadsheets and a bunch of other sources.

As a customer to a consultant team, I was involved in the installation and deployment of ODI. There were some challenges, which was probably due to the relative inexperience of the team that handled it. Eventually, they were able to get through it. Fortunately, my internal team as costumers were also able to do our research and participate in that discovery, too.

You would have to evaluate what your key purpose is, and your existing, internal talent and experience. It's my belief that you should always try to have internal talent that is very confident, rather than having to always rely on consultants. If your talent has the experience in Infomatica – I don't think Infomatica is going anywhere – then it might be the best choice for you. I don’t think your office will fall apart. I think you have to evaluate which one will work for you.

We were new customers to data integration, so we decided to go with newer technology that had already come from the same source.

The ability to extract from multiple sources, the flexibility of using the Knowledge module, and the ergonomics of the GUI are the features I've found most valuable.

Before using ODI, I was forced to develop programs with multiple technologies (Java, Python) to extract data from multiple sources. Now with ODI, I just have to configure the knowledge module to perform the extraction.

I think that job scheduling can be improved.

I've used it for four years.

We've had no deployment issues.

I think that ODI 11g is very stable. I've had no issues with instability.

We've had no issues scaling it for our needs.

I have never contacted customer service or technical support of Oracle for this product. If I have a problem, I try to find a solution from the Oracle community.

I've used Microsoft, but I think that ODI is simpler to use and offers more flexibility.

The initial setup was a little complex because the architecture of the product was blurred, so I needed some weeks to understand it.

I implemented with our in-house team. You should try to have good documentation before using this product.

The product separates business logic (data mapping) from how data moves from source to target. A Knowledge Module defines the steps to move data from an Oracle DB to SQL Server for example, leaving only the transformation logic for the developer to define. This results in an ability develop transformations more rapidly than say Informatica.

We spend much less time developing integrations because all we need to focus on is the business logic.

The user interface is a little slow. When compared to Informatica, the UI is more intuitive, but because it is Java based, it does hang at times. This can be tuned, but it is something that could be streamlined.

I've been using it for over five years.

There were no issues with the deployment.

We have had no issues with the stability.

It's been able to scale for our needs.

It is adequate.

It is adequate.

I have used a number of ETL tools. I like this one because it is part of Oracle Business Intelligence applications which is my primary focus. I would choose it over Informatica because you can develop more rapidly.

It was straightforward as the installation is fairly easy and well documented.

As with all software, read the installation guide cover to cover before you start.

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. 

Provides us with a relational database.

It needs more robust functioning and ease-of-use for development using reusable jobs.

We have used this solution for one year.

There were no issues with deployment.

There were no issues with stability.

There were scalability issues.

Customer service is good.

Technical support is good.

We had a vendor team help us with the implementation.

We looked at FDMEE.

It needs improvement with reusability.