The exception management concept of the Demand Data Foundation (DDF) module in SAP Customer Activity Repository allows you to quickly view, process, and - once resolved - delete large numbers of exceptions for your area of responsibility (AOR).
Exceptions are system-based messages that inform you about situations requiring special attention or action. In most cases, they are related to business processes (for example, Forecasting configuration and control settings do not exist for product X and location X
). Sometimes they are of a more technical nature (for example, Missing RFC authorization
).
In general, the situations that generate exceptions can occur either in the background or in dialog mode:
Background: These exceptions are typically collected in a log (such as the application log), for later viewing and processing.
Dialog mode: These exceptions usually interrupt business processes with a message because the situation requires immediate attention or action.
The data in DDF is processed in large volumes and a large number of exceptions can occur in the background. These exceptions require postprocessing by users in various roles who need filtering options that allow them to quickly pinpoint and process the exceptions that they are responsible for.
Exceptions collected in DDF are stored on the database so users can conveniently postprocess them using the Monitor Exceptions
function. For more information, see Monitor Exceptions.
If the DDF exception management concept has been integrated, you can use it to process exceptions generated in the consuming application installed on top of SAP Customer Activity Repository. To find out to what extent the concept has been integrated, see the product documentation of your consuming application.
Customer-Specific Integration
DDF includes interfaces that allow you to incorporate the exception management concept into customer-specific enhancements. For more information about how to do this, see the documentation of the following interfaces (transaction SE24):
/DMF/IF_EXCEPTION_MANAGER (API)
/DMF/IF_EXCEPTION_READER (API)
/DMF/IF_EXCEPTION_CHANGE (API)
In addition to having the standard ABAP message features, the DDF exceptions are grouped into the categories “high level” and “low level”. This categorization is not influenced by the exception message type (such as warning or information). A high level exception describes a particular issue; the low level exceptions assigned to it help explain the reasons. A high level exception can be generated without any low level exceptions, but a low level exception is always assigned to at least one high level exception.
High level exceptions provide information about the following:
an unexpected and probably unintended situation with business impact
the actual or expected (business) impact
how critical the situation could be
the reason for the unexpected situation
how the situation could potentially be resolved
If message context information is supported, low level exceptions are provided in addition to the high level exception. The low level exceptions give extra information and indicate the context in which the message was generated. For example, you can see which product in which location is affected, what the sales organization and distribution channel are, or which process has generated the message.
Example
You are transferring the current product prices for a particular location to DDF. However, one of the products does not exist in DDF and the price for that product cannot be stored. For you, the business context is that you want to transfer prices. In this example, the high level exception would inform you of a problem during the price transfer. Additionally, a low level exception would state that a product does not exist, and the specific product and location would be indicated.
You can customize high level and low level exceptions in the activities under
. For more information, see the documentation of each activity (transaction SPRO).The following table shows the most important settings that you can make:
Customizing Activity | Settings | Examples |
---|---|---|
| Message type |
|
Priority (high level exceptions) |
Recommendation Performance considerations: Consider switching off any warnings that you no longer care about. End of the recommendation. | |
Validity period | 30 days (until the exception can be deleted by the Recommendation Performance considerations: Check the default setting and, if required, reduce this to 30 days or less. Business processes, such as modeling, can create millions of messages within a few runs. End of the recommendation. | |
Assignment to business area |
| |
| Priority (low level exceptions) | Note By default, low level exceptions inherit the priority of the high level exception to which they are assigned. You can adapt the setting as needed. End of the note. |
| Select from the provided standard messages to replace them with your own messages. | Note Before you can replace the standard texts, you must first create your own message texts using transaction SE91. The table for the customer-specific replacement messages is End of the note. |
| Add, maintain, delete custom statuses as required for your business. | Default statuses: Example custom status: Under Review |
After you have processed your exceptions, you should use the Purging Exceptions from the Database
report (/DMF/PURGE_EWB_MESSAGES
) to delete the exceptions that you no longer need. In the Monitor Exceptions
function, you can mark exceptions for deletion by this report. For example, you might want to delete all exceptions that have expired. For more information, see the report documentation (transaction SE38).
To access this report on the SAP Easy Access screen (transaction nwbc), choose
.Recommendation
Performance considerations: To avoid risking database overload, you should schedule the report to run on a daily basis.