What needs improvement with Oracle Integration Cloud Service?

Improvements in Oracle Integration Cloud Service include addressing bugs, such as unexpected closures during development. Users can report issues through Service Requests (SR) with Oracle's customer support, which promises a 24-hour response. Oracle communities provide solutions for known problems. There's potential for more functionality, including additional functions to complement existing capabilities such as minimum, maximum, substring, and more. Setup and deployment can be done in OCI, the Oracle Cloud Infrastructure, allowing for role-based access and configuration, managing access levels for Oracle Integration Cloud Service environments such as Dev, Test, and Production.

One area requiring improvement involves multi-tenancy scenarios, as no customers operate on a single cloud. Most large customers use multiple clouds, and Oracle's partnership with Azure and other hyperscalers needs additional development on the Integration Cloud Service side.

The ease of configuration is something that could be improved. The mapping is a bit complex, so configuration is not very easy for a new user. The mapping part is complex.

Other than ready-to-use solutions and services to consume it, anything has to be developed. It has to be developed. And all the other Oracle PaaS solutions have to be procured to develop, deploy, and start using it. So sometimes what happens is such things become an expensive proposition, though it is a powerful solution. The only thing is, if I have to build a solution, I have to start consuming the other services on the cloud, which becomes a pretty expensive solution if I have to develop it. So that’s the only thing. In fact, we are also part of the product. We are a partner with Oracle, and we are also working with their product team on this, giving feedback and things like that. That is an ongoing process between us and Oracle. Oracle needs to ensure that some of the most commonly used types of consumption or services are bundled—for every industry, every vertical, and even region-specific services like payment gateways, suppliers, and logistics suppliers—so that they can be consumed straight away. This would provide absolute value for money in terms of time to market, faster deliverables, and quick implementation.

The solution should improve its support.

In Oracle, most of the things are based on XML and SOAP Messages. Nowadays, JSON is also very much in use. Most of the integrations are JSON-based with mobile phones, and all are coming into the picture. Most of the digital integrations are based on JSON. If I use Oracle Service Bus, I know it mostly uses XML and Java-based or JSON objects. Oracle has most of the message exchanges between XML, and it supports SOAP Messages. The support for JSON should be more in Oracle Integration Cloud Service. The tool offers very good capabilities for transforming XML and objects. With JSON, if the tool provides support similar to XML, then it would be helpful. Nowadays, most things are on JSON, both digital and mobile. The pricing model could be more flexible for clients.

In terms of the area of improvement in the product, I would say that the way we design the services is very limited. The kind of architectural design we can have is an area that is pretty limited if I compare it with a tool named Boomi. We could not expect everything to be done like what we have done in Oracle, SOA Suite, or MuleSoft. The design is limited to five or six design approaches, and within that, the number of activities is limited. The debugging part is sometimes difficult in the tool. There have been situations where the drag-and-drop features might not work, so you need to include some coding, but it may not be that user-friendly. If I compare it with Boomi, you can put Groovy and some other scripting languages, which might help you navigate tricky situations where your drag-and-drop feature doesn't work. I would not say the tool is lacking in something. There might be different ways to do it. If somebody has to choose between a couple of products, they can choose Oracle Integration Cloud Service as one part, and the other part is the deployment environment. We are still in Oracle Cloud, and if the things in it can be moved to AWS or Azure and made compatible with other tools, then it would be good.

Oracle Integration Cloud Service could have better intuitiveness compared to Microsoft products. It has lengthy documentation, making the process of building applications more time-consuming. These particular areas need improvement.

Dealing with the large file sizes has occasionally been a challenge, though we have found workarounds. But dealing with large file sizes could be easy in integrations. I have also come across schema files where headers, footers, and bodies are there, but it's not a valid schema. None of the MSCAs are defined properly. In such cases, we have to think of multiple workarounds, such as splitting or merging. But this is a standard requirement for organizations, so custom solutions should be provided. There are cases when the systems don't expect additional MSCAs, or they expect headers, footers, or tags with different values. But this is not a proper XML. So if we are dealing with XML conversions, mapping, and integrations, we have to do some custom work. These are solutions that Oracle can provide.

They should include more integration for the solution with other platforms. Also, they should provide tutorials for beginners to learn about the processes.

In designer mode, sometimes the browser closure or other unknown issues can cause strange behavior, which requires a restart. I've also experienced issues with caching.

It would be helpful if there were more tutorials or documentation to learn about Oracle Integration Cloud Service.

There is a limitation with the file size that Oracle Integration Cloud Service can read and transform. If an inbound file is larger than one GB, it cannot be transformed within Oracle. In cases where we face that limitation, we have to use other solutions that can handle higher volumes. For each delivery, we use it in conjunction with Oracle OIC, which is another Oracle product, and they could make it easier for us to query the underlying data, at least with the Oracle tables. It is a tedious task and we have to write VIP reports and get that data via web services, so that is something that they can improve.

We would love to have more and more ready-to-use interfaces from Oracle. We'd like to download the marketplace right away. We'd like it, so we don't have to put in so much effort with integration. Therefore, I'm still keen to see a continuation in the addition of ready-to-use interfaces.

I think this product is evolving and there are certain areas where there are still some limitations. The solution has a payload size limit and there are some legacy applications we'd like to integrate but can't. We can get what we need using our on-premise product, but not OIC. Our clients generally have on-premise servers and they have processes they'd like to convert to OIC but they're not supported and so our clients look for other solutions. I would like to see more flexibility regarding accessibility to files.

Oracle Integration Cloud Service can improve file handling. Currently, our real-time file polling limitation is 10 MB, if that size can be increased it would be helpful. For example, increasing the size from 10 MB to 1 GB.

The solution did use to have stability issues, however, that is now dealt with. The solution is expensive. We would always prefer any solution to be more secure.

This is entirely web-based development. We lack an IDE for developing integrations. Back in the days of OSB and BEPL, we had to go into the code and not just drag and drop. We used to go into XML and modify it. We could, for example, edit some XSLT or XQuery documentation, but this is mostly a drag-and-drop. A person cannot directly enter the code or examine and modify so many variables. As a result, one had to rely solely on the drag and drop feature. Oracle has implemented a few modifications. For example, you can now manually edit the XSLT by going into the code, but there are many things you cannot change. You cannot move from one location to another. UI-based controls still have room to improve, but migration can be made simple. If we are migrating integrations from one environment to another, such as development to testing, if it is a one-click migration, which is possible in some cases, that would have been good. As of now, we simply export the IIR and import it into the new environment. Migration and the User Interface could be improved. Make it more similar to the on-premises features. For example, if you can edit the code directly rather than just dragging and dropping, or if you can edit the examples by going into the background, and one-click migration, I'd like to see included in the next release.

In terms of improvement, debugging and error handling, Oracle can be much more user-friendly on this, because clients must provide a much more error handling framework, which is a monitoring framework, that is much better. The current one has some level of monitoring, but then there are retrying mechanisms, automatically retrying mechanisms and error recovery mechanisms. Those things need to be greatly improved; they have something, but it is very basic. The error retrying mechanism could be improved. If an error occurs, it can be retried automatically, it would be helpful. Resilience can be enhanced. The migration flow has to improve. They have some kind of agent connecting with the on-premise systems. We need to simplify the process of connecting with non-cloud applications. If you have to connect to some servers from this cloud to non-cloud, that is a bit of a hassle. They now have something called an agent for those, but they can simplify it, and the error frameworks can be implemented much more effectively.

The bulk processing needs improvement. When the data it needs to process is huge, then it does not work well, for example, when we're talking about gigabytes or terabytes. If data is received in this way, then this middleware doesn't work properly. We would like to see more out-of-the-box adapters with different boundary applications. The solution needs the support of more EDI protocols, like RosettaNet.

There are a few features that we noticed are not in the cloud. There are some improvements needed. One example is the graphical user interface that needs to improve, it could be easier to use.

Improvements can be made in several areas, as follows: * Configurable timeouts on each connection would be better than a single global timeout that applies to all. The rationale for why timeouts are necessary is described here: weblog.singhpora.com/2019/07/fault-tolerance-in-integration-flows.html In my opinion, this feature can actually save resources (CPU, memory) for Oracle and also deliver better runtime functionality to customers. * Retryable scopes and activities could be useful. * Easier ability to edit a DB operation via DBAdapter when a schema changes, such as a column added or removed from a table. At least as of version 20.1.3.0.0 (200401.0200.34935), this required some careful manual editing of artefacts. * Better ability to edit XSLTs and maybe XQuery in the future. As of this version, any non-trivial editing of XSLT requires unpacking and re-packing the deployable archives (iar) manually. * Ability to add Java libraries for very corner situations like file/ftp adapter valves, which is a feature that exists in Oracle Service Bus and can be very useful in some rare situations. * Consistent Oracle Support experience. I had the pleasure of interacting with some of the finest professionals in the industry, from the infrastructure and systems administration team allocated by Oracle to the customer. However, in some other situations, I found it very hard to explain very basic issues to Oracle Support. It involved so much effort and repetition that I often found it simpler to find a workaround or alternative. Ultimately, Oracle support did provide solutions too, and acknowledged some of my important enhancement requests for future product quality.

It lacks configurable time-outs on connections. Configurable time-outs is an important nonfunctional property that it is currently missing. I have also written about it in an article, and I have also submitted some enhancement requests. Its visual designer could be a bit more responsive. It would also be good to get more XSLT editing capabilities.

IDCS doesn't currently have a fully fledged workflow feature like they have in OIM for provisioning lifecycle management of the user, which means having to create a user in IDCS, getting approval for the financials and security before pushing into the Oracle Financial Cloud setup. They have a light version for now and that should be improved. If you want to provision a user with IDCS, you need to kick an approval process and rely on PCS for that, which is risky. We are currently using OIM as an on premise application, where you get the full suite of approval and don't have to go to other cloud applications. That's lacking in ICS. There's no out-of-the-box solution like OIM in IDC. There's also no in-built hierarchy for approval. You can't directly use your HR hierarchy for the approval process. It requires writing custom approval policies and maintaining the provision to do that. More approvals features would be good. Finally, there are two options of database. You can bring your own license, or take the enterprise license and use it as a loan license which unfortunately costs. Given that we're already paying for the database enterprise, why should we go and pay again for the PaaS. We've asked about that but haven't had a good response.

Our client was quite concerned about the cost, which is something that could be reduced. Having more documentation about different use cases and test cases would be helpful when it comes to integration.

It could be improved in the supply chain. I think some of these features are just available to their own consulting services, their own professional services arm. Not all features are available to the implementation partners. So especially the features that are related to leverage mission turning and artificial intelligence. They're still not available to the partners in reality. So in that case, if they make tools framework available for us, then we would give them an eight.

The solution could benefit from using things like AI and machine learning. For example, with certain orchestration fails it would be helpful to look at them as a way to either terminate or re-issue or restart the whole process again. Oracle-based automation blueprints for the majority of the integrations would be helpful to have in a future release. There are some default recommendations that shouldn't be done in some of the firewall integrations. At the end of the day, I don't use the product straight out of the box. Some of the finer integrations have problems like looping or standard patterns that we will have to integrate with Windows and Linux right away. It would be helpful if Oracle could provide one quick deployment method. The solution needs to provide good oversight over the entire integration platform, with more analytic capabilities.

The product has to mature a lot. I think they've created a lot of cloud integration platforms, and their integration cloud has to mature a lot more in terms of features and capabilities. There are other improvements for the integration cloud, like how it works with EPI. They should bring in more orchestration and integration because it's a cloud-based solution. Now the platform is not built in a way that you can define.

There could be much improvement in integration and automation within the solution. The solution needs better dashboarding. There should be reports on running reloads, how things are being deployed and what's in the pipeline. If there was a nice dashboard to have a look at this information, that would allow for more control of the tool itself. From a performance perspective, there could be more improvements done.

Some of the adapters could be enhanced to make integration even simpler. The example I would use is the GMail interface - it requires Base64 encoded content. But to make the interface simpler, the API should provide the encoding and the adapter simply accept plain text.