제어기가 다음 두 방식으로 메시지를 수집합니다. 제어기가 curam.citizenmessages.persistence.impl.ParticipantMessage API를 통해 데이터베이스에 지속적인 메시지를 읽습니다. 또한 curam.participantmessages.events.impl.CitizenMessagesEvent를 발생시켜 수집합니다.
데이터베이스에 메시지 "넣기" 여부를 결정하거나 시민이 로그인할 때 발생하는 이벤트를 청취하는 리스너가 즉시 동적으로 메시지를 수집하도록 합니다. 각 옵션의 이점 및 단점과 함께 메시지 유형의 특정 요구사항을 고려해야 합니다.
이 시나리오에서 시민의 관심 대상이 될 수 있는 사항이 시스템에 발생하면 메시지가 데이터베이스에 지속됩니다. 예를 들어, 회의 초대가 작성되면 이벤트가 실행됩니다. OOTB 회의 메시지 기능이 이 이벤트를 청취하며, 회의 초대자가 링크된 UA 계정이 있는 참여자인 경우 메시지가 ParticipantMessage 테이블에 기록되어 시민이 회의에 초대되었음을 알립니다.
이 접근 방식의 한 가지 장점은 시민이 이 메시지를 보기 위해 로그인할 때 처리가 거의 수행되지 않는다는 점입니다. 메시지가 필요한지 여부를 판별하기 위해 계산이 수행되는 것과는 대조적으로 간단히 데이터베이스에서 메시지를 읽어 표시합니다. 그러나 이와 같은 구현에서는 메시지를 무효화하거나 변경할 수 있는 기본 데이터의 변경사항을 처리하고 적절한 조치를 수행해야 합니다. 예를 들어, 회의 메시지 기능은 회의 시간, 위치 등을 최신으로 유지하여 시민에게 위치나 시간이 변경되었음을 알리는 새 메시지를 발행하도록 회의 변경사항도 청취합니다.
이러한 메시지는 시민이 로그인할 때 curam.participantmessages.events.impl.CitizenMessagesEvent.userRequestsMessages 이벤트를 청취하는 이벤트 리스너가 생성합니다.
런타임 시 메시지가 생성되므로 시간이 경과함에 따라 변경사항을 관리하는 코드가 필요하지 않다는 장점이 있습니다. 시민이 로그인할 때마다 시스템의 데이터를 기반으로 메시지가 생성되므로 일부 기본 데이터가 변경되면 다음 번 시민이 로그인할 때 올바른 메시지가 표시됩니다.
이 접근 방법의 단점은 메시지를 생성하기 위해 런타임 시 중요한 처리가 필요할 수 있다는 점입니다. 시민 계정 홈 페이지의 로드 시간에 불리한 영향을 주지 않도록 주의해야 합니다.
메시지가 관련된 데이터의 시간 경과에 따른 변경사항을 관리하는 데 드는 노력과 특정 메시지 유형의 요구사항과 비교하여 성능 고려사항을 평가해야 합니다. 예를 들어,OOTB 확인 메시지는 동적입니다. 즉, 시민이 로그인할 때 해당 시민에 대한 미해결 확인이 있는지 확인합니다. 이 작업은 상대적으로 간단한 데이터베이스 읽기입니다. 반면에 확인 엔진에서 여러 이벤트를 청취하고 참여자의 미해결 확인에 관한 최신 데이터를 데이터베이스에 저장해야 하는 경우 복잡해질 수 있습니다. 한편, 회의 메시지는 시민에게 회의 변경사항에 대해 알려야 하므로 시간 경과에 따른 회의 레코드와 관련 메시지의 변경사항을 관리하는 기능을 작성해야 합니다.