Solace Read connector: data classes and mapper

[bzablocki]

PR for the Solace Read connector (addresses #31440).

Adding the data class and mapper

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• 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.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[bzablocki]

R: @damondouglas

[github-actions]

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control

[damondouglas]

Apologies, I know we talked about the need for the SchemaFieldNumber when it comes to Dataflow updates. Is this the only reason for it? If so does this update error only happen with Schema updates? It seems like a lot of investment i.e. repeated annotation for a situation that may seem rare. This will be the last time I raise this issue and thank you again for talking about it.

Is it possible to provide references to the solace API so that someone seeing the code can match the various fields with the solace API reference?

[damondouglas]

Where in the code are these constraints enforced? Iimplementing one's own Builder build method with autoBuild(); would allow for these constraints, however when doing this, you'll get an error when deriving a Beam Schema/Row. In such situations, I've ended up using a Pojo instead of Autovalue, though I prefer AutoValue when instantiating my own classes. I'll support whatever you decide but thought it would be helpful to enforce this behavior somewhere and write a few unit tests to validate.

[bzablocki]

These are not actually constrains imposed in the code in this connector. These are constrains from the respective methods of BytesXMLMessage (for example, BytesXMLMessag#getPriority) and I copy pasted them as this class is basically read-only (at least in the read connector), and a user will not create it manually.

This got me thinking, if these restrictions should be mentioned here, or should I only leave a references to the relevant documentation pages of the BytesXMLMessage class. What do you think?

[damondouglas]

What would Solace respond with if the message ID was an empty string instead of null?

[bzablocki]

I'm not sure, the documentation for this method doesn't specify this. But since this is a read connector, and a user will not create this class manually, should we worry about this?

[bzablocki]

Apologies, I know we talked about the need for the SchemaFieldNumber when it comes to Dataflow updates. Is this the only reason for it? If so does this update error only happen with Schema updates? It seems like a lot of investment i.e. repeated annotation for a situation that may seem rare.

I actually ran a few additional tests. I discovered that updating doesn't work well if the coder is inferred from the schema registry, no matter if the SchemaFieldNumber is there or not. In this connector, the coder is inferred from coder registry by default, so there should be no issues. This annotation matters more for the write connector, so I will add it only later, with the write connector PR. So thanks for bringing my attention to it again.

[damondouglas]

Thank you @bzablocki