URGENT - NAMEX API request - Create 2 new API requests for the Home Team

[ozamani9gh]

As discussed, we would need the following new APIs to be implemented on the Namex side for NRO decommissioning.

1. On the current Namex.NameRequestFields class, within the api.route of ('//<"",:nr_action>' , add a new "CONSUME" NameRequesPatchAction which transitions a name request state from 'APPROVED' to 'CONSUMED' based on name request id (nr_id) .                                      2.a. On the current Namex.PaymentReceipt class (or any other appropriate class), add a new api.route ('//archive'), which archives a name request payment (in JSON format) originated and completed on the NRO side based on the name request id (nr_id) as the primary key.

2.b. On the current Namex.PaymentReceipt class (or any other appropriate class), add a new api.route ('//query'), which returns all archived NRO name request payments (in JSON format) based on the name request id (nr_id) as the primary key.

2.c. The content of the NRO name request payment contains the following fields (some field value can be empty) as attached, which is a JSON object can be archived either as a whole JSON String in a single column (as an easier approach) or further broken and stored into each individual matching columns in the Postgres (Namex or Payment) database.

Here is the layout of the NRO name request payment in JSON format. { "nrId":"", (note: This is the name request ID as the primary key) "paymentStateId":"", "paymentInvoiceId":"", "paymentStateType":"", "bcepTransactionId":"",       "payment" {                   "applicationCode": ""                   "authorizationNumber": "",                   "baseFee":"",                   "baseFeeGstAmount":"",                   "baseFeePstAmount":"",                   "batchId: "",                   "bceid":"",                   "bcolAccountNumber":"",                   "bcolAppliedDate":"",                   "bcolAppliedTime":"",                   "bcolKey":"",                   "bcolRacfId":"",                   "bcolReferenceNumber":"",                   "bcolSequenceNum":"",                   "creditCardExpiryDate":"",                   "creditCardHolderName: "",                   "creditCardType":"",                   "datNumber":"",                   "email":"",                   "fasBalance":"",                   "feeCode":"",                   "folioNumber":"",                   "gaLocationCode":"",                   "gstNumber":"",                   "nsfCheckNumber":"",                   "paymentDate":"",                   "paymentId":"",                   "paymentTotalAmount":"",                   "paymentType":"",                   "phoneNumber":"",                   "routingSlipNumber":"",                   "secureCreditCardNumber":"",                   "serviceChargeAmount":"",                   "serviceGstAmount":"",                   "servicePstAmount":"",                   "staffIdir":"",                   "transactionId":""             },       "stateTimestamp":"",       "bcepResponseStatusCode":"",       "bcepResponseMessage":"",       "bcepWsResponseCode":"",       "bcepWsResponseMessage":"",       "bankAuthCode":''",       "bankProcessDate":"",       "bankResponseCode":"",       "refundAmount":""       }

Thanks

David

[eve-git]

I updated the existing NR state transition service to handle the state change to CONSUMED. However, some additional tasks, such as Solr updates for the CONSUMED state, may need to be handled separately, as they were not included in the service.

service call: • method: PATCH. • URL: https://namex-test.apps.silver.devops.gov.bc.ca/api/v1/requests/{{nr_num}} • headers: -- Conent-Type = application/json -- Authorization = Bearer • body: { "state":"CONSUMED", "corpNum":"BC000001" } Note: user= name-request-service-account or user role is one of APPROVER, EDITOR or SYSTEM

validation: the state of the NR to be “consumed” must be APPROVED or CONDITIONAL. The consent flag value must be 'R' (consent received) or 'N' (consent wavied) in case of CONDITIONAL.

[eve-git]

we need support from relationship team to handle payment record updates

[eve-git]

2.b The payment info can be retrieved: url: https://namex-test.apps.silver.devops.gov.bc.ca/api/v1/payments/{{nr_id}}, nr_id is the Request.id in namex

[eve-git]

I'm unsure how Lear manages corp_name updates in Solr. In the COLIN Oracle process, after a corp_name insert (e.g., incorporation), a new record is added to solr_feeder based on the corporation type. The corp types that require name conflict checks are 'BC,' 'OT,' 'SOC,' and 'XPRO.'

On our side, after a requests record is updated (such as when the state changes to 'CONSUMED'), we enqueue the name state change, and the possible Solr conflict is deleted to prevent duplicates.

[ozamani9gh]

David Li is testing these two, once we have confirmation we can pass to home team to do verification testing.

[Mihai-QuickSilverDev]

Another one that will be QA-ed by the Home Team.