[VI-920] updates to MPI add_person_proxy & orchestrated search methods

[bramleyjl]

Summary

• Updates to MPIData add_person_proxy and downstream methods.
  • At the end of the method the mvi_response cache is now deleted instead of being updated, forcing a new call to now-updated MPI endpoint the next time a user's MPI profile data is requested.
  • MPI "orchestrated search" has been updated to query MPI based on a user's ICN instead of identifying attributes such as last name & DOB.

Related issue(s)

• https://jira.devops.va.gov/browse/VI-920

Testing done

• New code is covered by unit tests

Cached Response Destruction Testing

• Testing can be performed most easily in a Rails console. Obtain the necessary information for your test user identity and use it to construct a UserIdentity object in the console.

first_name = 'John'
last_name = 'Doe'
...
...
identity_payload = { first_name:, last_name:, icn:, edipi:, birth_date:, ssn:, loa: { current: '3', highest: '3' } }
user_identity = UserIdentity.new(identity_payload)

# create MPIData instance and call MPI for a response
mpi_data = MPIData.for_user(user_identity)
mpi_data.status
  => :ok
mpi_data.mpi_response_is_cached?
  => true

# check redis cache directly
redis = Redis.new
redis.get("mpi-profile-response:#{icn}")
  => "<redis response>"

# call add person proxy - deletes cache upon success
mpi_data.add_person_proxy
  => <MPI::Responses::AddPersonResponse:0x00007eaddd2bdf4
        ...
        @status=:ok>
mpi_data.mpi_response_is_cached?
  => false
  
# check redis cache directly
redis.get("mpi-profile-response:#{icn}")
  => nil

MPI Orchestrated Search Changes Testing

• In order to test the change from using user attributes to user ICN for the orchestrated search request, uncomment the following line in vets-api/lib/mpi/configuration.rb:

      conn.request(:curl, ::Logger.new(STDOUT), :warn) unless Rails.env.production?

• With this line uncommented the mpi_data.add_person_proxy invocation will log TWO calls to MPI to the console - parse the FIRST call for the following lines

          <parameterList>
          <id root="2.16.840.1.113883.4.349" extension="1012832013V553700"/>
          <otherIDsScopingOrganization>
            <value extension="VBA" root="2.16.840.1.113883.4.349"/>
            <semanticsText>MVI.ORCHESTRATION</semanticsText>
          </otherIDsScopingOrganization>
        </parameterList>

• Compare this to the master branch add_person_proxy generated XML:

<parameterList>
          <livingSubjectBirthTime>
            <value value="19730526"/>
            <semanticsText>Date of Birth</semanticsText>
          </livingSubjectBirthTime>
          <livingSubjectId>
            <value root="2.16.840.1.113883.4.1" extension="796265005"/>
            <semanticsText>SSN</semanticsText>
          </livingSubjectId>
          <livingSubjectName>
            <value use="L">
              <given>Maurice</given>
              <family>Murphy</family>
            </value>
            <semanticsText>Legal Name</semanticsText>
          </livingSubjectName>
          <otherIDsScopingOrganization>
            <value extension="VBA" root="2.16.840.1.113883.4.349"/>
            <semanticsText>MVI.ORCHESTRATION</semanticsText>
          </otherIDsScopingOrganization>
        </parameterList>

What areas of the site does it impact?

MPI add_person_proxy call and subsequent Redis caching

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected

[emilykim13]

I made an identity_payload and created a new UserIdentity which I passed through an MPI instance and followed your testing steps. I got the expected results. Lgtm!