Skip to Content

Has this happened to someone you know: in their eagerness to start development for a repair or change, they forgot to confirm if the development version being worked upon was in sync with production? Thus promoting unintended code to production. The consequences of that are never pretty!

Let’s consider a simplified scenario (derived from real life 😛 ): Person A makes changes to a program, activates it and deletes his transport. Subsequently person B starts a new set of changes on the active version in development.  Person B tests and moves his/her changes to production and has to deal with the not so nice consequences of also moving person A’s changes. (Now, there are those who may argue correctly that there is a process gap, improper quality control and human error but leave that aside for now. Also, I am strong believer in automation to overcome the human element).

Here’s how you prevent this from happening again: all it takes is a well placed exit enhanced with the code below. The code compares the local versions with the version stored in the production system. It takes the latest development version and works backwards till it finds a version that matches production. As an example, for the following program –

Capture.PNG

Check if active version matches production

if not

Check if modif  version matches production

if not

Check if version 4 matches production

if not

Check if version 3 matches production….and so on, resulting in

Untitled.png

The code is attached.

Right now the code works for the ABAP Editor (SE38): Relevant Enhancement Spot: SEUED001, Component: EXIT_SAPLS38E_001. The exit is triggered when the editor is invoked, so this works automatically for all programs you try to edit.

Finally, I believe it should be trivial to adapt this code to Class Editor or Print workbench or whatever else you can think of. That and the task of identifying the proper exits are left as an exercise for the reader 😀 .  It would be great if  a common exit could be found for all objects.

Please add your improvements and let know if useful. One known limitation is this gets called multiple times if you are jumping around in the edit mode and the object is not locked in any transport. There are ways around it but I haven’t gotten around to adding the relevant code.

TIP: For SE37, try SEU00004 -> EXIT_SAPMS38L_001

P.S: I take a couple of shortcuts in my code, by hardcoding the production system and its RFC path. I am sure one can figure out how to make that part generic by using the SLD. However since the definition is done once per system, the tradeoff is acceptable to me.


To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. Matthew Billingham

    A comment on your code. Creating a processing block with DO 1 TIMES is, in my view, not good practice. It indicates that you should be modularising the code.

    So, anyone implementing this, either put into a function module, or make a proper OO version.

    But the idea seems sound!

    (0) 
    1. sameer p Post author

      I agree, modularizing should have been the way to go and the code could be reused. I took the easy way out because I was developing it ‘for myself‘ at that time 🙂 .

      (0) 
  2. Jan Hempel

    Hi,

    I think applying changes to a workbench object and then deleting the transport (or just releasing it without transporting it) is a bad idea in the first place.

    As long as developers know that it is an absolute no-go to leave changed objects without lock entry, the described problems should not occur anyway.

    Regards

    Jan

    (0) 
    1. Matthew Billingham

      On the other hand what should not occur, happens far more often that it.. er… should!

      Developers do silly things, especially as the median experience for developers gets lower and lower.

      (0) 
    1. sameer p Post author

      Hi Shai,

      I specifically ignored  the whys because that could turn into an endless discussion. All I’ll say is that I have seen it happen.

      Now, there are those who may argue correctly that there is a process gap, improper quality control and human error but leave that aside for now.

      (0) 
      1. Shai Sinai

        Well, if you ask me, such case isn’t human error, but a case of unskilled developer who doesn’t know what he is doing.

        Such case should NEVER happen because deletion of changed object should be forbidden.

        P.S.

        More important: I don’t see how a developer who isn’t aware of the consequences of CR manipulation will understand the meaning of the suggested info message.

        (0) 
        1. Matt Fraser

          Nevertheless, it happens. Sometimes it even happens with experienced developers, when they’re in a hurry, lose track of what’s been modified, are context-switching between multiple simultaneous projects, etc. We actually don’t allow developers to delete transports at my shop, for much this reason, but the result has been that we have dozens of old, unreleased transports, all titled “test” or “do not transport,” etc, and it seems to be an impossible task to get the responsible developers to go back and clean those up. In some cases, the responsible developers were consultants who are long gone. Given that our shop is short on developers and long on tasks, no one is seeing the business value-add to it except the basis team.

          So, periodically the basis team is called upon to do manually much what Sameer’s code does automatically.

          (0) 
          1. Shai Sinai

            Cannot argue with that:

            If it happens, than it happens.

            BTW, I didn’t say you should never delete any object from CR, but only you should never delete changed object from CR.

            In case of obsolete changes, you should first retrieve latest version and then eliminate the CR.

            Moreover, even if you don’t delete the CR, in such case you may be able see automatically that the object is already assigned to other CR.

            (0) 
  3. Matt Fraser

    Sameer, I’m sure you’ve noticed, and it’s probably too late to change it now, but the URL for this post is “placeholder-before-publish.” Oops! I don’t want that to distract from the great idea you’re promoting here, though.

    (0) 
    1. sameer p Post author

      I am not sure if I can change the URL right now, maybe a moderator or someone else can tell me how.

      However I will make sure that the next time I post, I use a appropriate title while drafting as the URL seems to be derived from the original title before publishing.

      (0) 

Leave a Reply