on 07-09-2014 4:45 AM
Hi,
I am trying to understand how does transport works. I have a issue while moving some SAP BW objects.
Transport X - Containts - A process chain , Transformations, some newly created variants and routines. - Moved to Q.
Now the problem is I dont need to move the Process chains to Production, that means I need to move only transformations, newly created variants and routines.
How do I do that.
If I create another transport Y- just containing the objects apart from process chain and take that TR to Q and then to P will it work. and stop the TR - X in quality.
Ok, got it, but what I am trying to get here is rather than a hypothesis, a theorem.
Lets see it as a experiment- first creating an ideal conditions-
1) No Human error as in nothing to forget,no wrong sequence or anything.
2) As Mathew said , that seems logical as if I split the class and method it wont work, but what if I always capture the complete object. As in, in the new TR i capture the complete class and the methods again . then what?
I am trying to get here the science behind the transports, everyone has diff experience with TR, I consulted some colleagues, they say - yes if i move the Z TR it will work,
But what exactly happens , when we release the TR. Does the co-files and the data files contains the complete object or just the version change.
If the version change it definitely wont work, if it contains the complete object I don't see any reason of its not working.
Am i clear in my question and concern.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Abdul,
Thanks, but I know the solution, what I am trying to understand here is the mechanism and any proof like SAP documentation to support it. Please see below post.
"
Ok, got it, but what I am trying to get here is rather than a hypothesis, a theorem.
Lets see it as a experiment- first creating an ideal conditions-
1) No Human error as in nothing to forget,no wrong sequence or anything.
2) As Mathew said , that seems logical as if I split the class and method it wont work, but what if I always capture the complete object. As in, in the new TR i capture the complete class and the methods again . then what?
I am trying to get here the science behind the transports, everyone has diff experience with TR, I consulted some colleagues, they say - yes if i move the Z TR it will work,
But what exactly happens , when we release the TR. Does the co-files and the data files contains the complete object or just the version change.
If the version change it definitely wont work, if it contains the complete object I don't see any reason of its not working.
Am i clear in my question and concern."
Hi Vivek,
It will capture complete object if you put an object in a new TR. The catch here is that the object shall not be one containing any objects/having any dependencies.
For eg, if i capture only the process chain in TR Z, and send it all the till Production, it will go through only if all the info packages , DTPs, the variants involved are all present already in Production. Otherwise all these needs to be included in the TR Z. This is what the option " Only necessary objects" in transport connection does.
If i create a cube and send it to QA in TR A, then another change in TR B, both can stay in quality no issues.
I can still send a TR C with the cube to production, provided its dependencies like transformations/DTPs are taken care of.
Hope it helps.
Regards,
Rathy
I will summarize the post, thanks to two correct answers by Matthew Billingham and Rathy Moorthy,
Yes, that's possible to leave any TR in Q and create a fresh TR in D and then move it till P system, unless there is no dependency factor. and it also depends on Object to Object.
I will test it out when my objects will actually go in production and write my final conclusion again.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi All,
I hear you all,
I understand that I should make diff TR for diff objects, but due to some business limitations its now possible. Anyways, that't not the major concern, thats a "best practise"
What I am trying to understand from this example is actually how TR works.
Suppose I create a cube and keep it in TR -X , move it to Quality.
then I make some change in cube suppose delete a info object and move new TR - Y to Q.
Now I add another info object - and move the new TR Z to Q.
what I know that usually we move all three TR in the same sequence.
But what if i just move "Z" to Production and leave X and Y in Q.
Will it work. If yes then what is the point of having multiple TR in P apart for logging and version purpose. Coz in any of the case there is no Roll Back on Production.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I see what you mean, but... that's very tricky stuff! If you "forget" for example to put your InfoObject created in Y in Z, transport Z will fail in production and you may have no clue why (unless you're very familiar with transports, which obviously you're not)!
It's not only best practice, it's just common sense. I've been on projects where they do/did this and trust me, you don't really want to go there.
It can't be guaranteed to work. Depending on the object, transport Y may be a kind of "delta" of what you put into X.
For example, with ordinary abap programs, the first transport contains
R3TR PROG z_myprogram
This transports the program with all texts and includes.
If I then change the TOP include and save against another transport, that will only contain
LIMU REPS z_myprogram_top
BW objects are rather more complicated, so the risk is even higher that just taking the last transport won't work.
Hi
Looks like it will be an on-going requirement, wherein, you will have to transport only selected Objects from one environment to another.
It's a recommended practice to break-up the ETL Objects and Reporting Objects and transport them in individual TRs. This gives better Control and easy management of transports from Dev -> QA -> Prod.
There are many documents around Transports on the net, just google. One of them is.. http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d04c8c3c-40bf-2e10-139a-f7c5cd6e6...
Hope this helps.
Cheers,
Chandu
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
In general we create transports request for each objects.
as you stated, you better to create new transport at dev system and collect required objects(exclude process chain) into it.
Present moved request to bw qua you can keep it there itself. no issues.
in future, always try to collect transport for each object.
Like one transport request(TR) for process chain,
one more TR for transformations and routines.
another one for bex query and variants.
Thanks
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you are careful, you can split the process chains off quite safely and proceed as you suggest. In future, the best way forward would be to either put the process chains in a separate transport, or save them in the $TMP package.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
88 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.