The Ongoing or Hourly Processes

The following diagram illustrates the dependencies between the ongoing or hourly batch processes.

The mnemonics in the boxes refer to the individual batch processes described above. When a box contains multiple processes, these processes must be run sequentially.

Note:

No dependencies exist. As you can see, there are no dependencies between the boxes (meaning they may be run in parallel).

Throughout the course of the day, you will likely want to run jobs to bring measurement and event data in from the various metering / head-end systems and other external systems. To accompany this, you should consider running the following batch processes:

  • Ongoing Master Data Sync Processing

    With the Oracle Utilities Customer to Meter deployment, data synchronization is used to keep certain objects synchronized. Refer to the C2MIntegration section for further details. Cleaning out synch staging records in error by running D1-SIOER may be necessary.

  • Command Processing

    If using Oracle Utilities Smart Grid Gateway to process device commands, it’s important to keep communications flowing to and from smart meters to provide the most accurate picture of the state of a given meter. This would include:

    • Retrying inbound communications in error (D1-ICERR)

    • Retrying outbound communications in error (D1-OCERR)

    • Processing outbound communications waiting for a response (D1-OCWT) to see if they should be timed out.

    • Processing command request activities in error (D1-CRERR) and those that are waiting (D1-CRWT)

    Note: Base package business objects for communications and command activities are designed to trap any processing errors encountered and transition the object into an Error state. To deal with unexpected errors that can't be trapped, which could leave communications / command activities in unmonitored states, implementations can choose to configure their own batch controls based on the delivered D1-ACTVY and D1-COMM batch controls, restricting records processed by business object or maintenance object as needed

  • Initial Measurement Processing

    For initial measurement processing, the following batch processes should be scheduled on an ongoing basis per business requirements:

    • Processing initial measurements in the pending state (D1-IMD).

    • Processing initial measurements seeders in error (D1-IMDSD).

    • Processing initial measurements in the exception state (D1-GNIMD).

    These processes are also highlighted in the Nightly Processes stream to reflect the need to bring in as much measurement data as possible prior to running billing, both up-to-date data from late-reporting meters and corrected readings from the head-end system.

  • Event Processing

    The base package is configured such that device events are processed immediately upon receipt, since they might need to be sent to some other application such as an outage system. This can be changed by configuring a monitor process on the device event business object to stop records in a specified state, and then use a batch process to process the events all at once. Beyond this type of batch-oriented processing for events, other event processing could include:

    • Re-processing device event "seeders" in error (D1-DVEVS)

    • Processing all device events that can come in as pairs (D1-DEVPR)

    • Picking up device events for processing if they've stopped in any state (D1-DVEVT)

    If device events are configured to be held from being sent onto downstream applications, such as to prevent "flicker" outage events (an outage event and a restore event received in rapid succession) from being sent, device event monitoring (D1-DEVPR and D1-DVEVT) should be set up to be run periodically to ensure timely transmission of events.