Package psdi.app.eventresponse

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

See: Description

Interface Summary

Interface	Description
EventResponseRemote	Remote interface to a EventResponse Mbo.
EventResponseServiceRemote	Remote interface to the EventResponse Service.
EventResponseSetRemote	Remote interface to EventResponseSet.

Class Summary

Class	Description
ERUtility	This is a collection of utility functions to use when dealing with event names and topics.
EventListenerRegCacheFactory	Wrapper class of tenant specific caches of EventListenerRegistration
EventResponse	EventResponse defines, by a specific reference Mbo, actions to take on event messages for specific source Mbo.
EventResponseMboMonitor	This object listens to EventResponse Mbos being added or deleted and updates the RespondingEventListener.
EventResponseService	EventResponse Service.
EventResponseSet	EventResponseSet has special methods to determine whether this set is created for an immediate response.
ImmediateList	This singleton class stores the ER changes registered through the service.
ImmediateListFactory	Wrapper class of tenant specific ImmediateList
RespondingEventListener	This object is created to respond to all events and redirect those to the members of the ER set that match the source and event name.
TimePriorityQueue	This class ensures that abandoned ERSets aren't left in memory of the Immediate List.

Package psdi.app.eventresponse 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

• ERKey -- Has all the unique identifying data for a Event Response. Used for keys in hash tables.
• ERUtility -- A collection of utility functions for dealing with event names and topics.
• EventListenerRegistration -- Manages the events the RespondingEventListener listens to. This class is a singleton.
• EventResponse, EventResponseSet -- The Event Response Mbo and Set record event name, mbo identification, and action data.
• EventResponseMboMonitor -- This object listens for EventResponse Mbos being added or deleted and updates the RespondingEventListener. This is a singleton.
• EventResponseService -- The Event Response Service has a method to register a response, creating a EventResponse Mbo from parameters of a method call.
• ImmediateBase -- This class stores the Immediate Nodes for a given ERKey.
• ImmediateList -- This singleton class stores the ER changes registered through the service. It keeps track of the changes per source Mbo. The immediate list has a hash table of Immediate Bases using LDHashKey as keys.
• ImmediateNode -- Immediate Nodes are the leaf ends of the ImmediateList structure. They store EventResponseSets per reference Mbo.
• LDHashKey -- Defines a lookup key given a Table and a Unique ID.
• NodeRegistration -- Stores and handles the registering / unregistering of a single topic node.
• RespondingEventListener -- This object is created to respond to all events and redirect them to the members of the ER set that match the source and event name. It also supports matching immediate changes, before ER Mbos are saved to the database.
• TimePriorityQueue -- This class ensures that abandoned ERSets aren't left in memory of the Immediate List.
• TopicRegistration -- Stores the registration details for a single topic base and its nodes.

Related Documentation

• MXServer -- This object's getEventTopicTree method returns a reference to the framework's event listener object.
• EventTopicTree -- This is the framework's event listener registar.
• Action -- Actions are used to define what will happen in response to an event.
• WFInstance -- Workflow Instances register responses in order to prevent status changes or make fields read-only.
• WFWaitList -- Wait Nodes of a work flow process register themselves to wait for events to happen to the controlled Mbo.

Last updated: Wednesday, April 9th, 2004