MATRIXX Event Detail Records

MATRIXX Engine generates an Event Detail Record (EDR) for all activities that can trigger rating, such as usage, catalog item purchases and cancelations, recurring cycle processing, or the first use of a balance. MATRIXX Engine also generates EDRs for non-rated events such as forfeitures. You configure event generation in My MATRIXX, including the events to generate and whether to add a custom container with additional mapped fields.

EDRs can contain information from the network message, such as the subscriber ID, device ID, and event type initiated. They can also contain information about the product offers used during rating, the charges, discounts, and grants that update balances, and updated balances and meters. For aggregated balances, only the impacts to the general ledger (G/L) balance are recorded. For debits associated with one-time usage events, such as SMS, if the usage event fails, the refund information is also included in the EDR.

Each EDR has a unique identifier (the EventId) that has a minimum of two parts:
  • A three-character encoded event date for internal use. For example, F2F.
  • An event ID value (string). This is the value assigned by MATRIXX Engine. For example, 0:1:52:7.

F2F0:1:52:7 is an example of an EventId with an encoded event date.

In addition to the EventId, each EDR also includes:
  • An EventTime.
  • (Usage EDRs) A Duration.
  • If the EDR is associated with secondary events, a SecondaryEventList to identify them. Also, a placeholder attribute called SecondaryEventList that is initially empty but is later populated with any related secondary events by the Event Streaming Framework.
Each EDR has the balance impacts for a single wallet (subscription or group) only. EDRs also include the following information when a zero amount is applied to offers and balances:
  • An optional, configurable per-engine prefix value for use in multi-engine installations.
  • Charges.
  • Discounts.
  • Grants.
  • Adjustments.
  • Cancellation refunds.
  • Cancellation forfeitures.
Note: Tax information for charges, discounts, and refunds is also included in EDRs when applicable. For information about taxes, see the discussion about taxation in MATRIXX Pricing and Rating.
Multiple EDRs can be generated per network message in the following circumstances:
  • If an activity impacts multiple wallets, then multiple EDRs are generated with one primary event associated with the event initiator’s wallet and one or more secondary events. Secondary events reference the primary event EventId and do not duplicate the primary event balance impact information. When primary and secondary EDRs are generated, they are always in the same MtxEventRecordData.

    For other impacted wallets, MATRIXX Engine generates secondary events that record impacts to balances in those wallets. Secondary events can include some information from the primary event, such as the ID of the event initiator, and certain tax-related fields. Secondary events are included in one batch with the associated primary event. Secondary events reference their primary event using the primary event EventId.

  • When the action triggers recurring processing or processing associated with first use of a balance. A separate EDR is created for the action and for the recurring processing or first-use processing.
  • When a Diameter Credit-Control (CC) message includes usage for multiple service contexts, each of which is rated separately. A separate EDR is created for each service context.
  • When rating a session and an INTERIM message is received (regardless of whether the INTERIM message has a rated amount). A separate EDR is created for each INTERIM message and the STOP message.

Extend an EDR with additional fields by changing the service type definition or the event type definition in My MATRIXX. Any events added to parent service type definitions are also included in the EDR for a child service type. The fields can be located in a message MDC and the subscription, group, device, and user MDCs. The fields can also be located in the MtxMultiServiceData MDC, which allows administrators to populate EDRs with fields from specific service contexts. The source field must be located in the MultiServiceList element (in the message MDC) for a service context.

To add fields from non-usage events, you must create an event mapping to map the event containing the additional fields to an operation type, such as recurring_subscription.

EDRs are stored in the event database. When the event database reaches the maximum allocated size, EDRs are deleted starting with the oldest to make room for new EDRs. The event database allows recent events to be included in query results before they have been written to an external database. SubMan queries can retrieve in-process aggregations associated with a specific device, subscription, or group. Each event has balance impacts for one subscription or group. To create a complete event query result, query both the external and the in-memory event database, and then remove any duplicated events (events found in both databases). A query of the external database by itself does not include events generated shortly before the query.

Note: The event database only allows insert and delete operations; EDRs in the event database cannot be updated or modified.

EDRs are written to the transaction log as part of the commit operation for the transaction that rated the event. This ensures that an EDR is always logged if balances in the database were impacted. Activities that do not result in updates to the database, for example, subscription queries, do not generate EDRs. EDRs are written in the transaction log in MDC format. The Transaction Server changes to a new log file based on time and size configuration parameters.

EDR details are contained in MATRIXX Event Files (MEFs). For an overview of MEFs, see the discussion about MATRIXX Event Files.

MATRIXX Engine can optionally load EDRs into the Event Repository. The Event Repository is an optional component separate from MATRIXX Engine that serves as a long-term event storage repository. Each EDR includes a DeleteCode that can be used to remove EDRs from the Event Repository using the Event Purge utility. For more information about Event Repository and the Event Purge utility, see the discussion about purging events from the Event Repository.

How and where EDRs are stored (whether they are loaded into the event database, loaded into the Event Repository, or written into MEFs) has no effect on the EDR contents.

For more information about MtxNotification, see the discussion about notification data relationships.