Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Diff. between "transport of copies" and workbench transport?

Vitaliy-R
Developer Advocate
Developer Advocate

Hi,

Can someone help me to understand the difference between "transport of copies" and "workbench transport"? I cannot get it from SAP help

I know what transports are and how they are transported. I just want to understand the specifics of "transport of copies" and cases to use it.

Thank you!

Vitaliy

Message was edited by: Vitaliy Rudnytskiy - to precise the question

1 ACCEPTED SOLUTION

Well, that was painful to read through. I think the last few may contain some understandable true possible uses, but I believe I have an additional one, and some documentation to back it up.

"But this thread is so old!"

Vitaliy - At well over 7 years later, I'm sure you, personally, have long received your answer by now. However, somewhat newer users to this concept (like me) are still searching for the answer to your original question (which I understood immediately). Presently, this link/page is still consistently returned at/near the top of a Google search for things like "sap why use transport of copies" and "what is the use of transport of copies in sap", so I think it is appropriate and justified to exhume this old thread in order to share the following with future questioners who will inevitably find this page in their search. Admittedly, my source material is newer than this thread and the following information, or even these functions themselves, may not have been available back when the OP was made.

"OK, get on with it, then."

Alright "Future Questioners," although I am sure there are many, here is my favorite potential use of Transport of Copies (ToCs): You can use ToCs to *not* send multiple "regular" transports to QA and Prod for the same issue.

Some key ToC points:

  • Rajiv Jha gave me the single most important point not yet mentioned here via THIS article, by stating, "Beauty with this type of transports is, it dies in the next target system." Light bulb!
  • And Joe Markgraf, in THIS article, summarized what I will expand upon below (if it's not clear enough here). "They will only affect the system that we move them into. You will still be opening a single Customizing or Workbench request to move your changes to production, but you will only be releasing these requests when you know you are ready to move. For unit testing in QA you will be moving Transport of Copies until you are satisfied with what you have. At this time, you will release your original change request and move it into QA for final User Acceptance testing. By doing this, you will be using a single transport for your change that will ultimately go to production."

Background:

I am a Security/former-Basis guy, so I can best frame this from my perspective, which is transporting Roles, which move on Customizing transports and are not subject to locking. If you move Workbench items, you can account for the locking but the rest should be the same.

Environment:

Dev => QA => Prod (possibly even multiple Dev clients)

Also, there is a change management system of some kind where you must essentially apply for your transports to be approved to move to Production on a given cycle.

Situation:

You are requested to develop a ______ (for me, it is a security role). Once complete in Dev, the main testing will occur in QA. However, it is expected that new issues will likely be found in QA, necessitating multiple transports from Dev to QA before final approval. Then all of those transports must be sent into Prod based on the appropriate administrative/business change management rules of the business.

Without ToCs:

Lots of administration may be required to keep track of all of the transports involved in your development so it all goes to Prod properly.

With ToCs:

What if you followed this procedure instead?

  1. Put your initial round of development objects on your Customizing/Workbench transport, but DO NOT RELEASE IT!
  2. Create a Transport of Copies and be sure to specify the Target equal to your QA client where the testing will occur. You get an empty transport which will only go to that Target System and Client. It will not go to Prod or any other Dev or QA client. Like Rajiv Jha said, it will "die" in the Target.
  3. Use the Include Objects button to put all the objects from the transport in Step 1 into the ToC by entering the Task (2nd level) number of the original transport into "Object List from Request."
  4. Release the ToC.
  5. When the ToC arrives in QA, testing may continue. You do not have to manage this ToC further.
  6. If another issue arises, make the changes in Dev, which go onto the original, unreleased transport in Step 1.
  7. Repeat Steps 2-6 for as many iterations as is necessary until testing is complete and no more changes are required.
  8. When all is ready to make this "final" and send to Prod, *now* release the original transport from Step 1 into QA (really into all clients next on the path).
  9. Now perform the required administrative steps for Production import for only one transport!

Having been in several businesses with challenging change management mechanisms, this is now my favorite use of Transport of Copies (as long as you can convince your people to allow you to use them). Please Like if you are happy to know this!

23 REPLIES 23

Former Member
0 Kudos

transport of copies to transport conversion rules.

workbench transport is organizer to get overview of transport request

0 Kudos

I am not asking about Transport Workbench, but about Workbench Transport

0 Kudos

Hi. I looked into SAP help already. But I need someone to explain me in simple words

Former Member
0 Kudos

HI Vitaliy,

<b>workbench transport</b> - Transport system allows to transports the object from on SAP system to another (Development system to Production system). It allows to over write or delete existing object in target system and import new objects to target systems.

During development work we start by opening a task (correction) to

which we can assign new and changed objects. Once changes have

been made, transport new or changed objects to other SAP system by

means of transport (Change) request.

<b> You can think a Transport Request as a Container having all the related objects buldled together. And when we move ahead to another clients (testing, UAT, production), we transport these requests to each client, so that we don't have the complete object in the different clients.

Hope this Clarifies your doubt.</b>

You can see this request in SE09/ Se10.

Hope this Helps,

Manish

Message was edited by: Manish Kumar

Message was edited by: Manish Kumar

0 Kudos

Hi Manish,

Thank you for detailed answer. I know what is the Transport Request and how I do transports between different systems. My original question was what's the difference between transport of copies and workbench transport, and when should I use the "transport of copies"

Thanks!

Vitaliy

shishupalreddy
Active Contributor
0 Kudos

hI,

Transport of copies is nothing but getting all versions of an object which are in released status to compare the differences in betwwen them .

workbench request is the one we'll create whenever you develop an object in ABAP.

GO TO se10 YOU WILL NOTICE THESE

REGARDS,

Surferpeck
Employee
Employee
0 Kudos

Hi Vitaliy,

Better late than never...

Transport of copies allows you to transport objects to any specified SAP System. It allows you to move the original location of objects to a target system.You can use if for a number of reason, but this would be the main reason.

Find more here:

http://help.sap.com/saphelp_nw04/helpdata/en/57/38e1a94eb711d182bf0000e829fbfe/frameset.htm

Cheers,

Chris

Former Member
0 Kudos

Hi ,

Transport of copies is generally done , when the changes of your task are available in more than one Request and you want to transport these changes in a single request , instead of indvidual transports .

For eg :

Let us say for one program you created aroound 10 requests and transported to Q box , and later your Q box got refreshed frpm P system before these transports actuallt went to Production system . IN this case your 10 requests will not be available now .

To make changes in these program available in Q box , you can create one transport of copies containing changes of these 10 requests .

Thnaks .

Well, that was painful to read through. I think the last few may contain some understandable true possible uses, but I believe I have an additional one, and some documentation to back it up.

"But this thread is so old!"

Vitaliy - At well over 7 years later, I'm sure you, personally, have long received your answer by now. However, somewhat newer users to this concept (like me) are still searching for the answer to your original question (which I understood immediately). Presently, this link/page is still consistently returned at/near the top of a Google search for things like "sap why use transport of copies" and "what is the use of transport of copies in sap", so I think it is appropriate and justified to exhume this old thread in order to share the following with future questioners who will inevitably find this page in their search. Admittedly, my source material is newer than this thread and the following information, or even these functions themselves, may not have been available back when the OP was made.

"OK, get on with it, then."

Alright "Future Questioners," although I am sure there are many, here is my favorite potential use of Transport of Copies (ToCs): You can use ToCs to *not* send multiple "regular" transports to QA and Prod for the same issue.

Some key ToC points:

  • Rajiv Jha gave me the single most important point not yet mentioned here via THIS article, by stating, "Beauty with this type of transports is, it dies in the next target system." Light bulb!
  • And Joe Markgraf, in THIS article, summarized what I will expand upon below (if it's not clear enough here). "They will only affect the system that we move them into. You will still be opening a single Customizing or Workbench request to move your changes to production, but you will only be releasing these requests when you know you are ready to move. For unit testing in QA you will be moving Transport of Copies until you are satisfied with what you have. At this time, you will release your original change request and move it into QA for final User Acceptance testing. By doing this, you will be using a single transport for your change that will ultimately go to production."

Background:

I am a Security/former-Basis guy, so I can best frame this from my perspective, which is transporting Roles, which move on Customizing transports and are not subject to locking. If you move Workbench items, you can account for the locking but the rest should be the same.

Environment:

Dev => QA => Prod (possibly even multiple Dev clients)

Also, there is a change management system of some kind where you must essentially apply for your transports to be approved to move to Production on a given cycle.

Situation:

You are requested to develop a ______ (for me, it is a security role). Once complete in Dev, the main testing will occur in QA. However, it is expected that new issues will likely be found in QA, necessitating multiple transports from Dev to QA before final approval. Then all of those transports must be sent into Prod based on the appropriate administrative/business change management rules of the business.

Without ToCs:

Lots of administration may be required to keep track of all of the transports involved in your development so it all goes to Prod properly.

With ToCs:

What if you followed this procedure instead?

  1. Put your initial round of development objects on your Customizing/Workbench transport, but DO NOT RELEASE IT!
  2. Create a Transport of Copies and be sure to specify the Target equal to your QA client where the testing will occur. You get an empty transport which will only go to that Target System and Client. It will not go to Prod or any other Dev or QA client. Like Rajiv Jha said, it will "die" in the Target.
  3. Use the Include Objects button to put all the objects from the transport in Step 1 into the ToC by entering the Task (2nd level) number of the original transport into "Object List from Request."
  4. Release the ToC.
  5. When the ToC arrives in QA, testing may continue. You do not have to manage this ToC further.
  6. If another issue arises, make the changes in Dev, which go onto the original, unreleased transport in Step 1.
  7. Repeat Steps 2-6 for as many iterations as is necessary until testing is complete and no more changes are required.
  8. When all is ready to make this "final" and send to Prod, *now* release the original transport from Step 1 into QA (really into all clients next on the path).
  9. Now perform the required administrative steps for Production import for only one transport!

Having been in several businesses with challenging change management mechanisms, this is now my favorite use of Transport of Copies (as long as you can convince your people to allow you to use them). Please Like if you are happy to know this!

0 Kudos

Nice effort, you could have created a blog or document for more visibility.

When I met this procedure first I was sceptical (having done it the "usual way" for many years), but I also saw the advantages, by now I would recommend it as well.

My current client has created a small add-on development that automatically fills the objects into the ToCs and keeps track of the original transport and all its related ToCs via some common attribute. Works really well in practice, production queue is much shorter than before.

Thomas

0 Kudos

Thank you very much, Thomas. That means even more given your obvious experience here and I'm essentially new to this community.

I would private message this next part if I could find a function here to do so ...

I believe it's not too late, and I'm more than willing to create a Document from this material; I didn't even know about Documents until late today. I agree that it is general and useful enough to not be buried in a specific question, albeit one that many might find via Google as I did. My feeling is that this topic has already been blogged about here (which was part of my source material) and that this is more of a how-to, which my reading indicates that is more appropriate for a Document here. Is that correct thinking?

My further "private" questions (because they are not on this topic) would be:

  1. Which area would such a Document go best into? This one? Because it can apply well beyond ABAP Development.
  2. Is there a formatting guide (re: how they should look vs. a how-to) for Documents here?

Thanks again,

Steve :^{D

0 Kudos

I would put it into the forum.  As for blog vs document, I think the 'rules' are a bit fuzzy on that point (though I've only written one blog post and no documents here, so I'm not one to talk... but I spent a lot of time trying to decide which was best before-hand, and ultimately concluded it didn't matter that much).  However, that's a great question for the 'About SCN' space, or one of its subspaces.

--Matt

0 Kudos

I think "document" is more appropriate, and "Software Logistics" the correct place. You can mention in the document like I did here, so it shows on the landing page and you might get a few more readers.

Regarding the formatting, just do it how you would expect a well readable text from somebody else

Thomas

0 Kudos

Hey ,

I totally agree with , you should have created a blog or document not just for more visibility. Thorough insights. I'm sure had got his answers back in 2006 only but we are getting ours now. Thanks to you.

Gaurav

0 Kudos

Steve, thanks for the detailed explanation - it helped to bring in a lot of clarity to an old topic that had been obfuscated by all the multiple "red herring" postings.

Just a point perhaps - ToC seems to have it's uses, but it seems to me that this would work only for a project that creates/contains only new object developments.

If you are working with existing objects among a large development team (think: multiple people changing the same objects, especially for systems that have matured and are in a "support" phase) - would this concept still work?

When the 1st round of changes are ready for Production, but the 2nd round of changes are still being validated in QA, you can't move the 1st round of changes to Production *first* until everything is done in Development...

0 Kudos

At one of my clients we have created a program that automatically generates the ToC, gives the same text as the original, but with the original tp number included, and releases the ToC. It also locks the original transport, so it's clear what's already been ToC'd.

This works perfectly for new objects and for maintaining already existing objects.

However, you are correct that for large changes involving many people, it can cause problems. However, with careful management these can be dealt with, and the work required is far less than the traditional approach.

-> come on, where's the document?

0 Kudos

Steve,

Let me know if I understood you correctly.

1.In Dev I had created a TR D2BK1234 and captured the changes.

2.I had created a ToC with target client as Q.

3.Without releasing the TR D2BK1234 I had INCLUDED this TR in ToC.

4.Does that mean now I can import this ToC TR even though the underlying TR D2BK1234 is not yet released ?

5.If yes,can I use the same ToC ( may be not as we have to release the ToC to get it imported to Q )and the same TR D2BK1234 ( as it is not yet released ) again to do changes in Development and repeat steps 3 and 4.

6.This process of steps 3,4,& 5 can be repeated N number of time till the changes in Q were successfull ?

7.Do we have to create multiple ToC's just to get the changes of TR D2BK1234 imported to Q mutilple times without releasing TR D2BK1234.

I am aware of using ToC to transport multiple TRs of an Object so that we don't have to bother about the sequence of the TRs when they are getting imported to Production but not this concept of not releasing the TR but still getting the ToC imported to Q .

K.Kiran,

0 Kudos

5) Yes, the underlying transport is not released. No, you cannot use the same ToC - it's been released.

You do end up with many ToCs. This can be quite an advantage, as an workbench objects are versioned with each ToC. That is one reason that it's a good idea to mark the ToCs as ToCs in the text.

0 Kudos

Gone through the link attached by Steve.

"So, you cannot create a ToC in ECC system for an unreleased transport."-

If it is true then how we can call it as an advantage when the higher versions are not letting us use ToC in one of the way mentioned by Steve ie using the same TR without releasing it and also we having to create multiple ToCs.

A few more queries in addition to my previous post---

Can we import those ToCs to Production ?

Any difference in this concept when we do changes to an exisiting object or a New Object ?

Is this entire concept is version specific ?

K.Kiran.

0 Kudos

The blog is misleading - I'm not entirely sure what point it is wishing to make. Perhaps it's only relevant when you are trying this through some Solution Manager tool?

You cannot lock objects in the ToC. But you can create and release the ToC quite freely. I know. Because I do it twenty times a day!

Do NOT import the ToCs to production. You can. But the point of Steve's message is that the ToCs are intermediate releases for testing. Once you've tested, you then transport the original across your system landscape.

We've used an automated version of this procedure for 8 years, so covering at least 6.20 to 7.40.

0 Kudos

Matthew Billingham wrote:

Steve Quinn -> come on, where's the document?

I have a draft now. I need to give it the once-over, and I'm new so it will have to be moderated.

Frankly, I'm overwhelmed by the unexpected response here and apologize for not being responsive myself, but Matthew is doing a great job at that. I haven't been here in a while and I have all my SCN notices going to a big pile that I never get to look at.

Also, now that I have written the draft, I have a question for those who think this should be a separate Document. In my original post, I reference an article by Joe Markgraf. Obviously, at the time, I didn't originally get the complete answer to this question out of that, otherwise I just would have linked it and moved on. But now that I know, understand, and use ToCs regularly, I'm having a little trouble seeing how mine is not a duplicate.

So the question I have is: What did you get out of my original post that was not already in Joe's article which justifies posting a separate Document?

Of course, I like the rep that comes with posting (don't we all?) and I'm not shying away from putting in the work/time (it's practically done now), but I don't want to replicate someone else's work and call it my own. Thoughts? (I have my own thoughts but I'll save them and listen to yours first.)

0 Kudos

This message was moderated.