ways to remove custom code developments and backup data

[former_member191441]

Good morning

We have had a lot of custom code developments (mainly reports). These were created over period of last 10 years but it is not used currently (not executed last 12 months).

What process would you suggest where we can remove these programs and correpsonding tcodes, but still have the data available if we ever require that information at a later stage.

We talking about a 1000 odd reports/programs that need to be cleaned up.

It would be really interesting to know how you would handle such a scenario.

1) Clean up all unused custom code. Remove code from system completely

2) it must be available later if need arise to get it back into the system.

Regards

Johan

[Former Member]

It will not be just reports - there will be associated domains,  data elements,  tables,  GUI-Statuses and titles,  screens,  classes, function groups, modules,  texts,  messages, documentation etc etc etc etc.

To automate the download of all of these things is relatively easy but re-uploading it if required is a totally different matter.

On an item by item basis you could use SAPLink (Sorry - can't cut and paste here but search using google).  You could probably automate the selection of items to download using a wrapper.

However,  the problem comes when re-uploading something.

Say you wish to upload something simple such as a report.  You know the report name.  Which custom message class does it use ?  Have any custom domains been created ?  Data elements ?? etc etc

So what you are attempting to do is not a trivial thing,  so the next question is Why do you want to do it ?

Rich

[former_member191441]

Rich

Thank you very much for the detailed reply.  you gave give a lot of things to re-think.

Appreciate the time you took to shoot a few holes in our argument to delete data but still have it available for some rainy day.

Johan

[Former Member]

Hi Johan,

I'm not shooting holes in it - just pointing out a few problems!   I had to do something similar once when a company was bought out during a development project and the new owners wanted all the custom code removed.  The project lead wanted it saved so I had to write a 'download the kitchen sink' program that was pre SapLink.  That worked like a charm - analysing the programs for dictionary stuff etc  but When I thought about the upload side of things I ended up with a whole bunch of different programs and a manual process which was ok for one program but for a 1000 ??

Rich

[former_member191441]

We use "shooting holes" in a positive sense whenever we need to hear arguments why we off the beaten track.

Appreciate your insights. always good to hear other perspectives.!

[Former Member]

-Classify folder based on each module

-Save all the programs into txt or xml file and name it based on program name - Use program REPTRAN.

[Former Member]

Hi Elzkie,

Reptran does the job - I've used it myself but it does not handle various objects that would also need to be removed or uploaded.

Rich

[Former Member]

Hi Johan,

partially I don't agree with Richard Harper, custom domains, data elements and tables mustn't be deleted to keep your custom data.

Normally your program code is developed on a DEV system and transported to a PROD system, where the interesting data are available. Do you have only DEV and PROD clients or systems? Also a transportable program deleted on your DEV system will be still available in the Version History,

For your purpose it might be easier to change the users roles and profile, that the unwanted programs and transaction can't be executed any longer.

Regards,

Klaus

[Former Member]

Hi Klaus,

I was assuming the data was going to be downloaded as well - apologies for not mentioning that.  However,  I think Klaus's idea of changing the roles and profiles would be an easier route if it is to just prevent the execution of the reports.

However,  if like in the project I mentioned above the development has to be totally removed for (in that case tax reasons) some reason then you're still a bit stuck.

Rich