What frustrates you when using the "Administrator Word Bench"? (RSA1)

Question

Hi All,
As a developer and user of the "Administrator Workbench (RSA1)" ... what feature makes you mumble under your breath in frustration?
Problem: When deleting PSA requests, the dialog box does not have a u201CSelect Allu201D button. It was easy to manually clean up the PSA requests in the older AWB.
Solution: You have several choices, neither of them is ideal and both are not as good as having a u201CSelect Allu201D button. You can either select each row/requests individually or change screens and create a temporary process chain/variant in transaction RSPC to do it.
Problem: The u201CTransport Connection Wizardu201D functionality is a memory hog that spends a lot of time processing iterative, nested loops which means even a decent hardware capable desktop slows down and makes selecting/ticking individual nodes/objects to be gathered into a transport request a slow and un-necessary time consuming activity.
Solution: You can stop the slowdown from occurring by collapsing the branches as you go. There is a very noticeable difference in speed if you minimise the number of open branches at any given point in time. This allows you to gather many simular objects in one cycle and then proceed to analyse them all at once by navigating the object tree one branch at a time.
The question is only for BW Developers and Administrators who spend a fair amount of time in transaction RSA1.
Please, politely vent your frustration at even the smallest thing.
Kind Regards,
John.

Answer 1

Hi Durgesh,
Sven is absolutely right.
You need to put some time aside and remove the unused objects from the system. Usually the development system is the worst as many objects are activated but never used and never transported.
This activity is best done in reverse to the order in which you would have activated the content.
Web Templates
Queries
MultiProviders
DTP
Transformation
Update Rule
InfoSource
Cube
DataStore
InfoPackage
InfoArea
Application Component
Etc, etc, etc u2026
I would suggest a 2 phase approach to doing this.
(1) The $TMP objects. Try once for all objects that allow you to delete them without a transport request. Take note of the objects that have previously been transported as you would be wise to do further impact analysis in the Test and Production systems before committing to deleting them from Development and transporting the deletion. For each of the previously transported objects do a quick where-used search in the Test and Production systems to confirm that it is truly not being used. The issue we are trying to avoid is that we can never know what other developers might have broken in development (accidentally) without realising and then you come along and transport an object deletion that was ok (not related) in development but is still being used in Test/Production.
(2) Using the above list of previously transported objects, try transporting the deletion of only 1 type of object per week or per official transport cycle for move to Production. This will allow you to clean up the system with out consuming too much noticeable time from other more important activities. It will also reduce the risk of getting something wrong because boring, monotonous tasks like this one (clean up) it is too easy to get distracted and accidentally transport active objects that you did not mean to.
Now do a clean up of unused DataSources in any source system connected to BW.
This includes DataSources for the "Myself" DataMart where BW talks to itself.
Kind Regards,
John.