What’s that coming over the hill? Is it a Monster? IS IT A MONSTER?
Writing a Book for SAP Press – Part Two
Table of Contents
To Be Continued
It’s Alive – In the City of Light
Simple things please simple minds, so I was delighted by the positive response to my first blog about writing a book for SAP Press, a book about monsters (and the latest ABAP features).
In that blog I talked about the process of getting access to a trial SAP system, and some thinking about what type of content to put in the book. Once I had scribbled down by list of topics on the back of an envelope, which co-incidentally is the same medium that is used for storing technical specifications for ABAP programs, then the next question was how to arrange those topics.
Turn Around Bright Eyes
When connecting to the trial SAP 740 HANA system you log on by means of a remote desktop session. On that remote desktop is an SAP GUI logon pad as might be expected, but also an icon to call up Eclipse. The idea is to open the Eclipse system, not use the SAP logon pad, and do your programming from Eclipse.
Now, Eclipse is not everyone’s cup of tea – comments made in regard to my last blog described programming in Eclipse as “programming with broken fingers” and no doubt there are far better equivalent tools out there, but that is rather like discussing which airline is best with someone who refuses to fly.
In other words there seemed to be a lot of people who would rather die than stop using SE80. So as a first step talking about Eclipse seemed a good idea. If they don’t accept the idea that an alternative to SE80 is even possible / desirable then the other tools will not get a look in, and I bet some conservative development managers would not be comfortable with having their team move to a development environment that was not endorsed by SAP.
I try to keep an open mind, so some considerable time before Eclipse became available for ABAP I installed Eclipse to see what it was like and ran through all the tutorials – which were all to do with Java naturally – and was very impressed.
So, I put Eclipse in as the first chapter on the grounds that what development environment you use would seem to be the first step in any programming project. I would try to look for ways in which you could do useful things in Eclipse whilst writing code which you could not normally do in an SE80 environment.
I would also note that an open source IDE such as Eclipse evolves far faster than an SAP system. Already since the book was finished there have been two minor releases of the SAP tools and I have started making a list of new features in case I get asked to write a second edition of the book in 3 years’ time.
An open source IDE might evolve faster, but in fact the whole of the SAP technology stack – every single subject I write about in the book – is evolvingat a ridiculous pace. Most likely in 3 years’ time so much will have changed the book will need a total re-write, which is fine by me.
The Bash Street Kids – featuring Plug-In
American songwriter Steve Earle once sang a song called “I ain’t ever satisfied” which is what gives us IT types job security – not only are the end users never happy, but neither are the developer community.
Due to this fact I was hoping to try to end each chapter which dealt with an imperfect new tool (and how many are going to be perfect? Oh yes that’s right, none of them) with ways that it is possible to improve the functionality that you get “out of the box”.
In the case of Eclipse adding new functionality takes the form of “user defined plug ins”.
As an example, if I found a boring repetitive task that I had to do every day in the ABAP workbench I would write a tool to help me, but that would be my tool and I could not add it into the standard SE80 menu without the sort of modification to the core system we try to avoid, so even my colleagues inside the company would find it difficult to re-use this, let alone the whole world.
Eclipse works off the principle of being able to add such tools as plug-ins – the whole ABAP in Eclipse framework is such a plug-in. So I wanted to find an example of where there was a gap in the ABAP workbench and someone had added a plug-in to ABAP in Eclipse to address that gap.
I am a Universal Model, if you know what I mean
When I first started getting interested in object orientated programming someone said to me “before you do anything, learn UML”. So I found and read a corker of a book called “UML Distilled” by Martin Fowler.
My favourite quote is as follows:-
“If someone came up to you in a dark alley and said ‘psst – wanna see a UML diagram?’ it would probably be a class diagram”
When I walked past this enemy territory I noticed that they had pinned to the wall above their desks posters full of square boxes all connected with arrows. It turns out those were UML diagrams, literally a map of whatever application they were creating.
It seems the idea in OO programming is to draw up a diagram showing what classes you need and how they inter-relate, and what methods and attributes such classes have before you start programming. Moreover, such UML diagrams can be created with VISIO like tools within IDE’s like Eclipse, and then for languages like Java and Avengers Assembler at the press of a button the system will generate skeletons of the classes and methods and method signatures for you.
Then you are supposed to write unit tests for these skeleton classes before putting any real code in them – but I am getting ahead of myself.
So, if that is what a real OO programmer does, and I want to act like one to see what it is like, then I would need something similar in ABAP. So if I could find an Eclipse plug-in that enables this functionality in ABAP (i.e. creating skeletons of ABAP classes and methods based on a diagram) that would be a wonderful example.
Hunting for the UML Snark
It doesn’t take much googling to find blogs about UML for ABAP. I found two almost at once, and I thought they were both talking about the same plug-in but in fact they were utterly different.
Now I don’t want to go into how to install these or how they work – as that is in the book – but I do want to thank the creators of both for the help they gaveme, and to make sure people do not get as confused as I was at the start.
The problem is the name of both tools appears at first glance to be the same, which is why I thought there was only one.
UML2ABAP is the name of a product which you would have to pay for, from a French company called Obeo.
UMAP is an open source project, but just to confuse everybody, the web site for this is called UML2ABAP, and the open source project uses a lot of technology supplied by Obeo.
The company Obeo were kind enough to give me a trial edition of their product, for which I am grateful. I imagine they were very happy to have their product being mentioned in a book, though they only get a couple of paragraphs.
I also conversed via email with the inventor of the open source UMAP, Mathias Märker.
You are not my TYPE
One point that he mentioned I was meaning to put in the book but never got around to, so I will mention it here. UML is language independant, and you download whatever open source tool you can find to Eclipse or somewhere similar to create the diagrams.
Naturally since such tools that you use to create UML diagrams in the first place have never even heard of SAP, so when when someone writes a tool to convert the diagram into ABAP code they have a whacking get problem.
Naturally it cannot, so the generated code in SAP comes out looking like:-
IMPORTING ID_SALES_ORDER TYPE (empty space) .
IMPORTING ID_SALES_ORDER TYPE INVALID.
That is how the two tools deal with the problem i.e. by giving up in the face of the seemingly impossible. Then you would have to manually add the data type yourself. According to Mathias in UMAP the workaround is in the UML diagram creation tool to create a package called “datatypes” and in there you can create UML elements of type “Data Type” and name them like standard SAP data elements e.g. PERNR or VBELN. Those you can then assign to your UML attributes (either class attributes or signature parameters) in the diagram you are building and when the conversion tool is called in your SAP System the generated code will have the attributes and parameters that are created TYPED with the corresponding data element.
I tried this myself to make sure and it works fine.
If the first step in programming is the development environment, and the next stpe is to generate skeletons of classes and what have you, then the next step is to fill up those skeletons …. with code! And what sort of code do we like?
- · Morse Code
- · The Spy who Came in from the Code
- · ABAP Code
I thought I would go with the third one, and so therefore the next obvious subject to include was a chapter on the improvements in the ABAP language that came along in version 740 – what can only be described as a sea change. I can‘t stress that enough – going from 7.02 to 7.40 is an enormous boost.
Mind you since ABAP is backwards compatible, you can get away with writing things the same way you did in version 3.0 and everything will work fine, though the extended syntax check will – quite rightly – have a cow as Bart Simpson would say.
So, given the „we have always done it this way“ nature of some programmers, along with all the new 740 things I also included some features that came in with version 7.02 which I strongly suspected a lot of people did not know about, let alone use.
Obviously there is standard SAP online documentation for each new ABAP statement, but (a) IT people do not read documentation and (b) most of it is boring and (c) often such documentation does not appear related to the real world. It is difficult to grasp the idea when the examples use variables called A and B, when we are used to dealing with real world objects like sales orders and purchase orders. That is why at the SAP Architects and Developers conference in Sydney in 2014 Thomas Jung used all his own examples for each new feature.
However credit where credit is due – unless it is been censored by now, if you go on the internet looking for SAP online help. Once you have found the site take the path ABAP Keyword Documentation -> ABAP Reference -> Declarations -> Local Declarations in Expressions, and if you look at the example code for the LET expression then that may well win the award for the funniest example code in the history of SAP online help. Of course, now I have said that „they“ will probably remove it, and take out the author and shoot them.
The Man who Never Asked WHY?
I have a horrible habit of mixing the HOW with the WHY. What I mean by this is that when a new feature comes along 99% of the blogs and documentation are concerned with how to get whatever it is working technically. As to discussing whether using this shiny new feature is a good idea or not – that discussion never seems to get a look in.
The „how“ part of programming is always changing as technology evolves, the „why“ part is philosopical and so never changes. As part of the chapter on new ABAP language features I had included a discussion as to whether the new (much more condensed) syntax made the code less readable and how we can counteract this.
I was allowed to keep that in the book, though it got moved to an appendix. As time goes by I have started to wonder if I am a madman – thus far everyone I have asked says that mixing the WHY and the HOW is a no-no. The consensus seems to be that the two topics should not even be in the same book, let alone the same chapter. However to me it seems they go hand in hand.
As an example the other day I saw a series of blogs on SCN about the BUS framework for coding DYNPRO screens in an object orientated manner. That was very well written but focused solely on how to get this working. I did not spot anything about why using this framework was a Good Thing, though that may be coming along in a subsequent blog.
When trying to justify something as a Good Thing I don’t accept statements like „because it is object orientated“. I want an example of the bad way of doing things, and the good way, and it should be obvious that the good way makes things more resistant to change, or faster to develop, or some other benefit.
So when I was trying to write a book I wanted to say why these new tools were good, alongside the mechanics of how they worked. However due to the vast amount of content a lot of the WHY had to be cut in order to concentrate on the HOW.
That makes perfect sense, but just for my curiousity I would like to ask the floor – is it enough just to say how to make something work? Do the philosophical aspects have no place in SCN blogs or in „how to“ textbooks?
To Be Continued
In subsequent blogs I will continue to talk about the thought process behind how I chose what topics to include in the book, enriched with some content that was cut from the final version of the book for reasons of space.