ABAP Game – Spot the Bug
This fine day I have been talking to the inventor of abapGit and discussing how to fix bugs on an open source project.
With your own Z code it is of course really easy to fix problems – with open source ABAP code it should be almost as easy.
But what about standard SAP code?
Now as we know SAP function modules are usually flagged as “not released” and none of us horrible customer organisations should ever use them. Luckily in the entire history of the universe not one SAP customer ever has used an unreleased function module in their Z code.
But let us just say they did – and found a bug in that standard code – and tried to tell SAP via OSS.
I think you can guess what happens. This is the reason the extended program check does not work on standard SAP code.
As an SAP mentor I am supposed to have a “Point of View” and my point of view is thus – if there is a bug in any code anywhere – and it is brought to your attention – with instructions on how to fix it – then you should fix it. Even if there were no instructions you should still fix it because if you are a professional programmer how can you let bugs remain once you know they exist in your code?
Let the game commence
In my organisation one of the developers brought to the attention of SAP a bug in unreleased function module SHP_DELIVERY_READ_SINGLE.
I understand that according to the rules no-one outside SAP should be using this, but what if someone inside SAP wanted to use it? It has a serious bug.
All we want to do is fix an error in the code, and the fix is really simple as well. Naturally we were knocked back at every turn – it is far more important to spend hours or days to tell us we are breaking the rules by using such a function module rather than spending the two minutes to fix the code.
So the game is thus – can the panel work out the bugs (there are more than one) in function SHP_DELIVERY_READ_SINGLE routine APPEND_DELIVERY?
It is highly unlikely SAP will ever fix this but that is not the point – the point is finding bugs n code is a fun thing in and of itself.
Cheersy Cheers
Paul
Hi Paul,
What release ? What is the behaviour you are seeing ? How can we replicate the behaviour ?
Sorry to go all OSS on you, but apart from the fun of fixing the problem, it would be nice to know if any of my customers are affected 🙂
hth
The bug is still there as of 7.50 (i.e. ECC 6.0 EHP8)
Of course no-one should be using unreleased function modules (he he he).
The principle is just that no bug should be left unfixed. This is quite a complicated function module sos someone must have put a lot of effort into it so it is a shame that something simple stops it working properly.
It is OK if you call the function module once or even a dozen times. However calling it in a loop causes a short dump due to a memory leak.
I don;t want to give the answer and thus spoil the fun but I will give a clue. In routine APPEND_DELIVERY how does LT_VBELN get filled?
same issue for all 3 variables? this is something that is usually caught in code inspector
I strongly suspect some developers inside SAP do not use the code inspector.
But yes the code inspector would complain that those variables never get written to, hence they are always blank.
This means in the loop at the end the entire contents of one internal table gets appended to the buffer - every single time the function module is called. So you get more and more duplicate entries in the buffer table as time goes on until the whole thing explodes.
Hi Paul,
You might assume that some developers earlier never used EPC or SCI/ATC but right now usaully there are pretty stringent quality gates and its a mandate to use these for any successful delivery ....may be it was some very old code or may be it was not inteneded to be used regularly....
These are my two cents....
Regards.
"Not intended"...
If you write code, it is you duty to ensure that it is as idiot proof. If you ever think to yourself "well, it'll be ok, no one will use it like that", then quickly whack yourself on the head, tell yourself not to be so lazy, and fix it!
😉
I agree with you Matthew 🙂 and that is why I mentioned that it generally does not happen now.... By this, I am not justifying the developer's assumption that such development is acceptable but also due to business reasons it might not be feasible to rectify everything and everywhere.
HA! I personally have never - oh lets be serious - of course I've used unreleased function modules. If I find a bug - the answer is usually, from SAP. "You shouldn't be using that FM". So what do I have to do? Find where it is used in SAP code and hope I can create an issue with it. And that doesn't happen often. So sadly, I give up.
I now, do not try to use OSS to fix FM that I use in custom code. (Unreleased ones) I do thank some very smart thinkers that we now have enhancement points that we can use. IF that fails, of course I use modify. Yuck. But now if someone fixes it my code will be fixed.
Oh I have another good one that will make OSS folks not so happy. How about never finding a BADI, Enhancement point , or user exit. I'm sure no one would use field symbols to solve the issue. No one. Then at some future point forget they used them when an SAP program fails. Then they use OSS, and it takes OSS a day or two to find out it is a customer issue. Being the devil here. There might just be a reason they ask for all your custom changes to be shut off.
Oh well, many of us love to dislike OSS at different times in our career. And yes, I have worked around an issue before. In my world (you remember with rainbows and unicorns - and those sneaky dragons) all the code would be perfect and... Opps there goes my job. All the code would be perfect and we would always be working on fun new projects. 🙂
But then again - remember - I never use unreleased function modules.
PREACH!!! Paul, I don't know if it is a kiss or a curse that I have worked with SAP now since about 1996......and during that time, yes, I have found PLENTY of bugs for SAP that slipped through the cracks.
My experiences have been mixed. I won't get off on the side discussion and downward spiral of OSS support over the years. I will say that in EVERY case, I provided VERY detailed documentation of WHAT the bug was, WHERE it was, WHY it failed, and HOW to fix it.
For instance, SAP had code that was checking something like "is THIS_FIELD = 2" however, somewhere along the line THIS_FIELD was changed to be a 2 char field and no longer an integer....so any values in THIS_FIELD that could not convert/cast to integer would blow that check up). Seemed a straightforward and easy fix to me..."is THIS_FIELD = '02'"....ohhhh but that's what I get for thinking!
In almost all cases, the follow up would involved the usual round of "sir, thanks for the information....we are attempting to duplicate"....then 2 weeks later "what was the problem again?"....then "we can not duplicate this...THIS_FIELD has values or '00' through '10' and no problem" to which I would tell them try a customer value like Z2.....then another 2 weeks "wait, we now see the problem"....then another 2 weeks "what was the problem again?".....then "I am turning this over to someone else".....ugggg......so in some cases, we never heard back again.....but then magically an OSS note/fix would appear a few weeks later with almost word for word from my documentation and my fix....and guess what? We would have never known the fix was even there if not checking OSS for other things. So in ALL cases, I just wait for the next patch/update where the "fix" is just included and move on.
Its almost as if SAP never wants to admit they ship code with bugs....they are all due to customer customization or unforeseen configuration setting combinations. =)
That's similar to what I've encountered a couple of times. I always make it a point to add a document with relevant screenshots of what happens and why I think it does (and how it could potentially be fixed if I have an idea). If possible, I add the information how the issue can be reproduced and information from debugging. Often, the issue is not time-critical so I raise the message with the appropriate priority of "medium" but nobody seems to look at an OSS-message with that priority for several weeks and once somebody does, the first quesiton often is "how to reproduce it" even though I had added the information or that it's not reproducible and why that's the case. At least I usually get feedback with a solution, sometimes in the form of an OSS-note to apply.
One case from a couple of years ago worked better, though. We had noticed a kind of "sleeper problem" in the interface between ERP and APO a couple of months after we had done an upgrade to EHP6 (IIRC). It took me about 2 weeks of on-and-off debugging to find what was causing this: one single character field used as a parameter for APO losing it's content of "A" somewhere along the long processing chain. The underlying reason turned out to be some code missing in SAP's logic which we had received during the upgrade where the logic was there for one type of processing but not for a comparable second type. All that was needed to fix that was to copy and paste said code to the second process.
Once I had all the information properly documented I raised an OSS-message and within a couple of days SAP provided an OSS-Note which eliminated the issue. Somebody from SAP even called to say "Thanks" for alerting them to the bug (which was a first for me and came quite out of the blue).
Most of the bugs in standard SAP code I have reported over the years were left or even still are unfixed. My favorite reason for SAP not to fix their broken code over the years has been "we are afraid to change it because it is used all over the system". More Z code is your answer.
I was on one project where an unreleased function module in APO was used. After an upgrade, it had gone. What was particularly notable about this case is that it was a SAP employee who had made the decision to use the FM.
Hehehe. Yeah, with the upgrade of Solution Manager to 7.2 we had lots of issues because we were using some SAP function modules that SAP simply decided to delete. Or even worse, comment out and throw message type 'E'. You can look for example at function module /TMWFLOW/GET_RFC_DEST... Good fun!
I have worked for a major aeronautics manufacturer in Europe (that kind of gives it away, doesn't it?) and was supporting their CRM system. I had a task to investigate why it was not possible to upload .xlsx files (or any file with a 4 char extension).
After some debugging I found the part where the extension was stored in a variable with length 3... I found nothing on OSS notes at the time... and asked the IT director: "I know where the bug is. It would take 5 minutes for me to solve it. Shall I open an OSS message for this?" - "No, please just fix it and document it well. If we open an OSS message it will take months until it's fixed, if it's ever fixed."
So not even SAP Mentor-superpowers can make SAP fix such an error?
That’s kind of disillusioning.
So what's left is just x-ray-vision and the ability to fly, right? 😉
best
Joachim
...oh and of course doing real-life TDD!