[BE] 10-10EZ - Zero Silent failures: Validate APIs used

[hdjustice]

Benefit to the Veteran

As a Veteran, I want to be notified when there is a fatal error with my application, so that I can make any necessary changes for a successful submission.

Reference

• EZ zero silent failures checklist

Scope

To ensure we account for all fatal errors that can occur for the 10-10EZ form, we need to confirm the APIs we use currently, and have used since production launch in May 2016.

• Using APIs?
  • Are we using EVSS Document Upload API?
• Did your application use the same APIs when it shipped as it does today?
  • need to do research on this, I do know that we did stop using EVSS APIs, so this would be a Yes, and we need to determine what they were and what they are now for any remediation.

Tasks

• [x] Research the APIs that are used with the 10-10EZ
• [x] Research any API changes that have occurred as far back as you can go
  • Use Github tickets
  • Use any documentation found in the current and old folders
• [x] Outline the APIs used and when they were used
• [x] Tag PM to review

Acceptance Criteria

• Any and all APIs used with 10-10EZ form have been identified.

[coope93]

API's currently in use:

• Veteran Enrollment System - submit validated form data and documents
• Veteran Enrollment Eligibility System - used to validate if a Veteran is eligible for healthcare.
• S3 - Temporarily store POA files before3 submitting them to Mulesoft. Also used to store facilities .csv file that is used to validate updated facilities.
• MPI - Validate veteran status
• Lighthouse Facilities API - Used to generate list of valid facilities
• BGS - Used to get disability rating information
• VaNotify - Used to send submission failure email

Questions:

facilities job process - what all do we need to document here about that? @Mitch-A6

[coope93]

@hdjustice @longmd @Mitch-A6 I went through the 10-10EZ flow (mostly on the backend) and added the api's I am aware of. Let me know if I missed any or if we need to clarify anything here.

[hdjustice]

S3 - Temporarily store POA files before3 submitting them to Mulesoft. Also used to store facilities .csv file that is used to validate updated facilities.

Hey @coope93 - this item above applies to the CG. Do we use the same/similar service for other file uploads for EZ?

[coope93]

S3 - Temporarily store POA files before3 submitting them to Mulesoft. Also used to store facilities .csv file that is used to validate updated facilities.

Hey @coope93 - this item above applies to the CG. Do we use the same/similar service for other file uploads for EZ?

My mistake, I copied it from CG as far as the POA. We do store hca attachment files in s3 before sending them to the enrollment system, they are just not POA's and instead any of the attachment types we accept.

[hdjustice]

Next Steps: Review old Enrollment system docs to confirm if the endpoints we use are the same or if there are some old ones we no longer use. (this doc may be helpful)

[hdjustice]

After some research was done into the old archived documentation, we have found that the endpoint APIs we are using today have not changed since the form was launched.

As far as we know, the wsdl file is used to describe the available endpoints and services for an api. In our case, we have this voa.wsdl file , which was originally added 8 years ago when the 10-10EZ form was first created online. It has only had one edit (which was related to updating the gem we use to make the request 3 weeks ago), but which did not change any of the endpoint descriptions. It looks like the only endpoints we use with the enrollment system are the saveSubmitForm (used to submit the completed form) and the getFormSubmissionStatus (which is used by our healthcheck endpoint). So in conclusion, our usage in regards to which endpoints we are using have not changed since the app was first created.