Oracle Data Integrator (ODI) Reviews

We use the solution for getting transactions and BI reports for stakeholders.

Stability could be improved because some operators have issues.

I have been using Oracle Data Integrator for two years and a half.

We used the solution, and we didn't have any problems with that.

I rate the solution’s stability a six out of ten.

We didn't have a problem with the tool’s scalability. There are six to seven people using this tool in our organization. We don't have plans to increase the usage. It responds to all our problems.

We didn’t contact the customer support team. We figure it out by ourselves.

The initial setup is easy. It took about two and a half months to deploy.

We set up the tool in an environment because of data sensitivity.

Overall, I rate the solution a seven out of ten.

We are using the solution for ETL purposes for our data warehouse.

The product has an ELT approach. It is much faster than any other ETL.

The initial setup is a bit complex compared to other tools.

I have been using the solution for three to four years.

The tool’s stability is good. I rate the stability an eight out of ten. We need to do a lot of engineering to understand the ODI mappings, knowledge modules, and how to load them. We need to learn a lot of other things, too.

It is a native tool of Oracle. It has no problems with scalability and availability. We have around 12 to 14 users.

The support depends on the severity of the tickets raised. A P1 ticket might be resolved fast. P2 or P3 tickets take a long time. I rate the support for P1 an eight out of ten, but for P2 and P3 tickets, I rate support a five out of ten.

Positive

The deployment takes at least 30 minutes. The tool has a lot of prerequisites. If we don't have a consultant or expert to help with the deployment, we won’t be able to complete it within 30 minutes. It would take longer. We must install JDK and the OBIEE repository that contains ODI packets. The software setup is confusing. The installation can be done in-house if the SOP is clear with the prerequisites and steps to follow.

The solution is very expensive. If it is cheaper, more people can use it. Oracle licensing is complex to understand. We pay a yearly licensing fee.

Since the product is expensive, we are exploring other tools like Azure Data Factory to reduce costs.

People can use the tool if they don't have a limit on their budget. However, people generally have budget constraints. We need to understand the cost before we implement the product. Overall, I rate the solution a six out of ten.

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.

Integration with all systems is easy with Oracle Data Integrator, and it is easy to use. I have not used any other product, but with Oracle Data Integrator, we can easily connect to an ERP system, an SAP system, or a cloud application.

It has been very good. Just recently, I've faced an issue, but I solved it somehow. While integrating with a file, I faced an issue where I wanted output files, and I had used the text field limited quotations, but at the end of the file, there was a line breakage for the last column. So, we just removed the text field because it was not working correctly for us.

I have been using this solution for around seven years.

It is pretty good.

It is scalable.

I didn't contact them for the line breakage issue, but I have contacted them for other things. My experience with them was good. Their solution was quick and the response was quick. I would rate them a four out of five.

We have seen a return on investment with this product.

Everything is good, and I would rate it an eight out of ten.

We use ODI for integration services from different systems, such as finance systems and online display systems. Additionally, we integrate it with the external partners with ODI. 

We use ODI in combination with the SFTP server.

The most valuable features of ODI are the ease of development, you can have a template, and you can onboard transfer very quickly. There's a lot of knowledge modules available that we can use. If you want to connect, for example, a Sibyl, SQL, Oracle, or different products, we don't have to develop them from scratch. They are available, but if it's not, we can go into the marketplace and see if there's a connector there. Having the connector available reduces the amount of hard work needed. We only have to put the inputs and outputs. In some of the products, we use there is already integration available for ODI, which is helpful.

The interface of ODI could be improved. For example, navigating and finding functions can be difficult. For example, you have to know which step you need to go to look at where your job status is. The logical step is a bit complex compared to other tools. It's much easier to get a graphical view, but with ODI, it's graphical, plus you have to know all the other pieces that fit around it. You have to think about the logical and physical aspects.

One aspect I always struggle with is there's no single view to see which jobs are going to run or what time. You have to look around, it's very clunky. If you had a couple of agents, you can't see everything in one place. You have to go and look at an agent schedule and look at that, and then, go to another one to look. There's no single view that gives you the whole picture.

What would be nice for us is, if ODI can easily integrate to GitHub, to allow us to have all our source code in GitHub rather than within ODI. This would be a very good feature, everyone is using GitHub.

I have been using Oracle Data Integrator (ODI) for approximately two years.

Since we moved to the new version, ODI has been very stable, and we haven't had any unplanned outages. We only have had planned outages, I'm pretty happy with it.

The only issue we have had recently was when we patched ODI all the jobs that were supposed to be scheduled at 6:00, it ran seven hours earlier. It's a result of the patch. We were working with Oracle and they gave us a fix.

The solution is scalable, we can increase the agents and let it do more work.

We have approximately 12 people using the solution in my organization.

We use this solution extensively without our organization.

The technical support is very good. f you give them all the information, they seem to give you a solution pretty quickly. We have not had any issue with the support. However, we are using paid support and I am not sure if the regular support is the same.

I've used other solutions previously, such as Microsoft tools, they are much easier to set up. ODI is a bit clunky to begin operations, it requires a longer learning curve.

We are using this solution extensively.

The initial setup is complex, it took us three months.

We reached out to Oracle and a few other partners that Oracle has but, in the end, we decided we should do it ourselves. If we did not do it ourselves we wouldn't have the knowledge of how to do it in the future. We received a quotation from them and then decided, we would do it ourselves, in-house.

For all these cloud products, we have to patch them ourselves, it is not done automatically. I was expecting patching to be automatic but it is not. 

The solution is expensive because of the model they use. The cost is for the license and for support.

I would recommend it if they were an Oracle house mostly. It works very well with other Oracle products. If a business is not an Oracle shop, I would not recommend it. OBI understands Oracle E-business, Oracle CRM, and other Oracle products well. However, if you were to go to another company that had different products, ODI would struggle.

I rate Oracle Data Integrator an eight out of ten.

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.

The biggest feature for ODI is the fact that it uses the power of the source or target database to actually perform the ETL processing. So a typical data integration tool might have its own ETL engine, and that would be an additional server, additional costs, something else you have to maintain. ODI actually has the ability to create and generate code that runs potentially on your Oracle database, or even on a big data target, on Hadoop or somewhere like that. So, you have that flexibility, and you don't have to have that additional cost in maintenance.

A couple other additional benefits of Oracle Data Integrator would be the use of what's called a knowledge module. So this is like a code template that uses the metadata that you have available within ODI, and within your mapping, to generate that code, that then can be executed, like I said before, on the source or target system. The code will be generated in the native format of that database or that technology. So, again, you have sort of a hands-off.

These knowledge modules are built in. They can be developed and modified. So, the biggest thing, I always think, with ODI is, it fits around your data warehouse needs. Rather than taking your production, or your business, and trying to make it fit a tool, you do the opposite. You make the tool fit your business.

One thing that is included, and it's going to improve, is the integration with a configuration management tool. Right now, they integrate with Subversion. And we know in the future, there's going to be more tools implemented there for configuration management and some new features there. So right now, it's kind of one of those features that, it's been released, but it's sort of a beta version of that feature where a lot more functionality will be coming down the line.

So ODI is actually quite a stable product. As a testament to the product team that develops it, they're not going to release something that is extremely buggy or things like that. So, I do see that often they will release features that are highly anticipated and highly sought after. And they might release them a little early. So there's definitely patching that comes into play there, to kind of get the full solution there.

As far as stability, the Oracle Data Integrator has agents that run either in WebLogic, as a Java deployment there, or on a server as a Java agent, or a Java deployment. As long as a client has had the product implemented, with no issues there. So that's kind of the key there, you don't want to have those agents have a blip or any issues.

So as far as scalability of Oracle Data Integrator, from the high availability standpoint, if you use WebLogic for your agent, you can use the clustering capability within WebLogic to create multiple nodes on different WebLogic servers. And then run your agent through that process there. So if something fails, if the main agent fails, it can fail over to the secondary agent or, again, another agent in your cluster.

I'd probably put them up there around an eight, yeah. Being a system integrator of Oracle products, typically I'm on behalf of a client. So oftentimes it depends on who your client is and what their level of support is, as far as response and how things go. But I've always had great response with those guys.

A lot of the projects I've worked on recently are Oracle VM apps projects. So, it's the folks that are in the Informatica version of VI apps, and looking at moving to the latest and greatest, which has Oracle Data Integrator behind the scenes. I'm not saying they're actually talking about using Informatica, they're just, that's what they have. And they're looking to migrate. Quite often where we come into play, ODI is typically chosen at that point. And then they call us in to help with it.

It's not too difficult. It's tough to look at it from the perspective of someone who hasn't been doing it for a while. And oftentimes, that's what you need to kind of make that determination. But as far as just getting up and running, you can get it installed, configure an agent, quite quickly. And then the next step would really be getting ready to build a mapping. And they actually introduced in the most recent release, or maybe even when 12C came out, they introduced a feature that would basically get everything, topology, the models, all the data stores, everything, ready to go for you, just in one simple wizard. And then you could actually start building mappings quickly.

A lot of it is when they have home-grown ETL processes. So they'll manually script their ETL code. It's basically something that's difficult to maintain. So we talk about how we can use ODI to keep everything centralized. And even if we're not using ODI to actually build out mappings within the product, we might still be able to run that PL SQL or whatever it is, the script for ETL, from within ODI.

So we still have everything consolidated and contained and then the other approach, or reason for moving to ODI, would be the need to get off of that middle tier integration server. That we don't need with ODI.

As far as why consider Oracle Data Integrator, I think the big thing is the ability to consolidate all of your ETL into one place. Whether it's an Oracle to Oracle, source to target load, or even Oracle to Hadoop, or anything in between. SQL Server, MySQL, XML. ODI can basically talk to all of those different technologies. From a consolidation of all of your data warehouse or your data integration, if you will. And also, just use the same approach for mapping and creating processes for all of those different types of solutions. You have everything logically defined. And so when you're developing, it actually doesn't look any different than an Oracle source, and target doesn't look any different than a Hadoop source and target.

So I would rate ODI a nine. And that's really because, just looking across the other ETL tools, so I mentioned Informatica, there's a lot of other ones out there. I've seen what ODI does from a sort of a declarative design approach, and the push-down of work to the source and target. I've seen that replicated in other tools that have come out after Oracle Data Integrator. That's a big key.

It puts it kind of at the top, if you're going to look at a scale across all of the ETL tools. The other aspect to that rating is how they're integrating a lot of the big data technologies now. And it's a big deal from an Oracle standpoint, it's kind of how things are going. And it also just makes sense to, again, keep everything consolidated in one place. You already have an investment in ODI, it makes sense to try to drive some of your other big data type Hadoop loads or whatever it may be from that same place.

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.