What is best way of changing the ABAP standard code

Question

I have almost 4 months learning/working in SAP. I've done several reports and enhancements all along this time but recently I began to work in a requirement which is related to Mobile Data Entry or RF and it basically consists to add the EAN and some other data to the dynpro 2502.

I made a copy of the dynpro 2502 in program SAPLLMOB into SAPLXLRF 9502, related the user exit MWMRF502 and programmed the basic functionality of it but it is not working as I expected because this exit is very limited and it only lets me import and export a small group of data and is difficult to perform exactly as the standard.

I've been searching all over internet and a lot of people make their own implementations and other just simply change the standard. I don't know how to make my own implementation cause I don't understand all the process within and the alternative of changing the standard code would be better for performance and time spent in development but as I quoted I would have to change the standard code and that's something I would like to do only if there's no other option.

But the question is ¿Is it OK to change the standard? ¿How often is the the standard code changed in SAP implementations? ¿What would be the better alternative?

Thanks in advance.

Answer 1

[TL;DR] Implement user exits, never do a copy of standard except if extremely simple, do modifications of standard if not too complex, else create from scratch. Do database changes only via BAPI or Batch Input.

This answer is based on my experience in the software SAP R/3, SAP ERP, SAP ECC and S/4HANA (not considering the Public Cloud and Clean Core approaches).

My opinion relies on considerations discussed by SAP in the following notes (the access is limited to the clients with a maintenance contract):

• 213751 - Programs: Copying versus modification.
  • Although SAP discourage modifications, they don't either recommend copies.
  • First of all, prefer implementing existing user exits.
  • If user exits are not sufficient:
    • Copies can be done if the program is very simple and doesn't involve database changes, or if VERY extensive changes are to be made, but in that case it's usually better to create a program from scratch and use BAPIs, CALL TRANSACTION USING or batch input to reduce the risk of data inconsistencies.
    • In all other cases, modifications are recommended.
    • During a software upgrade (SPAU), the modifications made on the standard can be automatically or semi-automatically reapplied on upgrade, while it's fully manual for a program copy.
• 7 - Error caused by customer modification/development
  • It says that if the problem is due to a modification of standard, it's not guaranteed by the maintenance contract (license), but the SAP Consulting services may help.
• 83020 - What is Support – What is Consulting: On Premise Solutions
  • It gives a detailed list of topics which are supported by the maintenance contract.

The big advantage of modifications over copies is that they are automatically detected during an upgrade and there's a tool to merge the modifications, while copies are completely ignored and there is no tool to detect them.

The modification key is not an obstacle to do a modification of standard:

• Before S/4HANA, a modification key is to be requested, but it's very simple to get one and it's never refused.
• Since S/4HANA, the clients can change the standard without a modification key.

Of course, user exits should be preferred over copies and modifications as far as possible.

The user exits are usually documented in the transaction code SPRO.

If in doubt, the "major" user exit technologies may also be identified by developers during the execution of the program to be enhanced:

• Customer Exits: add a Statement Breakpoint on CALL CUSTOMER-FUNCTION.
• BAdI (SE18 and SE19)
  • Classic BAdIs: add a Breakpoint at the start of the method CL_EXITHANDLER=>GET_INSTANCE.
  • New BAdIs: add a Statement Breakpoint on GET BADI and CALL BADI.
• Business Transaction Event (FIBF, BERE and BERP): add a Breakpoint at the start of the function modules BF_FUNCTIONS_FIND and PC_FUNCTION_FIND.

Note that the debugger may not stop by default at breakpoints inside background processes, Update Tasks, etc. Workarounds: run background processes in foreground (search SM37 and JDBG), activate the Update Debug setting. Some debug workarounds are very specific and can't be all discussed here.

The Enhancement Framework is to be considered as a modification of standard because the clients may change the standard behavior in an uncontrolled way (i.e. which may lead to database inconsistencies). The user exits are less prone to this type of consequence.

Answer 2

Your options are, from most to least desirable:

1. Check the documentation of the application on help.sap.com for possible extensibility scenarios. There are many ways how SAP intends for you to customize their applications through various kinds of event architectures. Unfortunately any attempts by the various departments at SAP to agree on one event architecture and then stick to it failed. So you have user exits, BTEs, FQEVENTS, BAdIs, explicit enhancement spots and many more. If you want to know what's used by the application you need to change, RTM.
2. Use an implicit enhancement spot. Enhancements are a great way to modify standard software in ways SAP did not anticipate, because they are easy to disable and usually pretty stable during upgrades (use the transaction SPAU_ENH after an upgrade to confirm that your enhancements still make sense in the new version of the program). You will find implicit enhancement spots at the beginning and end of every include and every kind of subroutine, which allows you to inject arbitrary ABAP code in these locations.
3. But sometimes there just is no implicit enhancement spot where you need it to be. In that case you can copy the whole program into the customer-namespace and modify it. This gives you the freedom to do whatever you want with the program while still retaining the original program as a possible fall-back. It is usually a good idea to use as many components from the original program as possible, by including its includes or calling FORMs from the original program via PERFORM formname IN PROGRAM originalprogram. The main problem with this method is that after a new release, your program might no longer behave as expected. You will have to look at the new version of the program and see if there are any changes you need to port to your version. And there is nothing in the SAP standard that assists you with this maintenance task. So you are responsible to keep a list of all your copies of standard programs.
4. Just modify the program directly. But this is really a last-resort option for programs that are too complex to copy into the customer-namespace. The problem with this is that it means SAP will no longer offer you support for that program. If you post a ticket about that program on launchpad.support.sap.com, and they find out you modified the program, they will assume it's your own fault and close the ticket. But fortunately, when you upgrade your system, you have the transaction SPAU that will help you to merge your changes with the new versions of the modified SAP programs.

Answer 3

You are asking the right sort of questions and it is good that you are not just plowing ahead without thinking about the consequences of what you are doing. Keep researching!

As far as changing the SAP standard goes, you generally do not want to copy an object to change it. For screens SAP quite often creates a user-exit with a sub-screen that can be modified by the customer. For Web-Dynpro you can use enhancement points and/or bADI's to extend the functionality.

Try to look for one of the following:

• A SAP BAdI in the area that you want to change (transaction SE18),
• a user-exit allowing you to change the necessary screen(s) (transaction SMOD),
• explicit enhancement points within the functionality,
• one of the implicit enhancement points in functionality

There are a lot of documentation on sdn.sap.com as well as within the SAP help regarding the topics above.

If none of are available, you may have no other choice but to modify (repair) the SAP standard objects. In order to be able to change the SAP standard you need to register the object(s) that you have to change on SAP OSS and get a repair key that the system needs to allow you to make changes. Always ensure that the SAP Modification Assistant is switched on when making changes, this will make your life a lot easier when you patch or upgrade your system.

If at all possible try to find an experienced ABAP programmer to help you with this.

Also see this question regarding changing SAP standard code:

Edit: Thomas Weiss on SDN has a helpful blog series on the enhancement and switch framework.

Answer 4

Always make sure that there's absolutely no other way to implement the functionality you need. If you're sure about that, then either write your own implementation from scratch, or simply change SAP's code. Just don't copy SAP's programs to the customer namespace, because I can guarantee you that that'll turn into a maintenance nightmare. You'll have to decide yourself whether the size of the change is worth the time building your own implementation, or changing SAP's.

If you decide to change SAP's code, keep in mind that all changes will pop up for review when the system is upgraded, which will take time to evaluate and adjust to the new SAP code.