Importance of semantic groups in DTP

Semantic Groups to specify how you want to build the data packages that are read from the source (DataSource or InfoProvider). To do this, define key fields. Data records that have the same key are combined in a single data package. 

This setting is only relevant for Data Store objects with data fields that are overwritten. This setting also defines the key fields for the error stack. By defining the key for the error stack, you ensure that the data can be updated in the target in the correct order once the incorrect data records have been corrected.

A very simple example:

Lets say there are two records in the input stream of data for a DTP.

Product   Material 

P1           M1 XYZ 

P1           M1 PQR 

If the data gets divided into multiple packets while getting processed, the above two records might go into separate data packets. In case you have defined semantic group in DTP with product and material, system will always put these two records together. This is sometimes required when it is needed to process all such records together, for eg., in start routine.

Semantic Groups are to specify how you want to build the data packages that are read from the source. To do this, you determine key fields. Data records that have the same key are combined in one data package. Currently, only data that has been read from the PSA can be processed further in semantic groups.

This setting also determines the key fields for the error stack. 

In bw3.x infopackage directly transfers the data to targets but in BI 7 infopackage will only bring data to PSA, Data Transformation Processing will transfer the data from PSA tothe target. PSA is only staging area this will not be a target (we can’t do anything here)

Difference between DTP and IP in BI 7.0

The key difference between 3.5 and 7.0 is that in 3.5 an infopackage would load from a single DS to multiple data targets (infocubes, ODS etc) so if the source was sending delta, then the load to targets has to be done as a single data load to all,meaning a delta has to get loaded to all targets at the same time. you could not load them at different timings.

Whereas in 7.0, DTP helps in maintaining delta queues from PSA to different targets enabling you to load the delta to each target, independent of the other because each target will have its own delta Queue maintained. This is a big change in 7.0 and helps in load distribution mechanisms.

Error handling mechanisms in BI 7.0 and BW 3.5

Error stock DTP

Incase of 7.0 Version 

1) DTP: In DTP, you find the Update tab , where you will find the different error handling options.

a. NO Update, No Reporting.
b. Update Valid Records only, Reporting not possible (Request red).
c. Update Valid Records only, Reporting possible (Request green).

Incase of 3.x version 

2) In info package : You find the update tab , under Data update types in the data targets, you find the error handling push button , when you click this you will find all the options related error handling

Rule types in transformations

1.Constant 

2.Direct Assignment 

3.Formula 

4.Read Master data 

5.No Transformation 

6.Routine

behavior of transfer routine at characteristic level in transformations

When you create a transfer routine, it is valid globally for the characteristic and is included in all the transformation rules that contain the InfoObject. However, the transfer routine is only run in one transformation with a DataSource as a source. The transfer routine is used to correct data before it is updated in the characteristic. 

During data transfer, the logic stored in the individual transformation rule is executed first. Then the transfer routine for the value of the corresponding field is executed for each InfoObject that has a transfer routine. 

In this way, the transfer routine can store InfoObject-dependent coding that only needs to be maintained once, but that is valid for all transformation rules.