ADR-060: Apache Camel Integration Evaluation

Status

REJECTED - Integration runtime is out of scope

Date

2025-12-17

Deciders

Context and Problem Statement

iDempiere consultants frequently need to integrate iDempiere with external systems (CRM, fulfillment APIs, data warehouses, message queues). These integrations require:

Question: Should iDempiere Hub incorporate Apache Camel Quarkus to provide enterprise integration capabilities?

The Opportunity

Apache Camel offers compelling capabilities:

Example Use Case

AI-powered order export route:

from("sql:SELECT * FROM C_Order WHERE DocStatus='CO' AND XX_Exported='N'?...")
    .to("bean:orderEnricher") // Enrich with REST API data
    .to("langchain4j:validate?bean=orderValidator") // AI validation
    .choice()
        .when(header("validationResult").isEqualTo("APPROVED"))
            .to("direct:export-order")
        .when(header("validationResult").isEqualTo("FLAGGED"))
            .to("kafka:manual-review-queue")
    .end();

from("direct:export-order")
    .marshal().json()
    .to("http://fulfillment-api/orders")
    .to("sql:UPDATE C_Order SET XX_Exported='Y' WHERE C_Order_ID=:#id");

This demonstrates Camel's power: SQL polling, AI integration, content-based routing, REST calls, and database updates in ~15 lines.

Technical Feasibility

✅ Technically viable:

✅ Development effort reasonable:

Decision Drivers

Must Preserve

  1. Hub Identity: Central intelligence service for consultants
  2. Core Mission: Build software, automate support, generate docs
  3. Simplicity: Easy to understand and use
  4. Focus: Do one thing well (intelligence/automation)

Evaluate Against

  1. Vision alignment: Does this fit "central intelligence hub"?
  2. Scope appropriateness: Build-time vs. run-time concerns
  3. User clarity: What is the Hub, what is it for?
  4. Complexity management: Cognitive load on consultants
  5. Maintenance burden: Long-term ownership and support

Considered Options

  1. Embed Apache Camel runtime - Add Camel routes as optional Hub module
  2. Generate Camel integration code - Hub AI generates Camel code, deployed separately
  3. Add Camel knowledge only - Include Camel docs in RAG, answer questions
  4. Do nothing - Keep Hub focused on current capabilities

Decision Outcome

Chosen option: "Do nothing (reject runtime integration)", because it violates the Hub's core identity as an intelligence service and represents scope creep into runtime integration concerns.

Alternative path forward: Option 2/3 (intelligence + generation) may be considered in future for Phase 2+ if user demand justifies it.

Confirmation

Decision is confirmed by:

Pros and Cons of the Options

Option 1: Embed Apache Camel Runtime

Add Camel as optional module activated via profile:

java -Dquarkus.profile=integration -jar idempiere-hub.jar

Pros:

Cons:

Option 2: Generate Camel Integration Code

Hub AI generates Camel route code that consultants deploy separately.

idempiere-hub ask "generate Camel route to sync completed orders to REST API"
# AI generates: OrderSyncRoute.java, pom.xml, application.properties, README

Pros:

Cons:

Option 3: Add Camel Knowledge Only

Include Camel documentation in RAG knowledge base, answer questions.

Pros:

Cons:

Option 4: Do Nothing

Keep Hub focused on current capabilities only.

Pros:

Cons:

Why Option 1 (Runtime) is Rejected

1. Identity Violation

Current Identity (ADR-057): > "iDempiere Hub is a central intelligence service that helps consultants build iDempiere solutions faster."

With Camel Runtime: > "iDempiere Hub is a central intelligence service + integration runtime platform that helps consultants build solutions and run integrations."

Problem: This is two different products. Like combining VS Code (development) with Docker (runtime).

2. Architecture Mismatch

Current Architecture (ADR-048):

74% = Shared intelligence infrastructure (AI, tools, RAG)
26% = Interfaces to access that intelligence (CLI, API, MCP)

With Camel Runtime:

60% = Intelligence infrastructure
20% = Interfaces
20% = Integration runtime

Problem: Hub would no longer be primarily an intelligence service.

3. Scope Creep

Aspect Hub Domain Camel Domain Conflict?
Phase Build-time Run-time ✅ Different lifecycle
Output Generated code, docs, answers Running integrations ✅ Different artifacts
User Consultant building solutions Operations deploying integrations ⚠️ Different roles
Concern Intelligence & automation Integration & connectivity ✅ Different scope

Conclusion: These are different domains with different concerns.

4. Complexity Explosion

Current Complexity:

Add Camel Runtime:

Result: High cognitive load. Consultants must learn AI + integration patterns.

5. User Confusion

Current User Questions:

With Camel Runtime:

Problem: Hub serves two different use cases with different mental models.

The Better Alternative

Intelligence + Generation (Not Runtime)

Hub should generate Camel integration code, not run it.

Example Flow

$ idempiere-hub ask "I need to sync completed orders to fulfillment API"

AI Response:
I recommend using Apache Camel Quarkus as a separate integration service.
Here's why:
- Decouples integration from iDempiere runtime
- Provides enterprise-grade error handling
- Easy to deploy/scale independently

Would you like me to generate a Camel route for this? [Y/n]

$ y

AI: Generating Camel integration service...
✓ Created: order-integration/
  ├── src/main/java/com/example/routes/OrderSyncRoute.java
  ├── pom.xml (Camel Quarkus 3.27.0)
  ├── application.properties
  └── README.md (deployment instructions)

Next steps:
1. Review generated route in OrderSyncRoute.java
2. Configure API endpoint in application.properties
3. Deploy: mvn quarkus:dev
4. Monitor: http://localhost:8080/q/health

Benefits

✅ Maintains Focus: Hub = intelligence/generation, Camel = separate runtime ✅ Reduces Complexity: No need to embed 300 components in Hub ✅ Better UX: Consultants get code they can customize, not black-box runtime ✅ Flexibility: Generated code can be deployed anywhere, not tied to Hub ✅ Transparency: Code is visible and reviewable ✅ Separation of Concerns: Development vs. operations remain distinct

More Information

Vision Alignment Matrix

Hub Mission (ADR-057) Camel Runtime Intelligence/Generation
Build software from specifications ❌ No - runs integrations ✅ Yes - generates integration code
Automate support responses ❌ No - unrelated ✅ Yes - answers Camel questions
Generate documentation ❌ No - unrelated ✅ Yes - includes deployment docs
Central intelligence service ❌ No - becomes hybrid ✅ Yes - stays focused
Consultant efficiency multiplier ⚠️ Partial - adds complexity ✅ Yes - generates faster

Verdict: Intelligence/generation aligns with vision, runtime does not.

Comparison with Industry Patterns

Similar Decision: GitHub

GitHub is:

Why? Different concerns. GitHub generates configs, doesn't run workloads.

Analogy:

Similar Decision: AWS CodePipeline vs. ECS

AWS separates:

Why? Different lifecycle phases, different concerns.

Analogy:

Future Consideration Path

If user demand justifies it, Option 2 (Intelligence + Generation) could be implemented:

Phase 1: Knowledge (2 weeks)

Phase 2: Code Generation (4 weeks)

Phase 3: Architecture Guidance (1 week)

Requirements for reconsideration:

References

Research Study:

External Resources:

Industry Precedents:

Key Takeaways

What We Learned

  1. Technical feasibility ≠ strategic fit - Camel Quarkus integrates beautifully technically, but violates architectural principles
  2. Scope discipline is critical - Intelligence service is a clear, valuable identity; dilution weakens it
  3. Generation > Runtime - Generating code consultants can customize is better than black-box runtime
  4. Separation of concerns - Build-time and run-time concerns should remain distinct

Decision Summary

Question Answer
Is Camel technically compatible? ✅ Yes - perfect fit
Does Camel provide value? ✅ Yes - 300+ connectors, EIP patterns
Should we embed Camel runtime? ❌ No - scope creep, mission drift
Should we add Camel intelligence? ⚠️ Maybe - future consideration if demand justifies
What's the Hub's identity? ✅ Central intelligence service (build-time)

Recommendation

REJECT Apache Camel runtime integration.

PRESERVE the option to add Camel intelligence (knowledge + generation) in future if user demand justifies the investment.

MAINTAIN Hub's focus as a central intelligence service for building iDempiere solutions, not running integrations.

ADR-060 | Version 1.0 | 2025-12-17 Status: REJECTED Next Action: Archive study, no implementation planned

Appendix: Decision Comparison Table

Criterion Embed Camel Runtime Intelligence + Generation Current (Do Nothing)
Vision alignment ❌ Violates ✅ Aligns ✅ Aligns
Scope appropriateness ❌ Scope creep ✅ Appropriate ✅ Appropriate
Complexity ❌ High (+300 components) ⚠️ Medium (RAG + templates) ✅ Low
User clarity ❌ Confusing (2 products) ✅ Clear (code generation) ✅ Clear
Development effort ⚠️ High (6-8 weeks) ⚠️ Medium (3-4 weeks) ✅ None
Maintenance burden ❌ High (runtime support) ⚠️ Medium (template maintenance) ✅ Low
User value ✅ High (if needed) ⚠️ Medium ❌ None
Deployment complexity ❌ High (profile config) ✅ Low (separate service) ✅ None

Overall Score:

Decision: Do nothing now, consider intelligence/generation if demand justifies.

Path: /docs/developers/architecture/idempiere-hub/060-apache-camel-integration-evaluation