EVSS - PCIU Migration Discovery

[sethdarragile6]

Issue Description

Several callouts to the EVSS PCIU API were found to occur during the "form pre-fill" phase of the 526EZ application. This ticket is to thoroughly research and determine which calls/services along this use case will need to be migrated from EVSS -be that to LH or "VA Profile".

Information delivered via EVSS today :

• contact address
• email address
• phone

---

Tasks

• [ ]

Acceptance Criteria

• Mapping of fields between the two sources
• Identify datasource
• Identify endpoints that need to be called
• How does it work? FE - Middleware - provider

---

How to configure this issue

• Attached to a Milestone (when will this be completed?)
• Attached to an Epic (what body of work is this a part of?)
• Labeled with Team (product support, analytics-insights, operations, service-design, Console-Services, tools-fe)
• Labeled with Practice Area (backend, frontend, devops, design, research, product, ia, qa, analytics, contact center, research, accessibility, content)
• Labeled with Type (bug, request, discovery, documentation, etc.)

[sethdarragile6]

Started (just barely) to map out the prefill logic in this mural. There is logic to pull (or create) contact info from a Redis cache before pulling from the VA Profile API, but I think I need more seasoned "ruby-eyes" 💎👀 to better understand what is going on with the do_cached_with...do construct. I'm assuming that what they're saying is, "pull info from the redis cache. failing that, do what's in the do block here (i.e. call the API)". But a. why are they using do, which is supposed to be used as a looping construct, and b. how exactly is the response returned from do_cached_with conditionally executing contact_info_service.get_person (the API service call)

[sethdarragile6]

Completed the diagram in this mural, only to realize/remember that this is only the base class prefill. The prefill specific to our application is here. This realization lead to some other big takeaways, over which I mobbed with @aurora-a-k-a-lightning to make sure I was interpreting right:

1. Within the 526 contact info prefill, we are calling VA Profile once, then EVSS PCIU 3 times, before calling the base class's prefill. The base class's prefill always calls VA Profile + 2 EVSS PCIU calls- unless any of those calls were just made (except the PCIU email call, which will always run again). However, because of the way we're using this, we are making those 2 EVSS PCIU calls in the base class anyway. So all told, we're making 1 VA Profile and 5 EVSS PCIU calls per user prefill. Woof!
2. Since the base class is calling EVSS PCIU, that means that most (if not ALL) form profiles in the project are making these calls- not just our lil 526 app. So while we could potentially migrate just our app away from PCIU, that leaves ~30 other apps to migrate. Yikes!

3. Also because the base class is calling EVSS PCIU and VA Profile, this means A. we've basically already migrated to VA Profile and B. apparently VA Profile was/is insufficient and necessitated additional calls to PCIU to gather better email and phone information (plus in the case of our form, address information).

@RakshindaAslam let's talk in standup tomorrow about all this and explore our options. Thanks!

[sethdarragile6]

@RakshindaAslam @aurora-a-k-a-lightning More thoughts/questions about the default prefill (base class) before going into the holidays and forgetting it all...

VA Profile potentially delivers a wealth of information about a vet. So why are they calling EVSS PCIU to grab email and phone in the default prefill?

• Calls to VA Profile require a vet360_id associated with the user. Is VA Profile an opt-in service?
  • If so, perhaps the problem is that not enough vets have opted in to make it a be-all-end-all solution?
• Maybe when prefill was initially implemented, VA Profile was lacking in this information and PCIU was used to fill the gaps.
  • If so, the PCIU calls could be (carefully) removed. "Carefully" meaning every team in charge of all of the above forms look into it and sign off on removing it 😜

Also, regarding another piece of the PCIU puzzle hinted at in the description: contact address. The contact info default prefill simply takes from the user's properties and passes them on- no external calls at this point. Fishing around slack resurfaced some references to PCIU_Address, and fishing around in vets-api surfaces quite a few as well. We need to research where/if these are being called from vets-website

• pciu_address\service.rb
• addresses_controller.rb

If there are PCIU_Address calls being made from the front end, it might be easier to migrate those touchpoints versus calls from the prefill. However, the same questions above apply here- is VA Profile a viable solution to migrate to...

[RakshindaAslam]

@mtcA6 - would you be able to help with these?

[mtcA6]

Thanks @RakshindaAslam for flagging this.

What's interesting is I found some old slack messages about PCIU being potentially the source of the address update errors in the direct deposit pages (ie. if a user didn't have an address in PCIU it caused some validation failures). This seems very similar to an ongoing issue we have today. Additionally, it also seemed like the letters application moved away from PCIU to leverage something in vets360 which I'm guessing could be our code that the profile team talked about blocking just a few weeks ago if there's a flagged user.

There's also this message which suggests Vets360 has had parity w/PCIU for some time, but Seth it seems like your saying no one ever plugged into that code in Vets360, for prefill processes at least, and everyone has continued looking/sending calls to PCIU?

Anyway, my knee jerk response is to say it seems like it would make sense for these applications to use VA Profile instead of PCIU (since PCIU is an old ebenefits backend). I'd say this is especially true since in the Profile we use VA Profile for our address and contact information data which in turn looks at MPI.

@sethdarragile6 when you said:

is VA Profile a viable solution to migrate to

What would you use to judge an answer to this question? Put differently, what makes you doubt VA Profile as a viable solution?

Or maybe I'm misunderstanding what you said above but it sounds like VA Profile already calls PCIU anyway? And 526 is already using VA Profile, so that question feels moot.

we've basically already migrated to VA Profile

@adamwhitlock1 @tpharrison can you take a look at Seth's last comment up above and take a stab at answering the questions.

[sethdarragile6]

@mtcA6 Thanks for responding! Find my comments/answers below

Additionally, it also seemed like the letters application moved away from PCIU to leverage something in vets360...

I'd be curious to know exactly what in vets360 (aka VA Profile) that was. Can you point me in the right direction for that?

There's also this message which suggests Vets360 has had parity w/PCIU for some time, but Seth it seems like your saying no one ever plugged into that code in Vets360, for prefill processes at least, and everyone has continued looking/sending calls to PCIU?

1. That thread asks about PCIU vs. "Vets.gov profile". Is that actually the same thing as "VA Profile"? That's a pretty old thread, so maybe that's what they called it before Vet360 or something? Totally guessing here 😂
2. Sorry for the confusion, that is not what I'm saying. Put another way: everyone who is using prefill is (by default) using VA Profile AND PCIU (whether they realize it or not). Some apps (like 526ez) will override some parts of that default prefill to get other custom things, but even they (like us) will usually call the default prefill in addition to that.

is VA Profile a viable solution to migrate to

What would you use to judge an answer to this question? Put differently, what makes you doubt VA Profile as a viable solution?
What makes me doubt that is that the prefill is calling VA Profile AND PCIU to get what it needs (plus my question about VA Profile opt-in, i.e. does every vet already have a vet360_id)

we've basically already migrated to VA Profile

I meant this in the sense that we are already calling VA Profile for some things by default (like most other apps are, as I explained above). The real question here is: what does migration look like? Can we truly just remove PCIU calls and still get enough prefill data? We may need to call VA Profile in different ways.

Now, multiple that question by every team's different profile- because they're calling PCIU as well by default. Hopefully that clears up what I'm saying a bit, my apologies if not. cc @RakshindaAslam @aurora-a-k-a-lightning

[sethdarragile6]

Reached out to Samara w/Authenticated Experience with our questions about all of this, and found we're still not reaching the right people 😂. However, she was able to point us in the direction of more appropriate people to ask.

For VA Profile: Mike Richard (contractor) or Barbie Flowers (VA PO) via the #va-profile channel (however he and his group are more accessible on Teams
For pre-fill: probably the Platform team

So where we stand with EVSS PCIU migration right now is that it is beyond the scope of any one team, in my opinion (except Platform, possibly?). If we can verify that one way or another VA Profile will fulfill all our needs, we (the 526ez team) could probably

1. move whatever functionality we needed from the pre-fill base class into our 526ez derived class, then
2. remove our call to the base class
3. remove the call to PCIU_Address from our 526ez derived class pre-fill

However, that would only remove EVSS PCIU calls from our application. Then, if every other team did the same (or similar) with their pre-fills, it might be safe to remove PCIU from the default pre-fill. But even after that, we need to be 100% sure that there are no further calls to PCIU_Address (via the AddressesController) from the front end before we can safely sunset EVSS.

cc: @RakshindaAslam @aurora-a-k-a-lightning @emilytheis

[sethdarragile6]

Mentioned this on the above thread but forgot to include it on this ticket: I've created this wiki page for PCIU discovery findings

[sethdarragile6]

Michael Harlow's informed opinion.

[sethdarragile6]

@sethdarragile6 test notification