Semantic Grouping set in a DTP or in TRFN?

Semantic Grouping enables grouping of data based on its semantics into the same data pack that is process by the BW load. In BW classic based systems, this function is normally called the Semantic Grouping whereas in BW/4 based systems it is called Grouped Extraction.

If the function is used, data records are extracted from a source as per a logical key and they processed together. The function can be switched on by selecting particular fields on DTP or in TRFN (Transformation). The DTP part was there since BW 7.0 and availability on TRFN came with BW 7.2

Why there is an option to use the Semantic Grouping / Grouped Extraction in the TRFN level as it is available at the DTP level already? Is there any difference between the DTP and TRFN?

Instead of finding a difference, it is better to looked at it as what they can do if they are combined. There can be following cases:

1. Error handing on the DTP is activated (‘Cancel Request, Track First Incorrect Record, No Update’) only the sources fields of key fields can be selected in the DTP. Grouping uses the intersection of these selected key fields and the fields selected from the transformation for semantic grouping.

2. Error handing is deactivated (‘Cancel Request, Do Not Track Records, No Update’), all the sources fields that were also selected in the transformation can be selected in the DTP. The Grouping is formed from this intersection.

3. For compatibility reasons - similar case as no 2 but no source fields have been selected in the transformation for the semantic grouping, all the source fields can be selected in DTP.

SAP is recommending (see in online doc links below) a selecting fields for grouping at the transformation level.

More information:

Online docu BW 7.3

Online docu BW4/HANA

SAP BW DTIS - Data Transfer Intermediate Storage

Run of DTP error instance DUMMY_NO_REQ_CREATED

In case of an attempt to run a DTP process it ends with an error “instance DUMMY_NO_REQ_CREATED” there are following cases possible that might went wrong.

·         Transformation (TRFN) related to the DTP is not active

·         Issues occurred while attempt to active the TRFN

·         Runtime object of the TRFN cannot be created

·         Request can’t be created

This error can be recognizable with Process Chain of its log view. The DTP process looks like it is disable, not green neither red. Simply it didn’t run.

The error also can be observed in logs of PC and of corresponding job:

PC log:

Process Data Transfer Process, variant OBJ1 -> OBJ2 has status Skipped at restart (instance DUMMY_NO_REQ_CREATED)

Job log:

Process Data Transfer Process, variant OBJ1 -> OBJ2: has status Ended with errors (instance DUMMY_NO_REQ_CREATED)           RSPC   9

Resolution in most cases is reactivating or re-transporting corresponding TRFN.

More information:

2416976 - DTP in process chain fails with DUMMY_NO_REQ_CREATED

 

Transformation code in INCLUDE: how to perform where-used?

Here let’s have following scenario. ABAP logic for Transformation (TRFN) is encapsulated in ABAP INCLUDE and it needs to be changed. Before a change is done it is beneficial to check what are all TRFN where the ABAP include is used. In case there are several TRFN and change is not supposed to be done for all of them an issues can came.

Normally as the INCLUDE it would be regular ABAP one there is a Where-Used functionality available in t-code like SE38/SE80. However it doesn’t work as the code of TFRN is stored in generated report (GP*).

What actually works in case of the GP* reports is Syntax Check functionality available as well as in the SE38/SE80. Via the Check the list of the all TRFN is available.

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.