Transport Timing

[Former Member]

Hi All,

I'm trying to find information on whether general guidelines or official documentation for transport timing.  I do a lot of abap development and am often running into situations where I'm wondering if a change can go through during working hours or if it will cause an issue when moving to production.  It seems as though it's learned through experience and searching scn and google has gotten me a lot of broken links on training documentation or simple tutorials on how to create a transport.

If anyone can point me in the right direction I'd appreciate it.

-Chris

[Former Member]

A large part of it is mainly common sense, though I'd say it would depend (heavily) on the contents of the transport:

• if it contains modifications regarding an urgent bugfix (think a transaction that dumps) I guess as soon as possible
• on the other hand, if it concerns changes that are less urgent or up to medium projects, then I would time it when as little as users are impacted. But also in that case timing would depend on whether it is something completely new, or something that impacts existing code
• major projects I've seen being transported during the weekend, where the team has the time to make sure everything is transported fine
• lastly, upgrades. As they require downtime, it is rather obvious these would be planned during the weekend

Personally, I'm not a big fan of transporting stuff when nobody is available for direct intervention if stuff goes wrong. Or you have to make sure you're on site before the first user as you probably don't want him to find out something messed up with the transports. I also consider that, when the project gets bigger, the time and resources that are required to deal with the transports do as well. After all the bigger the project, the bigger the possible impact it might be.

I've worked for different companies that have their own specific policies, with (bi-)weekly, or even monthly releases. In that case you 'only' have to make sure not to miss the deadline, and ask those in charge nicely to import your stuff..

[Former Member]

Hi,

Mainly the transportation is done with the tcode: SE10. There you select the transport that you want to release and push the truck icon or pusth the F9 key. After this the transport will go to the next system and there you need to go the the tcode STMS_IMPORT. There you find your transport and again you must to select with one click your transport and push the truck icon. In this moment a popup appear and there you can choose the date and the time that you want to release the transport into the system.

TIPS:

- Try to release the transport during the night when no one is working. Otherwise you can cause some dumps. Next day of the transports check the tcode ST22 to know if the transports cause any problem.

- Don´t do transports on Fridays otherwise during the weekend if you are not working and something went wrong you will no be able to fix it till Monday morning.

Hopefully this will be help a little bit and sorry I don´t have any document, I learn by doing .

Regards

Luis

[Former Member]

Yes - it can cause issues:

Importing transports takes time and resources - not a lot, generally, but some.

If users are running a program while a transport is being imported, they may get a dump with "load program lost" or "program was changed while executing". The user would then have to re-execute the program.

For these reasons (and probably others), it's best to import to production when there are fewer users on the system.

Rob

[Former Member]

Yes, that's the kind of information I am curious about.  I guess I'm just wondering if there's a method beyond using my best judgement on whether a transport is relatively safe to move during peak hours.  An example being I made an update to an extention of the LOIPRO idoc that's generated for us when POs are saved and was debating on whether to wait till off hours to move it.

Thanks for the info about what users could run into.

-Chris

[Patrick_vN]

A large part of it is mainly common sense, though I'd say it would depend (heavily) on the contents of the transport:

• if it contains modifications regarding an urgent bugfix (think a transaction that dumps) I guess as soon as possible
• on the other hand, if it concerns changes that are less urgent or up to medium projects, then I would time it when as little as users are impacted. But also in that case timing would depend on whether it is something completely new, or something that impacts existing code
• major projects I've seen being transported during the weekend, where the team has the time to make sure everything is transported fine
• lastly, upgrades. As they require downtime, it is rather obvious these would be planned during the weekend

Personally, I'm not a big fan of transporting stuff when nobody is available for direct intervention if stuff goes wrong. Or you have to make sure you're on site before the first user as you probably don't want him to find out something messed up with the transports. I also consider that, when the project gets bigger, the time and resources that are required to deal with the transports do as well. After all the bigger the project, the bigger the possible impact it might be.

I've worked for different companies that have their own specific policies, with (bi-)weekly, or even monthly releases. In that case you 'only' have to make sure not to miss the deadline, and ask those in charge nicely to import your stuff..

[Former Member]

seems the consensus is that it's left to best judgement.

Thanks,

-Chris