The Proposal Backend

This page lists the events that are being sent over the message broker and too which queues as well as which events the system is looking out for.

RabbitMQ supports 2 main types of message queues: queues and exchanges. Broadly speaking queues are just what they seem, you can post a message to it and some consumer can take that message out it is important to note if you have multiple consumers on the same queue in theory only one of them will read the message . Exchanges (well a least the one we are using are there different types) are set up so multiple consumers can receives the same message. To do this the consumer sets up a queue and binds it to a exchange. When the producer sends to a message to the exchange it will then send the message on to any bound queues therefore ensuring all consumers get the message.

For a more in-depth look at RabbitMQ they provide a few nice tutorials: https://www.rabbitmq.com/getstarted.html

Within duo-message-broker there are 3 queues and 1 exchange defined:

    Queue["PROPOSAL"] = "PROPOSAL";
    Queue["SCHEDULING_PROPOSAL"] = "SCHEDULING_PROPOSAL";
    Queue["SCHEDULED_EVENTS"] = "SCHEDULED_EVENTS";
    Queue["BROADCAST"] = "useroffice.fanout"; // The exchange

The queues/exchange are identified through the string on the right, you can use this string to listen to the queues from other applications. To refer to a queue within the backend we can then look at the Queueenum or to send a message to the exchange we can use the sendBroadcast which will post to the "useroffice.fanout" exchange within duo-message-broker.

We have a general type ProposalMessageData which is sent over most events:

type ProposalMessageData = {
  proposalPk: number;
  shortCode: string;
  title: string;
  abstract: string;
  members: { firstName: string; lastName: string; email: string; id: string }[];
  proposer?: { firstName: string; lastName: string; email: string; id: string };
};

The data sent over the message queue:

Event

Queue

Data

PROPOSAL_STATUS_CHANGED_BY_WORKFLOW

PROPOSAL, SCHEDULING_PROPOSAL

proposalPk, callId, allocatedTime, instrumentId

PROPOSAL_STATUS_CHANGED_BY_USER

PROPOSAL, SCHEDULING_PROPOSAL

proposalPk, callId, allocatedTime, instrumentId

PROPOSAL_MANAGEMENT_DECISION_SUBMITTED

useroffice.fanout

ProposalMessageData

PROPOSAL_UPDATED

useroffice.fanout

ProposalMessageData

PROPOSAL_DELETED

SCHEDULING_PROPOSAL

ProposalMessageData

PROPOSAL_CREATED

useroffice.fanout

ProposalMessageData

PROPOSAL_SUBMITTED

useroffice.fanout

ProposalMessageData

TOPIC_ANSWERED

useroffice.fanout

proposalId, question, questionId, dataType, answer

CALL_CREATED

useroffice.fanout

All the call data

Currently the system is only listening on 1 queue SCHEDULED_EVENTS and on events:

Proposal Allocations

The STFC have the proposal allocations app to integrate the proposal system with our other systems currently. It is currently listening to the useroffice.fanout exchange for the following events: