This chapter describes the Oracle Communications Billing and Revenue Management (BRM) Pipeline Manager aggregation feature.
For procedural information, see "Creating Aggregation Scenarios".
For information about pipeline rating, see "About Pipeline Rating".
You use the aggregation feature to compile data from event data records (EDRs). Aggregation is typically used for the following:
To filter and summarize data for compiled statistics about service usage, customer activity, network activity, dealer commissions, and so forth. For example, you can compile the sum of charges per customer per month.
To aggregate data and use for rating. For example, you can compile GPRS usage records and rate the aggregated amount.
To output a back-out file used as input for rerating. See "About Rerating Pipeline-Rated Events" in BRM Setting Up Pricing and Rating.
Because the results of aggregation are typically not used by other modules, and because the aggregation process uses more resources than rating, aggregation is typically performed by a separate pipeline. You can run an aggregation pipeline parallel to a rating pipeline, so that the same input files will be processed by both pipelines.
The aggregation pipeline processes EDRs in transactions, typically one transaction per input file. When the transaction is finished, the data is written from memory to a file.
After every transaction, the aggregated results are written to a file that contains the transaction ID. For every transaction and aggregation scenario a result and a control file is created. The control files are used by the Database (DB) Loader utility to load the results into the database. See "Creating Aggregation Scenarios".
You define the control file in the FCT_AggreGate registry entries. After the data is processed by the pipeline, you use DB Loader to load the data from the file to a database. This can be the same database used by Pipeline Manager or a different database. You can run the utility automatically or manually. See "Database Loader".
See "Creating Aggregation Scenarios".
See "FCT_AggreGate", "DAT_ScenarioReader".
Important:
If you configure aggregation for rerating, ensure that the FCT_AggreGate module is working in back-out mode. See "Configuring rerating in Pipeline Manager" in BRM Setting Up Pricing and Rating.You aggregate data by creating aggregation scenarios (see "Creating Aggregation Scenarios"). An aggregation scenario specifies which data to use and how to process the data. You use the following criteria when setting up aggregation scenarios:
Filter conditions: Allows you to choose which EDRs to aggregate; for example, you can specify all calls for a single customer, service, time period, or rate plan.
Note:
Conditional filters for combined attributes are not supported. See "Defining Filter Conditions" in BRM Collecting Revenue Assurance Data.Grouping rules: Allows you to group calls according to various criteria; for example, you can aggregate sums based on levels of duration, as follows:
All calls less than one minute.
All calls from one to five minutes.
All calls over five minutes.
Aggregation functions: You can do the following with the data:
Count the number of selected events.
Sum the values of selected events.
Generate the square sum from values of selected events.
You can use any EDR field for filtering, grouping, or aggregating. However, aggregation criteria are limited to the following:
The data must be in the EDR.
The data must be available for an overall aggregation, typically of a NUMBER type.
Note:
An aggregation scenario is analogous to an SQL SELECT statement with a GROUP BY claus.For example, select all EDRs where the time period is peak time, then group the calls by levels of duration (for example, 0-1 minute, 1-5 minutes), and aggregate the charges for each level of duration.
When you create an aggregation scenario, you define filter, grouping, and aggregation functions. When you run an aggregation pipeline, you specify which scenario to use in the FCT_AggreGate registry. See "Creating Aggregation Scenarios".
Define the following when defining filter criteria for a scenario:
The status of the filter criteria (active or inactive).
The EDR field that the filter is applied to.
The data type to use; for example, string, number, or date/time.
The value to filter with.
The function used for aggregating:
Count
Sum
Square sum
The decimal precision for the aggregated result.
See "Defining Filter Conditions" in BRM Collecting Revenue Assurance Data.
In addition to defining the filters, groups, and aggregation functions, you can use the registry to define the following attributes for each scenario:
The EDR container description for the scenario.
Note:
You can only set up filters and groups for fields included in the EDR container description.A default table name where the aggregation results are stored.
The maximum number of aggregations held in memory before writing the data to a file. Enter 0 to specify an infinite number.
Default directories for the following:
Where to store the aggregation results file (temporary and finished data).
Database (DB) Loader control files.
A default delimiter for the single values of grouping and aggregation fields.
You use grouping rules to group and order aggregation results. Grouping rules are applied to EDR container fields and associated with a rank. For example, aggregation results can be grouped first by the event originator, then by zones, and then by time periods, or by duration, area code, or geographic zone.
When you define groups, you define the database columns that contain the aggregated data. For example, if you group aggregation results by duration, a column for that value is created in the table in the results file.
A group includes the following attributes:
The EDR field for which the values are grouped; for example, time period or duration.
The column name where the aggregations for the group are written in the results file.
The data type for the grouped data:
String
Number
Date/time
If applicable, the output format for the data. This can be date/time values or string format; for example UPPER, LOWER or SUBSTR(x,y).
You create classes to group results for a type of data. For example, to group aggregation results by the duration of events, you can create the duration classes shown in Table 7-1:
| Class | Value to group by |
|---|---|
|
Duration Class A |
0 to 60 seconds |
|
Duration Class B |
61 to 300 seconds |
|
Duration Class C |
301 to 600 seconds |
|
Duration Class D |
More than 600 seconds |
When creating a class, you define the following categories:
The name; for example, duration.
The data type:
String
Number
Date/time
Class items. For each class item you define the following:
The name; for example, duration.
The data type (string, number, or date/time)
The value; the following is an example duration class item:
D=1-5 & HH=08-20
You specify values by using regular expressions. Use the same expressions defined when "Defining Filter Criteria".
Tip:
For values that do not match any other class items, specify an "undefined" class item for every class.About linked classes
You can create multiple linked classes to group results by more than one category. For example, if you create groups for time period and duration, you can group results as follows:
Peak time: 0-1 minute
Peak time: 1-5 minutes
Peak time: over 5 minutes
Off-peak time: 0-1 minute
Off-peak time: 1-5 minutes
Off-peak time: over 5 minutes
During aggregation, class groupings are processed in order as defined in a tree structure. To define this order, you assign classes to nodes in the tree structure. For example, to aggregate data by time and duration, data is aggregated first by the time class, and then by the duration class.