Messaging functionality in SAP BW allows you to provide clear error messages to the monitor about why a data load failed. This helps with troubleshooting, making for a more efficient batch processing window as the BW administrator can more quickly identify and fix errors.
Key Concept
Data loads into SAP BW sometimes require advanced filtering or validation of data at the time of data load. This filtering and validation usually occur in the update or transfer rules. You can accomplish further filtering via start routines in the update or transfer rules.
BW data requirements sometimes make it necessary to abort or fail a data load if certain validations are not met. The failed packages are set to red to indicate the failed load. For example, say you expect to get flat files of data from an external source to feed a BW InfoCube. It should only contain data for division 10. If any other division appears in the flat file, you want to fail the load and set it to red to indicate an error with the source data.
You can set up a check in either the update rules or the transfer rules to validate the division field. If any other division shows, you would set the ABORT flag and fail the data load. The monitor would show a red light for this data load, and the data would not be loaded into the InfoCube.
Troubleshooting failed data loads can be difficult without communication of the failed load to the load monitor. In the example above, it would be helpful to know that an unexpected division came through on the flat file. I will explain how to send such messages so the results of validation in transfer or update rules are shown and communicated to the monitor.
Whoever monitors batches can then be given specific instructions on how to deal with each of the error messages that may appear in the monitor. This cuts down significantly on the time to troubleshoot because they do not have to research the actual data to determine why a specific package failed during batch processing. It is a good idea to use this messaging whenever you plan to abort a data package. I have used this technique multiple times and have found that it provides a very good method of communicating messages to the monitor.
You can send messages to the monitor in update rules, transfer rules, or start routines. The coding technique is a bit different for each. In my coding examples, I will use very simple filter criteria, filtering data loads to include only division 10. You can alter this code to your specific filtering and messaging criteria. My goal here is not to show how to filter, but how to communicate the results of a filtered record to the monitor.
Transfer Rules
To show messages and filter data in transfer rules, you first add a routine to one of the InfoObjects in an InfoSource. You can add routines on individual key figures or characteristics (Figure 1). You get to this screen by choosing transaction RSA1 and then InfoSources. Double-click on the source system assignment of an InfoSource. The InfoSource shown brings in flat-file data through the InfoSource to the InfoCube.
Figure 1
Transfer rules routine on 0DIVISION
The routine appears on the InfoObject 0DIVISION. Although in this example I am only filtering on one InfoObject, you can place filtering on any InfoObject that appears in the InfoSource. Thus, you are not limited to sending messages to the monitor from just one routine.
The goal is to fail a data load and send a message to the monitor if records come in from the source that is not division 10. This is a legitimate scenario because often outside data sources provide data to BW and you have no way to ensure that the outside data source conforms to the rules of BW. The routine code in Figure 2 shows the coding technique to check for division 10 and if it is incorrect, to abort the load and send an error message to the monitor. Let me break down the code.
* Check to make sure division is valid. If so allow, if not abort and
* provide message in applications log.
data: l_s_errorlog like g_t_errorlog with header line.
If TRAN_STRUCTURE-division ne 10.
l_s_errorlog-msgty = 'E'.
l_s_errorlog-msgid = 'ZZZ'.
l_s_errorlog-msgno = '001'.
l_s_errorlog-msgv1 = 'Error - Invalid Division'.
append l_s_errorlog to g_t_errorlog.
ABORT = 1.
ENDIF.
RESULT = TRAN_STRUCTURE-division.
* returncode 0 means skip this record
RETURNCODE = 0.
|
| Figure 2 |
Code in transfer rules |
The data statement field l_s_errorlog allows for a work area to place the error messages. The system, by default, provides a global area called g_t_errorlog to provide error messages. You populate this global area with error messages that are then automatically displayed in the monitor. In the code, you place the fields you need into a local work area l_s_errorlog. At the end of the code, send your local area fields to the global area g_t_errorlog so the system can send this to the monitor.
You must fill several fields in the code to send messages to the monitor. Populate all of these fields in your code to send a message to the monitor:
- MSGTY: Message type. When sending error messages, set to E for error.
- MSGID: Message ID — an up-to-20-character descriptor of the message with any characters you want. The system uses the message ID to display with the message in the monitor. It is used for display purposes only. You can use it for your own internal message ID codes. For example, you could document message IDs for a specific action each time a specific message ID is shown.
- MSGNO: Message number — any number from 1 to 999. The system uses the message number for display purposes only with the message in the monitor. Again, you could document message numbers to recommend specific actions whenever a message number appears.
- MSGV1: Message — the text of the error message to be shown in the monitor. It can be up to 50 characters. This is where you place your message such as “Invalid data - Incorrect Division.” The monitor will show the message text.
In the example above, I set the message type to E for error, the message ID to ZZZ, and the message number to 001. I then set the message as “Error - Invalid Division” and the ABORT flag to 1. This sets the data load package to red and the monitor shows the message using the message ID, number, and text (Figures 3 and 4). The system now shows an error message, which indicates a message is in the log. The user then views the log. Figure 3 shows the button you use to view the log and then to see the custom error message.
Figure 3
Monitor of data load showing error as a result of the ABORT flag. Click on the message log to display the custom error message
Figure 4
Error in the message log shown after clicking on the error message icon in Figure 3
Transfer Rule Start Routine
Start routines loop through data all at once in either the transfer or update rules. You run the start routine in the update or transfer rules before doing any other mapping in the update or transfer rules. From the start routine you can validate data and send messages to the monitor.
Use the start routine code either by itself or in conjunction with individual routines used on characteristics or key figures in the transfer rule or update rule. This is a big advantage because you can then use code to send messages to the monitor both from the start routines and in the individual routines found on each key figure or characteristic mapping.
Basically, start routines give the advantage of looping through all data and validating several things at once, if needed. You can then send the results of any failed validation to the monitor via messaging. Figure 5 shows the coding technique for the transfer rule start routine.
The code in Figure 5 loops through all data into an internal table if the division is not equal to 10. If this occurs, an error message is sent to the error log global table. The system then displays the error message in the monitor.
DATA: l_s_datapak_line type TRANSFER_STRUCTURE,
l_s_errorlog TYPE rssm_s_errorlog_int.
loop at datapak into l_s_datapak_line where division ne 10.
l_s_errorlog-msgty = 'E'.
l_s_errorlog-msgid = 'ZZZ'.
l_s_errorlog-msgno = '001'.
l_s_errorlog-msgv1 = 'Error - Invalid Division'.
append l_s_errorlog to g_t_errorlog.
ABORT = 1.
endloop.
|
| Figure 5 |
Transfer rule start routine code |
The coding technique for sending messages in transfer rule start routines is similar to sending messages in transfer rule routines. You cycle through the data coming in, look for those records that are not in the desired division, and set the error messages into the global area g_t_errorlog.
Update Rules
It is also possible to send a message to the monitor in update rules. Update rules differ from transfer rules because they run after the transfer rules but before the package gets to the InfoProvider. To filter on the division, the first step is to add a routine to the division characteristic in each of the key figures of the update rule (Figure 6).
Figure 6
Division field with a routine in the update rules characteristics
The coding technique for update rules is similar to the coding for the transfer rules. The fields are the same as those as shown in the transfer rules. The difference here is that you fill the fields into an internal table called MONITOR. The code appends the message to this internal table and an error message appears in the monitor. In my example, several error messages are shown because the code appends a message to the monitor for each failed record (Figures 7 and 8).
* Check division is 10, if not provide error message in monitor
if COMM_STRUCTURE-division ne 10.
MONITOR-msgid = 'Z_MSG'.
MONITOR-msgty = 'E'.
MONITOR-msgno = '01'.
MONITOR-msgv1 = 'Error - Incorrect Division'.
append MONITOR.
ABORT = 1.
endif. * result value of the routine
RESULT = COMM_STRUCTURE-division.
|
| Figure 7 |
Update rules code |
Figure 8
Update rules error message in the monitor message log
Update Rule Start Routine
Again, the start routine coding technique for update rules is similar to the coding technique within the individual update rules (Figure 9). Place the message in a table called MONITOR. The messages automatically show in the monitor.
*$*$ begin of routine - insert your code only below this line *-*
* Loop through all records, if there is a bad division, send error
* message to monitor.
data: wa like DATA_PACKAGE.
loop at DATA_PACKAGE into wa where division ne 10.
MONITOR-msgid = 'Z_MSG'.
MONITOR-msgty = 'E'.
MONITOR-msgno = '01'.
MONITOR-msgv1 = 'Error - Incorrect Division - '.
append MONITOR.
ABORT = 1.
endloop.
|
| Figure 9 |
Update rule start routine code |
Warning Messages
You also can send a warning message to the monitor in either the update or transfer rules. Set the MSGTY message type to W for warning. The system sets the package to a yellow status. Whoever is monitoring the batch can then look at the warnings and manually set the InfoPackage to either red or green depending on the actions taken from the warning.
The warning option is not as popular as an error message because it requires user intervention to set the package to either red or green; however, the coding technique is the same, except for setting the MSGTY to W rather than E in the case of an error in the monitor.
