Category Archives: SAP ABAP

Business scenario:
For a given BW master data object, I needed to identify deletions that take place in the source system. However for this particular object, the data source does not provide you with a deletion flag. Instead, the object is simply removed from the source tables.

I therefore created a transformation in BW that flags as ‘deleted’ those master data records that do not appear any more in the PSA table of the daily FULL load.

The transformation i created is a loop-back transformation (the source and target of the transformation are the same object). In the source routine, the PSA table of the objects data source is checked.

To identify the PSA table dynamically I used the functions described in the Following SDN Article. (If you use SAPLINK, the report described in the article is available for download below.
You can download the code of the function here in Saplink format.Download – PROG_ZBW_IDENTIFY_PSA.slnk – 5.2 kB – 353 downloads

Some information on how to access PSA data:
When the system detects an incompatible change to the transfer structure, a new version of the PSA, meaning a new PSA table, is created. Data is written to the new table when the next request is updated.

The original table remains unchanged and is given a version. You can continue to use all of the PSA functions for each request that was written to the old table.
Data is read from a PSA table in the appropriate format.

1. If the request was written to the PSA table before the transfer structure was changed, the system uses the format that the transfer structure had before the change.

2. If the request was been written to the PSA table after the transfer structure was changed, the system uses the format that the transfer structure has after the changed

ABAP unit tests enable writing and running white box tests during the development of complex BW transformation rules and routines. This How-To document shows you the tools you need to develop BW transformations according to a test-driven paradigm. Step by step, we describe a prototype implementation of an ABAP unit test for a selected BW transformation.

The create method has to fill table e_th_chas with all admissible combinations for the given selection table i_tsx_seldr. Use the method seldr_to_range to convert i_tsx_seldr to a the format e_t_range which is similar to a standard ABAP range table.

The selection tables can be compared with the ‘where’ part of an SQL statement. So in general it is not ok to pick values from the selection table and to fill it to e_th_chas.

Infos:

1) characteristic relationships depend on the InfoCube, not on the aggregation level. This is the reason why per relation you have to choose the characteristics relevant for the relation. So you can (and should) use the minimal set of characteristics needed in the relation. The system automatically decides when a relation has to be called (based in the aggregation level used and the ‘list geometry in an input ready query).

2)

The create method will be called at run time whenever the system has to create the valid combinations (e.g. in some implementations of planning functions or in input ready queries when the setting ‘access mode for result values’ based on characteristic relationships is used). This does not affect invalid combinations, e.g. when these combinations exists on the DB.

When invalid combinations exist on DB then the system will read these combinations and will check these combinations (call the check method) and make the corresponding records not input ready. Usually one should delete invalid combinations with the corresponding planning function and then compress the cube with zero elemination.

A simple way to communicate the values of the BEx variables for a BEx Query execution to some other application (another query, an ABAP program…), is to store these values in memory via the command EXPORT to MEMORY

here is a rough description of the development actions to perform to achieve this: