Simpler way to create multiple TOCs?

[Jelena]

Is there a simpler way to create multiple transports of copies in SAP?

Lately we are frequently dealing with this odd but seemingly unavoidable process. There are multiple projects going on plus some SAP system realignment, etc. As a result, we end up with a temporary, isolated sandbox-like SAP system where configuration/ABAP changes are made. Later those changes (=transports) need to be moved to another system.

Management thinks it's a piece of cake, but what happens in reality is: we send a list of transports to the hosting provider asking to move them. In response we get - bwahaha, the TRs are "local", there are no files, so create TOC and then we talk. And here we go - SE01 -> create TOC -> include objects, wash-rinse-repeat about 20-30 times. (Yes, technically we could combine multiple transports into one TOC, but for some reason consultants are very particular about the order in which transports need to be moved even though there seems to be no reasonable explanation why unrelated configuration has to be moved in this exact order. Can you tell I've just done 24 TOCs manually? )

I looked everywhere but other than creating LSMW don't see any easier option for such activity. Is this really all we have in 2015?

And for the bonus points could someone please explain why when we do 'include objects' and enter the transport # the objects are not actually included and we have to do that using task number instead? Or am I doing something wrong?

Thank you!

[TomCenens · Accepted solution]

Hi Jelena

The best solution would be to avoid the "local" transport requests in the first place. To avoid it, you would need a transport target. If you only have a single system, this should still be feasible by using virtual systems.  Your SAP Basis resources should be able to help you out on this.

As long as you've got a target, you can change the target and in case of virtual systems, the virtual system(s) can be replaced by the actual system(s) once those are available thus avoiding the need to create TOC's out of local requests.

"And for the bonus points could someone please explain why when we do 'include objects' and enter the transport # the objects are not actually included and we have to do that using task number instead? Or am I doing something wrong?"

I would have to check that, dunno that by heart.

Kind regards

Tom

[ceedee666]

Hi Jelena,

we use ToC in our normal development process to transport new or changed objects to QA. This has the advantage that development objects stay locked in the dev system. To simplify the process of generating the ToC we created a simple transaction that takes a transport request or a list of them as input and creates the ToC as a result. It's actually quite simple and works very well. I can share the core functionality if its helpful.

Furthermore, I created a eclipse plugin that does the same (cf. ).

As to your bonus questions; I guess your issue is that the task in the original transport request are not released. The standard functionality only adds objects form released tasks or requests when doing an include objects.

Christian

[SuhaSaha]

Hi Christian,

To simplify the process of generating the ToC we created a simple transaction that takes a transport request or a list of them as input and creates the ToC as a result. It's actually quite simple and works very well.  I can share the core functionality if its helpful.

If the program is not proprietary, can you share the code with the forum? Maybe a blog/document!

I have to deal with ToCs regularly & normally create one at the end-of-day for the config/dev objects. I was hoping there was a utility to automate the process for me

Do you follow any "best practices" w.r.t ToCs?

BR,

Suhas

[ceedee666]

Hi Suhas,

we basically use the best practices describe in the with respect to ToCs. It's a document written by the German SAP User Group (DSAG). We just recently started to work on a second version of the document. However, what is written in the document regarding ToCs is a very good starting point.

Regarding the transaction to create ToCs: I always though this is something everyone has in his toolbox. So I never thought it would be worthwhile sharing. I'll put the program in a shape I'm comfortable sharing with the critical eyes on SCN () and share it somewhere. Currently it'S still one of these things I have on my list of things that I should do right some day. So sharing it is a goot trigger to finally get this done .

Christian

[Jelena]

Thanks, everyone, for the replies! Unfortunately there is no Eclipse or Solution Manager available in those systems (or rather there is SolMan but with some strange temporary arrangement, I don't really know the details).

It looks like there is no simpler way using just the standard transactions, but Tom had a good point - we need to look into the root cause and try to avoid TOC altogether. I'm not a Basis person, so I thought we had no other options, but using a virtual system as a target and switching later seems to make sense. I'll check with our hosting provider on that.

Adding objects to TOC seem to work the same way whether the transport/task is released or not - I tried both. If I enter the transport number then it just adds a comment but if I add the task number then it actually includes the object list. The same effect is mentioned in this blog as well.

[ThomasZloch]

It's not about released or unreleased, but whether the source request or task contains any objects at all. Requests only contain objects, once underlying tasks have been released to them. Before, they are just empty so you end up with an empty TOC as well

Cheers

Thomas

[Matt_Fraser]

That's right. But, you can definitely create a TOC from the unreleased task and that works. You just have to remember to pick the task and not the request.

I would completely agree with Tom that local transport requests should be avoided altogether if you ever intend to actually transport from that system.

[ThomasZloch]

Absolutely (on both points).

[ceedee666]

Thanks Thomas and Matt for correcting my incomplete answer. That was what I tried to say but failed....

Christian

[ceedee666]

Hi Jelena,

just to add to what Tom already said.,

We are also quite regularly in a situation where we have a sandbox system in parallel to the normal system landscape. The problem with this setup usually is that

a) development form the normal system landscape will not be transported to the sandbox system

b) development from the sandbox system needs to be transported back to the normal landscape at a certain point in time. However, because of a) you can never be sure if everything works as expected in the normal system landscape after this step.

Therefore we usually set up the transport routes in such a case like this:

1.) Transports released in the dev system are automatically added to the import queue of the sandbox system. The import queue of the sandbox system is imported automatically every 15 minutes.

2.) We create a virtual target system and a transport route for this in the sandbox system. Once we need to switch from the sandbox to normal dev again we simply release all the transport request in the sandbox and import them into dev manually.

There are some glitches one has to take into account (e.g. parallel changes of the same object in dev and sandbox) but this approach generally works very well for us. However, I guess it's only an option for rather simple landscapes. As soon as you work with more then one or two sandboxes and a more complex development landscape this approach won't work.

Christian

[Matt_Fraser]

We do something a little similar, in that unless specifically requested otherwise by the developer involved, we import transports released from DEV into the sandbox system, so that it stays up-to-date with current developments and configuration. We also periodically refresh the sandbox from production, so it has some realistic data volume for unit testing.

Where we deviate, however, is that we don't take transports out of the sandbox. We treat it as an isolated system for experimentation, for practice, and for quick dev testing before committing to a course of action. Probably more of this sort of testing occurs on the Basis side than the ABAP side, and also probably more on the functional configuration than with ABAP (at least where such config is complex in nature). Once an uncertain change of this nature has been validated, we repeat it (usually more cleanly) in the 'real' DEV system.

ToCs are a great way for ABAPers to get their current developments over to the sandbox for a quick "checkup" before releasing to QAS, if they want to do that. However, ToCs make their way to one or another of our QAS systems for that kind of thing just as frequently.

You know, it strikes me that this is the kind of "architecture" and best practices discussion that is interested in promoting.

[Jelena]

Thanks, Thomas. I thought I was going mad, but it turned out that the transport/task was in fact not released when I was given a list of transports to copy (it was expected to be and I spot-checked only few transports from the list). So once again "assumption is mother of all screw-ups". I checked with other transports/tasks and it worked as you described.

[Jelena]

Matt - yes, we also have the actual Sandbox system where no transports are moved either in our out.

In this case we are dealing rather with temporary DEV systems. Personally I'm not fond of this setup at all and it causes a lot of headaches. But it's not my decision, unfortunately, and we have to accommodate business, not the other way around (for some strange reason ).

Agree that this could make an interesting architecture level discussion.

[TammyPowlas]

Solution Manager / Charm Retrofit might work...paging or for his input

There are multiple Tom Cenens and I can't seem to select the right one

[GrahamRobbo]

This response puts me firmly in the #troublemaker camp - again. Have you seen https://github.com/larshp/abapGit?

This project is a work in progress, but it has huge potential.

A more mainstream answer might be SAPLink.

Cheers

Graham Robbo