Configuring Information Lifecycle Management (ILM)

Related Eligibility Algorithms

There are a several Oracle Utilities Meter Data Management specific algorithms involved with ILM refer to the detailed description of the algorithm type of each algorithm for more information about the functionality each provides:

1. ILM Eligibility - Activity (D1-ILMELGACT): determines eligibility of Activities and cascades child Activities, Communication Out, Communication In, Device Events, and Completion Events.
2. ILM Eligibility - Communication In (D1-ILMELGCI): determines eligibility of Communication In.
3. ILM Eligibility - Communication Out (D1-ILMELGCO): determines eligibility of Communication Out and cascades Communication In.
4. ILM Eligibility - IMD (D1-ILMELGIMD): determines eligibility of Initial Measurement data and cascades VEE Exceptions.
5. ILM Eligibility - Device Event (D1-ILMELGDE): determines eligibility of Device Event data and cascades VEE Exceptions.
6. ILM Eligibility - Usage Transaction (D1-ILMELIGUT): determines eligibility of Usage Transactions.
7. ILM Eligibility - Usage Transaction Exception (D1-ILMELGUEX): determines eligibility of Usage Transaction Exceptions.
8. ILM Eligibility - VEE Exception (D1-ILMELGVEX): determines eligibility of VEE Exceptions.

The following provides additional information beyond that provided in the ILM Eligibility - Activity (D1-ILMELGACT) algorithms' detailed descriptions on how specific activity types are handled:

• Request Orchestration Activities: Request orchestrations also archive any child activities that were created, and those child activities archive any child activities or data (completion events, device events, etc.).
• Field Activities / Command Activities: Field activities and command request activities are archived either as part of a request orchestration or by themselves. When a field activity/command request is archived, it also archives any of the following child transactions:
  • Update/Cancel Orchestrators
  • Communication Out
  • Communication In
  • Completion Event
• Non-Dispatchable Activities: Non-Dispatchable activities archived either as part of a request orchestration or by themselves. When a non-dispatchable activity is archived it also archives child completion events.
• Orchestration Maintenance Activities: Orchestration Maintenance activities are only archived by themselves if they do not have a related activity. When an orchestration maintenance activity is archived it also archives any of the following child transactions:
  • Communication Out
  • Communication In
• Device Event Activities: Presently device event activities are limited to outages which have an initiating and an ending device event. These types of activities cannot be archived until their related device events are either archived or ready to archive. However the device events do not have to wait for the activity to archive so the device events are not updated with the activity's ILM date.
• Bulk Activities: Bulk Activities are comprised of the Bulk Header and the Bulk Request/Response, and depending on how the header was created there will be one header to many bulk requests/responses. The Bulk Header will only be eligible for archive if all related Bulk Request activities are also eligible for archiving. All related bulk activities are archived together. Bulk activities also generate one-to-many command request activities. Those individual command activities are archived separately.
• Extract Request Activities: These activities are used to request data from the head-end system on a periodic basis. Extract request activities should be in a final state prior to being archived.
• Other Activities: Other types of activities can be archived provided they do not require any special logic for handling for archiving purposes, such as checking for related data. These activity types can archive without checking related transactions:
  • Consumption Sync
  • Dimension Scanner
  • Error Activity
  • Measurement Quantity (deprecated)
  • Meter Read Download Activity
  • Suppression
  • Usage Transaction Correction Processor

In the event that your implementation uses custom activity types that require special handling, a custom algorithm should be created and added prior to the base package algorithm to preemptively handle the activity type category.

Related Batch Controls

There are a several Oracle Utilities Meter Data Management specific batch controls involved with ILM:

1. ILM Crawler - Activity (D1-ACTCR): identifies and executes eligibility evaluation for Activities. This batch control supports multiple retention periods.
2. ILM Crawler - Communication In (D1-CICRL): identifies and executes eligibility evaluation for Communication In.
3. ILM Crawler - Communication Out (D1-COCRL): identifies and executes eligibility evaluation for Communication Out.
4. ILM Crawler - Device Event (D1-DECRL): identifies and executes eligibility evaluation for Device Events.
5. ILM Crawler - IMD (D1-IMDCL): identifies and executes eligibility evaluation for Initial Measurement Data. This batch control supports multiple retention periods.
6. ILM Crawler - Usage Transaction Exception (D1-UEXCL): :identifies and executes eligibility evaluation for Usage Transaction Exceptions.
7. ILM Crawler - Usage Transaction (D1-UTCRL): identifies and executes eligibility evaluation for Usage Transactions.
8. ILM Crawler - VEE Exception (D1-VEXCL): identifies and executes eligibility evaluation for VEE Exceptions.

For additional details see the Batch Processes section the Oracle Utilities Application Framework Administrative User Guide.