Skip to Content
0

Transport between systems: problem releasing the TRs

May 23, 2017 at 07:12 AM

115

avatar image

Hi all,

We've been developing in a "borrowed" temporary system.

Now we need to move all the objects to other system.

I know we can download the TRs in path DIR_TRANS. Downlading the COFILES and DATA, etc... there are several tutorials and blogs about that.

The problem is that is necessary to release the TRs to create the files in COFILES and DATA. And by the moment we can't release the TRs because there is an automatic scheduling to transport released TRs.

By the moment we prefer to not talk with anybody to stop the automatic process, its a sensitive issue.

Is there any workaround to solve this problem?

Don't know if we can create a Destination pointing nowhere and put this destination in the package and TRs or something to skip the processing of released TRs. or if exists other options...

Any help will be helpful.

Regards.

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

4 Answers

Jelena Perfiljeva
May 23, 2017 at 08:00 PM
1

It's not 100% clear but I'm assuming here that "borrowed" system has some other objects that you don't want in the target system and that target system also has other stuff that is not in the "borrowed" system. (If it's a simpler scenario then Matthew's suggestion could work.)

As Vinit noted, in this cases a separate target system is used. It does not even have to be a "dummy" system, you can actually release the transports directly into the target system, as long as it's technically feasible to connect them and establish the transport path. What you should've done in the beginning is created a designated package for all your stuff and assigned that package to another target system. It's still not too late though.

I believe that would be the best solution. Otherwise Sandra's answer is about the only option.

Also Vinit had a good point about the TOCs. This is very handy when you have the whole bunch of transports in the source system but don't need them separated in the target system and just want to get all the objects in. In this case, just create a TOC of all the transports needed and then you'll have only one set of files and only one transport to import. Note: you can create a TOC even without releasing the original transports. But you'll have to release TOC itself to get the files, as you correctly noted.

Share
10 |10000 characters needed characters left characters exceeded
Vinit Joshi May 23, 2017 at 07:29 AM
0

Hi,

You can ask your BASIS Team to create a dummy target system which you can use to release your TRs. Ideal option would be instead you import multiple transports (after you release them to dummy target) , create single transport of copies to include all your transports and release it to dummy target. You can use this single transport of copies to import it in 'other' system.

Share
10 |10000 characters needed characters left characters exceeded
Sandra Rossi May 23, 2017 at 07:41 AM
0

I'd prefer to do everything via the transport system, but if you can't, you may install SAPlink in the source and in the target systems, to save the objects into an XML file, and restore them in the other system.

Caution: some types of objects may not be handled by SAPlink. There might be some issues which need a rework of objects in the target system because of limitations or bugs(translations, activation errors). I'm not confident about how the objects will be assigned/locked to transport requests in the target system.

Share
10 |10000 characters needed characters left characters exceeded
Matthew Billingham
May 23, 2017 at 07:56 AM
0

Rather than transport, why not just do a client or system copy - with cross-client objects.

Share
10 |10000 characters needed characters left characters exceeded