This question was closed Mar 15, 2017 at 02:22 PM by Bärbel Winkler for the following reason: The thread provided valuable feedback for our discussions. But it'll take some time to find out what the best answer for us will be.

What are best practices to allow multiple developers to change the SAPMV45A enhancement?

Mar 02, 2017 at 07:34 AM|847 Views

Hi All,

I'm aware that this question has already been asked more than once but none of the responses I found seem to be a good fit for our particular (?) situation as far as I can tell:

we are on SAP_BASIS 740/SP11 with EHP 7 (but haven't activated (m)any of them)

(almost) all of the custom-code for SAPMV45A is in one big enhancement

special logic has been added over the years for various org-units, countries or other groupings of which we have a lot (>50)

many changes are surrounded by an additional check to see if the code-snippet is currently active or not (done via a select on a Z-table which contains relevant entries)

the code and comments in the enhancement totals >30,000 lines

most of the code is kept right within the enhancement includes (MV45FZ*) with some special cases also having their own country-specific include (e.g.
ZRU1_MOVE_FIELD_TO_VBAK)

the enhancement needs to be changed often as new requirements come in, be it for longer term projects or quick fixes due to other requests (we sometimes have 2 to 3 changes per week)

several developers routinely work on these changes at any given time

In order to avoid tripping over each other, we've been documenting currently happening and upcoming changes in a collaborative workspace, so that the developers involved with this enhancement are aware of what's happening and don't overtake each others' changes.

As more concurrently running projects are currently being planned, we are trying to find a way to make parallel development possible, ideally without losing the one advantage we have with just having "everything" in one enhancement: comparing versions for just one entity via SE84 and version compare.

While searching here and elsewhere, I saw suggestions for both using dedicated Z-includes as well as BADI-implementations, but I'm not really sure what's the best approach, esp. to ease this in as a major rework of what we already have in the enhancement is not planned.

What I'm especially interested in is to learn about the respective pros and cons of the different options.

Related questions

6 Answers

BADI is much better approach than Z includes. It decouples the coding from SAPMV45A. It also allows you to properly modularise your code. This modularisation alone will enable multiple developers to work without interfering with each other - if combined with multiple BADI instances, it gets even easier.

While being able to use version management on just one entity is nice, the Total Cost of Ownership of a single program 30000+ lines long almost certainly outweighs the cost of having to compare individual methods.

Includes should not be used, since a single syntax error in one include kills the entire program. Includes are not a modularisation technique. Includes are solely for managing source code.

Add comment

in fact that you have a lot of developments and changes over the time, I suggest to use BADI with filters in combination with Switch Framework (SFW5).

What is the benefit ?

1.

Values of an filter can be maintained by a good keyuser . So if you have code running depending on organisational data e.g. sales organisation, and you want to add oder change this, you only need to maintain the filter values --- No Programm changes neede, no Z-Tables needed ---

2.

Code at Userexits with a lot of developments, will be much more easier to maintain.

3.

By using the Switch-Framework you can use a standard tool for activation/deactivation of your developments (useful at system upgrades for example to test sap standard and after that, the different developments you have made.

4.

A very big point is : If you organize you development projects a little bit at SWF, you see at ONE look, that there are dependencies to other developments. For example : You will code something what gives you values for use in another module, where another developer does an development. In Switch-Framework you define a hierarchie if you want. All depending developments can be simply seen. And more less you get a warning if you try to deactivate a switch, witch is base for another part. So you will never deactive something which is part of an later development. Doesn't matter at days, months or years.

-----

-Extensions will be switchable

-Dependencies will be shown

-No big thinkover about the structure of any Z-Tables to stear the development

- Less of research time

- Less of coding time

- Standard functionality - let SAP do the job for you.

- you can integrate it step by step to remove an older not really working solution

----

I had the same issue, with an existing z-table-concept and a lot of changes, and exits, and all should be switchable. A horror to debug, and to see through for new developers at this system.

Add comment

I was also searching for best approach. And custom Z* BADI is good one.

Only problem with these USEREXIT_SAVE_DOCUMENT_PREPARE etc blocks is, that there is no clearly stated interface. I mean importing, exporting, changing parameters :-( But you will collect them all (used ones) if you do a refactoring of current code.

Add comment

I would echo what Matt has said in that the situation will not change if you don't explore alternatives that give way to a new approach. We have utilized Z BADIs in a handful of locations where it has helped immensely and although it takes a little time up front it will help on the back end. The one other alternative that I would mention is BRF Plus (FDT_WORKBENCH) which can be called via the ABAP runtime to execute rules based on business needs. I have not had a chance to use it yet because we are not on a high enough BASIS release but we have implemented a larger custom application using the precursor in our current environment. Here is a link to a PDF with some pages included from an SAP Press book on the subject: BRF Plus