Oracle Data Integrator (ODI) Reviews

The possibilities provided by using knowledge modules and the integration with other Oracle products.

The old fashion PL/SQL codes have been translated into ODI, improving the way of maintenance. Several developers can work on the same project easily.

The software is developed on Java so it is very hardware dependent. You will need enough hardware to run the software otherwise you will struggle with it.

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

There were no issues with the deployment.

When developing on huge internal repositories, the performance is often quite poor.

It's been able to scale for our needs.

I have managed to solve my questions/issues via OTN or forums.

I haven't used any other products.

The first time might look a bit complex but using the right documentation it should be easy to handle.

It was already implemented on the projects where I have worked.

I didn't look at any other similar products.

The ability to build integrations that process large amounts of data (in GBs), be it file transfers ,DB operations, and web service calls, etc.

ODI has made it possible for our organization to rapidly build robust integrations that process large data. The learning curve of this technology is also very smooth and can be picked up by any one with minimal programming experience.

ODI's "in-memory RDBMS" is still a black box for programmers as there are no tools/dashboards to monitor/administrate this in-memory database. As a result, inconsistent data processing issues generally force us to restart the ODI server.

There were no issues with the deployment.

We've experienced no issues with performance.

It's been able to scale for our needs.

The product may not be as evolved as Informatica, but still has a lot to offer in the Fusion Middleware Product Suite. Keeps all the promises of an ETL/ELT tool, but when it comes to Administration and maintenance the product still leaves a lot to be desired.

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.

In my opinion the notable difference between ODI 10 and ODI 11 is the possibility to keep multiple interfaces open at the same time. This makes it very comfortable to work with. Another technical feature that I like, is the possibility to create a dataset. This is the Oracle set operator inside the interfaces such as UNION, INTERSECT, MINUS. It has a friendly interface where you can see all tools very clearly because the designer tab shows the operator, topology and security workflow together and you can access them at the same time without any problems.

With ODI 11, I have spent time developing different interfaces at the same time instead of developing them one by one. ODI doesn't have an interpretable language in its architecture, so if you know Oracle you can write mapping SQL statements that you need for getting the data. This allows you me to have a greater adaptability.

I would like more different tools of transformation. In the current version I have only worked with lookup and filter, and sometimes is not good enough for what I use it for.

I've been using it for seven months.

There were no issues with the deployment.

We had issues with the early versions but lately the product is performing well.

It's been able to scale for our needs.

Oracle provides good support for this tool.

The initial implementation was simple, and there are no issues to report.

I tried PowerCenter a few months before Oracle Data Integrator. I wanted to try the Oracle ETL to compare it with the tools of PowerCenter.

ODI is a great ETL tool that you can use for implementation. It’s not complicated to use, and with knowledge of SQL and PLSQL you can customize it a lot.

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.

The most value feature of this product are the Knowledge Modules. Oracle Data Integrator comes with a comprehensive library of Knowledge Modules that helps automate the data flow, reduce the learning curve, and shorten the implementation time.

The use of this product has helped identify data quality issues in upstream source systems. As a result, data quality rules have been implemented in order to capture them during data entry.

I would like to see in the next version/release the ability to scale a package workflow or data flow process during the execution at run time. Once a workflow is developed, a snapshot of the code is taken and a scenario is created. It is the scenario that is executed during run time. In order to add a step to the package workflow, you must modify it and re-create another scenario. Thus, making such changes to package workflow can impact other packages that are dependent.

I have used this product for more than 13 years. I was first exposed to this product back in 2003. Before Oracle Corporation purchased the product, it was formerly known as Sunopsis. I learned to develop workflow packages with version 3.

We experienced no issues with the deployment.

It’s a perfectly stable product and we’ve not experienced any issues.

We have been able to scale it for our needs.

Oracle technical support for this product is excellent.

Although the initial setup was straightforward, you must decide if you will create one schema for the master and work repository or separate schemas. However, the product provides a step-by-step menu-driven UI, which makes the installation a breeze.

The implementation was done by both a vendor and internal resources. In addition, name standards for objects (e.g., packages, scenarios, procedures) should be considered and each package should be design independently from other packages (e.g., Modular Programming).

MS SQL Server Integration Services (SSIS) was considered. However, the internally-preferred vendor company was Oracle. The availability of a license and expertise in product usage helped in the decision-making process.

The most important decision is the deployment strategy of the Master and Work Repositories that is the use of Single or Multiple Master Repositories. The company’s internal policy will determine which strategy can be used. However, the most common implementation I have seen is multiple master and work repositories. It performs and works as advertised.

The most valuable features of ODI are the relatively comprehensive ELT features (i.e. execution of data transformation and validation processes), with scheduling.

In our experience with ODI, we've found that the best use of it was with the development of our data warehouse.

There are a couple areas for improvement. First, it needs better error handling (i.e. messages, debugging). Second, it also needs the ability to perform more complex interfaces (i.e. multiple sources to targets).

I've used it for over a year.

There have been no issues with the deployment.

We have had no issues with the stability.

There have been no issues scaling it for our need.

In our experience, technical support is just average.

It is relatively complex for a first-time setup. There is a need to set up separately the RCU configuration of agents, and there's definitely a learning curve to this.

We implemented with our in-house team.

• Direct infusion of statements to the database, which allows the full use of database capability
• Ease of creating data flow and transformation
• Flexibility on technology on transformation

My customers started to increase their ETL performance with great margins. This was especially the case when ODI was used with Exadata, which allows each statement to be executed much faster.

The main problem with ODI is that you have to create each step of the transformation as a new interface. A big data flow can have more than 100 interfaces, which can make it difficult to trace the data. However, in v12, this approach changed to become more flexible.

Another complaint is with the user interface performance -- as the work repository gets bigger, issues arise.

I've used it for seven years now.

We have had no issues with the deployment.

There have been no stability issues.

It has been able to scale for all our needs.

7/10

I have a lot of experience on Oracle environments. I've started to have projects with my client using Oracle solutions. In my experience, ODI is a tool that is 100% compatible with all Oracle environments.

I can say that the level of complexity of the initial setup is medium. It is not straightforward because each customer may need specific logic on ETL approaches, so this means that your Knowledge Modules are mostly customized. Although except after the first installation and environment definitions, it is pretty easy to do after that.

I am a part of a vendor team. I think the most important thing is to decide where to reside this tool and its agent. This architectural question will help in the future to execute ETL processes. Secondly, the naming standards of all projects, immediate tables, Knowledge Module and folder names etc. are pretty important. Thirdly, versioning is crucial. All these standards should be done at the beginning of your use.

The product has a wide range of options on licensing.

The Knowledge Module is the heart of this solution. If you have nicely written Knowledge Modules, then you will not have any performance issues. The language should be kept as common as possible and all in one solution. You can write in many different languages, but the maintenance will need a wide variety of knowledge in the future. This can be very tricky in the long term. Do not forget to clean temporary tables after each execution of ETL. Otherwise, the database will be full of unnecessary data.