1. System Administrator's Guide
  2. ECE System Administration
  3. Managing Failed Customer Data Updates

80 Managing Failed Customer Data Updates

Learn how to configure and manage failed customer data updates in Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE).

Topics in this document:

Managing Failed Customer Data Updates

The following are examples of when customer data updates from BRM might fail:

  • A delay in receiving PDC pricing data

    A PDC delay where ECE has not received a charge offer or discount offer from PDC but did receive the offer external ID from BRM. Since the offer is not loaded into ECE because of the PDC delay, the external ID update does not find the offer in the cache. Consequently, the offer update fails.

  • Configuration errors in customer data

  • Errors in management requests associated with the rerating process

    Management-type requests for the rerating process, such as PrepareToRerate and RerateCompleted, may fail.

Customer data updates are placed in a suspense queue. As part of the post-installation tasks in an ECE installation, you create the suspense queue for BRM Gateway to collect the failed customer data updates and you create a queue table called ifw_sync_sus.

Once you have collected the failed updates, you view them in the BRM Gateway suspense queue and manually reprocess. When failed updates are moved to the suspense queue, error messages are displayed in the customerUpdater.log files in the ECE_home/logs directory.

To view the failed updates in the suspense queue:

  1. Map the suspense queue to the ifw_sync_sus table.

  2. Run the select user_data from ifw_sync_sus query to view the failed events after connecting to the SQL database.

Once you view the events in the suspense queue and you identify the cause of failure, you propagate the events from the suspense queue to the BRM Oracle DM database queue with the events_propagate_utility script. The Customer Updater reprocesses the events. For more information, see "events_propagate_utility.pl".

Moving Failed Data Updates From the Suspense Queue

ECE automatically moves the failed updates from the suspense queue at regular intervals to BRM Gateway. You can change the interval at which the requests are moved from the suspense queue and the maximum number of requests that can be moved at a time.

Typically, ECE moves the update failed due to network failure or other exceptions in BRM; for example, credit limit breach. However, if the update failed due to incorrect message format, you must manually fix the format and then move the failed update. You can perform this by using WebLogic Server Administration Console.

Before fixing the message format, you can increase the interval for moving the failed updates to BRM Gateway, as required, so that the requests are moved to BRM Gateway only after you fix the message format. See "Modifying the Interval and Batch Size for Moving Failed Data Updates".

To fix the message format and move the failed update manually, do the following in WebLogic Server Administration Console:

  1. Export the update request into an XML file.

    For instructions, see the discussion about exporting messages in the WebLogic Server Administration Console Help.

  2. Fix the message format by editing the XML file.

  3. Import the fixed update request in the XML format.

    For instructions, see the discussion about importing messages in the WebLogic Server Administration Console Help.

  4. Move the failed updates from the suspense queue by doing the following:

    1. Log on to the WebLogic server on which the BRM Gateway suspense queue resides.

    2. Log in to WebLogic Server Administration Console.

    3. In the Services section, select JMS Modules.

    4. In the JMS Modules, click ECE Module.

    5. In Summary of Resources, click Suspense Queue.

    6. Click Monitoring, and select ECE!Suspense Queue.

    7. Click Show Messages.

      The Summary of JMS Messages appears.

    8. In the JMS Messages table, select a message.

    9. Click Move.

    10. In the NotificationServer field, select JMS Server.

    11. In the DestinationServer field, select Suspense Queue.

    12. Click Finish.

      The failed update is sent back to the BRM Gateway suspense queue for reprocessing.

Modifying the Interval and Batch Size for Moving Failed Data Updates

To modify the interval and batch size for moving the failed data updates from the suspense queue to BRM Gateway:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand charging.brmGatewayConfiguration.

  4. Expand Attributes.

  5. Specify the values for the following attributes:

    • brmSuspenseQueuePeriod. Specify the interval (in milliseconds) for moving the failed update requests from the BRM Gateway suspense queue to BRM Gateway.

    • jmsBatchSize. Specify the maximum number of failed update requests to be moved from BRM Gateway suspense queue to BRM Gateway in a batch.

Purging Failed Data Updates From the Suspense Queue

To manually delete a failed update:

  1. Log on to the WebLogic server on which the suspense queue resides.

  2. Log in to WebLogic Server Administration Console.

  3. In the Services section, select JMS Modules.

  4. In the JMS Modules, click ECE Module.

  5. In Summary of Resources, click Suspense Queue.

  6. Click Monitoring, and select ECE!Suspense Queue.

  7. Click Show Messages.

    The Summary of JMS Messages appears.

  8. In the JMS Messages table, select a message.

  9. click Delete.

The failed update is deleted from the suspense queue.

Loading Events Into the Database

After you view the events in the suspense queue and identify the cause of failure, you propagate the events from the suspense queue to the Account Synchronization Data Manager (DM) database queue with the events_propagate_utility script. Customer Updater reprocesses the events. You can also move events or purge data from the suspense queue by using the events_propagate_utility script. For more information, see "events_propagate_utility.pl".