Please assist with any knowledge on configuring auto-import for Maint. Cycle and urgent corrections. Currently, the auto-import is working on a daily basis instead of hourly.
This can be turned on by using STMS in the target system so (test or production for example). Once you are in the Import Queue you click the truck icon labeled "Import All Requests". There is a drop-down called "Period" that you can set even though it may appear grayed out in your system. You can set the transports to import every 15min, 30min, Hourly, Daily, Weekly, Monthly or Other.
If these instructions don't help let me know and I can e-mail you screenshots directly.
This is excellent information. We too are planning the auto import for periodically transporting ONLY to QAS. I also understand that the auto import anything in the queue that has been released from DEV system.
So what my research has presented is that it would first be wise to do a mass cleanup of the transport domain, as we have transports sitting in the queue since 2008
Hi Maria - nice too meet you.
So you are saying that you have transports that have been abandoned in your development system since 2008? How is management okay with this? Do they realize that your developers are basically developing in an environment that is not similar to the test environment? I would think this is a huge risk in how you manage development and ultimately move changes into QAS and then Production. Okay, I will back off...
We regularly refresh our development environment from our test environment to ensure they are in sync. We also follow up on transports that have been sitting in Development and QA longer than 30 days. I would recommend the same approach right away.
You will find cleaning up tranports since 2008 a huge undertaking. It is likely several of the people who created those transports are no longer at your company, the transports that are sitting the QAS import queue cannot be "deleted" because they are already ready for import. SAP strongly urges companies to follow a golden rule, "NO transport left behind". This means that anytime a transport is released at the request level and it's ready to be imported to QA, then it MUST be imported to QA and then onto Production. If the transport contains changes that will negatively impact your QA or Production system then a "corrective" transport should be created and imported to QA and Production to reverse the changes.
You may be better off refreshing your QA and DEV environment from Production with a subset of data. This would save you alot of time. A good basis team can refresh a system in less than a week.
Hi Ryan... nice to meet you too. I'm so glad you picked up on this thread. With all the research I've done, I have not had the detail and advise you've provided
Unfortunately our system has been in evolution over the past few years. When we migrated from Unix to Windows we left behind the transports and started with a new and fresh queue. Then we started the migration from Peoplesoft HR/Pay into SAP and this is where the fun started. To make a long story short, we are fully aware that there are insynchronizies between DEV and QAS. However QAS and Production ARE in synch.
I agree with you that new transports must be created to fix issues transported to production or revert 'WRONG" configurations sent to qas and production and this is definitely the methodology that we've been following. However When the migration from Peoplesoft to SAP occured (FYI we've been running SAP for almost 15yrs), this is where the complications happened, with the consultanting team making changes adhoc even in QAS, skipping DEV.
Brings us to today. We have determined that we cannot re-transport anything after mid-year or year patches, so we've taken the approach ie. to review transports in the queue for the past 6months and then decide what can be removed. Whatever is sitting in the QAS queue will have to be visited and IF possible maybe somehow remove as well going back about 6months.
The cleanup we want to achieve is in the efforts of also speeding up the manual transports to QAS and Production as well, we have experienced a couple of rounds of extremely slow HRSPs deployment. In our conversations with SAP their recommendation was if possible conduct a clean up of the transports in our domain
We hesitate to refresh DEV as it REALLY messes things up for us. We loose all history as well as the domain will need to be rebuilt. So much unwanted baggage and configuration will be brought over from Production or QAS that is really unnessary. BTW any suggestions on how you refresh is it thru system copy via attach/detach method or is it thru R3copy import the data file?
Your approach on the cleanup sounds appropriate since you can't import transports before the HR support packs went in. I am assuming the last support pack you put in relating to the transports that need cleanup was 6 months ago? I recommend that if the transports are older than 6 months then just delete them from the import queue to eliminate any risk of them being imported to QA. As for refreshing, I went and talked to our Basis team. Apparently, we don't refresh Development (I was under the impression we did) but it was explained to me that you never want to refresh your source system because that is where everything "originated" from. Doing so has deterimental effects including transports logs and history information is lost. I guess we learned that one the hard way awhile back before I was here. In any case, we use a tool called Tivoli to do system backups. We then use our DBAs to restore the full system backup over the top of our QA system. We also use TDMS to restore systems with a subset of data by time, business process, empty shell, etc..(I am trying to regurgitate what I learned from someone else so this may not be making sense as I am not a Basis person). I hope this information was helpful or at least makes you feel a little more comfortable in the direction you are heading.
Hello Again Ryan...
Your information alligns exactly to what we do. NEVER refresh DEV and for the reasons your BASIS team offered. I am in the BASIS team as well.
Also we are MS shop running windows 2008 , sql server 2008 (clustered) , we run commvault for our sql and system backups , good comparisons.
Instead I use the SAP System export/import tools via 'sapinstall' which offers us to be able to use export of pure data, and then same tool on the target system for import of the data. This is nice because it cleans up and re-orgs our data.
Also there is the option of using the MS SQL function to detach/attach the db, which allows us to have the backup team restore the data files from a source system (ie. Prdn) onto the QAS system , in MS SQL Mngt studio we re-attach the data files, then we run the 'sapinstall" tool (on the backend) to build the SAP system , and voila, quick refresh
We just completed Year End HRSPs but no matter at which point we will make the decision for the cleanup it will still be for about six months this simplifies the ability of the ABAP team to reference their transports. Of course when I say , remove, we would just go to the transport directory (backend) make a copy, and move out the data and coefiles we no longer wish to be available in the transport queues.