Release V9.1.11
System Performance Improvements
The following improvements enhance system stability and performance:
Optimized Server Logging and Removed Unused Metrics in JBoss 7.4
Context: High volume transaction processing systems require careful logging configuration to ensure optimal performance without sacrificing the ability to diagnose issues.
Solution: Implemented improved logging level detection methods in UnipayJavaLogger and UnipayJbossLogger classes and removed unused metrics collection from JBoss 7.4 configurations.
Impact: System operators now have more efficient and accurate logging with reduced overhead, while the removal of unused metrics collection improves overall server performance.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: None
- Configuration Changes: Removed metrics module configuration from JBoss 7.4 standalone XML files
- Code Changes: Updated logging level detection in UnipayJavaLogger and UnipayJbossLogger classes
- Filesystem Changes: Modified _build7/cli2/jboss-eap-7.4/standalone-unibroker.xml and standalone-unipay.xml
- Data Migration: None
Implementation Actions
- The updates are implemented via standard deployment mechanisms
- No additional update actions are required as all changes can be executed through standard code deployment
- No manual configuration changes are needed after deployment
- Standard application restart is sufficient to apply all changes
Configuration and Access Steps
- No special configuration is required for testing these changes
- Changes are automatically applied upon deployment and server restart
- No specific UI paths are available as these are system-internal changes
- Monitor server logs to verify correct logging behavior
Test Scenarios
-
Basic Functional Testing
- Steps: Verify that core application functions continue to work correctly
- Expected result: All application functions operate normally with no regression
-
Log Level Verification
- Steps: Generate activities that trigger different log levels and verify appropriate messages appear
- Expected result: Only logs at or above the configured level are output
-
Performance Verification
- Steps: Compare server performance metrics before and after changes under standard load
- Expected result: Equal or improved server performance with metrics module removed
Common Issues
- Application logs might show different patterns after deployment - this is expected
- Server metrics dashboards that relied on the removed metrics module will no longer receive data
- Some third-party monitoring tools might need reconfiguration
Potential Impact Areas
- Logging System: Streamlined logging implementation may change the volume and format of logs
- Monitoring Tools: Any custom monitoring that relied on the removed metrics module will need adjustments
- Performance: Overall server performance should improve with reduced overhead
Schema Updates
- No database schema changes are included in this update
Rollback Information
This update does not include any database changes and therefore no database rollback is required.
- No database rollback steps are necessary
- Code changes can be reversed through standard deployment procedures if needed
Improvements and Fixes
This release addresses issues with fee processing and remittance operations:
- Fixed duplicate fee charging through previous balance(GA-1957)
- Fix for Statement Duplication on Deactivated Merchants(UP-975)
- Remittance Jobs Authorization with System Merchant(UP-455)
Fixed duplicate fee charging through previous balance
Context: When merchants had fees configured after transaction processing had already begun, an inconsistency in previous balance calculation could occur if statement generation took a long time and coincided with post-statement timer execution.
Solution: Implemented consistency improvements in the Remittance module to ensure proper loading of merchant account data and transaction information at the beginning of the statement creation process, preventing duplicate fee charges.
Impact: Merchants will no longer be charged twice for the same fees, eliminating the need for manual balance adjustments and ensuring financial reports accurately reflect fee transactions.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: No schema changes; only affects data processing logic
- Configuration Changes: No configuration changes required
- Code Changes: Modified fee processing logic in the Remittance module
- Filesystem Changes: None
- Data Migration: None required
Implementation Actions
- Modified the
RemittanceMerchantStatementHandlerandMerchantStatementHandlerclasses to load merchant account data consistently - Ensured proper timing of merchant account group loading and pending remitted amount calculation
- Improved data consistency during statement generation processes
- Enhanced transaction handling to prevent duplicate fee processing
Configuration and Access Steps
- No special configuration is needed to test this fix
- The fix applies to standard fee processing workflows
- Verification requires checking statement generation for merchants with delayed fee configuration
- Navigation: Admin Portal → Merchants → Fees → Statement Viewer
Test Scenarios
-
Late Fee Configuration Test
- Steps: Configure fees for a merchant after transactions have been processed, then generate statements
- Expected result: Only one fee charge appears across all statements and bank withdrawals
-
Extended Statement Period Test
- Steps: Generate a statement covering a long period for a merchant with newly configured fees
- Expected result: Previous balance is calculated correctly with no duplicate charges
-
Post-Statement Timer Test
- Steps: Monitor statement generation that occurs close to post-statement timer execution
- Expected result: Fee charges are consistent regardless of timer execution timing
Common Issues
- Previous balance incorrectly showing fee amounts that were already processed
- Inconsistencies between merchant statement reports and bank withdrawal records
- Fee amounts appearing twice in different parts of the financial workflow
Potential Impact Areas
- Fee Processing: Ensures correct fee calculation and application across statements
- Reconciliation Reports: Improves accuracy of merchant reconciliation statements
- Financial Reports: Ensures correct financial reporting for both merchants and administrators
Schema Updates
- No database schema changes were made for this fix
- The issue was resolved through code logic improvements
- Existing database tables and structures remain unchanged
Example SQL
-- No SQL changes were required
-- The fix was implemented at the application code level
Rollback Information
This change involves only application code logic and does not modify database structures or require data migration. Rollback is possible by reverting the code changes if necessary.
- No database rollback steps are needed
- In case of issues, standard code rollback procedures apply
Fix for Statement Duplication on Deactivated Merchants
Context: Merchants with recently configured fees (especially deactivated merchants) were experiencing statement duplication issues causing incorrect financial reporting and potential duplicate payments. In some cases, these duplicate statements were processing through to the bank before they could be canceled.
Solution: Implemented a logic fix in the statement generation process to prevent incorrect date tracking that led to statement duplication. The fix specifically addresses how the system handles lastRemittanceDate updates during reconciliation statement generation.
Impact: Statement generation now works correctly for all merchants, preventing duplicate statements and ensuring accurate financial reporting and payment processing. This resolves the urgent issue affecting deactivated merchants when fees are configured after deactivation.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: No structural database changes were made
- Configuration Changes: No configuration settings were modified
- Code Changes: Fixed statement generation logic
- Filesystem Changes: No filesystem changes were made
- Data Migration: No data migration is required
Implementation Actions
- The issue was resolved through code changes to the statement generation logic
- No database schema changes were needed
- No existing data required migration or correction
- The fix is implemented within the standard application code deployment
Configuration and Access Steps
- Create a test merchant account with processing history
- Deactivate the merchant account
- Configure fees on the account using DC schema
- Navigate to: Remittance → Merchant Statement
- Generate statements manually for the account
- Check statement list and verify no duplicates are created
Test Scenarios
-
Configure fees on historically inactive merchant:
- Steps: Set up fees on merchant that has been inactive for over 6 months; Generate statement batch covering entire period of inactivity
- Expected result: No duplicate deposit statements are generated; Transactions are not incorrectly included in multiple statements
-
Manual statement generation validation:
- Steps: Generate a reconciliation statement for an empty period; Verify
lastRemittanceDateis not incorrectly reset - Expected result: Subsequent deposit statements don't include duplicate transactions; Statement amounts match expected values based on transaction history
- Steps: Generate a reconciliation statement for an empty period; Verify
-
Edge case testing:
- Steps: Test with merchants that have very large date ranges without statements; Verify performance with accounts having multiple years of transactions
- Expected result: System handles pre-2020 transaction dates correctly; Correct behavior when configuring fees on already deactivated merchant accounts
Common Issues
- Verify all deposit statements show the correct transaction totals
- Check that remittance payments are processed only once
- Confirm statement generation on DC schema does not create overlapping date ranges
- Ensure no statements are being generated for deactivated merchants unless explicitly requested
- Verify that any SQL verification queries correctly identify potential duplicate statements
- Check that statements aren't being sent to the bank before manual review for high-risk accounts
Potential Impact Areas
- Statement Generation: The fix affects how statements are generated for merchants with newly configured fees
- Deactivated Merchants: Special attention to merchants that are deactivated but still need statements
- Reconciliation Process: Impact on how statement reconciliation works with historical data
Schema Updates
- No database schema changes were implemented in this fix
- No data modifications were made to existing statements
- The fix only affects the logic of future statement generation
Rollback Information
Rollback is possible for this change because:
- The fix only modifies application logic, not database structure
- No irreversible data transformations were performed
- Previous behavior can be restored by reversing the code changes
- No data was deleted or permanently altered
Prerequisites for rollback:
- Standard application deployment rollback procedures
- Testing to ensure statement generation works as expected after rollback
- Communication to users that the duplicate statement issue may reoccur
Remittance Jobs Authorization with System Merchant
Context: When merchants become inactive between job creation and execution time, remittance jobs could fail with authentication errors, as the system was using the merchant's credentials for job execution.
Solution: Implemented a fallback authentication mechanism that checks merchant status at job execution time and automatically uses the system merchant for authentication when the original merchant has been deactivated.
Impact: Remittance jobs now continue processing successfully even when merchants are deactivated after job creation, improving system stability and ensuring critical payment operations complete as expected.
- Implementation Details
- Testing & Validation
- Database Changes
System Changes Overview
- Database Changes: None
- Configuration Changes: None
- Code Changes: Modified authentication logic in remittance job processors
- Filesystem Changes: None
- Data Migration: None
Implementation Actions
- Introduced a new authentication helper method that provides fallback to system merchant
- Replaced direct authentication calls in remittance job processors with the enhanced method
- Added verification of merchant status during job execution
- Implemented automatic switching to system merchant (code 1000) when necessary
Configuration and Access Steps
- No specific configuration is required
- The functionality works automatically when needed
- Verification requires monitoring job processing logs
- Navigation: Admin Panel → Jobs → Job Messages
Test Scenarios
-
Merchant Active During Job Creation and Execution
- Steps: Create a remittance job while the merchant is active; Execute the job while the merchant remains active
- Expected result: Job completes successfully with authentication using the original merchant
-
Merchant Deactivated Between Job Creation and Execution
- Steps: Create a remittance job while the merchant is active; Deactivate the merchant; Execute the job
- Expected result: Job completes successfully with authentication using the system merchant (code 1000)
-
Job Handling with Different Authentication Errors
- Steps: Simulate different authentication errors (not just L01 errors)
- Expected result: System should only use system merchant for authentication when the specific L01 error occurs due to merchant inactivity
Common Issues
- Authentication errors may still occur for reasons other than merchant deactivation
- Job execution logs should be monitored to verify proper fallback authentication
- System merchant must have appropriate permissions for all operations
Potential Impact Areas
- Job Processing: The authentication changes affect all remittance job processors
- Error Handling: The system now responds differently to specific authentication errors
- Audit Logs: Authentication events may now show the system merchant for previously failed jobs