Is there an official way to create a deletion transport?

[Former Member]

Dear gurus,

I have been searching high and low to find a way to manually create a deletion transport, but it seems there are only hacks and no official way. Does anyone know what the proper procedure is?

Details: I want to send a deletion transport for a package with many objects in it to a target system. But I don't want to actually delete them in the source development system.

Idea: Find a 3rd SAP system which does NOT have the package in it. Add a transport WITH the whole package objects in it to the import queue. Create a new Workbench Transport and import the object list from the first transport into it. Then delete the 1st transport without importing it. Then release and export the 2nd transport. My theory here is that it might be converted into a deletion transport and that it might work to delete the objects when imported into the 2nd system where they do exist. But this "might work" seems a bit of a long shot to me, so I thought it best to first ask for an official or at least better way to do this...

Any ideas?

Cheers,

Julius

[matt · Accepted solution]

1) Create local ToC of the objects you want to delete. Release it.

2) Delete the objects you want to delete, record against a workbench transport

3) Release WB transport

4) Import ToC created at step 1 into your dev environment

5) Import the WB to the system that you want to delete stuff from

Some of this can be done programmatically. (1-4, IIRC).

[Former Member · Accepted solution]

Also here the problem is that I have master data, customizing data and even application data and logs in some of these tables in the development system which I cannot loose, in addition to needing the developments there in future as well.

Unfortunately the trick with the empty sandbox and releasing a transport with the object list in it did not work. R3trans spotted it and instead of converting into a deletion request (which is what I was hoping...) it stopped the export.

That is of course much worse than what I originally anticipated... 😞

I discovered that TADIR actually has a table mainenance view to add entries directly (which very much surprised me actually...). In that case one can maintain the entries before releasing the transport and then r3trans should remove them again on export and change it to a deletion request. That is how the normal was of recording an object which you then delete works as well.

Somehow I think I am not "back to standard" using this approach... but am optimistic that I am getting warmer and it will not be impossible.

***holding thumbs***

Cheers,

Julius

[Former Member · Accepted solution]

So... digging a bit further I found subroutine form SUBMIT_RSWBO052 in include LSTR5F01. It has no where-used-list as it is called indirectly as a constant. It calls a maintenance view for TADIR which is "handmade" (report RSWBO052) and offers the option to insert TADIR entries.

Downside (considering that I have thousands of objects) is that it does not have select-option type of imports and lots of popups asking for the repository objects and then packages and transport requests.

I guess we could batch-input it, but a direct hit on TADIR in a "naked" sandbox is going to achieve the same and certainly be faster.

But I still can't believe that there isn't some standard way of doing this via parameters at the OS level for TP exports or some other way. Surely many customers have sent objects which are only used locally in DEV systems to upstream systems where they are not needed and wanted to create such deletion reports?

@ Juan: In my case, the target system received trial versions of software for POCs (proof of concept tests). They then decided to upgrade first and want to remove everything they do not use in QAS and PROD. But some of these things they want to have removed must remain in the development system for testing purposes or they developed them there, but dont want them in PROD anymore and asked me to help them remove the objects from PROD (and QAS) only, but not DEV. A bit strange, but this must happen often enough that there must be some procedure for it.

I raise the stakes and offer beers (or tea) for any ninja who can help me further here.

Currently it looks like hard updates on TADIR in a system which is wasted anyway is the only option, but that transport will go to PROD... so it is also not a "walk in the park" test in a sandbox.

Hmm... the plot thickens...

Cheers,

Julius

[Matt_Fraser · Accepted solution]

Hmm, I suspect most customers have the opposite problem, which is that they created "local" objects in DEV, or various "POC" objects in a multitude of transports labeled "do not import" (we had a number of developers, both staff and contractor, do this in our system, much to my chagrin), and thus they have numerous "out-of-sync" objects in DEV that don't exist in QAS, etc, and which probably should... or which should only have been in a sandbox to start with, and not the official DEV system.

[Former Member · Accepted solution]

"opposite problem"

That is why you should control developments at package level as the highest but also lowest form of organizational control of development as well. It is unrealistic to go lower than package level IMO. We also transport at package level and are trying to delete at package level as well.

Cheers,

Julius

[fredrik_borlie · Accepted solution]

Julius.

After a good night of sleep I got a brilliant idea 😃

You have already found TADIR which is be the source to find which objects to delete, based on your transport request.

You should also look on tables E070 and E071 which are are involved in transporting.

In theory you should be able to execute SQL-statement on TADIR and insert into E071 from your original transport request number.

But most likely there is some more tables involved. But this should lead you forward

If you want it more controlled write an ABAP that is more thorough in select and insert.

Have not studied what flag that says to delete but it should be there somewhere. Will look a bit more.

Do not forget to take a backup of you system if it fails.

/fredrik

[Former Member]

Dear gurus,

I got it to work. Perhaps not the official way either and not documented anywhere, but here is how it worked. Background is that r3trans is not allergic to all object types, but it does not play along with it if the object list might contain any contents of tables. This means that the object types VDAT (View maintenance data) and TABU (Table contents) cannot exist in a transport request if the TABL object (so the actual table itself) does not really exist in the system being exported from. This is because client independent tables (of which I had a handful) will ask for workbench transport requests and not customizing transports when you call the view. And exactly that was causing the problem, but when you delete the TABL type object in the target import, then TP in the import stage will automatically delete any VDAT or TABU type entries in the table anyway, which means you don't need them.

So... step-by-step procedure for anyone else who encounters the same problem:

• Find yourself a "naked" SAP system without the objects in it.
• Add the request with the objects to the STMS import queue but don't import it.
• Create a new transport and import the list from the real transport into it's object list.
• (now comes the trick!) Edit the transport task to remove all TABU and VDAT type entries in it.
• Delete the first transport from the queue again.
• Release and export the 2nd transport, which will no longer be blocked by r3trans and will be converted into a deletion transport.
• Fetch the Co- and Data-files from the TRANS directory and import them to any target systems as deletion transports.
• Add salt and pepper to season it. Serve with a cold beer. Enjoy.

Cheers and thanks all for the help. Hopefully this trick will also be helpful to you until one day there is an official way to do it...  🙂

Julius

[Matt_Fraser]

Well done!

[Former Member]

Hi Julius,

This option may work, It's again a standard procedure:

1) Add all the objects and create one transport TR1 and release it

2) Delete whatever you want from source system and then it creates new TR2

3) Import request which is created during step#1 into source so that you get objects as it is

4) Take the TR2 to target system

Regards,

Nick Loy

[matt]

Isn't that what I recommended - except I suggested creating a ToC?

[Former Member]

PS: ideal solution would be a TP command option to export a transport request for existing objects with the option to convert it to a deletion transport. I am also fine that this is only command line enabled.

That would solve my problem without having to create a system copy and manually delete the object hierarchy or hobble the TADIR entries (even if I do that, I am sceptic about the import success as the sequence of the object deletions in the target which has much more than just TADIR entries is also important.

That is also what makes manual deletion of thousands of objects quite painstaking. You have to start at the top of everything in the way objects are called and work your way down. Deleting a package is an art form in the end.

Currently I am playing with the idea of a WB transport with table entries for TADIR only, and then follow the procedure of exporting a WB transport of the same list. But for that I need a "naked" system. I have one. But what do folks do if they dont have one?

Cheers,

Julius

[Former Member]

julius.vondembussche wrote:

Currently I am playing with the idea of a WB transport with table entries for TADIR only, and then follow the procedure of exporting a WB transport of the same list. But for that I need a "naked" system. I have one. But what do folks do if they dont have one?

Cheers,
Julius

Also does not work. Message TR731. But perhaps it works on a 7.00 or earlier system as this message is relatively new?

The plot thickens... 🙂 But still not a normal procedure...

Cheers,

Julius

[JPReyes]

Hi Julius,

What are you up to now??.. 😄

The only way I can see this happening is by building a parallel landscape so you can run the deletion and create the transports then applying that transport manually on your landscape without touching DEV.

This as I'm sure you know a very unorthodox way of doing things and does have its own drawbacks... you need to make sure your "deletion" is not upsetting anything else to start with.

Juan

[Former Member]

Hmmm... so this is what it feels like for the home team to be 0:4 goals down at half time..

[JPReyes]

The procedure is simple... add all your objects to the transport -> delete the objects -> release the transport (as far as I remember)

You could take a backup of your DEV system, create the transport of deletions, transport it across and then restore your DEV system.

Regards, Juan

[Former Member]

Problem 1: there are thousands of objects.

Problem 2: the tables have master and application data in them in the dev system which I cannot loose.

Problem 3: I don't want to actually delete them in the source dev system - though a sandbox could be organized I guess.

Cheers,

Julius

[Reagan]

Create a copy of the DEV system (out of the landscape).

Make the changes there and include them in the TR.

Once you have all the changes recorded in the TR then you can move the TR to the target system.

if you don't want to create a new system then take an offline backup of the DEV system and then do the changes in the DEV system, once done restore the database.

This is a boring task but not difficult. No pain no gain

Cheers

RB

[Reagan]

There is no official way as far as I know.

If this is really required then I would do it on a sandbox system and then get the TR moved to the next system.

There is no standard procedure. You need to play safe here.

Regards

RB

[Former Member]

Thanks for confirming that there is no official way. I still keep my hopes up that a ninja will show up and provide one despite chances looking bleak.. 

As there are about 2000 objects of all sorts in the package and actually deleting them in the source system would be a total disaster, I have to find some way to do it which is far away from the original source system. Hence the ideas that somehow tricking r3trans into converting a normal transport into a deletion transport would be the next best option to something which is not official or a menu option in STMS...

I will keep it open for a while still.

Thanks again!

Julius

[fredrik_borlie]

I am afraid there is no official way to do it. It is not intended to remove options without deleting them from development system.

But, if I was phased with the issue I would have looked at two options.

1. Assuming you have transported the objects to production you should be able to create a deletion transport and send that through the landscape. Then simply re-import using the one that imported the objects in production into development again. Drawback. Versioning of objects is lost since you overwrite them during import. .

2. I would create the deletion transport in the test system and send it to production.

Drawback. Risk of getting inconsistencies in landscape.

You should also consider the restore option. But if you are looking on a production system that is not always possible.

Another way that is also used is to "rollback" using the previous transport. That does not remove the object, it only restores the previous version.

Regards and good luck!

/fredrik