Trouble shooting and Assumptions

14 Trouble shooting and Assumptions

This topic provides information on Trouble shooting and Assumptions.

Issue: Content API failing, or Origination product details cannot be seen on screen.
Assumption: This is due to the content API IP and port not being properly configured in the database.

Steps to Troubleshoot:
- First, test the API using Postman. Refer: OBO API testing via postman-steps 4and5.
- Configure the user and branch name correctly. Refer to the OBRH Origination config for CMC user configuration and properly configure the Origination service consumer for the DMS server.
Issue: Final submit is failing for mandate details.
Assumption: This is because we are not sending all segments to OBO, as the OBDX channel is responsible for sending only the mandatory segments to OBO.

Steps to Troubleshoot: Check the request and response OBRH logs for BUSINESS_OVERRIDE, as after calling this API from OBDX, it is responsible for sending consents to OBO to handle the remaining mandatory segments managed by OBO.
Issue: National ID Verification failed, and access denied for doc upload.
Assumption: This is a UI issue; some required fields might not be loaded on the Personal Information screen due to the regional requirements of the framework.

Steps to Troubleshoot: UI validation needs to be handled to check which fields are present on the Personal Information screen.
Issue: "TIMED OUT EXCEPTION." While fetching workflows after login.
OR

Not able to proceed after login as registered user

Assumption: This is an existing user use case in which the user logs in, navigates to the Origination product offerings page from the kebab menu, starts a new application, selects any product, and the API fails with a timeout error. If you check the OBDX logs, you might find the error as shown below.
```
ERROR com.ofss.digx.app.origination.service.product.Product - Exception from fetchDocuments() 
for requestDTO DomainObjectDTO [auditSequence=1, createdBy=null, creationDate=null, entityStatus=null, 
lastUpdatedBy=null, lastUpdatedDate=null, recordStatus=null, version=1] in class com.ofss.digx.app.
origination.service.product.Product com.ofss.digx.infra.exceptions.Exception: null
```
Steps to Troubleshoot: This is because the content API is not configured correctly. Refer to issue no.1 to fix any content API failures.
Issue: Document type ID, name and Description in Remote Product Repository Adapter.
Assumption: OBDX either stores the document locally in the database or sends it to OBO. Since we are configuring the remote adapter, the document will be sent to the DMS server.

We need to ensure that the maintenance of this API is correctly done on the OBO side.

Steps to Troubleshoot: Refer OBO API testing via Postman-point5. There are two APIs: List of Categories and Category Sub-Type. The second API depends on the response of the first API.

Test with Postman first before testing via the OBDX application.
Issue: After entering financial information, Application update call failed.
Assumption: In the financial information section, there is a bug that was rectified and fixed in the previous release, and the same fix has been added in this release.
Issue: Personal Loan Application for new customer is failing at OBDX with Error "SUM OF INDIVIDUAL REPAYMENT SHARES SHOULD BE EQUAL TO 100%".
- Assumption: This issue might be related to the mandate segment.
  Steps to Troubleshoot: This issue needs to be rectified from the logs, and the OBDX request should check if the mandatory details have been sent to OBO, as well as whether the same mandate segment is received in the OBO response.
Issue: JUMIO Flow is failing.
Assumption: This could be a Jumio API issue that gives us a non-compliance response

Steps to Troubleshoot:Test the Jumio API with Postman and check if it is giving a compliance response or not. If it is giving a non-compliance response, check with the Jumio team.
```
curl --location 
'<protocol>://<host>:<port>//netverify.com/api/netverify/v2/scans/<reference_no>/data' \
--header 'Accept: application/json,text/plain,image/jpeg,*/*' \
--header 'Authorization: Basic xxxx'
```
Issue: Details of the existing user are missing in originations application.
Assumption: In UBS, the expected mandatory fields might be missing. Also, check if the OBPY API is providing the same user details.

Steps to Troubleshoot: ln UBS, * denotes mandatory fields, and the same will be read in OBDX.

Refer to the API below that fetches user details from OBPY, and verify the UBS API response details.
```
curl --location
        ‘<protocol>://<host>:<port>/obpy-party-services/service/v1/getParty/<party_id>' \
--header 'branchCode: <branch_code>' \--header 'appId: PRTONB \
--header 'entityId: DEFAULTENTITY' \--header 'userId: <user_id>' \
--header 'Content-Type:application/json'
```
Issue: Mobile number entered already exists
Assumption: This issue occurs when an existing customer tries to initiate a new application using the prospect flow with an existing mobile number.
Steps to Troubleshoot: An already onboarded user attempting to use the same mobile number to initiate the prospect flow is an invalid use case. Ask them to log in and initiate the application.

Description of the illustration troubleshooting.png

Below are a few assumptions
- Online KYC is entirely dependent on the bank's site. The bank will define the mode of verification that needs to be enabled for Online KYC.
- A DMS server is mandatory from the OBDX perspective, as required documents are read, uploaded, or deleted from that system.
- If the bank is using a customized alert system for email, SMS, or other media, the bank is responsible for troubleshooting any issues related to integration with other systems.
- If any OBO API takes more than 1 minute, check with the OBO team to resolve the issue.
- Check the type of encoding used in the system to encode the username and password example
```
select * from digx_fw_config_all_b where prop_id='OBRH_ENCODING' update value to PLATO_ENCRYPTION
```
- If OBO APIs are using HTTPS, then check for SSL installation on the OBDX and OBRH servers.