Canofy Process Standardization & Refactoring

User Story
As a developer, I want to establish a common ULIP integration framework so that different ULIP services can be connected to the Canofy application through a consistent, maintainable, and replaceable API layer.

Description
Develop a common integration layer between the Canofy application and ULIP services.
A reusable ULIPClient was implemented to act as the abstraction layer for ULIP API communication. The framework provides separate service methods for vehicle verification, driver verification, FASTag services, cargo/shipment services, and customs-related services.
Since production ULIP access is dependent on government approval, mock API responses were implemented for development and demonstration purposes. These simulate realistic API behaviour, including successful responses, failed searches, unavailable services, and network latency.
The framework was designed so that the mock implementations can subsequently be replaced or extended with the actual ULIP API calls without requiring major changes to the application's UI or business workflows.

Configuration / Prerequisites
Frappe/Canofy ULIP application environment configured.
Common ULIPClient class available to the application.
Service methods defined according to the expected ULIP functionality.
Standardised success and failure response handling implemented.
Mock responses available for development and demonstration.
Simulated API latency implemented to represent external API communication.
Error/exception scenarios available for testing.
Application modules able to call the ULIP client rather than directly depending on API implementation details.

Acceptance Criteria
A common ULIP client layer is available for application modules to use.
ULIP-related functionality is exposed through dedicated client methods rather than being tightly coupled to individual UI pages.
Vehicle, driver, FASTag, cargo and customs service workflows can use the common integration layer.
Mock responses accurately represent the expected structure of successful and unsuccessful API interactions.
The framework supports successful responses, record-not-found/failure responses and server-error scenarios.
Simulated network latency is supported for realistic development and demonstration.
API implementation details remain separated from the application's UI and workflow logic.
The integration layer can be replaced/extended with approved production ULIP endpoints without requiring the complete application workflow to be rewritten.

Test Cases
TC01 – Successful API Response
Call a supported ULIP client method using a valid demo input.
Expected Result: The client returns a structured successful response containing the expected data.

TC02 – Record Not Found
Call a service using one of the configured invalid/demo search values.
Expected Result: The client returns a controlled failure response with an appropriate message rather than causing the application to fail.

TC03 – ULIP Service Error
Call a service using the configured ERROR500 test value.
Expected Result: The simulated ULIP service raises an exception which can be handled by the application.

TC04 – API Latency Simulation
Execute a mock ULIP request.
Expected Result: The response includes simulated network delay, allowing loading/verification states in the UI to be tested.

TC05 – Multiple ULIP Services
Test the client methods for different service categories such as vehicle, driver, FASTag and cargo.
Expected Result: Each service returns its corresponding structured response without affecting the other services.

TC06 – Input Normalisation
Submit supported test values using different casing/whitespace where applicable.
Expected Result: The client normalises the input and correctly identifies valid configured test scenarios.

TC07 – Integration Layer Separation
Trigger a verification workflow from the application UI.
Expected Result: The UI invokes the application/API layer, which communicates through the common ULIP client rather than containing the mock/API implementation directly.