Y24-021 Update the message consumer to process Bioscan messages and pass the request to Traction Service

[sdjmchattie]

User story
A consumer should be set up to process messages for Pool XP tubes going to Traction. This should probably be added to the existing code base for the TOL Lab Share repo, but we need to consider whether it should be run as a separate process (and therefore deployment) or if we want one process to handle both TOL and Bioscan messages. If the latter, the consumer would have to be a separate instance inside the one process since a consumer can only listen to one queue at a time. The risk with the latter is that an issue in one consumer that takes the process down affects all consumers at once and scaling needs to be considered, though that is unlikely to be a real issue if RabbitMQ and Traction are coping with the load.

We should also be considering how to log issues with processing messages. The design is planned to not have feedback messages going back through to Limber about the submission success. As such, if a message fails to process and needs intervention that will need to be logged robustly. A good idea might be to have a separate Slack channel that only posts messages when a RabbitMQ message has failed in a way that requires intervention. The design of such reporting will need to be considered as this is developed.

Who are the primary contacts for this story
Stuart McHattie

Who is the nominated tester for UAT
PSD

Acceptance criteria
To be considered successful the solution must allow:

• The TOL lab share repo is augmented with new processors and message types.
• Processed messages go to Traction Service API to add the Pool XP tube data.
• Reporting for failed messages is robust and organised so that PSD know if a problem has occurred and can intervene.