How to import transport of copies to productive systems

[Former Member]

Hello,

I have been experiencing a problem that even the guys from admin could not solve (yet). I should say I work in a development team.

Imagine you have two landscapes, one DEV-QAS(1) to develop big projects and a normal DEV-QAS-PRD(2) landscape where my objects will be imported. After a new group of objects is finished in (1), we ask to import the workbench request in the STMS queue of DEV(2). After this, and after some small test, we create a transport of copies in DEV(2) where we include the first transport, release it and import it to the QAS(2) queue. After the tests in QAS(2) the idea would be to import the transport of copies to productive system PRD(2). But it does not work...

In STMS queue for PRD(2), there is no entry for the transport of copies. Also, when I tried to add the transport request to the import queue (via menu -> Extras -> Other requests -> Add), I get an error message stating that no co-files where found for the transport.

Does anyone know this problem? I suspect it can have sothing to do with the use of a transport of copies, but, if I don't use this kind of transport, how can I get objects from other systems to production?

Thanks in advance.

Davide Sepanas, Portugal

[Former Member · Accepted solution]

Hi Davide,

Re your two issues:

In STMS queue for PRD(2), there is no entry for the transport of copies.

This is normal. The transport of copies is not a standard change request moving over the configured transport layer. Therefore the fact of importing it into one system does not automatically place it in the import queue of the next system on the transport route.

Also, when I tried to add the transport request to the import queue (via menu -> Extras -> Other requests -> Add), I get an error message stating that no co-files where found for the transport.

>

Do your QAS(2) and PRD(2) system share the same transport directory (/usr/sap/trans)? If not, then the data file and cofile of the transport of copies must be transferred from the QAS(2) transport directory to that of PRD(2). For norma

[Former Member · Accepted solution]

Hello Mark,

Thanks for your answer.

The DEV(2)-QAS(2)-PRD(2) are all in the same transport directory.

As I wrote, if I create and release a transport of workbench or customizing in DEV(2), and import it to QAS(2), it appears in the PRD(2) import queue. All is working as normal.

If I create a transport of copies in DEV(2), and release it, it appears in QAS(2) import queue, but, after I import it to QAS(2), it is still not possible to add it to the PRD(2) queue. These is the problem.

Davide

[Former Member · Accepted solution]

Davide,

The fact that the transport of copies does not appear in the import queue of PRD(2) after importing it into QAS(2) is normal as explained in my earlier reply. However, the fact that STMS cannot locate the cofile and/or data file is abnormal. Can you check whether the files are physically present in the directory where the transport system expects them (/usr/sap/trans/cofiles, /usr/sap/trans/data). For a transport request SIDK912345 the cofile is called K912345.SID and the datafile R912345.SID. Also check things like read access on both files and write access on the cofile.

Regards,

Mark

[Former Member · Accepted solution]

Mark,

I made a new test, looking at AL11 files, and here is what I could see:

1) I created a transport of copies in DEV(2). I released the request. In AL11 of DEV(2) the corresponding data and cofiles were created.

2) I go to STMS in QAS(2), press the button "Refresh", and the request appears in the bottom of the list, with the "green lightening" symbol, indicating that data file must still be transferred.

3) I press the button "Adjust import queue", and after passing the popup, the request is now ready to be imported. The data and cofiles are now also in AL11 folders of QAS(2). I import the request with success.

4) I go to STMS in PRD(2), press the button "Refresh", but nothing happens. I try to add the transport via (menu -> Extras -> Other requests -> Add) but I get the error message "0247 - problem reading data or co-file...". This way it's not possible to import the transport of copies.

5) I tried now to use in STMS of QAS(2) the functionality to forward the request (menu -> Request -> Forward -> System), indicated the target system PRD(2), and only this way I could pass the request to the PRD(2) queue!!! After this I could import the transport in PRD(2).

So, the problem seems to be when I refresh the import queue of PRD(2), that it does not identify the co-files and data files in DEV(2) or QAS(2). But these files are there. And the problem only happens in the case of a transport of copies. Could it be some customizing in TMS of PRD(2) ? Or no one uses transports of copies like we are using, in their projects, to pass repository objects from other systems to production?

Davide

[Former Member · Accepted solution]

Davide,

There is definitely something wrong with your STMS setup because if, as you say, DEV(2), QAS(2) and PRD(2) share the same transport directory, then there will never be a file transfer and you will never see the green lightning icon. I suspect that the systems may have been assigned to a different transport group. Please go to STMS, open the "Systems" window and check whether anyhting is listed in the column "Transport Group" and if so, whether there is a different group name for the DEV, QAS and/or PRD systems. Transport groups are used for systems that are member of the same transport landscape but do not share the same physical transport directory.

Let me know what you find.

Regards,

Mark

[Sandra_Rossi · Accepted solution]

In my project, we do that by recreating a workbench or customizing transport request in DEV(2) and importing the list of objects of the transport of copies. Then we transport as usually from DEV(2) to QAS(2) to PRD(2).

Maybe the best thing is to ask sap support, you will have the answer (but as said by the docs, I am afraid it's definitely not possible).

[Former Member · Accepted solution]

> In my project, we do that by recreating a workbench or customizing transport request in DEV(2) and importing the list of objects of the transport of copies. Then we transport as usually from DEV(2) to QAS(2) to PRD(2).

>

That is a valid approach if you use relocation transports, i.e. the objects then become original in DEV(2) and will be maintained out of that system. But I think we have established that there is something basically wrong with the setup of the transport landscape at Davide's site, so I think we better concentrate on that so that his current procedure based on transports of copies will work.

>Maybe the best thing is to ask sap support, you will have the answer (but as said by the docs, I am afraid it's definitely not possible).{quote}

Well I am a SAP consultant so in a sense he's already getting SAP support

I can assure you that importing a transport of copies is possible.

Regards,

Mark

[Sandra_Rossi · Accepted solution]

I am sure that you are right, I just pointed out sap library text :

Transports of copies
You can use this request type to transport objects to a specified SAP System.
The objects are transported with the version they have in the current SAP System.
The original location of the objects remains unchanged.
There is no delivery to another SAP System.

The last sentence is not very clear to me. What I thought is that it meant that we cannot "put a transport of copies on a transport route" after the initial transport, a transport of copies is just one shot. Importing manually is possible, of course.

Well I am a SAP consultant so in a sense he's already getting SAP support 
I can assure you that importing a transport of copies is possible.

Let keep us informed what the issue was, this will be interesting to know.

[Former Member · Accepted solution]

> There is no delivery to another SAP System.

> The last sentence is not very clear to me. What I thought is that it meant that we cannot "put a transport of copies on a transport route" after the initial transport, a transport of copies is just one shot. Importing manually is possible, of course.

Your interpretation is correct. A transport of copies will never follow a transport route ("delivery"), you must place it in the import buffer and import it manually. The trouble here is apparently that adding it to to buffer is impossible because of a misconfiguration in the transport setup. Davide's feedback will make this clear.

Rgds,

Mark

[Former Member · Accepted solution]

Hello Mark,

In fact, in STMS - > Systems there is a different transport group for each machine (like GR_DEV(2), GR_QAS(2) and GR_PRD(2)). I have used the button "Check transport groups", and the result was green for all of them...

Davide

[Former Member · Accepted solution]

Hi Davide,

Regardless of the green light the check gives you, if your three systems share the same /usr/sap/trans area then they must NOT be assigned to different transport groups. Please assign them to the same group and test again.

Regards,

Mark

[Former Member · Accepted solution]

Hello Mark,

I have checked your proposal with our system administrator, and after all the three systems do not share the same /usr/sap/trans directory. My mistake, sorry for that ;-(

Another hint: can it be a parameter in the transport tool for system PRD(2) that is missing, and is causing this problem? I noticed that there are three parameters more in this tab for DEV(2) and QAS(2) then for PRD(2). They are: REPEATONERROR (8), STOPONERROR (9) and WORKFLOW_STRATEGY (0). These ones were not configured in PRD(2)...

Davide

[Former Member · Accepted solution]

Davide,

In that case your only option is to use Request > Forward in QAS(2), as you have already tried with success. The TMS will only do automatic forwarding for requests that are on a transport route. To my knowledge there is no option to enforce automatic forwarding for all requests imported into a system. The three TP parameters that you mention are unrelated to this issue.

Is using the "forward" function a viable solution for you, knowing that this is indeed the normal behaviour of the TMS? If not we'll have to think of workarounds (e.g. custom design of a forwarding system), but these won't be too easy to implement.

Regards,

Mark

[Former Member · Accepted solution]

Hello Mark,

I think we can use the "forward" function from QAS(2) to PRD(2) in the case of transport of copies, since these kind of requests are only used from time to time. Nevertheless, I still am curious about two things:

1) Why this problem with transport of copies doesn't happen from DEV(2) to QAS(2), since these systems are also not in the same transport directory?

2) The mentioned problem, in productive import queue, only happens with this kind of request, workbench or customizing requests work fine?

Can we assume, then, that, where I was working before, all three systems were configured in the same transport directory, avoiding thus the problem with the transport of copies requests?

Thanks again for the interesting discussion. Always learning...

Best regards,

Davide

[Former Member · Accepted solution]

Davide,

Re your latest questions:

> 1) Why this problem with transport of copies doesn't happen from DEV(2) to QAS(2), since these systems are also not in the same transport directory?

>

I think the answer is in your original problem description:

we create a transport of copies in DEV(2) where we include the first transport

>

When you create a transport of copies you must indicate a terget system and I suppose you enter QAS(2) there. In that case the TMS will add the request to the import buffer of the target system when you export the request from DEV(2). I understand that you never have to add transports of copies to the import buffer of QAS(2) manually, which proves the TMS does this for you. However, for further imports into systems that are not designated as target system of the transport of copies, like PRD(2), the TMS will do nothing of the sort and you must add the request to the queue yourself - which in your case also means you have to forward the transport files first.

> Can we assume, then, that, where I was working before, all three systems were configured in the same transport directory, avoiding thus the problem with the transport of copies requests?

Yes, and that is the most common way of setting up the transport system. Having separate transport systems really only makes sense when sharing the transport directory between the dev, qas and prd systems (via NFS for UNIX, via network shares for Windows) is not possible, either because there is no local network between the servers or because some security policy forbids it. I'd advise you to certainly ask the question to your system admin.

Regards,

Mark

[matt]

Thread moved to more appropriate forum. I don't think this is a development question. I seems to me that there is a problem with the configuration of your CTS. Anyway - you may get more informed opinion here.

matt

[Former Member]

hai david

firs tof all transport of copies do not have a target system if they dont have target then it is obvious that it will bot be reflected in queeue ,so for that u have to manually pick the cofiles and data files and then place them in respective folders of target system and then import using stms ,

i have done the same many times the same thing

we use to releease them and then collect cofiels and data files and then do the process

the advantage of transport fo copies is that u need not have any transport routes for the server

hope u got the point

m.a

[Former Member]

Sorry, I accidentally hit the "Post" button - previous message continues:

For change requests that follow the configured route, the TMS will take care of this, but for other transports you must do this yourself.

Regards,

Mark

[MarcinPciak]

Cofiles are necessary in order the transport can be imported. These are just metadata, which together with data files form transport with its objects. Basically you need to copy those files from one application server of first DEV system to application server of targert DEV system. Then you do the acctual IMPORT .

I described this process in details here: [How to copy Repository Objects between non-connected SAP systems|http://wiki.sdn.sap.com/wiki/x/ggJqBg].

Regards

Marcin

[Former Member]

Hello Marcin,

Thanks for the link in FAQ, it seems very complete.

Nevertheless, it does not answer exactly to my question. We use a similar process to copy objects from other systems to the main system, however the difference resides in the type of transport we use in the step "Matching imported data with a new transport". In the blog you use a Workbench request to include the objects, and in my case we are using a Transport of copies.

We are having trouble importing such a transport of copies to production. We don't have any problems if we use a workbench request.

So, the main question is still open: what can be preventing a transport of copies to be imported in production?

Thanks.

Davide Sepanas, Portugal

[Sandra_Rossi]

As found in another thread (please search!), there is a link to sap help where you can read: "transports of copies are not included in the CTS delivery mechanism, they are not transported across your system, and are therefore not imported into your production system" : see http://help.sap.com/saphelp_sm32/helpdata/en/34/819d423893c46ae10000000a155106/frameset.htm (check also http://help.sap.com/saphelp_nw70/helpdata/en/57/38e1a94eb711d182bf0000e829fbfe/frameset.htm)

[Former Member]

Hello Sandra,

For your information, I have been using SDN forums for some years now, so believe me that if this question was easy to find or answer I would probably have found it already. I would suggest some tolerance to this SDN colleague of yours...

I had already looked at the documents in both links you mention. The first one is related to Change Request Management, which we don't have implemented in our system, although we already know it due to a lat month presentation with an SAP team.

The second document is not very informative.

When I say that it is possible to import transport of copies to productive systems, is because I have worked in another company for some years with this reality, and never had any problem (!). Only where I am now working I see this problem, so... there must be some customizing missing in the TMS area that is causing the problem.

Davide

[Sandra_Rossi]

sorry to be a little bit too direct , I found the answer by just looking at "transport of copies" in forum. The second url says "There is no delivery to another SAP System." I also found other threads which say the same.

I guess it's because of your previous project that you are sure it's possible, but maybe something changed, or there was a custom program or special procedure to transport?

Edited by: Sandra Rossi on Aug 14, 2009 3:26 PM : or there was a modification of the standard? --> or there was a custom program or special procedure to transport?

[Sandra_Rossi]

This question should be posted to the admin forum !

[Former Member]

Hello Sandra,

Can you tell me in what forum category can I find the admin forum? I intended to post this message in such forum, but I could not find it.

Thanks in advance.

Davide Sepanas, Portugal

[Former Member]

hai davide, it is quite simple

when u reelase any request for every request data files and cofiels are generated

so form development server from OSS folders of server that is desktop of ur server u haev a trans folder from where u cna pick the cofiels and data files form cofiles and data folders

and in production server dektop just go and save them in corresponding folders

the cofiles will start with k and and data fiels with r

onc eu saved on oss level just jo to stms transcation and from menu chose utiliites and add reqest and from help u cna see the request just select it and then import it and it will be done

u cna take help of basis

m.a

[Sandra_Rossi]

the one which best fits is the Application Server, SAP NetWeaver AS, General (forum id : 45)