Removing customer implementation of exit function group: traces still remain in the system

[tudor_teoteoi]

I've done a test implementation of an SMOD project with some function exits (in the same function group, if this has any importance).

After deleting the CMOD project and the function exit includes from transactions CMOD/SE80, I noticed that:

- TADIR still contained the entries for the ZX includes, even though they were created in the $TMP package (you'd need to release the transport for non-temporary objects to see the TADIR entries dissapear);

- TADIR contains an FUGX entry in my list of temporary objects (R3TR FUGX Function Group with Customer Include: Customer Part); I moved that into a non-temporary package, creating a transport entry and double clicked that entry; it does navigate to the actual function group, so the object actually exists, not just the TADIR entry.

Questions that I have:

1) Do I need to proceed in a certain order when deleting these ZX includes (e.g. first CMOD project, then the includes)? Tried multiple options, and I did randomly succeed in deleting one include out of 4.

2) Is there any way to delete the customer part only of a function group with customer include?

[Jelena]

It's been a while since I've done those and this is just from the top of my head. I believe the removal order you stated is correct (CMOD stuff, then includes themselves). You also need to de-activate user exits before removing them and run a test to make sure all is well.

I would not worry about TADIR entries for local objects, as long as the user exits are not active and there are no syntax errors (due to missing includes or FMs) in the main program. The next system copy or upgrade, which will happen eventually in DEV system, will take care of any potential clean-up of odd artifacts.

There are several old questions on SCN about this, I'd suggest to go through them as they're all still valid. Google -> CMOD remove site:sap.com

P.S. I'm sure you already realize this but it's best to experiment in the Sandbox systems as clean-up can be tough sometimes.

[tudor_teoteoi]

Hello Jelena,

Thanks for taking your time to reply to this.

I wasn't very successful in uncovering questions about this exact problem.

In the end, I decided to use transaction STDR to identifying all orphaned TADIR entries (for those who may want to try this, it took 4 1/2 hours of running in the background, so plan head).

I could then delete my ZX-include entries from TADIR using this transaction (you can also use SE16N, but it gives me a bit of confidence that I'm doing it the right way when using an official transaction).

Not the same can be said about the FUGX object, which was not identified as orphaned. All these FUGX objects form pairs with FUGS, that build the exit function group together: customer part + SAP part.
Although the includes that are specific to each area clearly distinguishable - customer includes start with ZX -, there is no way to handle the two parts separately via transactions like SE80 to ask for instance the full deletion of the customer part.

I am indeed in a sandbox system; I guess I can live with this fake TADIR entry until the next system refresh.

Best Regards,

Tudor