CAMEL-23466: camel-aws-bedrock-agent-runtime - Add retrieve operation

[oscerd]

Summary

Adds the retrieve operation to the camel-aws-bedrock-agent-runtime component.

The component previously only exposed retrieveAndGenerate (semantic search + LLM
generation) and invokeFlow. The Bedrock Retrieve API — semantic search against
a knowledge base returning the matched chunks without invoking a model — was
missing despite already being supported by the underlying SDK
(BedrockAgentRuntimeClient.retrieve(RetrieveRequest)).

This is a common operation when users want to plug in their own generation step,
inspect retrieval quality, or paginate through knowledge-base hits.

Changes

• BedrockAgentRuntimeOperations: new retrieve value.
• BedrockAgentRuntimeProducer:
  • dispatches the new operation in process(...) and routes to a new retrieve(...) method;
  • supports both header mode (String body = query text, knobs via headers) and
    POJO mode (pojoRequest=true → body is a RetrieveRequest, forwarded verbatim).
  • surfaces results as the out-message body (List<KnowledgeBaseRetrievalResult>) plus
    a RETRIEVED_RESULTS header for parity with the existing CITATIONS pattern.
• BedrockAgentRuntimeConstants: new headers
  • CamelAwsBedrockAgentRuntimeRetrievedResults — the matched chunks.
  • CamelAwsBedrockAgentRuntimeNumberOfResults — overrides numberOfResults.
  • CamelAwsBedrockAgentRuntimeSearchType — overrides overrideSearchType (HYBRID/SEMANTIC).
  • CamelAwsBedrockAgentRuntimeNextToken — pagination token (in + out).
  • CamelAwsBedrockAgentRuntimeRetrieveGuardrailAction — guardrail action when present.
• Unit tests covering: default request build, header-driven knobs (numberOfResults,
  overrideSearchType, nextToken), failure when knowledgeBaseId is missing, and POJO mode.
• Regenerated catalog JSON and endpoint DSL artifacts.
• Updated aws-bedrock-agent-runtime-component.adoc.

JIRA: https://issues.apache.org/jira/browse/CAMEL-23466

Test plan

• mvn clean install from the module directory — module tests green (4 new + existing).
• mvn clean install -DskipTests from the repo root — full reactor build green.
• Manual smoke against a real Bedrock Knowledge Base (left to reviewer / follow-up).

---

Claude Code on behalf of Andrea Cosentino

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• catalog/camel-catalog
• components/camel-aws/camel-aws-bedrock
• dsl/camel-endpointdsl

All tested modules (10 modules)

• Camel :: AWS2 Bedrock
• Camel :: Catalog :: Camel Catalog
• Camel :: Endpoint DSL
• Camel :: JBang :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: TUI
• Camel :: JBang :: Plugin :: Validate
• Camel :: Launcher :: Container
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[gnodet]

Nice, clean addition — the retrieve operation fills a real gap and follows the existing producer patterns well. Tests, docs, and regenerated artifacts all look solid. A couple of minor observations below (both non-blocking).

This review covers project conventions, code patterns, test coverage, and documentation. It does not replace specialized review tools (CodeRabbit, Sourcery) or static analysis (SonarCloud).

Claude Code on behalf of Guillaume Nodet

[gnodet]

Nit: minor style inconsistency — the existing retrieveAndGenerate and invokeFlow cases call their methods with just exchange, and those methods fetch the client internally via getEndpoint().getBedrockAgentRuntimeClient(). Here the client is resolved at the call site and passed in as a parameter.

Not a functional issue at all, just a pattern mismatch that caught my eye. Feel free to ignore.

Claude Code on behalf of Guillaume Nodet

[gnodet]

The mock response exercises the nextToken path nicely, but the guardrailAction response-handling path in prepareRetrieveResponse is never covered — the mock response does not set a guardrail action, so the RETRIEVE_GUARDRAIL_ACTION header branch is untested.

Consider either adding .guardrailAction(...) to this mock response (and asserting the header in the first test), or adding a small dedicated test with its own mock response that includes a guardrail action. Low priority but would close the gap.

Claude Code on behalf of Guillaume Nodet