Systemwide cleaning planned - Feedback?

[openPhiL]

Hi Jörg-Michael,

we are in Progress of an ECC to S4Hana Transformation in a selective Data Transfer Setup.

We are now in the phase of building a new development system and plan to use the abap-cleaner on all the existing code there. Reasons why we clean shouldn't need explaining :) The time seems right to do that now at this stage, as we have a new system with our old coding, without anybody working on anything, no open transports etc. And "everything" is going to be tested before go live.

We are planning to download all the code on a desktop client using abapgit (some bigger junks it will be), then we clean using your cli tool, before pushing it all back. We talk about ~10mio lines of code.

Our Profile is planned to be https://github.com/endresshauser-infoserve/abap-cleaner-profile

So I wanted to ask.. Do you have knowledge of others who tried the same thing? Any suggestions, recommendations, warnings, insights?

best regards PhiL

[jmgrassau]

Hi PhiL,

really sorry for responding only now. To me, this sounds like the perfect point in time for this! Sorry that it does require some extra efforts (download -> cli -> upload) due to the fact that ABAP cleaner is not located in the backend (unlike Code pal, for instance). However, I'm sure it is nevertheless worth it! And wow, 10 mio. lines of code is a lot …

Unfortunately, I am not yet aware of others who tried the same thing – maybe @stockbal? But if you try, please share your experience and any issues found! (I think you are already doing this ;-)

Kind regards, Jörg-Michael

[openPhiL]

Hi Jörg-Michael, let me give you a short update. So we used ABAPGit to commit all our code to a local gitlab repository. We split the code in to some major packages, so not everything is to be processed/pushed/pulled at once. But still, that is a task that takes longer then one coffee.

Then we downloaded that to the local PC using vscode and regular git. We created a fresh branch there, used the CLI command

.\abap-cleanerc.exe --sourcedir "C:\tmp\Z1" --profile "C:\tmp\recommendedPoC.cfj" --release "750" --overwrite --stats --usedrules --recursive >output.txt

Which took only a couple of minutes.

Yes, there were edge cases that didn't work immediately, we reported here and you already fixed them :)

And then, the upload, back into SAP.. this is where we failed so far. Yes, technically, ABAPGit was able to detect the deltas and pulled the changes into the system. (with some hiccups, but manageable). But not only the sourcecode. We detected changes in TADIR, like internal status field and the date of creation, it changed languages of function modules, it updated screens and short texts, there were changed objects that we have never seen before. That drew us to the conclusion that we will not use ABAPGit to "update" our full repository in our productive development system - the risk of adding more errors to investigate into our current project is too big.

But, we don't want to stop here. The next approach is "similar". As we have a sandbox that has a lot of nice code now, we just need to find a way to extract the sourcecode from that system and import it into another system. We plan on doing this using regular CTS. So next step is to create a small report that creates a dedicated new transport that only contains sourcecode from all the objects of that abapgit-transport. so LIMU REPS instead of R3TR PROG for example. This approach allows us to have more control of the actual change, which makes us feel better.

An additional advantage of this CTS approach is that we can do that at a later point in time in our migration. It still needs to happen before we start testing, but we can do that even if locking changes have been made, where transports have been created etc. We need a short lock of the dev system, pull from there, clean locally, import into sandbox, create transport with clean sourcecode and export/import that back into the source system.

So that is the idea, of course we keep this thread updated and are happy for every advice anybody might want to add :) best regards PhiL

[fabianlupa]

But not only the sourcecode. We detected changes in TADIR, like internal status field and the date of creation, it changed languages of function modules, it updated screens and short texts, there were changed objects that we have never seen before. That drew us to the conclusion that we will not use ABAPGit to "update" our full repository in our productive development system - the risk of adding more errors to investigate into our current project is too big.

Hi @openPhiL,

would be interesting to know what happened here exactly. abapGit of course will not only update the source code part of the objects but also metadata / related database tables. Regarding languages, the repository has its own main language and does not account for subpackages / objects with different languages in the repo, that might be where that language change came from. Regarding screens: The dynpro fields / screen elements probably have relations to objects in the ABAP Dictionary and those relations maybe were "updated", i. e. pulling updated data element texts or field lengths onto the screens. Which should also happen normally if you do a mass activation run or manually activate the screens. Regarding creation date: Some object types probably do not have an API to update them or because of dependencies in activation abapGit opts instead for deletion and recreation of the object. That might also set some internal status flags in TADIR differently than before. But also of course you seemingly used abapGit on a lot of objects, there may very well be some edge cases that would need to be fixed in abapGit.

I am not sure you'll catch all the source code parts with LIMU objects. You could however easily check by comparing the packages / repos in dev with the cleaned state in gitlab using abapGit itself, even if you do not intend to use the pull functionality.