收集并验证传输

最新推荐文章于 2023-05-31 21:46:26 发布

Bruce_yin

最新推荐文章于 2023-05-31 21:46:26 发布

阅读量406

点赞数

分类专栏： BW

BW 专栏收录该内容

113 篇文章 5 订阅

订阅专栏

培训班是不教传输的，因为他们开发机和生产机是一体的。但传输很能判断一个BW的功底。

Some Additional Tips for Collecting & Validating Transports

发贴人 Arun Purohit 在 SAP Business Warehouse 打开 2015-3-14 9:28:02

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.