(如果遇到对传输要求非常严格的公司适用,比如做几个月项目只有两个小时可以传,而且是经过美国的TRANSPORT MANAGER加班给你传)
How to manage Error Free Transports
Introduction
This blog is going to explain you about "Managing Transports by using common sense". I am not going to talk about standard Steps to be carried out.
Common Mistakes : 常见错误
- We tend to collect multiple(too many) objects in a single TR :一个传输号中放了太多的对象
- We collect our objects in other's transport requests via separate tasks without our/their knowledge 与别人交叉包
- We collect different types of objects in a single TR. Eg: Transformations and DTPs together 不同类型放一个包内(比如TR和DTP)
- We overlook dependent objects while collecting our objects 各种对象相互依存
- We do not know whether RSLOGSYSMAP table has got right entries in Target systems or not. RSLOGSYSMAP 中目标系统是否正确
- We don't bother about dependent objects are active in Target Systems or not 相互依存的对象是否在目标系统是激活的
- We don't bother to drop data in Infoproviders in target systems when we want to transport any structure changes 如果对信息提供者做结构性的修改(比如CUBE加维度,DSO加主键)没有删除数据。
How to use our common sense while managing transports
Scenario : In our projects, we use some standard infoobjects like 0plant, 0Division, 0material etc., Please observe all these standard infoobjects belongs to their respective standard Infoareas and Application Components.
How to handle above scenario?
We need not to collect their respective Infoareas and Application Components every time. Because these standard Infoareas and Application Comps will be already available in target systems.
1. How to transport DSOs/Infocubes first time to the target systems?
As we might have already moved our infoobjects, we just need to collect only DSOs/Infocubes and move to target systems. We need not to collect any underlying infoobjects it is pointing to, like below. The infoobjects which has Expand icon can be collected with "Do not Transport Any below". This will reduce the burden on the TR. Note : It's better to use "Only Necessary Objects" and Collect Automatically".
(经验之谈:0plant,0material这种常被其他人用在DSO中而被锁定在其他请求中,因此最好不要传。)
2. What to do when DSOs/Infocubes becomes inactive target systems?
Just collect the active version of DSOs/Infocubes and move to target systems. You need not to collect anything below.(如果只是DSO不激活,你只需要将DSO包进传输过去。)
3. How to transport Transformations and DTPs first time to the target systems? (首次传DTP 和TR必须将源和目标都包进去)
We all are aware that Transformations are between Source and Target. That's exactly is the reason to collect Source and Target along with Transformation like below. We need not to collect all infoobjects of our Cubes and DSOs, because those objects have already been moved. Same explanation applies to DTPs also.
How to transport Transformations and DTPs after the first time to the target systems? (首次传输后如何再传TR和DTP:不需要包源和目标)
We just need to collect the active version of Transformation and DTP. It's not required to collect Source and Target as they are already actively available in Target systems. This procedure can avoid running RDG_TRFN_ACTIVATE program directly in Target systems. You can run this program if you want to activate Transformations/DTPs in mass.
Tips to consider while managing Transports
1. We tend to collect multiple(too many) objects in a single TR 一个传输号中放了太多的对象
We should not collect too many objects under one TR. Eg: 1) 30+ Queries 2) 10+ Process Chains etc., We will not be able to have a control on all objects. If you collect few and make them successful in Target systems, it gives you a great idea on our transports.
2. We collect our objects in other's transport requests via separate tasks without our/their knowledge 与别人交叉包,特别是不要放在别人的包里。
This is not really a big mistake. But there is a dependency here. Unless all the tasks of different users gets finished, you cannot release the main Request No. This will delay your work. To avoid all this mess, you should create your own TR and collect all your objects under it and release it.
Sometimes the other developer would have developed some objects and saved in his task. When you take up that work and start working on them, all your changes will get merged with the existing request and task. You will be confused finally, what is your changes and their's ? That's why you have to collect freshly just before you are ready to transport all your objects. Never transport the older requests, as you don't know exactly what are all changes have been done.
3. 在一个传输中放了TR和DTP
We collect different types of objects in a single TR. Eg: Transformations and DTPs together
This is a biggest mistake we generally do. When we start our developments in our BW Dev system, we might create one TR in the beginning and start saving all our work in that. Finally we land up in multiple errors while importing in target systems. Eg : (1 Infopackage, 1 DTP, 2 Transformations, 3 DSOs ) All in one TR.
My tip here is, you can still work on single TR, but finally unlock all your objects with the help of my other bloghttp://scn.sap.com/docs/DOC-31394. Collect again freshly object wise from RSA1-->Object types in individual requests. Be clear on object wise here. Eg: Cubes- 1 TR, DSOs- 1 TR, Chains- 1 TR, Transformations- 1 TR, DTPs- 1 TR
4. We overlook dependent objects while collecting our objects 对象相互依存
We should always cross check in target systems (before transporting our objects), whether dependent objects are active in Target systems or not. Eg : Datasource Replicas, Transformations, DSO/Cubes etc..
5. We do not know whether RSLOGSYSMAP table has got right entries in Target systems or not
Logical system conversions are must to be maintained in target systems , while transporting Transfer rules, Infosources, Datasource Replicas,Transformations etc. They basically check "Source System Reference" in target systems.
You can maintain them with my other blog http://scn.sap.com/community/data-warehousing/netweaver-bw/blog/2013/09/29/clients-and-logical-systems
6. We don't bother to drop data in Infoproviders in target systems when we want to transport any structure changes
If we don't drop data before importing a TR, that would fail saying it cannot add/remove a Char/KF as the target contains already contains data with them. So we should drop the data in Target systems before moving. Database inconsistencies will arise after that. We can resolve them by RSRV.
7. How to collect Data flow Migration work
This is a very sensitive task while collecting. All your sequence of steps have to be collected on the spot. Treat these TRs with special care. Don't allow any other changes to get saved under it other than migration activities. It is not as easy as unlocking from the old request and collect again in new Request from RSA1-->Object Types.
8. How to collect a BEx Query
You have to select the tick boxes like below and cross check whether all the query elements have been collected or not. You need to select the Infoproviders, as they will be already available in Target systems.
9. How to set your system Transport Request settings
Goto RSA1-->Transports Tab-->Follow below image
10 .If you switch on standard, then every activity will ask you for transport request through a pop up instantly.
If youSwitch -off standard, then all your activities will get saved in to local objects. Finally you will have to collect from RSA1-->Transprt tab-->Object types
Object Changeability
You can observe this functionality in above image. This can be used to provide a privilege for us to edit the objects directly in Target Systems. Eg: Queries, Web Templates, DTPs, Infopackages etc. This setting has to be done in Target systems
Conclusion
Transporting is an easy task if you organize things properly in a systematic manner. Maintain your own excel sheet with all your Transports. This will help you any time if you want to cross check.