davsclaus opened a new pull request, #28250:
URL: https://github.com/apache/camel/pull/28250
Stacked on #28246. This is the AI group of the catalog body types
(CAMEL-24961). The group is openai, langchain4j-chat, a2a, docling, milvus,
qdrant, ai-tool and ibm-watson-language: of the components the human-written
routes use, these are the ones used most that had no body types yet.
**What the catalog says now**
| Component | Producer input | Producer output |
|---|---|---|
| openai | `any`: the prompt, which `userMessage` can replace. audio,
image-edit, batch and decisions take their own body | `text`. With
`streaming=true`, an `iterator`. With `autoToolExecution=false`, the tool
calls. Per operation: embeddings gives a `list`, audio-speech `bytes`,
batch-results an `iterator`, decisions a Decision, and batch and moderation
keep the body |
| langchain4j-chat | `any`. CHAT_SINGLE_MESSAGE_WITH_PROMPT takes a `map`,
CHAT_MULTIPLE_MESSAGES a `list` | `text` |
| a2a | `text`, `bytes`, `stream`, `file` or `pojo` (a Message). The task
and push config operations read headers | `text`. Per operation and
`dataFormat`: an `iterator` of events, a `list` of tasks, a config |
| docling | `any`, as `CamelDoclingInputFilePath` can replace the body. The
batch operations take a `list` | `text`. A DoclingDocument, a status, metadata,
or the batch and chunk results |
| milvus | `pojo`: the request of the SDK | `pojo`: the result of the SDK |
| qdrant | `pojo`, `list` or `null`, by the action header | `list`, `pojo`
or `unchanged` |
| ibm-watson-language | `any`, as a header can give the text | `pojo`:
AnalysisResults |
The consumers:
- the openai webhook gives the event (UnwrapWebhookEvent) and answers
without a body;
- a2a gives the text of the message (the Message with `dataFormat=POJO`) and
replies with text or a Message;
- docling gives the converted document as text;
- ai-tool gives no body, as the arguments are headers, and sends the body
back as text.
**Checked at runtime** against llama3.2 on a local Ollama, through its
OpenAI API:
- chat-completion gives a String, also with `jsonSchema`;
- with `streaming=true`, an Iterator of ChatCompletionChunk;
- responses gives a String;
- with `autoToolExecution=false`, a `java.util.Optional` of the tool calls;
when the tools run, a String;
- the ai-tool route gets no body, and the argument as a header;
- the three operations of langchain4j-chat give a String.
The local server was not started for embeddings, so I took that body from
the SDK, where `Embedding.embedding()` returns a `List<Float>`. The other
components were read from their code.
**Two changes, for openai**
- The validator reads the options in the path of an endpoint, as the catalog
parses them. The operation of openai is in the path (`openai:embeddings`). A
path the catalog cannot read, such as a `toD` with an expression, says nothing
about its options.
- The build rejects a `byOption` value that its option cannot have: it must
be a value of the enum, or true or false for a boolean, ignoring case. A
misspelled `embedding` would otherwise never hold. The 166 values in the
catalog pass.
**When a header can replace the body.** Tooling cannot see headers. The
prompt of openai, the text of Watson and the file of docling can each come from
a header, and then the body is not used. So those inputs are `any`, and the
description says what the body must be without the header. This way the
validator never reports a body that a header replaces.
**Measured.** I ran the validator over the 1204 human-written and 1209
model-written route files: the reports are the same as with #28246. The human
files use openai 7 times, a2a 5, langchain4j-chat 2, ibm-watson-language 2, and
milvus, qdrant and ai-tool once each. None reads a field of the text answer
without an unmarshal: the milvus example splits the text with
`${body.trim().split(';')[0]}`.
**Tests**
- `TextBodyFlowTest.testTheOptionsInThePathOfTheEndpoint`:
- a field read on the JSON answer of chat-completion is reported;
- `llm:embeddings` gives a List;
- a `toD` with an expression in the path says nothing.
- `EndpointSchemaGeneratorMojoTest`: a value the option does not have.
- These pass:
- the 280 tests of camel-yaml-dsl-validator;
- the 187 validator tests of camel-jbang-core;
- the 102 tests of camel-package-maven-plugin.
Docs: the validation page has the openai example, and the catalog page lists
the new build check.
_Claude Code on behalf of davsclaus_
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
