-The API returns <responseMessage>No APs found</responseMessage>.
This occurs because the SRD backend reads from a materialized view instead of the correct view.

• Fixed the HttpClientErrorException issue.
  These issues will be resolved in patch 4.0.0.5

Please provide a sample with a trail we will get the details as output

What the API does:
checkGponTrailFeasibility checks if a GPON fiber connection can be provided to a customer site. Given the customer's GPS coordinates, it searches for nearby Access Points (APs) in the network inventory and verifies whether a complete fiber path exists from that AP back to the Exchange.

Business flow:
Customer requests GPON service at a specific address (lat/long)
The API searches for APs within the given radius
For each AP found, it checks if a complete GPON path exists:
AP → FDH (must have free ports)
FDH → OLT (active connection to Exchange must exist)
If a complete path is available → returns exchange, FDH, AP and distance
If not → returns "No Trail found"
To get a valid response from NEP, the tester needs:

In NEP inventory, find an AP that satisfies ALL of the following:
Has GPS coordinates (GLONG / GLAT) configured on the AP object
Has a parent FDH assigned
The FDH has free ONT ports (not all used)
There is an OSP connection between the FDH and the AP
There is an active OLT path from the FDH to the Exchange
Then use that AP's coordinates as siteLat / siteLong in the request with a small maxApDistanceInMeters.

The output is fine now, however, there is a performance issue : 01s on OLD versus 5s on NEW

The issue was related to a SELECT query taking between 1 and 3 seconds.

A database index has been added on the concerned table, which improved the query performance and reduced the response time to approximately 1 second.

The SQL script has been successfully applied.