ngibanel opened a new pull request, #40108:
URL: https://github.com/apache/beam/pull/40108
## Summary
SolaceIO now supports user properties (message metadata) mapping in both the
read and the
write direction.
Fixes #40099
## Motivation
The SolaceIO serialization layer (`Solace.SolaceRecordMapper`) currently
drops the JCSMP user
property map (`XMLMessage.getProperties()`, an `SDTMap`) in both directions:
- **Read**: `toRecord` does not map `getProperties()` into `Solace.Record`,
so all
header-level metadata carried by the message is lost when reading from
Solace.
- **Write**: `toMessage` never calls `setProperties(SDTMap)`, so it is
impossible to publish
user properties from a Beam pipeline.
User properties are the recommended way to carry small header-level metadata
fields alongside
the payload. They are also the mechanism that interoperates across
protocols: Solace translates
the SDTMap user property map to/from MQTT 5 user properties and AMQP
application properties.
Supporting them enables cross-protocol (MQTT 5 / AMQP / SMF) metadata
interoperability from
Beam pipelines.
This is a follow-up to #39875, reusing the same mapper/protocol layer
introduced for
payload type support.
## Changes
- `Solace.Record` gains a `userProperties` field of type `Map<String,
String>` (schema field 14).
It defaults to an empty map and is never null, so application code does
not need null handling.
- **Deserialization** (`toRecord`): each entry of the JCSMP `SDTMap` is
stringified
(`String.valueOf`) into the record. Entries with a null value are skipped
with a warning;
entries that cannot be read are logged and skipped. A message without user
properties maps
to an empty map.
- **Serialization** (`toMessage`): when the record carries a non-empty
`userProperties` map,
it is published as a JCSMP `SDTMap` via `setProperties(...)`. When the map
is empty,
`setProperties` is not called, so published messages are identical to the
previous behavior.
- The string-valued map is a deliberate, accepted trade-off aligned with
MQTT 5, where user
properties are strings. Users needing the original non-string types can
cast the values back
in their pipeline code. Typed SDT values are out of scope.
------------------------
Thank you for your contribution! Follow this checklist to help us
incorporate your contribution quickly and easily:
- [x] Mention the appropriate issue in your description (for example:
`addresses #123`), if applicable. This will automatically add a link to the
pull request in the issue. If you would like the issue to automatically close
on merging the pull request, comment `fixes #<ISSUE NUMBER>` instead.
- [x] Update `CHANGES.md` with noteworthy changes.
- [ ] If this contribution is large, please file an Apache [Individual
Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
See the [Contributor Guide](https://beam.apache.org/contribute) for more
tips on [how to make review process
smoother](https://github.com/apache/beam/blob/master/CONTRIBUTING.md#make-the-reviewers-job-easier).
--
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]
