One of the new applications delivered in the SAP NetWeaver stack is the Central Alert Framework (CAF). Why do you need a new way to alert a user to business or technical problems in the first place? Many SAP tools alert users: Process chains and workflow can send email messages. Strategic Enterprise Management, Logistics Information System in R/3, and Computing Center Management System (CCMS) all have alert capability. BW Reporting Agent sends alerts based on exception conditions in BW queries.

The fact that you have so many alert options forms the answer to my question: You need a central way to distribute alerts from various applications, not many separate ways in all the applications previously listed. CAF also supports alerting more generically, delivering alerts from your own custom applications.

Instead of breaking existing alert applications, SAP has left these tools more or less intact; they still trigger the alerts the way they did in the past. Using CAF as the delivery interface is optional. I’ll show you how you might use CAF with BW’s Reporting Agent.

Reporting Agent as of version 2.0B can send out email alerts and post alerts via exceptions views on BEx Analyzer or on the Web using Alert Monitor. As of BW 3.0 it can trigger your own processing of the problem via a Business Add-In (BAdI). The CAF delivery option became available in BW 3.5. Figure 1 shows the new delivery options using CAF. In addition, CAF has features that make it better than the older stand-alone Reporting Agent technique, as Table 1 shows.

Figure 1

Reporting Agent exception processing options

Now that you know why you might want to standardize the user interface for sending alerts using CAF, let me walk you through how to use CAF with Reporting Agent.

Alerting with Reporting Agent and CAF

For the alert implementation that follows, I’m assuming knowledge of the Reporting Agent’s alerting tools that were available in BW 3.0. Remember, CAF can be triggered in many ways; this article is limited to the setup of BW exception-based triggering.

Step 1. Configure the alert category definition. Begin a new CAF implementation by configuring the CAF’s controlling object, which is called an alert category definition. This object forms the interface between the universal delivery functionality of CAF and the application-specific job of triggering the alert. To configure this object, access transaction ALRTCATDEF from BW 3.5. Go to change mode using the pencil icon; the create icon appears, allowing you to create a new alert category.

The options on this object are many, but for the purposes I describe here the setup is simple. The required options are shown in Figure 2. By creating a few (or more than a few) different alert category definitions, you can group related messages that target the same group, or you can create one for each BW Reporting Agent setting when more fine-tuned distribution is necessary.

Figure 2

Alert category definition maintenance

The next section of the alert category definition is the container, which serves as an interface for the calling application, in this case Reporting Agent. Figure 3 shows the required setup for this section of the alert category definition, and Figure 4 shows the end result of this configuration step.

Figure 3

Initial configuration of the alert category definition container

Figure 4

Container details after configuration in Figure 3

The remaining two tabs allow you to define the details of the alert the user ultimately receives. One nice feature of having both Long Text and Short Text tabs (Figure 5) is that you can specify more details and text for an email alert than you would for a short text message/pager output. The user, by way of a user master record (transaction SU01), decides his or her preferred method to be alerted. Additional Long and Short Text features allow the creator of the alert category definition to input variables as part of the message. These variables can include the date and time of the alert as well as other system-related data.

Figure 5

Long and Short Text of the alert category definition

Optional Subseq.Activities allows other links and instructions to be included in the alert that the user receives. In this case, I have included the URL to a BI Web template that includes the query that caused the alert to be sent in the first place. This only works if each Reporting Agent exception setting is tied to its own alert category definition. Refer to Figure 6 for details.

Figure 6

Optional Subseq. Activities tab

Now that you have completed the technical and business-related information about the specific alert, you can decide whom to alert or who can opt in to receive the alert. This is all controlled using the buttons at the top of the Alert Category Change screen (Figure 7). The Fixed Recipients button provides a one-by-one way to enter alert recipients and the Recipients Via User Roles button provides a way to send alerts to everyone in one or more listed BW roles.

Figure 7

Alert category definition recipients and subscription

I consider Subscription Authorization one of the more interesting and important features of CAF. Using this button, you allow users to receive the initial alert, but then they can turn off future alerts. This feature might appeal, for example, to executives overloaded with too many alerts. You enter a list of roles under this tab. All users in these roles have the subscribe and unsubscribe feature, as I will show later.

Step 2. Integration with Reporting Agent. Following the configuration of the alert category definition, you set up Reporting Agent to execute the query, capture the problems, and forward them to CAF. Although the details to set up Reporting Agent are outside the scope of this article, the basics are:

1. Create a query.
   
   
2. Create an exception for this query.
   
   
3. Access Reporting Agent (transaction RSA1) and create a new setting for exception reporting for the query in step 2.
   
   
4. Drag the exception level and then an action to the settings area.
   
   
5. Determine recipients for each action. (This is where CAF comes in.)
   
   
6. List the characteristics that will appear on the exception views generated by the agent using drag and drop.
   
   Keep the number of exception views small by listing the characteristic with the fewest output combinations first. This might be a time characteristic and the query would generate only one value such as current week.
   
   
7. Activate the agent.
   
   
8. Create a scheduling package and schedule this using process chains following the successful loading of the related data target.

Of all the steps above, the only change necessary to integrate the new CAF is in step 5. In lieu of using Reporting Agent to directly send alerts with real recipients entered in Reporting Agent, the Reporting Agent recipient is an alert category definition of the CAF. This is shown on Figure 8.

Figure 8

Reporting Agent setting to trigger the CAF

In accordance with the normal tasks of Reporting Agent, the final step following activation is the scheduling of the Reporting Agent setting as part of a scheduling package.

Step 3. Processing alerts. Following execution of the setting (normally as part of a process chain), Reporting Agent sends the information about the exception to CAF. Based on user settings in SU01 and generic configuration of SAP Connect (SAP’s link to external mail services, transaction code SCOT), CAF sends the alert notifications via a posting on an Internet application or via email, SMS, or pager. The email message shown in Figure 9 is the result of the settings in my example.

Figure 9

Email output from CAF

In addition to the external access via email, SMS, or pager, CAF comes delivered with an Internet application that you can easily incorporate in a portal or as part of another Web application. This application was developed by SAP using Business Server Pages (BSPs). After activation in transaction SICF, it can be accessed by adding a BSP link to either your favorites or a role, as shown in Figure 10.

Figure 10

SICF and the BSP application for the alert inbox

Once added to your favorites or a role, the link in Figure 10 takes you to the CAF’s alert inbox on the Web. The alert inbox shows all the alerts to which a user is assigned and has not unsubscribed. It features the ability to confirm the alert, in which case it drops from the list, and the ability to forward an alert to others. In addition, you can subscribe and unsubscribe, using the appropriate link and then the light bulb icon, which acts as a switch turning the alert on and off.

In the Personalization tab, you can designate a representative to receive your alerts of all types or just a specific type (email alerts, for example). This designation can be specified with or without a specified time period. Figure 11 summarizes the features of the alert inbox.

Figure 11

The alert inbox

As you can see, alerting has taken on a new state of the functionality when Reporting Agent and the new CAF are combined. If you have already implemented Reporting Agent alerting, the conversion is not technically hard, but you have a few training issues to consider as the interface will not look exactly the same as with Reporting Agent alone. For those customers just starting on alerting, CAF is the way to go.

Ned Falk

Ned Falk is a senior education consultant at SAP. In prior positions, he implemented many ERP solutions, including SAP R/3. While at SAP, he initially focused on logistics. Now he focuses on SAP HANA, SAP BW (formerly SAP NetWeaver BW), SAP CRM, and the integration of SAP BW and SAP BusinessObjects tools. You can meet him in person when he teaches SAP HANA, SAP BW, or SAP CRM classes from the Atlanta SAP office, or in a virtual training class over the web. If you need an SAP education plan for SAP HANA, SAP BW, BusinessObjects, or SAP CRM, you may contact Ned via email.

You may contact the author at ned.falk@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.