[686c] RBPS Re-Processing Phase 3 | Prepare for RBPS Testing

[HeatherWidmont]

Product Outline

Link

High Level User Story/ies

As Team Tree, I need to prepare for RBPS Testing so I can proceed with reprocessing null 686 claims.

Hypothesis or Bet

If we prepare for RBPS Testing then we can move to RBPS Testing.

Description

For context, ideally, we should be able to "retry" each failed submission that resulted in a null claim by simply running the same code that was used in the original attempt, with the same form data the veteran used in the original attempt. Put another way, ideally, we would be able to re-submit the veteran’s form data to RBPS, using the same endpoints as before, in the same order as before, to reprocess previously failed claims. Before doing so, we will need to test RBPS and determine to what extent it can reprocess previously failed claims. Fortunately, RBPS has a testing environment (“prodtest”) that we can use to run tests without impacting production data.

There is a lot that will go into this. Steps envisioned by Eugene below:

1. Get whatever information and credentials are necessary to use BIS’s prodtest environment.
2. Review and merge an enormous pull request which redesigns our form submissions jobs so that they can be re-run.
3. Figure out how to get ICNs for a veteran, given a PID, name, DOB, SSN, and other information.
4. Write new BIS testing code so that we can use our production data with BIS’s prodtest environment that, among other things:
   • Does not alter VA.gov production data.
   • Logs appropriately and distinctly from our other production logs.
   • Is built so we can easily keep track of our progress.
   • Tracks errors to be kept aside and potentially retried later.
   • Validates that the PID maps to the same veteran record as the saved claim’s form data.
   • Ensures that veterans do not receive confirmation or failure emails during testing.
5. Run occasional tests with RBPS to verify assumptions, and iterate on our testing code if those assumptions prove to be incorrect.
6. Determine which subset of null claims we want to run a formal test with.
7. Discuss testing plan, assumptions, and potential edge cases with BIS.

Best Case - 1 Month

In the best case, the most substantial pieces of work would be steps 2 and 4 listed above. Step 1 would only entail getting an endpoint from BIS. As to step 3, we could get easily get ICNs via a MPI endpoint. Initial tests (step 5) would not raise any significant issues. Discussions on steps 6 and 7 are short and sweet. BIS and MPI are all readily available to collaborate when necessary.

Expected - 1.5 Months

In actuality, Eugene expects that step 5 and 7 will be relatively involved.

Worst Case - 2.5 Months

Assumes that we have difficulties, on the devops side, integrating with BIS’s prodtest environment; that it will be difficult to get ICNs without developing an integration with MPI; that tests (step 5) with RBPS go very badly and lots of iteration is needed; and in discussing our testing plan in detail with BIS (step 7), we discover some big issues that need to be addressed by a testing plan; and BIS and MPI are not always readily available.

Dependencies

BIS and MPI's availability and expertise.

[Link to full RBPS Re-Processing Estimates Doc](https://docs.google.com/document/d/1a41sVMaWsVBI0HWyOsqonDdSK547p6qQ8hNf3t7NRMU/edit)

OKR

Which Objective / Key Result does this epic push forward?

Definition of done

What must be true in order for you to consider this epic complete?

Take into consideration Accessibility/QA needs as well as Product, Technical, and Design requirements.

[steele-lm]

Closing as null claims will no longer be processed through RBPS.