Technical Documentation: Migration to New System Design: Partner Sales Services



 
Overview
This document outlines the high level transition from the existing system, an Azure Function based application primarily built with Java and Spring Boot, to New System Design: Partner Sales Services, which will utilize Azure Kubernetes Service (AKS). The migration addresses key architectural improvements to enhance scalability, maintainability, and flexibility.
Migration Highlights
1. Architecture Based on SOLID Principles
Single Responsibility Principle (SRP): In New System Design: Partner Sales Services, we will adhere to SRP by organizing the existing code and response generation around distinct controllers for each interface involved in the partner sales services module. The following controllers and their associated helper and service classes will be implemented:
•	StockController:
•	Helper Class: StockHelper
•	Service Class: StockService
•	Responsible for stock-related operations, with a focus on processing stock data.
•	SellingPriceController:
•	Helper Class: SellingPriceHelper
•	Service Class: SellingPriceService
•	Handles services related to selling prices, ensuring accurate data retrieval .
•	StoreController:
•	Helper Class: StoreHelper
•	Service Class: StoreService
•	Manages operations associated with store-related data
Each controller will implement a services.triggerProcess method that triggers the specific business logic needed for processing requests. 
The actual implementation will be divided into helper methods and service classes, promoting code reusability and the separation of concerns principle.
Open/Closed Principle: Utilizing helper methods allows us to extend functionality without modifying existing controller code, helping to fulfill the OCP.
Dependency Inversion Principle : By using Spring JPA for database interaction, we can decouple our data access logic from the business logic, which allows for greater flexibility in making changes to the data source without affecting higher level modules.
Separation of concerns ensures that each controller focuses on a specific aspect of the business logic, making the codebase easier to maintain and evolve.
2. File Format Variability
In the New System Design: Partner Sales Services, we will enhance our file handling capabilities to support multiple formats such as TXT, CSV, and XML.
Input Handling Logic:
•	All incoming files, regardless of format (TXT, CSV, XML), will be converted to a standard TXT file format by their respective handlers before further processing. This ensures that the subsequent extraction and mapping logic can operate on a consistent structure.
•	After conversion, the application will process the standard TXT file to generate the final JSON based on the common JSON schema structure. This approach minimizes changes to the extractor code and enhances the system's flexibility to handle diverse file formats.
3. Logic Apps Integration
Per-Partner File Processing: We will utilize Logic Apps to implement a file reading trigger for each partner, which will streamline the processing of incoming files based on unique partner requirements.
Endpoint Call Logic: Logic Apps will be responsible for invoking endpoints that retrieve partner information alongside the accompanying file data. To achieve this, we will add an HTTP Action using the "HTTP" connector to invoke the REST endpoint for each of the three interface controller services (StockController, SellingPriceController, and StoreController). This action will enable seamless communication with the respective services and facilitate efficient data handling across different partners. By integrating this HTTP action into our Logic Apps workflow, we enhance automation and reduce manual intervention in the data processing pipeline.
4. Database Configuration
No Changes Required: The database configuration, including the structure and schema of the existing batch processing audit tracking and configuration tables, will remain the same during the migration. This decision avoids complications and risks associated with modifying the database layer during the transition.
5. Codebase Setup and Pipeline
Environment Configuration: The deployment pipeline will include separate stages for development and production to ensure smooth code transitions and reduced risk during updates.
6. Validation Mechanism
Partner-wise and Common Validators: Existing validation framework will be reused that includes both partner-specific validators and common validators to ensure data integrity and compliance with the expected formats.
7. Auditing
Audited status: Existing auditing mechanism will be reused, tracking processing status, errors to ensure visibility over processing workflows and batch runs.



Emphasis on Azure AKS Migration
The transition to Azure AKS presents several advantages over the current Azure Functions:
•	Scalability: AKS allows for better resource management and scaling, which is essential in handling varying loads from different partners.
•	Flexibility: Deployment of microservices will enable us to modify, scale, or replace services independently without disrupting the entire system.
•	Performance: With greater control over container orchestration, we can optimize performance for specific workloads.

The transition from the existing system to New System Design: Partner Sales Services positions us for improved handling of partner sales data through better architectural practices, enhanced processing capabilities, and robust validation and auditing mechanisms. The implementation of Azure AKS significantly enhances our infrastructure, allowing for more adaptable and scalable service delivery.

Strategic Stock enhancement Custom exceptions

 

Custom exceptions within the com.mns.intl.pigw.exception package, along with their descriptions:
1.	AzureConnectionException
•	Description: Thrown when there is an issue connecting to Azure services.
2.	CloudFileDownloadException
•	Description: Thrown when there is an error downloading a file from the cloud.
3.	CloudFileUploadException
•	Description: Thrown when there is an error uploading a file to the cloud.
4.	ConfigException
•	Description: Thrown when there is a problem with the application configuration.
5.	CustomFileNotFoundException
•	Description: Thrown when a file that is being looked for cannot be found, providing a custom exception alternative to the standard FileNotFoundException.
6.	DatabaseConnectionException
•	Description: Thrown when there is a failure to connect to the database.
7.	EmptyFileException
•	Description: Thrown when an operation encounters an empty file where content is expected.
8.	FileNotParsedException
•	Description: Thrown when a file fails to be parsed as expected.
9.	JSONGenerationFailure
•	Description: Represents a failure state when generating JSON data; may be a class or a constant indicating an error in JSON generation.
10.	TimeoutException
•	Description: Thrown when an operation does not complete within a specified time period.

......rephrase it briefly to give script to respond in status meetng