Fix #1938: add an AWS Bedrock Agent sink Kamelet

[oscerd]

Fixes #1938.

The issue asks for Bedrock Agent support. Two thirds of it already shipped — this closes the remaining gap.

Camel component	Kamelet	status
aws-bedrock	aws-bedrock-text-sink	already in the catalog
aws-bedrock-agent-runtime	aws-bedrock-agent-runtime-sink	already in the catalog
aws-bedrock-agent	aws-bedrock-agent-sink	added here

aws-bedrock-agent is the knowledge-base management component. Its three operations are all about data source ingestion jobs:

enum=['startIngestionJob', 'listIngestionJobs', 'getIngestionJob']

A sink is the right and only shape — the component is producer-oriented, so the "and Source" half of the issue title has nothing to map onto. Say the word if you disagree and I will look again.

Properties

knowledgeBaseId and region are required; operation defaults to startIngestionJob.

property	notes
knowledgeBaseId	required
dataSourceId	required by startIngestionJob
operation	startIngestionJob (default) / listIngestionJobs / getIngestionJob
region	required, enum matching the component
accessKey / secretKey / sessionToken	format: password + credentials descriptor
the usual credentials-provider and endpoint-override options	mirroring aws-bedrock-agent-runtime-sink

The header strip, and why it is not optional here

BedrockAgentProducer.determineOperation reads the header before the endpoint:

private BedrockAgentOperations determineOperation(Exchange exchange) {
    ... = exchange.getIn().getHeader(BedrockAgentConstants.OPERATION, BedrockAgentOperations.class);

and knowledgeBaseId / dataSourceId are header-overridable the same way. Without a strip, an inbound message could point a sink configured for one knowledge base at another, or turn a startIngestionJob into something else — the exact pattern addressed for aws-ec2-sink in #2978.

      - removeHeaders:
          pattern: "CamelAwsBedrockAgent*"
          excludePattern: "CamelAwsBedrockAgentIngestionJobId"

CamelAwsBedrockAgentIngestionJobId is excluded deliberately — getIngestionJob has to name a job, so that one header is the Kamelet's intended message-level input rather than something it never asked for.

Verification

script/validator reports no errors, script/generator adds the nav.adoc entry, mvn clean install passes from the repository root.

Parameter binding against the real component with camel run — the route starts with everything bound:

Routes startup (total:1 started:1 kamelets:1)
    Started bed-real (timer://t)

The strip, checked by swapping the terminal endpoint for a log so the surviving headers are visible. Sending every overridable header plus an unrelated one:

in:  CamelAwsBedrockAgentOperation=listIngestionJobs
     CamelAwsBedrockAgentKnowledgeBaseId=attacker-kb
     CamelAwsBedrockAgentDataSourceId=attacker-ds
     CamelAwsBedrockAgentIngestionJobId=job-42
     keepMe=yes

out: {CamelAwsBedrockAgentIngestionJobId=job-42, keepMe=yes}

The three dispatch-controlling headers are gone, the deliberate input survives, unrelated headers are untouched.

No Citrus test — this needs a real Bedrock knowledge base and there is no emulator for it in the project's Citrus/Testcontainers toolchain, so it ships Preview without kamelet.verified=true.

Note

The catalog's headers block for aws-bedrock-agent lists CamelAwsBedrockAgentRuntime* names, but the component's own BedrockAgentConstants uses CamelAwsBedrockAgent* (OPERATION = "CamelAwsBedrockAgentOperation"). I went with the constants, which is what the producer actually reads and what the probe above confirms. The catalog metadata looks like it has the runtime component's headers copied into it — worth a separate look upstream, but it does not affect this Kamelet.

---

Claude Code on behalf of Andrea Cosentino

[oscerd]

Pushed a fix for the red build check.

KameletsCatalogTest.testGetKameletsByNamespace asserts an exact count for the AWS namespace, so a new AWS Kamelet fails it by construction:

KameletsCatalogTest.testGetKameletsByNamespace:124 expected: <31> but was: <32>

Bumped the expectation to 32. Verified against the tree rather than just trusting the CI delta — 31 Kamelets carry kamelet.namespace: "AWS" on main, 32 with this branch.

Worth noting the AWS namespace is the only one with a count assertion, which is why the SMPP and SNMP Kamelets in #2988, #2989 and #2990 did not trip it. If a maintainer would rather this were a lower bound than a change detector, that is a reasonable separate cleanup — but changing the assertion's intent felt like scope creep inside a Kamelet PR, so I left the design alone and just updated the number.

My own fault for not catching it before opening: I had run the root build with -DskipTests, which skips the catalog module's tests entirely. Re-ran the full mvn clean install with tests after the fix:

Tests run: 18, Failures: 0, Errors: 0, Skipped: 0 -- in KameletsCatalogTest
BUILD SUCCESS

Also rebased onto current main while I was here, so the branch is up to date.

---

Claude Code on behalf of Andrea Cosentino