Apache Camel has been the integration framework of choice, but I was not the person to make the decision to use it. Compared to other competing products like Tibco Business Works, etc., it is free and open source and its licensing policy is acceptable to the management of Cox.
Message brokering across different systems, with transactionality and the ability to have fine tuned control over what happens using Java (or other languages), instead of a heavy, proprietary languages. One situation that it doesn't fit very well (as far as I have experienced) is when your workflow requires significant data mapping. While possible when using Java tooling, some other visual data mapping tools in other integration frameworks are easier to work with.
Few scenarios 1. For viewing API analytics, I think it is best in the market 2. For earning money via API monetization 3. Securing API 4. Onboarding legacy APIs to provide modern REST endpoints
Camel has an easy learning curve. It is fairly well documented and there are about 5-6 books on Camel.
There is a large user group and blogs devoted to all things Camel and the developers of Camel provide quick answers and have also been very quick to patch Camel, when bugs are reported.
Camel integrates well with well known frameworks like Spring, and other middleware products like Apache Karaf and Servicemix.
There are over 150 components for the Camel framework that help integrate with diverse software platforms.
Prohibited from using JSON.stringify on Apigee objects (tokens)
Debugging is difficult
Unable to rename or delete policies without bumping revision
Why would anyone give a js policy one name, display name something else, and script a different name?
'Trace' limited to only 20 transactions
UI allows users to add target servers, but users must utilize the api to turn on SSL.
I'm sure there's more, they just aren't coming to mind right now.
Apigee forgets (expires?) your password at random intervals without notice. Every few weeks, or days, sometimes even three times in one day, I'll attempt to login to Apigee and my password will be 'wrong'. I've reset my password and Apigee still claims it's wrong. I've had to reset my password three times before it finally let me log back in.
I am not the one deciding whether to use apigee or not really. But personally, I would recommend the use of it as developing APIs on it is easy. And as a mediator between backend servers, we could easily modify request and responses in it without touching any backend code while having a centralize gateway to access our backend APIs too.
Quite hard to get support, at least on the coding side, when we encounter blockers. But general concerns, they would schedule a call to you for them to get a whole picture of your concern. Albeit in my experience, bad really as they haven't replied about the progress, but otherwise seems to have been fixed.
If you are looking for a Java-based open source low cost equivalent to webMethods or Azure Logic Apps, Apache Camel is an excellent choice as it is mature and widely deployed, and included in many vendored Java application servers too such as Redhat JBoss EAP. Apache Camel is lacking on the GUI tooling side compared to commercial products such as webMethods or Azure Logic Apps.
Apigee is the best in the market in terms of API Analytics Apigee is having wonderful Documentation with short videos Security is a major concern and Apigee provides an easily configurable policy to secure API Quota and rate-limit is again very easy to configure on every API basis It provides various policies to transform the response from one form to another form e.g. JSON to XML or XML to JSON
Very fast time to market in that so many components are available to use immediately.
Error handling mechanisms and patterns of practice are robust and easy to use which in turn has made our application more robust from the start, so fewer bugs.
However, testing and debugging routes is more challenging than working is standard Java so that takes more time (less time than writing the components from scratch).
Most people don't know Camel coming in and many junior developers find it overwhelming and are not enthusiastic to learn it. So finding people that want to develop/maintain it is a challenge.
As a public entity it is hard to say how much ROI we can have. We have yet to create a billing and ROI plan. We are thinking of other ways to create ROI, possibly through data/service barter.
