Task #64
Updated by Srishti Ghosh 18 days ago
**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. components shared across all verification modules. **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. Includes: **Acceptance Criteria** A common * [ ] Base ULIP client layer is available for application modules to use. Client ULIP-related functionality is exposed through dedicated client methods rather than being tightly coupled to individual UI pages. * [ ] Authentication Vehicle, driver, FASTag, cargo and customs service workflows can use the common integration layer. * [ ] Common Request Handler 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 Parser 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 Handling 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. * [ ] Shared Utilities