Some Additional Tips for Collecting & Validating Transports

[arun_purohit]

Objective

In this blog I just want to share few tips related to BW transports that might help in collection & validation efficiently.

Settings

Though its a personal choice, but some settings are recommended while some are chosen based on personal comfort level.

Following are the settings I prefer for more clear one shot view:

Grouping

Its most obvious setting but recommending it implies- we should collect different objects by types only. I mean, preferably, instead of dragging in infoproviders with "Data Flow Before" for collecting transformation, we should go & collect specific transformation from corresponding object type. For example-

Display

Following setting can be chosen once required objects are dragged in for collection:

Using this setting in conjugation with "Necessary Objects" settings makes picture very clear on what to be selected & what not, even for BEx Queries or transformation. For example :-

Here we can right click on required object type & click "Transport All Below". Same ways following is sample for BEx Query collection:

Grouping of BW Objects in Transports

I think there is no fixed rule for this but objective is complete transport without error & import in reasonable amount of time.

Following can be two strategies for grouping:

1) If we are sending our development first time & we have large number of data models & reports, then this strategy is recommended:

Separate Transport Requests based on following groups-

a) Infoobjects, Infoobjects Catalogs & Infoareas

b) Infoproviders

c) Datasources& Infopackages

d) Master Data Transformations & DTP

e) Transaction Data [First Level] Transformations & DTP "Transformations which are between datasource & infoprovider

f) Transaction Data [Second Level & Upwards] Transformations & DTP "Transformations which are between infoprovider & infoprovider

g) Process Chains

h) BEx Queries

i) Customer Exit Codes

If number of objects in any group is very high that group can be divided in parts, as if number of objects are too high sometimes importing that transport can become nightmare.

This is very generic sequence, but important thing is to take care of dependency i.e. dependent objects should go in second step once main objects are moved.

While releasing transports system itself checks dependent objects and give warnings or errors accordingly.

Possible question in section can be- "Why we collected 2 different transports for different levels of transaction data transformations?".

This is required only if we have multiple clients of ECC QA for testing but single client of BW. In this case BW will have two source systems connected, hence we will need to transport all TR's with a) first level transformations (between datasource & infoprovider) and b) datasources two times. Each time with correct destination client in "Conversion of Logical System Names":

2) This strategy can be used when we are making ad-hoc transports. For example if we want to transport only 1 simple data model & 1 query, then all objects can be transported together in same transport request. This approach is not recommended while transporting complex data model where total number of objects to be moved is very high.

Some Tips for Quicker Collection

This tip is mainly for collecting large number of transformations. Suppose we have list of 36 [random number] master data models (36 Infoobjects, some ATTR, some TEXT & some all three HIER ATTR TEXT) to be collected and we took a call to collect these in 3 separate transport requests with 12 (Infoobjects data flows) [We need to take a call if we want to move all 36 together in one TR or break them in multiple TR based on complexity of objects & total number of objects in one transport request] each (To avoid large import times). For sake of simplicity, suppose all master data transformations are between datasource & infoobject.

In excel we can use concatenate formula to generate a list of following pattern-

RSDS*<INFOOBJECT TECHNICAL NAME>*

This list can be used as shown in screenshot below-

This trick may seem foolish for collecting 2 or 3 transformations, but while collecting large number (15-20 or more) of transformations from even larger group (100 or more) of transformations, it will be handy.

This trick will reduce the number of objects shown in "Select Objects" pop-up and show only most relevant ones. Now quickly required transformations can be selected & transfer selection-

Note, here if we change concatenate formula little bit we can achieve following results as well:

a) Restricting result set only for specific source system - "RSDS*<SOURCE SYSTEM NAME>*<INFO...*"

b) Restricting only those transformations which are between BW objects- "TRCS*<INFOBJECT>*"

This technique of applying filter based on wild characters can be used for collecting almost all object types (Except BEx Queries).

If we have very robust development tracker maintained we can directly take UID's of Transformations for filtering [list in select options of object type as shown in 2 screenshots above] (or DTPs) using tables RSTRAN (or RSBKDTP) by making selection on source & target object (or other selection fields based on readily available information like source type or target type)

Another point worth noting here is, if we are collecting DTP & Transformations in a same transport request:

We can use same wild card technique for DTP as well. We need to just drag in all required DTP's and in one shot ["Necessary Objects"] we can collect both DTP & corresponding Transformation (plus dependent routines & formulas).

This trick can be easier to apply if we maintain a development tracker listing developed/changed objects by object type -Infoobject, Infoprovider, Transformations, BEx, Chains etc.

Validation of Transports

When we are working with multiple people in a team, it is a good idea to validate the transports before releasing them.

Following two tables are starting point-

1) E070 this table will give you list of sub tasks in a transport request

2) E071 this table will give all objects captured in sub tasks by object types

We can use following link to check different system tables by different object types:

http://wiki.scn.sap.com/wiki/display/BI/Important+Tables+in+SAP+BW+7.x

This link might not have all the system tables but by making use of wild card character "*" we can refer many more.

Some tables for reference-

1) RSZCOMPDIR for verifying BEx Query Tech Names

2) RSZELTDIR for checking different Query elements

3) RSTRAN for verifying Transformations

4) RSTRANROUTMAP & RSTRANSTEPROUT can help in identifying routines of a transformations based on table RSTRAN

5) RSBKDTP for verifying DTP's

Making use of tables listed above we can make quick & basic validations (using Excel & VLOOKUP) for example:

a) All relevant routines are captured or not for transformations collected in a transport request

b) Different Objects (by Object Type) are captured in transport request or not based on development tracker

References

References for transport related blogs

How to manage Error Free Transports

Note to SCN Members: Please feel free to add more references related to the topic.