Show TOC

Background documentationException Management

 

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.

Integration

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)

Features

High Level and Low Level Exceptions

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 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.

End of the example.
Customizing

You can customize high level and low level exceptions in the activities under Start of the navigation path Cross-Application Components Next navigation step Demand Data Foundation Next navigation step Basic Settings Next navigation step Exception Management End of the navigation path. 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

Maintain Configuration Data for High Level Exceptions

Message type

Error, Warning, Information

Priority (high level exceptions)

High Priority, Medium Priority, Low Priority, Not Relevant/Switched Off

Recommendation 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 Purging Exceptions from the Database report)

Recommendation 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

Inbound Processing, Modeling, Forecasting

Maintain Configuration Data for Low Level Exceptions

Priority (low level exceptions)

Note 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.

Define Customer-Specific Replacement Messages

Select from the provided standard messages to replace them with your own messages.

Note 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 /DMF/MSGCUST.

End of the note.

Define Customizable Message Status

Add, maintain, delete custom statuses as required for your business.

Default statuses: New, Processed, Ignore

Example custom status: Under Review

Purging Exceptions

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 Start of the navigation path Services Next navigation step Mass Maintenance Services Next navigation step Purging Exceptions from the Database End of the navigation path.

Recommendation Recommendation

Performance considerations: To avoid risking database overload, you should schedule the report to run on a daily basis.

End of the recommendation.