Troubleshooting ECE Cloud Native

Troubleshooting Incorrect Charges for Mid-Session Product Purchase

When a customer purchases a product during an active usage session, ECE may split the session at the purchase time and rate each segment separately. This split can cause ECE to rate the usage before and after the purchase as separate segments with split quantities.

For example, if ECE receives a 35-second usage request, and the customer purchases a product after 33 seconds, ECE splits the session at the purchase time and rates the first 33 seconds and the remaining 2 seconds as separate segments. For this example, assume when the customer uses a charge offer with a rate plan that:

Applies a zero rate when the quantity is less than or equal to two seconds.
Applies a non-zero rate when the quantity is greater than two seconds.

In this case, ECE rates the 33 second segment at the non-zero rate and rates the 2 second segment at zero. This outcome differs from the expected behavior, where ECE rates the full 35 seconds at the non-zero rate.

By default, ECE considers all products purchased by the customer for tariff splits. However, you can configure ECE to consider only products eligible for the current usage request by setting the productsConsideredForTariffSplit attribute in the ECE_home/config/management/charging-settings.xml file to CURRENT.

The productsConsideredForTariffSplit attribute can be set to one of the following values:

ALL: ECE uses the default behavior and splits the tariff when a customer purchases a product during a session.
CURRENT: ECE considers only the products eligible for the current usage request and does not split the tariff when the customer does any of the following:
- Purchases a product of a different product type (for example, a data product during a voice session).
- Purchases an offering that ECE does not use to rate the current request (for example, a voice offering that does not apply to the current voice request).
- Purchases an offering that grants balance elements that ECE does not use to rate the current request.

You can configure tariff split behavior in cloud native deployments during installation, before a system restart, or at runtime. For instructions, see:

Configuring Tariff Split Behavior During Installation or Before Restart

To configure tariff split behavior, do the following:

In the override-values.yaml file for the oc-cn-ece-helm-chart, set the productsConsideredForTariffSplit key to CURRENT.
Run the helm install command to deploy the ECE Helm chart:
helm install EceReleaseName oc-cn-ece-helm-chart --namespace BrmNameSpace --values OverrideValuesFile
where:
- EceReleaseName is the release name for oc-cn-ece-helm-chart and is used to track this installation instance. It must be different from the one used for the BRM Helm chart.
- BrmNameSpace is the namespace in which BRM Kubernetes objects reside for the BRM Helm chart.
- OverrideValuesFile is the path to a YAML file that overrides the default configurations in the oc-cn-ece-helm-chart/values.yaml file.

Configuring Tariff Split Behavior at Runtime

To configure tariff split behavior at runtime:

Connect to a JMX editor, such as JConsole. See "Creating a JMX Connection to ECE Using JConsole".
Expand the ECE Configuration node.
Expand charging.server.
Expand Attributes.
Set the productsConsideredForTariffSplit attribute to CURRENT.

Troubleshooting Missing Login Identifier for Existing Accounts After Enabling ECE

When you enable ECE in an environment where BRM and PDC are already live in production, ECE may synchronize only a subset of information for accounts that existed before ECE was enabled. As a result, publicIdentifiers may be populated with aliases, but the login identifier may be missing, which can prevent you from performing actions on those accounts. However, you can occur because, by default, ECE loads the login identifier only when publicIdentifiers is null or empty.

To control whether ECE loads the login identifier along with aliases in its PublicUserIdentity (PUI) cache by setting the loadLogins attribute in the ECE_home/config/management/charging-settings.xml file to true. The loadLogins attribute can be set to one of the following values:

true: ECE loads the login identifier along with aliases into its PUI cache even if aliases are present.
false: ECE loads only aliases into its PUI cache and loads the login identifier only when the alias list is null or empty. This is the default value.

You can configure login identifier loading in cloud native deployments during installation, before a system restart, or at runtime. For instructions, see:

Configuring Login Identifier Loading During Installation or Before Restart

To configure login identifier loading, do the following:

In the override-values.yaml file for the oc-cn-ece-helm-chart, set the loadLogins key to true.
Run the helm install command to deploy the ECE Helm chart:
helm install EceReleaseName oc-cn-ece-helm-chart --namespace BrmNameSpace --values OverrideValuesFile
where:
- EceReleaseName is the release name for oc-cn-ece-helm-chart and is used to track this installation instance. It must be different from the one used for the BRM Helm chart.
- BrmNameSpace is the namespace in which BRM Kubernetes objects reside for the BRM Helm chart.
- OverrideValuesFile is the path to a YAML file that overrides the default configurations in the oc-cn-ece-helm-chart/values.yaml file.

Configuring Login Identifier Loading at Runtime

To configure login identifier loading at runtime:

Connect to a JMX editor, such as JConsole. See "Creating a JMX Connection to ECE Using JConsole".
Expand the ECE Configuration node.
Expand charging.server.
Expand Attributes.
Set the loadLogins attribute to true.

Troubleshooting Long Cycle Grant Validity Splitting

When a bill unit has PIN_FLD_ACTG_LAST_T and PIN_FLD_ACTG_NEXT_T that span multiple months, your customers expect grant validity to be calculated monthly. However, creating an account with an older effective date can extend the billing cycle across multiple months. This happens because, by default, ECE grants overage buckets based on the full billing cycle period, whereas BRM splits them monthly.

When you enable monthly splitting for long accounting cycles, ECE grants validity in one-month periods, as shown in the following examples. For a current long accounting cycle, ECE determines the applicable monthly validity period for the request by using PIN_FLD_ACTG_NEXT_T as the reference boundary. ECE evaluates one month intervals to identify the period that contains the request time and ensures that the validity start time does not precede PIN_FLD_ACTG_LAST_T.

A billing unit has PIN_FLD_ACTG_LAST_T August 1 and PIN_FLD_ACTG_NEXT_T October 1, so the accounting cycle spans two months. ECE grants a request on August 29 that is valid from August 1 through September 1, and ECE grants a later request in September that is valid from September 1 through October 1, instead of granting one validity period from August 1 through October 1.
A billing unit has PIN_FLD_ACTG_LAST_T August 15 and PIN_FLD_ACTG_NEXT_T November 15, so the accounting cycle spans three months and starts mid-month. The system receives requests on October 5 and November 10. If you enable monthly splitting, ECE handles the two requests in different validity periods (September 15 through October 15 and October 15 through November 15, respectively). If you do not enable monthly splitting, ECE applies both requests to the same validity period from August 15 through November 15.

To control whether ECE splits long-cycle grant validity monthly, set splitLongCyclePeriod to one of the following values:

true: Split the grant validity on a monthly basis instead of using the full cycle.
false: Use the full long cycle for grant validity. This is the default value.

You can control whether ECE splits long-cycle grant validity monthly in cloud native deployments during installation, before a system restart, or at runtime. For instructions, see:

Configuring Long Cycle Validity Splitting During Installation or Before Restart

To configure long cycle validity splitting, do the following:

In the override-values.yaml file for the oc-cn-ece-helm-chart, set the splitLongCyclePeriod key to true.
Run the helm install command to deploy the ECE Helm chart:
helm install EceReleaseName oc-cn-ece-helm-chart --namespace BrmNameSpace --values OverrideValuesFile
where:
- EceReleaseName is the release name for oc-cn-ece-helm-chart and is used to track this installation instance. It must be different from the one used for the BRM Helm chart.
- BrmNameSpace is the namespace in which BRM Kubernetes objects reside for the BRM Helm chart.
- OverrideValuesFile is the path to a YAML file that overrides the default configurations in the oc-cn-ece-helm-chart/values.yaml file.

Configuring Long Cycle Validity Splitting at Runtime

To configure long cycle validity splitting at runtime:

Connect to a JMX editor, such as JConsole. See "Creating a JMX Connection to ECE Using JConsole".
Expand the ECE Configuration node.
Expand charging.server.
Expand Attributes.
Set the splitLongCyclePeriod attribute to true.

Reloading the Charging Configuration Reload Fails Due to Missing Cluster Port

When running the chargingConfigurationReloader Kubernetes job to update a charging-settings.xml entry, such as updateResponseTimeout, the job may fail with an error similar to this:

Reloading charging.emGatewayConfigurations Mbean.
Exception in thread "main" java.security.PrivilegedActionException
Caused by: org.springframework.beans.factory.BeanCreationException
Caused by: java.lang.IllegalStateException: 
This ContinuousQueryCache is disconnected. Retry the operation again.

This error usually occurs when the Coherence cluster connection is incomplete or misconfigured.

To resolve the issue, ensure that the cluster port is included in the charging-configuration-reloader.yaml file. In the file, find the following line:

- name: COH_WKA_PORT
  value: {{ .Values.charging.coherencePort | quote }}

Update the line with the appropriate port. For example, this sets the Coherence port to 31016:

- name: COH_WKA_PORT
  value: {{ .Values.charging.coherencePort | default 31016 }}

35 Troubleshooting ECE Cloud Native