| Oracle® Retail Active Retail Intelligence User Guide Release 15.0 E65706-01 |
|
 Previous |
 Next |
| Oracle® Retail Active Retail Intelligence User Guide Release 15.0 E65706-01 |
|
Previous |
Next |
Metadata maintenance is one of the most critical tasks in Active Retail Intelligence. No matter how well a business analyst defines exceptions and events, if the metadata does not accurately describe the DDL, ARI will not work correctly. Fortunately, because metadata reflects data storage specification and code specifications, it is not likely to change often in a redundant environment.
The following are requirements and recommendations for maintaining metadata.
Prior to the use of any ARI functions, the REALM.SCHEMA field must be updated to reflect that actual schema name in which the functions and tables are deployed. This can be done through the user interface for several 100 realms, but is better done in SQL*Plus by looking at what already has a schema name and validating against the DDL. A couple of update statements should be sufficient.
A business analyst may define functions to calculate values not stored on the database or to act as action shells around existing Oracle functionality so that actions available on an event can be created. In these cases, metadata for these new DDL objects can be created at any time without regard to the production schedule. This is generally true of any newly created objects, including new external data sources monitored through the API.
When the DDL is changed, the metadata needs to be updated to reflect it immediately. Active Retail Intelligence processes that expect data objects with one definition and instead find a different definition will, as a result, miss processing any exception candidates that might have occurred between the time that the DDL is changed and the metadata is updated.
Updating the metadata alone is not enough to start catching the new exceptions, but it will at least prevent time-wasting error generation. In some cases, the exception being monitored may not be critical enough that a gap in the exception record is even critical, or if it is not real-time monitored, a delay in detecting the exception (which is only periodically monitored anyway) may not be critical. However, in many cases the goal is in fact to catch all real-time exceptions.
In this case, after updating the DDL and the metadata, it is necessary to rerun the ARI_CONTROL_SQL processes to rebuild the monitors and associated support code. Of course, this process must run with no other user logged in or any other process running (as defined in the Oracle Retail Batch Schedule). This means that it may be difficult to rerun the process if the DDL and metadata are updating during the day; but this shouldn't be a problem in a production environment since, in such an environment, DDL changes are not made during production hours anyway.
The recommended procedure for changing the DDL is: run the shutdown process, disconnect users, change DDL, update metadata, run the build process, bring the database back up, and run the restart process.
Many actions within the Oracle Retail Enterprise Suite can be used directly from Active Retail Intelligence simply by describing them in metadata. Others involve user interaction, depending on certain checks made as the process is performed. Generally it is best to take these actions by using ARI's Event Viewer as a gateway into the appropriate GUI and then taking the action, using the traditional method defined in the GUI. In some cases, however, the user interactions have a limited number of outcomes and it may be useful to create a fully automated action that, when demanding user interaction, uses a predefined value.
Updating the metadata alone is not enough to start catching the new exceptions, but it will at least prevent time-wasting error generation. In some cases, the exception being monitored may not be critical enough that a gap in the exception record is even critical, or if it is not real-time monitored, a delay in detecting the exception (which is only periodically monitored anyway) may not be critical. However, in many cases the goal is in fact to catch all real-time exceptions.
An example of this is approving a purchase order check the open to buy. Two function shells could be created for approve order, one of which approves even if the OTB is exceeded. One does not proceed if the OTB is exceeded. The user can set up automated rules then to approve even if over the OTB, or can set up rules to approve but not if over the OTB. These action shells are described as two different actions in metadata and behave like two different functions, even thought they are coded around the same base Active Retail Intelligence code. In fact, it is possible to create a single shell with two different INSTANCE IDs in the metadata that have different default values for an input parameter that determines whether to ignore the OTB warnings.
