add RSS feed endpoint for querying AQ message views #1512
Conversation
MikeNeilson
left a comment
MikeNeilson
left a comment
There was a problem hiding this comment.
Overall I like it. I do want to make sure that if at all practical we're exposing more standard "queue/topic" semantics.
While this will always be read only, WM staff and core developers will be interacting with the same sources of data and we should make sure things map, preferably into the future and not the past.
Will very likely be making good use of SNS and SQS for queues and topics (of which this is technically the later regardless of Oracle naming).
I'm also currently inclined towards a "queue/topic per concept" vs per-office per-concept. The latter may be an impratical amount of things to deal with when the applications can easily choose to filter and let whatever broker deal.
|
|
||
| private Result<?> retrieveMessages(int offset, int pageSize, Instant since, String office, AqTable name) { | ||
| Timestamp sinceTimestamp = since == null ? null : Timestamp.from(since); | ||
| Table<?> t = table(name("CWMS_20", "AQ$" + office + "_" + name.name() + "_TABLE")).as("t"); |
There was a problem hiding this comment.
interesting trick, taking advantage of the queue persistence.
There was a problem hiding this comment.
yeah makes it so that we don't have to pull in all the aqapi and jms dependencies and keeps us from being stateful
cwms-data-api/src/test/resources/cwms/cda/data/dto/rss/ts_stored.xml
Outdated
Show resolved
Hide resolved
MikeNeilson
left a comment
MikeNeilson
left a comment
There was a problem hiding this comment.
Your new tests seem to be breaking, but seems like a reasonable start.
| " IF SQLCODE != -24034 THEN RAISE; END IF; " + // Ignore "Already a subscriber" | ||
| " END; " + | ||
| "END;", | ||
| "CWMS_20.SPK_STATUS", |
There was a problem hiding this comment.
Don't need to do this in this PR, but this seems like something that should perhaps just be part of the CDA startup sequence.
There was a problem hiding this comment.
that's a good point. For national we'd need to subscribe to every queue, local deployments would only be for the specific office
Alternate considerations: - Looked into using a third-party RSS library for building up the XML. Seemed like the only somewhat maintained library is Rome, but that hasn't been updated since 2023 and contains the jdom2 dependency which has a known vulnerability (wouldn't really matter to our use-case of producing XML only, but would matter on the client). didn't seem too much a lift to just use our own DTO's and jackson serialization. If this ends up being a burden, it also wouldn't be too hard to update to something else in the future. - opted to not set the atom links for self or previous as those would be moving targets given the week lookback limit. We do need a next cursor so the fact that the URL would not be reproducible after a time period is unavoidable. We could also throw out the cursor and only use the `since` field. - don't search for messages older than a week. This could be shortened as needed. (cherry picked from commit 118933c)
Alternate considerations:
sincefield.