CC Allowances

[kinika_nyenke2]

We have used allowances in a solution that creates up to 74 Allowances per contand it works fine SAP note has limit of 10 per Provider Contract and 100 per subscriber account but we don’t get an error is our assumption wrong or how do we get a failure

[francois_thimon]

Hi Kinika,

It seems that you're referring to SAP note 2478958 ("Impact of the Master Data on the SAP CC Performance").
This note is indeed important, and we strongly recommend users to comply with it.
Yet, its point is rather to avoid severe performance issues on the long run, but Convergent Charging has no hard limit regarding the volume of data you provision: as long as your database and memory can hold everything, you will never get a warning or an error, but you may still end up with slowness during rating operations, or while (re)loading subscriber data into your caches, especially when the larger accounts are involved.
The figures from the SAP note were established based on thorough load tests and measurements. They may not apply precisely to every real-life situation, but if your amounts of data aren't contained, it may then become nearly impossible for us to guarantee satisfactory performances, even with rigorous tuning.
Depending upon your needs, optimised designs may be considered: for instance, the "split account" feature lets you handle one large business partner in SAP CRM, while actually spreading its data across several smaller (and more manageable) subscriber accounts in SAP CC.

To sum up, the general recommendation is to revise your design in order to alleviate the load on the CC accounts.
Alternatively, if that really cannot be done, please at least run realistic performance tests, to make sure your system will be able to keep up with the expected traffic, in a live context. As suggested by SAP note 2478958, Convergent Charging consultants and the SAP CoE team can assist you with that.

Best regards.

François
SAP Convergent Charging Support

[kinika_nyenke2]

Thanks for your response much appreciated, really helped to validate what we thought as well as adding new insight.

Do you know how exceeding the SAP allowance recommendation is manifested, by that I mean does The Rater shut down in a Passive active setup and or does the system slowly grind to a halt or does the allowance stop counting correctly or in any other way. Thanks

[francois_thimon]

Hi Kinika,

Thank you for your feedback.

If you observe any impact, it'll be mostly on the latency of the rating processes. And it'll of course be worse if each rating operation actually involves all of the 74 allowances.
As long as you don't design anything that's really too huge for the system, you won't get any hard crash, or fatal error message. The functionality won't be affected either (i.e., all computations will always yield the right results, but just less quickly).
If your accounts were really huge, though, here are two situations you could face:
- The absolute worst case would be if an account was too large to even fit in a cache subdivision: you'd then get an actual error message, as it would be impossible to load (and charge) that account.
- A more common symptom is when some operations take too long and delay the following ones; you may then get timeout errors in your client rating application.

This wasn't mentioned in the previous message, but all the data of a given subscriber account is always kept together as one piece, within a same subdivision of the cache (by design, each subdivision is supposed to contain many accounts). So, each time you're targeting one contract, the rater also needs to have all its sibling contracts, as well as all their counters, allowances, subscriber tables, etc., also present in the cache.
For that, you'll need to allow enough overall cache space from the get-go, and make sure none of your subscriber accounts is too big for the cache subdivisions.

If you ever need to monitor the cache occupancy, you can use admin+ to generate cache status reports:
get subscription_cache_status
This'll tell you whether the rater sometimes has to discard/reload objects (the "vmem" field is increased each time this happens).

So, the first step to confirm that your design is viable is to run tests with data as realistic as possible. Thanks to that, you'll be able to verify that your cache is properly sized, that you don't get abnormally frequent timeouts and that, of course, the response times consistently meet your own expectations.
The reason why SAP note 2478958 appears so strict is mostly to help customers make the right choices during the design phase, while it's easier to identify and address performance issues.

Please let me know if you need further details.

Best regards.

François
SAP Convergent Charging Support