Skip to Content

There is an impressive dialog in scene 4 of Bertold Brecht’s Drama “Life of Galileo” where the court scholars refuse to use Galileo’s telescope as it is useless to observe things that cannot exist because they would contradict Aristoteles and the Absolute Truth of the Church (“… if your tube shows something that cannot exist it must be a rather unreliable tube.).
I experienced such a Jesuitical sophistry last week with a customer message.

Java Gui and Happines

At our companies plants we have many machine tools controlled by Linux systems. As we work highly cost optimized we use these systems and also the SAP Java Gui for the required SAP QM transactions. To better support the colleagues I use the Java Gui too for most of my SAP work, finding bugs and helping to improve it.

So since I have been using the Java Gui on Linux with the Solution Manager for the past seven years I seldom had problems.
OK, the SolMan graphics don’t work, but you get a polite message about this. Sometimes the html display of the DSWP transaction is messed up, but after some service packs it works again.
Sometimes while coding I am sad that the new ABAP editor is not ported as Java Bean (why not?) and I am angry about the missing graphical screenpainter. Sometimes I shake my head because the SOLMAN_WORKCENTER’s login dialog is broken (which would be very easy to fix …), but it works great when opened directly in firefox. Almost all other transactions such as SOLAR01, SOLAR02, STWB_2, and so on, work well.

Dumps are Not Nice

During some tests last week with SOLAR02 “Test Cases” tab I tried to upload a file as a Test Document and suddenly I faced a dump. I opened the post mortem debugger, looked at the coding and understood the problem.

In method CL_SA_DOC_CONT -> IF_SA_DOC_CONT~UPLOAD_DOCUMENT there is at line 186 ff. (ST SP 25) following code which tries to separate the path from the filename:

Here we have a misunderstanding of the SPLIT commands.
It does not behave like a search expression that would be false (or RC > 0) if the search item is not found. Instead if the separator is not found it will copy the whole character string into the destination table.
So the destination table will always have at minimum one row and the expression “if not l_pathix > 0” will always be false, so that the “split at ‘/'” will never be executed, with the sad consequence that in the following code:

l_length_path will finally be 0 and the “write” statement will overwrite l_path_data with spaces, so that the following method will throw the uncaught exception DIRECTORY_SET_CURRENT_FAILED ==> dump.

A simple and transparent case, wouldn’t you say? So did I and opened a customer message with a nice screen shot of the post mortem debugger with all important variables visible and a clear explanation.

A Dump That Cannot Exist!

The first level support was impressed and passed it directly to the development support (wow!). And here it comes:

Dear Customer,

your analysis is completely correct.

As you have slashes and not the Windows backslashes in your file paths,
we suppose that you use SAP GUI for Java.
However, transaction solar02 and Solution Manager in general is not
released for the Java GUI, as you can see in transaction
se93.
The problem now is that a correction would be fairly simple for the
upload method, but as we do not know what else is necessary to enable
this GUI, we will only provide a correction in the context of a general
Java GUI enablement.

Best regards

After having recovered a bit from the shock I answered that I spent a lot of time to present the bug on a silver tablet and that a correction refusal would not be very polite, that the coding relies heavily on peculiarities of MS Windows which might change in the future, that I never asked to activate the little nice check box for the Java Gui in SE93 and finally that a bug is a bug is a bug and should always be fixed.

The dismal answer (“Solution provided” with a link to SAP note 10):

Dear Mr. Escher,

first of all I would like to thank you very much for your elaborated
analysis. Basically you are right, that this piece of code is not 100%
clean.
But: Considering the assumptions where this code is supposed to be
executed (e.g. running within SAP GUI for Windows only) it has been
working correctly, as far as we know, and the potential bug is not
actually a bug in this environment.
Anyway, in general I fully agree that code should be as clean as
possible, and we discussed it again. We came to the conclusion that in
this particular case we would not change the code in the proposed way.
Let me briefly try to explain why:
We simply do not know how far our transactions actually work in a non
Windows environment. So we do not think that it is useful to change one
detail without being able to assure that everything else works fine in
the non-supported environment, where we definitely have known
restrictions.
This would not be serious from our side, in my opinion, and not really
helpful.
I understand if you do not accept our answer, but cannot provide a more
satisfying answer for you.
With kind regards,
Development SAP Solution Manager

Conclusions

Here we have another example that SAP is a very rich company.

Instead of replacing the few lines of code with lines as they can be found in the same method (line 53: if l_test_directory cs ‘\’. l_separator = ‘\’. else. l_separator = ‘/’. endif.), which would have been done by one person in some minutes, they preferred to verbosely dispute about not doing it!
How many people were involved in the discussion about these 5 lines of code?

Imagine you have a car and one day you discover that the cigarette lighter causes a short circuit if you use it. You bring it to the garage to have it fixed, but the automobile mechanic refuses to do his job and fix it, pointing to a “no smoking allowed” sign inside the car. Then he makes a speech that it would not be serious from his side and not really helpful to repair a cigarette lighter in a car that has a smoking ban.

What would Scott Adams‘s humoristic genius make out of this grotesque?

OK, then let’s begin with the Copernican revolution and ask for Java Gui support for the Solution Manager! May be then we will have this little bug fixed 🙂

To report this post you need to login first.

14 Comments

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

  1. Ajay Das
    Sorry to relish in your pain but this was really funny 🙂

    “A short dump that can not exist!” – perfect.

    Something tells me you have used the right tool (this blog) to get it fixed the way you would like to.

    (0) 
  2. Tom Cenens
    Hello Riccardo

    I always love it when I can make something work which is stated to be impossible or when I can detect a bug that no one had seen before.

    What I often see is that troubleshooting guides or notes are not being adjusted after multiple customers bumped into a specific issue.

    The explanation is most of the times “only a few customers had this issue so the documentation is not yet updated”.

    Launching idea’s is great so keep going.

    Kind regards

    Tom

    (0) 
  3. Russ Beinder
    I feel for you and the support guys. It is an obvious fix from your perspective and for them it is an obvious fix also, but one that opens them to the risk that other bad things may happen after they make this one fix since you are running a mode without “official support”. I guess they have reason to be risk adverse.

    To use your cigarette lighter analogy, I could offer a small update.
    – You buy an aftermarket lighter element that is extra big and hot to help you light your stogies.
    – Each time you push it down to heat it up, its size causes a slight deformity to the socket eventually causing the short.
    – You ask the mechanic to make the necessary fixes to accommodate the “unofficial” lighter including a more robust socket and fuse.
    – Unfortunately there is an unanticipated side effect of enabling this new use as the lighter draws more power than the electrical wiring was designed to handle causing your car to burst into flames; you sadly die in the ensuing inferno. The mechanic loses his license, goes to prison, and gets sued by your grieving wife.

    I think your suggestion is the right one for all parties involved, make the unofficial platform an official one. The best part with this is that no one would have to die.

    (0) 
    1. Riccardo Escher Post author
      Because there might be another short dump sleeping you would refuse to repair the already discovered one? We refuse to discover new planets because we might be forced to discover more and more? No, I don’t agree.
      The SAP developers should be happy that there is someone that volunteers in mine sweeping.

      Your example does not fit, because I don’t have changed anything at the car [and believe me, I do changes when required, but at my own risk – for example I am working now on a sort of tunneling under SOLAR01, SOLAR02, STWB_2 and the sequence dialog], because of a “do not smoke” sign I was the first to use the build in lighter of the car and discovered that it fails.

      You say it yourself: it is a platform problem, and the platform is somehow external, something around or under the transactions we use.
      By the way, there is already coding for paths containing ‘/’, but faulty.

      Yes, it’s time that SAP wakes up and breaks out from the MS prison.

      For example I live in Munich, a city which is migrating it’s complete client base to Linux (http://www.muenchen.de/Rathaus/dir/limux/english/147197/), a project that is influencing other cities; incredibly most of my colleagues and my boss and his colleagues and the boss of my boss are using Macs at home (so far); other countries are very suspicious because of the dependencies (and the costs) of a foreign proprietary platform and created own Linux distributions.

      I think that one day this will suddenly switch.

      Is SAP prepared to face these changes?

      I don’t think so. I attended a conference about UI strategy and there was shown only the NWBC (only for Windows) and some html stuff.

      As they have done the mistake not to use cross compilers for the Gui development the Java Gui is the only chance they have up to now. So, why are they so neglecting it?

      (0) 
  4. Tobias Trapp
    Hi Riccardo,

    I made the same experience again and again. Perhaps it has something to do with management by objectives? This could mean that people from support have the objective to avoid any code change – even if they discuss this issue for weeks with a customer. Of course this takes a long time, it makes no sense from a business point of view and doesn’t improve the product – but a management objective is fulfilled.

    I gave up those discussions and now I’m trying my luck with Idea Place. Perhaps this kind of development request would be a better way?

    In my opinion Idea Place and Customer Engagement Initiative is a better way to take influence on the product.

    Best Regards,
    Tobias

    (0) 
    1. Riccardo Escher Post author
      Which objective it might be? I sway between WDNW (Wally does not work) and Dogbert tech support 🙂

      Sure, I am engaged in CEI too, I also have tried Idea Place, but it was incredibly slow and buggy, so I left it.

      But IMHO a short dump is not a nice thing and should be corrected ASAP and both platforms are not fitting into this usage case.

      May be we customers should create a platform where we show how to correct all the bugs SAP refuses to do. We might release support packages too 🙂

      (0) 
      1. Riccardo Escher Post author
        I forgot one thing: You seem to have resigned. Don’t do it.
        I have experienced also very collaborative developers. For example my customer messages in the ChaRM (also Solution Manager development) are always taken in consideration and sometimes they helped to improve the product.
        As SAP has a silos culture it might differ from department to department how they behave when customers demonstrate bugs.

        Max Weber once said that politics is like slowly drilling through thick boards: with patience and passion – a familiar feeling, isn’t it? 🙂

        (0) 
  5. Sean M
    > As we work highly cost optimized we use these systems and also the SAP Java Gui for the required SAP QM transactions. To better support the colleagues I use the Java Gui too for most of my SAP work, finding bugs and helping to improve it.

    Your colleagues are using QM, not SOLAR02 or ABAP editors or any of the other Basis transactions you mentioned. I don’t see how you are supporting your colleagues, or optimizing your company’s costs, with a fruitless pursuit to try to get those transactions to work in the Java GUI.

    (0) 
    1. Riccardo Escher Post author
      Very simple: it’s not so primitive that I have to clone my users to support them. I don’t use QM, I even don’t know which transactions are used in QM and I don’t want to know. But these are back end transactions.

      In common we have the Java Gui and it’s implementation of tree control, of alv grid, drag&drop, text editor, of the set up, fonts, and so on.
      Sometimes I find a little bug in one my transactions that is not related to back end coding but that happens in one of these gui modules.
      And the developers of the Java Gui are very cooperative, I have never experienced problems like mentioned in this blog.
      So what?

      (0) 
  6. Rabanus Diehl
    Although most of what needs to be said is already here, I want to add some comments.

    – The code is certainly errorneous, not only in the sense that it dumps but also that the obvious requirement to work under Unix-like file systems is not met.

    – What astonished me from the development side is why the filename parsing was not delegated to a separate method or even better using a common central method.

    – Digging a bit around I observed that the cl_gui_frontend_services class does not support the splitting of a filename into directory, file and extension. This problem was solved minimum 10 times in my ERP system, mostly with the ability to support both Windows and Unix. A reusable example: cl_swdcl_document_utils

    – The inflexibility of the responsible development group (and I think others could write similar stories for other modules) seems to me caused by a bunch of possible reasons (missing customer perspective, inexperienced developers, internal overregulation, incomplete strategic development goals, … )

    – SAP strategy was always to be flexible concerning the underlying platforms (operating system, database, frontend, … ), so the wish to have the solution manager ready for the Java GUI is legitimite and reasonable for SAP and their customers. I wonder why not every development, which is not explicitly dedicated to a special technology platform is frontend independent.

    – Resigning due to the sometimes Dilbert like dialog situations is comprehensible but the really astonishing thing about the whole blog is that it appeared at SDN in the headlines. That makes me optimistic.

    – With SDN we have a platform to bring in our experiences and improvements and if they appear in such a prominent place it will certainly be not so simple to ignore these voices. It will be interesting to see if something will happen now.

    To answer the initial question: Yes, I am optimistic that we have an influence on SAP’s
    development. So let’s use the potentials of the SDN platform.

    (0) 
  7. Christian Braukmueller
    Hi Riccardo,
    unfortunately things like that happen in many companies (telephone, insurance,..) every day. And luckily we are talking about a product surrounded by a social network that publishes things like that to the front page. That’s how i found it and hopefully others too. 🙂
    I’m pretty sure that there are some people at SAP out there that do have the common sense and the power to get this bug fixed. (Personally i would like to avoid quoting answers to SAPCustomerMessages, but i can understand your position. 
    This is one thing:
    >>”We simply do not know how far our transactions actually work in a non Windows environment.” 
    but not going to change it even when a bug is reported will be a no-go for the java-gui.
    I can’t find anything like this in the major notes about the SAP JavaGUI.  (e.g. note 146505)
    Christian
    (0) 
  8. Jonathan Groll
    * I have dismal luck when logging support SAP messages. I often get the “consulting issue” stonewall reply (which is used too often), even when there are obvious system bugs. A colleague of mine always gets new notes written for him. I guess it must be my “direct” writing style, or the way in which the stars were aligned when I was born.

    * Where clients let me bring my own (Linux) laptop  I always end up running vmware or virtualbox with a windows VM to support *just* SAPGUI. Wish it worked under wine.

    * Don’t you think in the long-term SAP should either:
    – drop the java GUI completely
    – or drop the windows SAPGUI in favour of the java GUI for windows.
    Surely there is a duplication of effort involved?

    Like you I would love the java GUI to be better supported (it is so close, say ~95% there but trying to get that last 5% needs SAP buy-in and it is a cop out to not tick the “java supported” tick-box). I had a client that was ready to deploy Linux desktops at their 700 sites, but weird ALV issues made them simply swap over to Windows. It can’t be doing SAP many favours “focing” clients to run windows. Unfortunately, as judged by newer SAP developments (business client / new ABAP editor) there does seem to be an indication that windows is further favoured as the long-term client platform.

    * It is strange that the above code didn’t use cl_gui_frontend_services – it does seem to be reinventing the wheel.

    * Kudos to SAP for approving your blog post and promoting it to the SDN front page.

    (0) 

Leave a Reply