Handling KF behavior in Expert Routine in case of DSO as target

I came across following issue while dealing with expert routine. There was a DSO object as target of TRFN.  Key figures within the TRFN were updated but they weren’t aggregated. Basically values of KFs from last row that was processed were updated into the DSO but not values form previously processed records. So at the end the KFs were not summed up – no aggregation took place and what was going on was that there was just a move operation executed.

After checking with SAP documentation I realized that that this behavior is as designed:

“If the target of the transformation is a DataStore object, key figures are updated by default with the aggregation behavior Overwrite (MOVE).”

If one wouldn’t need this behavior then it must be overcome in custom coding within the expert routine. Data in result package must be collected instead just appended. Below is example of how to do it.

TYPE: t_ty_t_TG_1 TYPE SORTED TABLE OF _ty_s_TG_1 WITH NON-UNIQUE DEFAULT KEY.

DATA: ls_record_no TYPE rsarecord VALUE 0,

lt_result_pack TYPE t_ty_t_TG_1,

ls_result_str TYPE _ty_s_TG_1.

.

.

.

COLLECT ls_result_str INTO lt_result_pack.

Difference between 1st and 2nd global declarations in BW routines

Savvy BW developer may notice that there are two areas when it comes to global data declaration in transformation’s routines. Start/end (and also Expert) routines are quite heavily used within the transformation. The routines are generated as per templates. While coding in ABAP we following areas reserved for us:

1^st area for ABAP code:

*$*$ begin of global - insert your declaration only below this line  *-*
... "insert your code here
*$*$ end of global - insert your declaration only before this line   *-*

2^nd area ABAP code:

*$*$ begin of 2nd part global - insert your code only below this line  *
... "insert your code here
*$*$ end of 2nd part global - insert your code only before this line   *

3^rd area for ABAP code:

*$*$ begin of routine - insert your code only below this line        *-*
... "insert your code here
*--  fill table "MONITOR" with values of structure "MONITOR_REC"
*-   to make monitor entries
... "to cancel the update process
*    raise exception type CX_RSROUT_ABORT.


*$*$ end of routine - insert your code only before this line         *-*

While purpose of 3^rd area is clear – it serves for real code which encapsulated the business logic of routines in case of other areas it is not that clear. The 3^rd one is actually where the routine begins. It is either end_routine, start_routine or expert_routine METHOD begins. Why they are two areas for data declaration? If we have a look into SAP documentation available here or here we can found out:

This would suggest that: if data is declared in the 1st area then the data is available across all datapackage. If the same is declared in the 2^nd area then the data is only available for the actual package. But this may not be really true.

Let’s see what else we can say about first two. One of theories to solve this can be that 1st area is used for data declaration according ABAP OO paradigm. 2^nd one would be used for data declaration of pre-OO (or non OO) ABAP standards. But this again may not be true.

According SCN post in forum available here there was someone who got back to SAP with regards this mystery. If we can trust this post here’s what SAP said:

In the first global part you can write your declaration or code you want to be able to reach globally in the transformation.

The 2nd global part will be used for those transformations which are migrated from an update or transfer rule. Routines used there will be automatically generated into the 2nd global part.

BW 7.x: How to design start/end/expert routine within transformations?

There are several points that you need to recon while coding start, end or expert routines. 

Basically you need to be aware which data are you processing either it is source_package in case of start routine; result_package in case of end routine or even both tables in case of expert routine. Basically you do LOOP ABAP statement over one of those internal tables and you modify it or add new rows. There are available corresponding work areas (source_field, result_field) and field symbols (, ) that make you looping easier. 

Another point to be considered is creating new records within routines in one of its data_package internal tables. Here’s field called RECORD which needs special treatments. In case of end routine you need to populate value of this field by calling standard method new_record__end_routine.

In case of error handling you can populate called MONITOR. By this you can send messages to the Data Transfer Process (DTP) monitor. This makes maintenance of BW application easier. BW administrator sees error in monitor and can recognize its root cause directly by analyzing message instead of digging in coding or in ABAP dumps. Coding can be maintained like following:

IF sy-subrc <> 0.

  monitor_rec-msgty = 'msgty'. "e.g. W

  monitor_rec-msgid = 'msgcls'. "e.g. RS

  monitor_rec-msgno = '100'.

  monitor_rec-msgv1 = lv_par1. "Parameter 1

  monitor_rec-msgv1 = lv_par2. "Parameter 2

  monitor_rec-msgv1 = lv_par3. "Parameter 3

  monitor_rec-msgv1 = lv_par4. "Parameter 4

  APPEND monitor_rec TO MONITOR.

  RAISE EXCEPTION TYPE CX_RSROUT_ABORT. "aborts whole processing
*  RAISE EXCEPTION TYPE CX_RSROUT_SKIP_RECORD. "skips this particular record

ENDIF.

For  further reference see following SAP Notes:

1227667 - Guidelines for expert routine: Design rules
1223532 - Design rules: Adding records to end routine
1258089 - Design rule: Adding records to the start routine

- update 21.01.2011 - 
In case of expert routine, breaking processing of load via raising of exception doesn't work (CX_RSROUT_ABORT). You have to use method send_message of class cl_rstran_expert_rout_srv.

- update 19.05.2011 - 
Some more SAP Notes on this topic:
1349820 - Expert routine: Technical enhancements