Event Response dynamically defines actions to occur in response to an event on a specific Mbo.

See: Description

Package Description

Event Response dynamically defines actions to occur in response to an event on a specific Mbo. Responses to events on Mbos can be cleared or changed at any time.

Package Overview

The event response system uses the framework event facility. Built into the framework, events are thrown at certain defined occurrences. The names of these events have the form of "maximo.workorder.delete" or "maximo.workorder.statuschange.appr". Objects, like the RespondingEventListener, can register with the framework to be informed of these events, or a selection of similar events. An object registering for "maximo.workorder.*" will be informed of events like "maximo.workorder.delete" and "maximo.workorder.update", but not "maximo.workorder.statuschange.appr" - The wildcard only applies to the last section of the event name. Each event has different parts. All events have a "validation" action where interested listeners can prevent the action from being performed. For example, an event listener throwing an exception in the validation action of a "maximo.workorder.statuschange.appr" event will prevent that work order approval. Then there is the "presave", "event", and "postcommit" actions. Event listeners can do what they want here, but unlike the "validation" action, throwing exceptions won't prevent the event from continuing. "Presave" and "PostCommit" are only throw around events that update the database in some way.

A source Mbo may only register a single response to a target Mbo and event.

EventResponse Mbos record an event name, the source Mbo which throws the event, actions to perform in the validation, presave, action, and post-commit parts of the event, the target Mbo for the actions if the actions aren't supposed to be performed on the source Mbo, and the reference Mbo which is the one responsible for installing and controlling the event response record.

RespondingEventListener (REL) is a singleton object. It listens for all events required by the EventResponse Mbos, fetches EventResponse Mbos matching the event name and source, and executes the action for the part of the event (validation, presave, action, postcommit). The REL also supports adding EventResponses before the ER Mbo is written to the database. This allows a workflow instance to register event responses and immediately use them.

The classes EventListenerRegistration (ELR), TopicRegistration, and NodeRegistration record what events the RespondingEventListener is listening to. The aim is to listen to the minimum number of events, to avoid unnecessary processing. The ELR is a singleton object that stores event bases, like "maximo.workorder" or "maximo.po.statuschange", with TopicRegistration objects. In turn the TopicRegistration objects stores event name nodes, like "*" and "delete", with NodeRegistration objects. NodeRegistration object records the listener ID returned when the REL is registered to listen to the event. That ID is needed to unregister if the REL wants to stop listening. The structure of TopicRegistration + NodeRegistration matches the framework's event structure of topic's and nodes. These classes work so that an event topic is listened for using a wildcard or specific nodes. Listening for both, like "maximo.po.delete" and "maximo.po.*", would result in the REL getting informed of the same event twice.

The classes ImmediateList, ImmediateBase, and ImmediateNode support registering Event Responses before the ER Mbo is written to the database. These records take the place of database records until the ER Set is saved or deleted. Like the ELR, the ImmediateList is a singleton object but the structure of these object are not similar to ELR, TopicRegistration, and NodeRegistration. Changes are tracked per source Mbo in the Im'List, per event name in the Im'Base, per reference Mbo in the Im'Node. These objects work together, along with the EventResponseService method registerResponder, to update the ER sets fetched from the database with immediate, unsaved changes. These objects actually create ER Mbos using data from the registerRepsonder method.

The TimePriorityQueue prevents discarded immediate changes from hanging around forever.

Objects that create EventResponses are responsible for clearing them before the source, target, or reference Mbo is deleted.

Package Specification

Descriptions of the package's Mbos and other Objects

Related Documentation

Last updated: Wednesday, April 9th, 2004