Messages are gathered by the controller in two ways: the controller reads messages that have been persisted to the database via the curam.citizenmessages.persistence.impl.ParticipantMessage API, and also gathers them by raising the curam.participantmessages.events.impl.CitizenMessagesEvent
A decision needs to be made regarding whether to "push" the messages to the database, or else have them generated dynamically on the fly by a listener that listens for the event that is raised when the citizen logs in. The specific requirements of the message type need to be considered, along with the benefits and drawbacks of each option.
In this scenario, when something takes place in the system that may be of interest to the citizen, a message is persisted to the database. For example, when a meeting invitation is created, an event is fired. Our OOTB meeting messages functionality listens for this event, and if the meeting invitee is a participant with a linked UA account, a message is written to the ParticipantMessage table informing the citizen that they have been invited to the meeting.
One benefit of this approach is that there is very little processing performed when the citizen logs in to see this message: the message is simply read from the database and displayed, as opposed to calculation taking place that would determine if the message was required or not. However, the implementation needs to also handle any changes to the underlying data that may invalidate or change the message, and take appropriate action. For example, our meeting message functionality also listens for changes to meetings in order to ensure the meeting time, location etc are up to date, and to issue a new message to the citizen informing that the location or time has changed.
These messages are generated when the citizen logs in, by event listeners that listen for the curam.participantmessages.events.impl.CitizenMessagesEvent.userRequestsMessages event.
A benefit is that because the message is generated at runtime, code is not required to manage change over time: the message is generated based on the data within the system each time the citizen logs in, so if some underlying data changes, the next time the citizen logs in, they will get the correct message.
A drawback to this approach is that significant processing may be required at runtime in order to generate the message. Care must be taken to ensure that this does not adversely affect the load time of the citizen account homepage.
Performance considerations must be evaluated against the effort involved to manage change to the data that the message is related to over time, and the requirements of the specific message type. For example, the OOTB verification message is dynamic, when a citizen logs in it checks to see if any outstanding verifications exist for that citizen. This is a relatively simple database read, whereas it would have been complicated to listen for various events in the Verification Engine and ensure an up to date message was stored in the database regarding the participants' outstanding verifications. On the other had, the meeting messages need to inform the citizen of changes to their meetings, so functionality had to be written to manage changes to the meeting record and its related message over time.