Oracle Data Integrator (ODI) Reviews

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. 

Multiple data sources: "Most" of them, Oracle databases (some MS SQL, some Sybase, lots of files and some web services). Because the environment was overwhelmingly Oracle, ODI (we started from OWB) was a much better and cost-effective solution for us than Informatica.

Far more efficient and robust than OWB, (it was the natural evolution for us).

Separate environments for dev, test and prod from one management facility.

• Click intensive on mapping
• Lots of mouse clicking
• GUI could be improved.
  

It can do so much more than just load data. It can basically automate any task that you can think of, such a executing scripts for servers outside of your Oracle environment, executing any task that the IT team wishes to execute can be done via ODI. I created a button on a user’s machine once, this button executed only her job in ODI regardless of all the other jobs that were created. I love working with ODI because it tests your thought limits and creativity and the possibilities are endless when it comes to innovative tasks.

I work in a consulting role but I believe that by implementing it a lot of organizations’ manual processes have been automated

With ODI there is a lot of manual work to be done with the initial setup.

I've been using it for four years.

There were no issues with the deployment.

We've experienced no issues with performance.

It's been able to scale for our needs.

99% of the time we do our own trouble shooting.

I started with this product.

The initial setup was rather complex but I knew what I needed to do to achieve the end result. There are also allot of reading material on these products if you get stuck

We used an in-house team. My advice would be to know what you want to achieve with the tool because it is very flexible.

Their code-once-use-everywhere approach for coding data flows. Unlike other ELT solutions, ODI allows for creating scripts ("modules") which are then shared across multiple data load processes. If you find a bug, you fix it once, and it is fixed for everyone. It is the same if you need to code a new feature. It is also worth mentioning that ODI supports over a dozen of scripting languages. Chances are that your favorite language is amongst them.

The main improvement was unifying and standardizing ELT processes. For example, each table in the EDW solution has a set of standard columns used solely for auditing, data lineage and debugging purposes. Because the code to support those columns is shared across the whole solution, we are now capable of getting the auditing information for every single piece of data in the entire solution, without having to code it individually for each stream.

The GUI is Java based, and is less than friendly. It feels a little bit like being in the late 1980s when I started using it. So I would say: hey, Oracle guys! Improve the GUI. Make it more intuitive. Snappier. Sleeker.

I've used it for three years.

Not really. There were some caveats when upgrading from one major release to another but that's expected with tens of thousands of highly customized ELT streams. Nothing that could not be resolved within a day or two.

It is Oracle. So, you get what you pay for. We used their customer support once or twice (for instance, when resolving incompatibility with certain versions of the JDBC driver) and got all our issues fixed.

I used DTS/SSIS, Cognos DM, and Informatica previously. They all have their little pros and cons. For ODI, the killer feature was the shared code. Plus, the whole EDW solution is built upon Oracle databases so it simply makes sense to use Oracle ELT tool.

Well, it is certainly not the "Run the installer, click Next Next Next Next and have it up and running" kind of an install. There are many types of ODI agents that need to be installed and tweaked on uncountable number of servers so it does take a while to get the whole thing functional. It is all well documented though. Don't expect any major issues here but make sure you book enough time for the initial setup.

We have implemented this with an in-house team. The main thing is to get one or two ODI gurus into your DEV team. ODI is built with unique philosophy in mind and if you try to start implementing your solution using your past (non-ODI) knowledge, you will get into trouble very quickly.

I have no idea. I was not involved in ROI related discussions. I can assume that because the tool is extremely stable and, once correctly implemented, runs practically without supervision, it is a good investment in a long run. But that's just my private guess.

Make sure you understand differences between ETL and ELT (ODI is the latter). Have a well-structured source data. And if you don't know anything about ODI, find someone who does before diving into your data-warehouse project. You can learn SSIS or Informatica yourself in days. This approach is not going to work for ODI.