What is our primary use case?
The main use case is "systems integration" for my company's enterprise customers across many different industry sectors.
One of our customer projects that use Oracle Integration Cloud or OIC iPaaS is ERP to e-commerce integration. Integration flows were developed for keeping product inventory, prices, addresses in sync between various end-systems. Additional non-functional goals were maintainability, stability, scalability, graceful error-handling, and "predictable performance". The predictability has been verified via repeatable testing and seamless operation in production.
Additionally, we have implemented other use-cases like shipping integration (such as DHL, FedEx), order flows from e-commerce to ERP, & many more granular and custom use cases specific to customer needs (e.g. implementing internal APIs to support larger enterprise business processes or application user interfaces, bulk data reconciliation and many more).
In general, a cloud-based product helps avoid the high lead-up times and maintenance overheads involved in setting up in-house infrastructure, and this is adequately achieved by OIC iPaaS.
OIC, in particular, is also well integrated with Oracle SaaS ERP via "business events" and easy to integrate via Rest APIs (though other integration platforms also offer API-based integration, it makes a lot of sense to use OIC if a customer already uses Oracle SaaS).
OIC offers a number of pre-built technology and SaaS adapters for high productivity for a wide range of target systems, both in-house via agents and cloud/SaaS, via a very flexible range of interfaces. These include APIs by way of Rest/SOAP over http/s, files like ZIP and CSV over filesystem or S/FTP, databases, and more. All of these interface types were utilized in our customer solutions to deliver a range of functionality in the form of "integration flows".
How has it helped my organization?
It offered a natural transition from, and in some cases, it complements Oracle's existing middleware like SOA Suite (now SOACS), Oracle Service Bus, etc, for many but not all use cases.
Furthermore, it offers a compelling solution within the Oracle environment that makes it easier to integrate Oracle SaaS ERP (via business events, APIs) with any other cloud or in-house product that might support many different interface types.
Our organization, as a neutral systems integrator with a "client advocacy" approach, also offers solutions built on open-source platforms like Apache Camel. However, the choice of platform depends on customer preferences, suitability, and fit with the rest of their IT environment. Singhpora Consulting aims to deliver good "Software Engineering" to customers on tools and platforms best suited to them, at least to the extent technically feasible, rather than promote any one particular product.
Customers must however keep in mind that the mere fact that it is "cloud" and "iPaaS" does not mean a zero-effort pay-as-you-go solution. There is still quality technical design and skill required in actually producing a good solution to be deployed on it.
Furthermore, there is still ongoing effort involved in "Systems Administration". This includes functions like physical or virtual network setup and administration, information security, DB administration, patching, updates, etc. These are not directly "iPaaS" functions but important supporting functions, and the quality of these functions can make or break a high-profile project. Some of these functions are also shared between the iPaaS vendor and professionals working for the customer.
This is over and above quality and effort involved in the "Application Development" practice, which is what developers and applications architects do. We develop and deploy integration flows that run on the iPaaS platform.
It is important for customers to keep these expectations clear when making an assessment on skills, budgets, intended outcomes, etc.
What is most valuable?
The most valuable features are:
- Easy to provision environments
- Predictable costs
- It is easy to scale instances, though scalability also depends on how well designed the actual solution is that is being deployed on Oracle Integration Cloud.
- Decent designer interface for flow design and manipulation.
- Easy to promote across environments as environment-specific "Connections" are decoupled from the actual "deployable unit" (the *.iar archive). This is a big plus, as it is better for security (credentials don't leave the environment) and also maintainability (less chance of deployment errors, less chance of promoting a deployable unit meant for TEST into PRODUCTION). Some of the other technologies do not offer this decoupling and I have seen first hand some of the undesirable situations this can lead to in some badly implemented legacy environments.
- A range of connectors for different interfaces like files, sftp, http/s Rest/SOAP, databases, and more. With OIC, things "just work", with the right skills, experience, and attitude of course.
What needs improvement?
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: https://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 220.127.116.11.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.
For how long have I used the solution?
We have been using Oracle Integration Cloud Service since Q3 of 2018.
What do I think about the stability of the solution?
Stability-wise, it is excellent. See the note on scalability. A scalable solution is also stable and predictable in the event of "infinite load".
What do I think about the scalability of the solution?
Scalability is an important non-functional requirement in any software engineering project. Scalability supports two other non-functional requirements: performance (e.g. throughput or data processed per unit time OR response time in a synchronous request-response scenario), and availability (for high availability, the environment needs more instances in a cluster so if one goes down, others can serve requests without causing downtime to consumers)
Scalability depends on two (occasionally competing) aspects:
- Platform-level scalability; this is the ease of provisioning hardware, VMs, application server instances in a cluster, etc. In the case of Oracle Integration Cloud, this aspect is well abstracted away from application developers and fairly easy to manage. It can easily scale up or down.
- The second important aspect of scalability is the actual technical design of the application. In OIC's case, "integration flow", that is deployed on the platform.
A well-designed solution can achieve the same performance on a fewer number of instances, less memory, and less CPU. A well-designed solution that is "scalability-friendly" would easily spread its load across multiple instances that might be available to it and its performance (throughput) would ideally improve linearly with an increase in the number of instances. An important quality of a scalable solution is also that in the event of "infinite load", it would only accept as much as it can easily process at a predictable rate given the resources available to it, and would then start accepting more as more resources are made available (a non-scalable solution would simply fail under such an 'overload' situation).
It often happens that some of these application design level aspects of scalability get neglected, therefore, customers often end up incurring unnecessary costs in merely "platform-level" scalability with the expectation that "performance issues" would go away by throwing more OIC instances at an application.
To deliver the best outcome to customers, both of the above perspectives on scalability need to be addressed.
For our customer's use cases, we achieved this with our application design and repeated testing with large data volumes. We did not over-engineer or over-optimize, even when we felt the solution could be enhanced to perform with higher throughput, we took customer's feedback on when the throughput was acceptable for their immediate business objectives.
How are customer service and technical support?
Technical support is excellent by and large, but could be better and more consistent.
Which solution did I use previously and why did I switch?
The choice of technology depends on the customer's environment, suitability for their use case, preferences, and other needs. We deliver solutions on multiple technologies and each can have pros and cons.
Oracle Integration Cloud was the best suited for a fairly high profile customer I worked with.
On other customer projects, we have delivered solutions on Mulesoft, Apache Camel, Oracle SOA Suite, Oracle Service Bus, and more.
There are many "conceptual" similarities that I can see as a Software Engineer, but there are very many implementation level differences not just limited to technology but also in vendor support, community eco-system, quality of professionals, etc.
How was the initial setup?
The initial setup was straightforward and it was easy to get productive. Oracle offered initial support and guidance as well, as they were keen for the technology to be adopted.
However, enterprise customers MUST seek advice from qualified professionals around systems administration and network security, including penetration testing in consultation with Oracle, and must conduct a proper risk assessment as with any other non-trivial enterprise IT system whether or not it is cloud-based.
What about the implementation team?
We developed in-house. Singhpora Consulting was sub-contracted to develop key parts of the solution
What's my experience with pricing, setup cost, and licensing?
Many open-source products can offer a high level of customizability and no upfront licensing cost. However, there can be a high cost involved in provisioning infrastructure, expertise, and other aspects.
In the case of Oracle Integration Cloud, costs can be "predictable" as far as the platform and infrastructure are concerned. The platform offers a range of pre-built adapters and connectors but it is a closed platform controlled by Oracle. This has pros and cons in terms of flexibility versus productivity.
Which other solutions did I evaluate?
For this particular customer, the Oracle PaaS platform was their choice.
However, I did evaluate SOA-CS versus OIC for some of their individual use cases. In fact, some custom functionality was delivered on JCS (Java Cloud Service from the wider Oracle PaaS offering).
What other advice do I have?
Self-promotion: Please subscribe and follow: https://weblog.singhpora.com and @SinghporaTech
Customers can contact us for no-obligations brief consultations for their use cases where they might consider our future involvement.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Which version of this solution are you currently using?