What would you like to happen?
Problem statement
The Apache Beam Solace SDK currently drops the JCSMP user property map (XMLMessage.getProperties(), an SDTMap) in both directions:
- Read: SolaceRecordMapper.toRecord does not map getProperties() into Solace.Record, so all header-level metadata carried by the message is lost when reading from Solace.
- Write: SolaceRecordMapper.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 is required for cross-protocol (MQTT 5 / AMQP / SMF) metadata interoperability.
Proposed change
Extend Solace.Record with a userProperties field of type Map<String, String>:
- Deserialization (toRecord): map each entry of the JCSMP SDTMap into the record, stringifying values (SDTField.toString()). A message without user properties maps to an empty map (never null), to avoid NPEs in application code.
- Serialization (toMessage): when the record carries a non-empty userProperties map, build an SDTMap via JCSMPFactory and set it with setProperties(...). When the map is empty, setProperties is not called, so published messages are byte-identical to the current 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 back in their pipeline code. Typed SDT values are out of scope.
This continues the serialization/deserialization work introduced in #39875.
Issue Priority
Priority: 3 (nice-to-have improvement)
Issue Components
What would you like to happen?
Problem statement
The Apache Beam Solace SDK currently drops the JCSMP user property map (XMLMessage.getProperties(), an SDTMap) in both directions:
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 is required for cross-protocol (MQTT 5 / AMQP / SMF) metadata interoperability.
Proposed change
Extend Solace.Record with a userProperties field of type Map<String, String>:
This continues the serialization/deserialization work introduced in #39875.
Issue Priority
Priority: 3 (nice-to-have improvement)
Issue Components