Transports moving directly from QA to PRD without being created in DEV

[Former Member]

Hi,

I have an important question/issue to raise. We currently have a

transport strategy that moves our transports from DEV (ECD) --> QA

(ECQ --> PRD (ECP) systems. We have this one user that

only wants to create a transport in QA System which is ECQ 220 and wants the transport

to move to the PRD (ECP). He has not developed his transport in DEV. Is this even

possilbe to create transports in QA and move it to PRD without having them in DEV environment?

If so, what is the process and steps to do this task?

[Former Member · Accepted solution]

Hi Thareq Yahya ,

It is possible to create a transport in the QAS environment and transport it to Prod. environment. In order to perform the development/create the request in QAS environment, the client needs to be opened for development (Txn: SCC4) and after creating the request, the developer needs to release the request so that it can be transported.

However, IT IS NOT RECOMMENDED to by-pass the DEV environment. Please ask the developer to create the request in DEV environment and follow the normal transport strategy.

Regards,

Raj.

[JPReyes]

Its possible but as said before not a good practice. Why?, simple... DEV is the place where your developements are done and the history of those changes are kept on version management. Developments done outside DEV will not leave a trace and changes could compromise work done previously also making the systems inconsistent.

So, tell your user to stop messing and start working in DEV. 😄

Regards

Juan

[Former Member]

The problem is that the data for this particular user testing only exists in ECQ 220 and not in any other client. So, he is only able to create the transport in QA due to this EDI data. Also, After the user created the transport in ECQ and released it, and when i try to import it to prodcuction, the transport did not go through becauase the co-file and datafile does not exist for that transport. The thing is we already have a transport strategy in place which is moving transport from DEV>QA>PRD. Wouldn't change the transport queues or stategy would impact our current transport stategy?

[Former Member]

Hello Thareq,

Ah... this is an old story. Rule #1 : Try to resist changes in non-dev system directly as vehemently as possible.

However from your post it seems changes have already been made and even transport released.

From your post I reckon these were customzing changes. Now the transport requeast that must have got created as a result (a customzing transport most likely) would have target system/client missing from it since it QAS to PRDN is not a consolidation route but is delivery instead. There fore neither did the release create data file/cofiles nor would it have pushed the transport into the production import buffer.

Therefore what you must do is create a new transport of copies request with your production system/client as target system/client and then include the object list of the original customizing transport into it and then release it.The release would ensure data/cofile creation along with appearance of this request in production buffer!

Afterwards consult the guy and ask him if the changes can also be made to development for sake of consistency.

Regards.

Ruchit.