Dm_fusa Cannot Handle Large Batches with Paymentech Enhancments Due to Shared Memory Constraint
(Doc ID 2864487.1)
Last updated on JULY 12, 2022
Applies to:
Oracle Communications Billing and Revenue Management - Version 12.0.0.3.0 and laterInformation in this document applies to any platform.
Goal
On : 12.0.0.3.0 version, Paymentech Manager
The daily average of pin_collect volume is 550K transactions, with 1st of the month outlier of over 1.6 million. Refactoring Billing Day of the Month (BDOM) is not an option.
Currently the configuration of pin_collect is to fetch 600K at a time and process 6K per batch over 50 threads, meaning at any one time 300K transactions are somewhere in the CM/DM stack in 50 batches of 6K each with spike(s) of all 50 batches appearing in dm_fusa at the same time due to single-back-end dm_fusa processing of batches (per Paymentech restriction). Decreasing batch size increases batch file count past Paymentech restriction on number of files submitted per day - on the 1st of the month at the very least but also possible on other days of the month. Splitting across multiple dm_fusa's even with different SIDs/PIDs is not acceptable due to lack of cross-submission duplicate checking at Paymentech in that configuration.
Each charge involved 4 records in the batch, "S", "AB", "A2" and "A3" at the minimum. More recently new records to use Paymentech enhancements for the CIT/MIT mandate as well as Card Type Indicator encounters the following messages indicating the process will not scale much longer without running out of shared memory:
dm_malloc(9421): 2022-01-04 12:46:32 : WARNING ->heap size(48988) CROSSED high water mark(48988)
dm_malloc(9421): 2022-01-04 12:46:32 : WARNING ->heap size(48989) CROSSED high water mark(48988)
dm_malloc(9421): 2022-01-04 12:46:32 : WARNING ->heap size(48990) CROSSED high water mark(48988)
Without a way to decrease the batch size due to daily file count constraint, the maximum dm_fusa shared memory size of 512M (32M bigsize) is preventing any inclusion of CIT/MT "MT" records for a majority of the charges or "CT" records for all of the charges, both of which are required for business critical functions like credit card approval rates and fraud monitoring.
The ask is for dm_fusa to be able to handle a much larger volume of charges * batch records per charge than it can today.
Acronyms:
=========
CM: Connection Manager
DM: Data Manager
CIT: Cardholder-Initiated Transaction
MIT: Merchant-Initiated Transaction
SID: Server process ID
PID: Process ID
Solution
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
Goal |
Solution |
References |