Oracle Data Integrator (ODI) Reviews

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.

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 main features we use and has helped us to implement our ETL process are

• Data transformation
• In memory engine
• KM customization
• User friendly GUI
• Versioning
• Big Data support
• Security support
• Easy deployment
• Reusable Mapping
• Multiple Target Load
• ELT Architecture
• Application Server support for other vendor servers such as IBM Websphere

The features that we have applied to our project has helped us reduce manual effort and increased our scalability and growth. I worked on multiple domains where requirements were adversely different. We used many ODI features to enhanced our data transformation capability.

I am personally satisfied with current version, however, I think they should be able to provide a feature where we can easily use a configuration tool for TFS, GIT etc. This is essential for code management.

I've been using it for six years.

We have had no issues with the deployment.

There have been no performance issues.

It's been able to scale for our needs.

9/10

8/10

I have not used any other product. However, I have seen other ETL tools in use such as BODS, SOA, and Informatica and I did not like them as I did not that they were user friendly.

It was straightforward. I used an application server for the initial setup and I did not find any challenges.

We performed an in-house one. If you have a technical team for ODI, then they can easily perform any implementation. If not, then you should have the vendor perform your implementation.

10/10

It is not as costly as other ETL tools.

You should use Oracle Data Integrator for your data transformation, or at the very least give it a try.

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.

The most valuable feature is that it's bundled with all the other Oracle products. We use the ODI with BI Apps. It does all the ELT along with our data warehouse for BI purposes. That’s good. It comes as a bundled package. If we want to use the newest, latest version, we can install it separately.

It's very user friendly. We used to use Informatica; compared to that, it's easier.

The learning curve is a little less because if you are already in the ELT business, you know how it works. Overall, it's good.

I would like to see them make some more improvements on the troubleshooting side, to help with the troubleshooting because right now, the errors are not very clear. I think they are already working on it; it's in the latest release, but yet to be included in the BI Apps bundle.

It is still not as stable as the old BI Apps and ELT tools were, but it's getting there. BI Apps doesn't come with the latest ODI yet, but in the future, it might be better.

It works with Oracle Fusion, so it can be spread across the cluster. It's pretty scalable.

Technical support is good. That's the standard. It's good.

We upgraded because the old version was no longer supported. The new version comes with ODI, so we didn't have a choice. But, we like the product.

It didn’t come with any other option. However, even if we had another option, we would have gone with Oracle, because we are a big Oracle shop.

Initial setup is straightforward. If you are from a technical background, it's pretty straightforward.

We didn't actually look at anyone else. We looked at different Oracle partners who provided this software, but the product was Oracle from the start.

We learned some lessons, such as how to plan out the entire process, and so on. Oracle documentation is good. If you follow that, you should be fine.

When I’m choosing a vendor such as Oracle, support is the most important criteria.

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.

We mainly use ODI to integrate all of our EPM applications, which includes Essbase ASO/BSO cubes, Hyperion Planning, DRM and HFM applications. Also it is used to manage a custom data warehouse developed in Oracle DB which is used as source for OBIEE reporting.

We use ODI to integrate all Oracle EPM suite used in our financial area. ODI is the core engine used to move data across different applications every day. It’s by far the most important architectural element in our BI/EPM environment since all data passes through it.

ODI has the ability to connect to virtually any technology out there. If it does not connect out-of-the-box, we can very easily add a new technology into it. This flexibility gives a tremendous developmental advantage to its users, which can use ODI as the official ETL tool for any kind of integration project.

Its Knowledge Modules (KMs) may abstract the “how” portion of integrations, allowing the users to focus on the “what” that needs to be done. It can be easily used by either young ETL developers or expert professionals.

For resumes, the ease of use for young professionals and its great development flexibility for expert professionals make it a great product to be used for every ETL project out there.

In my opinion, ODI should connect to ALL Oracle products out-of-the-box, but currently that’s not the case for all of them. Hyperion Financial Management (HFM) is one of the Oracle products for which Oracle decided to remove its ODI support in its last product version. In other words, if you wish to use ODI and HFM together, both from Oracle, you will need to create custom code, which does not make any sense to me.

Another area to improve would be the development life-cycle, which did improve in the latest ODI version, but needs further improvements.

More than five years.

ODI 12 version is very stable. It can manage several parallel executions/large volumes without much trouble.

ODI scales very well.

This is a delicate subject. My experience with Oracle support has both great and very bad situations. If the problem that you are facing is only related to ODI, then your chances of having a great Oracle support experience are good. But if your problem involves multiple technologies, like ODI integrating EPM apps, then it is probably going to be a nightmare (and, unfortunately, most of the problems that will require support assistance will involve “multiple technologies”).

This happens because Oracle supports different technologies with different teams and the communication between them seems complicated sometimes. Several times I was in a situation where teams would keep discussing who should fix the problem instead of actually fixing it.

I've always worked with ODI for ETL development.

The initial setup is extremely easy and straightforward.

ODI was the only option we considered.

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.