oscerd opened a new pull request, #2997:
URL: https://github.com/apache/camel-kamelets/pull/2997
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:
```java
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.
```yaml
- 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_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
