Welcome
5273 Release Details
MATRIXX Rerating
- About MATRIXX Rerating
  THE MATRIXX RERATING SOFTWARE PROGRAM IS EXPERIMENTAL AND IS NOT AUTHORIZED FOR PRODUCTION USE. IT IS PROVIDED “AS-IS” WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED.
- MATRIXX Rerating Overview
  Use MATRIXX Rerating to reprocess messages for a range of dates previously processed by the Charging Server that were determined to have incorrect results due to errors in the pricing or tax configuration, or when a subscription was incorrectly provisioned, after the issue is resolved. MATRIXX Rerating supports past billing cycle periods for postpaid subscriptions.
- Installing and Configuring MATRIXX Rerating
  A deployment of the MATRIXX Rerating components consists of containers installed with a Helm chart in a multi-node Kubernetes cluster.
- Administering MATRIXX Rerating
  rerating/c_rerating_administering.html#concept_x5d_qbv_lwb__fig_hck_cxz_5wb illustrates the MATRIXX Rerating components and process.
  - Daily Database Object Snapshots
    The live system periodically generates checkpoints that record the contents of objects in the in-memory databases. Each checkpoint holds the state of the objects at a specific point in time, after a specific transaction is committed, so the objects in a single checkpoint are transactionally consistent. From one checkpoint each day, the Snapshot Loader utility extracts all the objects in the subscriber, activity, and balance databases and loads them into Google Google Cloud Bigtable. For more information about the Snapshot Loader utility, see the discussion about snapshot_loader.jar.
  - Understanding Rerating Orchestrator
    Rerating Orchestrator mediates between the Rerating Workbench user interface, the Rerating Director and Rerating Engine pods, Google Cloud Bigtable data, and the PostgreSQL rerating jobs database to manage rerating.
  - Understanding Rerating Director and Rerating Engine
    An instance of Rerating Director and an instance of the Rerating Engine run together in the same pod to facilitate tasks within a single job. The total number of Rerating Director/Rerating Engine pods is configured through Helm charts.
  - Understanding Policy Evaluation During Rerating
    During charging message rerating, policy evaluation is skipped. The current policy changes are not checked and policy notifications are not triggered. During policy message rerating, any pending recurring processing is triggered whereas policy evaluation is skipped.
  - Understanding Normalization During Rerating
    During rerating, some normalizers use the data from original processing.
  - Understanding Subscriber Management Operations During Rerating
    During rerating, if a subscriber management operation succeeded during initial processing, it succeeds during rerating. If the operation failed during initial processing, for example, a failed purchase, the operation is not attempted during rerating. If a balance floor is reached during rerating, that balance floor can be exceeded.
- Understanding Events in Rerating
  Use this section to understand events delivered to the billing system when a job is approved by the operator in Rerating Workbench, and transaction events which are generated by the live system when messages are rerated.
- Managing the Rerating Process
  An operator manges rerating through the Rerating Workbench user interface.
- Troubleshooting
  This section has information to help identify and resolve system issues.
- Appendixes
MATRIXX Rerating Workbench Help
Glossary

Administering MATRIXX Rerating

Figure 1 illustrates the MATRIXX Rerating components and process.

Rerating Process — Figure 1. Rerating in Kubernetes

The components include:

An instance of Rerating Director and an instance of the Rerating Engine run in the same pod to facilitate rerating tasks within a single rerating job. For more information, see the discussion about Rerating Director and Rerating Engine.
Rerating Orchestrator mediates between the Rerating Workbench user interface, the Rerating Director and Rerating Engine pods, Google Cloud Bigtable data, and the PostgreSQL rerating jobs database to manage rerating. For more information, see the discussion about PostgreSQL database storage. For more information, see the discussion about Rerating Orchestrator.
Google Cloud Bigtable stores a collection of searchable keys. When a rerating job request is received from Rerating Workbench, a new job is recorded in Google Cloud Bigtable. For more information, see the discussion about Google Cloud Bigtable.
Event Streaming Framework 1 (ESF1) processes primary events from the live engine.
Event Streaming Framework 2 (ESF2) processes transaction events from the live engine.
Event Streaming Framework 3 (ESF3) porocesses both MATRIXX Rerating events and transaction events from the Rerating Engine.
Event Streaming Framework 4 (ESF4) receives approved MATRIXX Rerating events from Rerating Orchestrator and sends the events to other publishing brokers.
Note: ESF1, ESF2, ESF3, and ESF4 instances use a single Google Cloud Bigtable instance. For information on setting up these instances, see the discussion about setting up Event Streaming Framework instances for rerating.
The PostgreSQL rerating jobs database stores rerating job data. This data includes data about MATRIXX Rerating jobs in progress and historical information about completed jobs.
Rerating Workbench is a web application you use to rerate a subscription or a collection of subscriptions. For more information, see introducing Rerating Workbench.

This section discusses how the rerating Kubernetes offline cluster and Kubernetes live cluster components interact to perform rerating.