SAP CC check BIT files loaded to CI

[mrstifler777]

Hi Experts,

Is there a way to check if the same BIT file is loaded again by SAP CC to SAP CI? We would like to see if there's any way we can check if SAP CC has the possibility of loading the BIT file again causing duplicates for example in SAP CI. Probably some kind of logs where we can search for the file name or transaction id and check if there are 2 instances this file or transaction id has been processed by the bulkloader for example.

Thanks,

Steve Stifler

[francois_thimon]

Hi Steve,

It's rather unlikely that CC would send the same items twice in particular because, whenever a bulkloader picks a file for processing, it first adds its own ID to that file's name, to indicate that it's already working on it of (e.g, bulkLoader#2 adds the suffix ".b02" to the file's name). Then, the file is discarded.

If you need to run additional checks, though, here are a few tips to help you track your BIT's:
a. CC bulkloader/system parameters: enable the "JCO" domain and the DEBUG severity
This'll show exactly what the bulkloader sends over to CI using the JCo/RFC layer. All BIT's will be pretty-printed in an ASCII-art table, it's very legible but slightly verbose, so better turn it on only for short periods.

b. CC/charged item folder: check for CTL and ERR files, and verify the INVALID/COM_EXCEPTION folders
If you know approximately when the BIT's were created etc., you can check all places that may contain error reports, and see whether those reports involve your duplicate BIT's.
For example, if CI first rejected some items as invalid, it may be that you solved the issue manually (e.g., by adjusting the BIT mapping), and that you then fed the same item file twice to the bulkloader, for some reason.

c. CC bulkloader/CIF configuration: set the "removeFile" attribute to "false"
This'll instruct the bulkloader to archive the processed charged item files instead of deleting them permanently.
Each archived will get the suffix ".rem" (for "removed"), and you'll be able to review them at your convenience.
This is a safe approach only if your file system has enough space for your volume of data.

d. CC rater/CIF configuration: increase the rollover interval ("timeBasedFileRolloverPolicy")
This is not standard practice, but it can leave you more time to review the files before the bulkloader processes and deletes them. This can be an alternative to disabling the file removal.

e. charged item files: match the "SRCTAID" fields of the suspect BIT's
That's the "SouRCe TrAnsaction ID": if two BIT's look similar but have different SRCTAID's, then they were produced by two different rating operations (two different transactions).
This may indicate that your client application requested the same charge twice.

f. CC bulkloader/system parameters: enable the "BLK" debug traces and the DEBUG severity
This is extremely verbose so not appropriate to all situations, but it tells you when the bulkloader does (or doesn't) find files that are supposed to be processed.
Even though this is highly unlikely, if a same file was processed twice, you'd see it using the "BLK" domain.

g. CC bulkloader/system parameters: enable the low-level JCo/RFC/CPIC traces
These come directly from the JCo library, and show even more details that CC's pretty-printed JCO debug traces.
Here's the reference of CC's logging settings, the JCo-related ones are at the top:
https://help.sap.com/docs/Convergent_Charging/9fe6117842b24350b6eb2fe619418b44/e2a5e04837694f0094bc3...

h. CI/list of BIT's: match the "Created at" timestamps with the bulkloader's logs
Any abandoned/improper files are dealt with when the corresponding bulkloader restarts.
So, if the BIT's were received by CI right after the bulkloader restarted, they might come from an improperly handled file. That's not likely, but still worth checking.

Can you please consider some of these approaches and tell us if you need further guidance?

Best regards.

François
SAP Convergent Charging Support

[mrstifler777]

Thank you Francois as usual for the detailed response!

Point b is the most probable cause but we're trying to find if we can prove it. We are trying to look for a file that the bulkloader processed twice using the LDF1 logs however we are not sure if this is reliable since we're thinking the bulkloader could have renamed the file again (e.g. the file timestamp based from the time it was processed).

b. CC/charged item folder: check for CTL and ERR files, and verify the INVALID/COM_EXCEPTION folders
If you know approximately when the BIT's were created etc., you can check all places that may contain error reports, and see whether those reports involve your duplicate BIT's.
For example, if CI first rejected some items as invalid, it may be that you solved the issue manually (e.g., by adjusting the BIT mapping), and that you then fed the same item file twice to the bulkloader, for some reason.

For point e, the SRCTAID are the same for the duplicated transaction.