11 Exception and Event Definition

The main jobs performed by Active Retail Intelligence are detecting exceptions and guiding a user through a set of workflows or events to respond to the exceptions.

Revalidation of External Realm Exceptions

When an exception occurs and an event is created, that event stays active until you close it by your actions or the event fails reevaluation. Events are reevaluated before actions on them are processed, and, depending on how your user preferences are set, as you open the event viewer to examine and act on them. Event reevaluation verifies that the exception data conditions that caused the event are still true.

Clearly, reevaluation is critical because it prevents you from taking action to correct data conditions that no longer exist. For example, if an order is submitted and an event is created, then the order is unsubmitted, and then you try to approve it from Active Retail Intelligence without first reevaluating, you would be trying to approve an order that is no longer submitted. This would cause various processing errors and be a waste of your time, but not nearly as big of an issue as if you had acted to order more stock for an out-of-stock event, only to find that in the meantime other stock had been transferred in.

Usually revalidation is not a concern since it always happens before action processing. However, you can save some time by using the revalidation user option to reevaluate when viewing events as well, since you can weed out many invalidated events before even trying to decide how to process them.

One case where revalidation is an issue is when the realm causing the exception is part of an external system. In this case, there is no way to ensure that you are not acting to correct a problem that no longer exists. In other words, even if it is not so, external realm exceptions are treated as if they are valid until the event is closed. The only workarounds are to be aware of the issue and do the following:

Take advantage of the creation date parameter added by default to all exceptions, and add it to the event as a parameter that must come from the exception. This gives it visibility, so take it into consideration when acting on such events.
Name the events that are driven by external systems with some convention that users will no require immediate action, or make all such events high priority.
Manually revalidate exception data by doing additional investigation, outside of the data that Active Retail Intelligence offers you, before taking a corrective action.
When possible, reserve external monitoring for events that do not require system critical actions, focusing more on informational notifications.
An issue such as this prompts the question of why revalidation does not work in some other way (internally at least, since it does not work at all externally). For example, why does Active Retail Intelligence not automatically invalidate a purchase order approval event immediately when the order is not submitted back to Worksheet status, and could such a method work for external revalidation?
Most automatic event invalidation strategies are either administratively cumbersome for you or performance prohibitive for the database, so on-demand revalidation seems the best way to go. Even so, Oracle has a continued interest in investigating ways to auto-invalidate external-realm-exception-driven events or to make those external realms more accessible (able to be queried) for on-demand revalidation.
Before reevaluation or revalidation all parameters that can be refreshed ARE refreshed. An exception driven by an "external" (non-refreshable) realm is an "external realm exception", though some of its parameters added from other realms may be refreshable, so the idea that an entire exception is external is somewhat incorrect.
However, the driving realm of an exception does determine how it can be monitored. A non-refreshable (external) driving realm means that the exception monitoring is trickle monitoring (when the realm is an external data feed realm) using the external monitoring APIs.
Tables deployed in the same database instance (internal) as Active Retail Intelligence can be monitored either in real-time or with batch. Oracle tables deployed in a different database instance (external to the Active Retail Intelligence instance) but connected with an appropriate link can be monitored through batch. In both cases these parameters can be refreshed.

Testing Exception and Event Processes

As you are learning to use Active Retail Intelligence, and even as you gain proficiency, you should try to test all new exception and event processes in a special development environment before using them in production. This is important because of performance issues and so you can ensure that the functionality is correct. Although creating Active Retail Intelligence processes is much simpler than doing customization work on the RMS, if these processes are critical, or destined to become critical to your operation as their definitions become more and more refined, then they should be treated as customizations from the perspective of planning, testing, and management.