Skip to content

VA Notify

Jump to bottom
Ki Mau edited this page Sep 12, 2022 · 37 revisions

VA Notify

Overview

VA Notify is the external service that Caseflow uses to notify appellants of status changes on an appeal. The process starts whenever a tracked event changes on an appeal. The Appellant Notification module will create a custom JSON payload that it sends to an SQS queue using a Ruby Gem called Shoryuken. The SQS queue will asynchronously start to make API calls to VA Notify with the custom payload created within the Appellant Notification module. VA Notify will then send a callback to Caseflow with a status based on receipt of the payload. Caseflow will then make a record of the notification within the Notifications table as well as the Notifications Event table. VA Notify will then check the appellant's communication preferences by querying another VA Service called VA Profile using the participant id of the appellant that it was sent by Caseflow. VA Notify will then use the template id and appeal id (UUID for AMA Appeals or Vacols ID for Legacy Appeals) that it received from Caseflow to generate a notification that it will send to the appellant based on their communication preferences.

Business Impact

Scope

Additional Information

Appellant Notification

At a high level, the Appellant Notification Module is what we use to implement prepended methods that, when triggered, will send out a JSON payload to an external service called VA Notify which will in turn send out a notification to appellants based on their communication preferences (email, text, or both). The Appellant Notification module and all of the files that are extended from it can be found within app/models/prepend/va_notify. There is a file for each type of status change that Caseflow tracks. At present, the Appellant Notification module tracks 9 different types of status changes within an appeal. If any of these status changes occur, the appellant will be notified. These statuses are:

Prepend

Prepend is a method that is baked into ruby. Prepend allows additional functionality to be added to methods that already exists in Caseflow without having to alter the original method definition. The benefit of this is that all tracked statuses can be housed in one singular directory rather than altering already existing method definitions directly within their original file. A good example of how this works can be seen while looking at the method docket_appeal. This method is defined within app/models/pre_docket_task.rb. Rather than changing the method definition directly within the class so that it will now notify the appellant using the Appellant Notification Module, we can simply add that functionality to it outside of the pre_docket_task class by using prepend. All it takes to do this is adding a prepend statement at the top of the pre_docket_task class. In this instance, that would look like prepend AppealDocketed. The AppealDocketed module that is being prepended houses the updated functionality of the original docket_appeal method that is defined in the pre_docket_task class. This method will have super in it so that it inherits the original functionality as well as our notification method AppellantNotification.notify_appellant(appeal, @@template_name). This allows aspects of Appellant Notification to easily be altered in one directory rather than having to hunt down the notification methods all throughout Caseflow.

Payload

The payload that is generated and sent to VA Notify consists of the following:

  • participant_id
  • template_name
  • appeal_id
  • appeal_type
  • status

Participant ID is a unique value used to identify the Appellant.

Template Name indicates the event that the appellant is being notified of (eg. Hearing Scheduled).

Appeal ID is the unique value used to identify the Appeal. This value refers to an appeal's UUID if it is an AMA Appeal or Vacol's ID if it is a Legacy Appeal. These two types of IDs are readily identifiable. UUID's consist of numbers, letters, and dashes. Vacol's IDs only have numbers.

Appeal Type indicates if the Appeal is an AMA Appeal or a Legacy Appeal. AMA Appeals have a value of 'Appeal'. Legacy Appeals have a value of 'LegacyAppeal'.

Status indicates if the payload was generated successfully. If all parts of the payload where found, then the status would have a value of 'Success'. If the appellant could not be found, then the status would have a value of 'No claimant'. If the appellant's participant id could not be found, then the status would have a value of 'No participant_id'.

The payload is initially generated as a Ruby object called VANotifySendMessageTemplate. This class is located within app/models/vanotify/va_notify_send_message_template.rb. This object is built using two parameters. The first parameter is message_attributes, which is a hash consisting of the participant_id, appeal_id, appeal_type, and status. The second parameter is template_name.

Clone this wiki locally