SAP Inside Track Copenhagen 2019

On May the 4^th (Star Wars Day) 2019 the SAP Inside Track Copenhagen event occurred, a long long time ago, in a galaxy far, far away…

Snowing

First things first – in the morning it snowed. I am told this is quite unusual for May, even in Denmark. Something is snowing in the state of Denmark as Hamlet would say. Thereafter Mr. Blue Sky came out to shine down on a day of SAP based fun.

These are my notes so if anything comes out wrong or silly it is my mistake rather than the presenter – so if you infer from the below that I am saying that the presenter does not like gerbils (say) and you are a big gerbil fan then do not have a go at the presenter, have a go at me for getting the gerbil like/dislike wrong.

Malin Liden – Innovation

Malin is fairly high up the SAP tree and has her dream job of promoting innovation in marketing, the job which got the highest number of applications of any job at SAP ever. She was making three interlinked points, which is the mark of a good presentation according to Toastmasters International. She also gets a Toastmasters tick because she never said “um” or “ah” once.

The first point was naturally to do with innovation – if your job is to come up with new radical things then this is (a) not as easy as one might think and (b) even if you DO come up with a radical new thing everyone is going to say “that will never work”.

I am going to add my ten cents worth – I can see that a healthy scepticism to new things is all well and good, but in my experience it goes far beyond that – the attitude (outside of Australia/Israel) is “no change at all costs”. The analogy I always use is that the enemy is camped in a particular mountain and so you aim all your weapons at that mountain and plan to fire at first light tomorrow. Just before dawn a scout comes back and says the enemy have moved on, the mountain is now deserted. Therefore it would be pointless to fire, but so many companies say “the plan is to fire at that mountain, so fire we will!” The companies that can adapt and fire at where the enemy have moved to will most likely do a bit better than those that cannot.

The next point was to do with community. Malin lived in a village and did not know any of her neighbours until she got a woof woof dog from a shelter. Then she got to know every single dog owner in the village within a week whilst walking the doggy, and hence became a member of the dog owning community, instantly she had a huge base of dog experts to draw on. Any community, in our case the SAP community, is like that. The point is that a community can provide about a million billion times for useful help than any formal system of experts.

Again in my experience sometimes when people get assigned to a new country to live you have highly paid “experts” to help you in the areas of HR type things and tax, but if you trust anything they say you are mad as a hatter. Far better to ask people who have gone through the experience before you – as an example a “Brexit” community formed at work comprised of all the UK people at work living in Germany to come together to deal with the common problem we all face.

The last point was to do with diversity in the workplace, which may seem unrelated to innovation at first glance, but I think the idea is that the more different cultures or points of view you are exposed to, the less likely you are to always think “within the box”. All this is just my take on the talk, I am probably getting it all wrong, and the same applies to my notes on all the other talks.

ME!

I was up next talking about the future of ABAP programming. Oddly enough I am going to gloss over this for the time being. I am giving the same speech at several SAP Inside Tracks this year, hopefully I will make it better each time – a speaker gets useful feedback every time they do a talk. Everything is crystal clear inside my mind but I sometimes struggle to bring everything across to the audience, and hopefully I will get iron out the bugs over time. I will do a dedicated blog on the subject after the last one in Oslo this year.

What I will say is that all the questions were about Test Driven Development which is WONDERFUL as I truly believe that is one of the key pillars that will drive ABAP programming into the future.

Soren Amdi Batch – The Internet of Things Hell

Amazing as it may seem some new technologies tend to get over-hyped. In this case the “Industry 4” idea of putting sensors on everything that does or does not move and then sending bucket loads of sensor information to the ERP system, adding “magic” on the way will lead to a utopian dream of some sort.

Soren’s point is that the ERP system is in danger of being overloaded if a huge amount of “events” come in all at once. Most ERP systems are not “scaleable” i.e. they cannot double their memory capacity at the drop of a hat if a huge flood of new information to be stored comes in.

He does not have a magic bullet for this but suggested a lot of possible solutions to the problem. As an example if a component is breaking down and sends an “event” to that effect to the ERP system then a PM service order is created. What if that event comes in multiple times? You would end up with lots of service orders for the same fault

Christian – Conversational UI

Before moving on to the content I would note that not only was his English perfect, but also the accent. I thought he was from the UK when I first heard him speak.

On another totally random point at one stage he asked me when my birthday was so he could input the date into the live example he was doing. It transpired I had the exact same day and month of my birthday as he did (and indeed Madonna) which surprised him no end.

Anyway what was he talking about? It was half a hundred Star Wars references, peppered with information how these so called “chatbots” work. Most websites have them now as in “ask the virtual assistant something”.

As an aside (nothing to do with the talk) IKEA was one of the first ones in this area and they had a virtual assistant with a cartoon picture of a woman. In the end they gave up and shut her down as 90% of the questions people asked her were of a sexual nature.

Hopefully people have grown up a bit in recent times, I really hope they have, but it does explain why a lot of chatbots on websites these days have the image of an actual robot rather than a human or animal.

In any event the point is that SAP provides tools for you to create your own “chatbot” or whatever you want to call it and adding one to your applications is not some far off science fiction thing but something quite possible today. The benefit comes if your customers keep asking the same questions a lot of the time.

I would say that for anything even slightly out of the ordinary I would prefer dealing with a human. I fact I would always prefer dealing with a human, but that is because I am a dinosaur.

Anne Kathrine Pettersoe – Fiori Design for Developers

Fiori is often confused with UI5 but in point of fact UI5 is the technology (JavaScript) and Fiori is the design pattern. Thus you can use any language to create Fiori applications as long as you stick to the standards. Hence the efforts within SAP to make Web Dynpro and SAP GUI applications conform to the Fiori standards.

I would just like to interject here – Fiori is OK and certainly looks better than the SAP GUI but I still would not classify it as GOOD and certainly not “delightful”. It is like moving from having two fingers to having six. A huge improvement but ideally you would like ten. I predict one day SAP will realise this and will come up with a new standard which actually is “delightful”. There are plenty of examples around on the internet. Naturally this is of course a very subjective view – as in “beauty is in the eye of the beholder”.

In any event Anne was delivering the “designer 101” presentation. Whether I like it or not there is no doubt a gigantic amount of scientific research has gone into the Fiori guidelines in regard to how the human eye/mind perceives and reacts to things they see on screen. As such it would be a really bad idea to deviate from those guidelines in custom Fiori applications in the way that, for example, standard SAP GUI applications all have a totally different look and feel.

One example that stuck in my mind was the list of colours and how human beings generally have an emotional reaction to them. The reaction to the colour gray for example was “sad/tired” which if true possibly explains people’s reaction to the traditional SAP GUI screens.

Here is an interesting rule – the “Golden Ratio”. If you have several areas on a screen, each area must be 1.168 times bigger than the area than the area that is one level below it in the hierarchy. I am sure this has been proved loads of times by academics with a bucket load of evidence to back it up, but it doesn’t half sound (to an ignoramus like me) like a load of nonsense. Then again I suppose a lot of what I spout about (e.g. TDD and the like) is perceived the same way.

Anne was asked what the most common UI error was and the answer was immediate – buttons – this is how the user interacts with the application and for some reason hardly anyone can get this right. Buttons that do the same thing need to look the same, be the same colour, be in the same place, between applications. The guidelines are very clear, but everyone thinks they know better and put them all over the place, looking totally different, even between their own custom applications. We had this in the past with custom SAP GUI applications, and indeed even between standard SAP GUI applications (e.g. the “refresh” icon meaning “delete” in transaction MIRO). There was even an “ergonomic check” option in the SAP GUI screen painter though it looks like it was never used that much by customers, or indeed SAP itself. Maybe this time round we should all pull together.

Frank – IOT Hell

This was the second presentation of the day which cast doubt on the “magic” ability of the so called “Internet of Things” to solve all the problems of the world in the way that (say) salespeople claim they might.

In this case Frank was using the example of commercial aircraft – which have had sensors all over them for decades – and seeing how to get that information into an air traffic control system using SAP.

More importantly that information needs to be correct. Boeing has had a terrible few months, as we all know, that is probably nothing to do with data flows but nonetheless you need to be 100% sure that the information coming in is accurate.

For more information on the aviation industry I would recommend the novel “Airframe” by the late Michael Crichton. Before I read that I realised I had no real idea how modern aircraft could fly. In the same way before Frank’s talk I had no idea why there were so many buttons/controls in an aircraft cockpit, literally hundreds, all over the roof.

With every crash/accident that happens to any aircraft anywhere in the world laws and procedures get more stringent (hence they are anti-fragile) and the point that Frank was making was that if the information coming from the sensors is so important – and it is, it goes to the pilot/co-pilot in real time and the black box, and to the aircraft manufacturer so they can make sure their new aircraft do not do dumb things, then it had better be right.

This requires an automated test run every night – what is being tested is the transmission of data from the sensors to the endpoint to make 100% sure it is OK. That is not as easy as one might think. In fact it is impossible. Nonetheless as it is both (a) important and (b) impossible Frank has been thinking about ways it could be done.

EXCURSIS

This is what these IT events, and indeed the SAP community, are all about. You state an impossible problem that cannot possibly be solved, and then see if you (or someone else) cannot solve it. One of my favourite sayings is “an aim in life is the only treasure worth finding”.

If I have an aim then it is to prove to the ABAP community than Test Driven Development works. That pretty much falls into the “impossible” basket, so I suppose it is like an athletic type person trying to climb a mountain ten times the size of Mount Everest whilst blindfold and wearing boxing gloves, whilst getting shot at by international master criminals in helicopters.

One of the delegates said that it (the effort for TDD) must be the same for other programming languages. Oddly enough to use Jelana’s terms they (non ABAP developers) all “jumped off the bridge” and started doing TDD many years ago. I challenge anyone to go and listen to how AWS do things (a release into production every 0.56 seconds) and then come away saying automated testing is useless.

To be more precise people would say such automated testing is not useless, but it cannot be done in ABAP without a huge effort which is true. It is a huge effort in other languages – probably more than in ABAP – as well, but they have learned to live with it.

I would say to an ABAP developer – go and do it once. The next program you develop try and do it in a TDD manner. For most people their manager would not allow such a radical thing, but let’s just say. The first time it will be AGONY and it does take a lot longer. However once you get through it take a look at the end result and see what you think.

Better still take two vitally important programs and do maintenance on one of them using TDD and maintenance on the other doing traditional fix it as fast as you can method.

ABAP Unit works on procedural programs by the way, you just have to deal with global variables in the setup/teardown methods,

CAKES!

Next, as it was Star Wars Day, we had Light Sabre cakes. You had to pick the light side or the dark side

Light Sabre Cakes

The blue ones were the good side, the red ones were the dark side I picked the dark side. It was quite difficult eating such a complicated construction without dropping any of it on the floor but I managed it – in fact it was a piece of cake.

Steve Guo – Fiori Elements

Steve has moved from the capital of China to Denmark to work with LEGO who are at the cutting edge of SAP technology, as well as making cool films.

This is not going to come as a gigantic mega-shock but SAP often change their recommendation on how to achieve a programming task. To be fair, their competitors do the same.

At time of writing there are many ways of creating a Fiori app, all endorsed by SAP?

Since 2016 the official (internal) SAP way is to use “Fiori Elements”. This involves a metadata declaration of how your application is going to look like.

Since that point (2016) SAP internally has followed that recommendation and now 485 out of the 2190 “apps” in S/4 HANA use “Fiori Elements”

This all boils down to the concept of “smart templates”. Think of a PowerPoint template branded for your company. You take a copy and mess about with it to include the content of whatever it is you want to talk about. It has been the same with UI5 thus far, you pick a template for a list report of whatever and then you change your copy.

A “smart template” however is not copied but rather referenced. You do all your changes in a different place and the Brucey Bonus is that if SAP add extra features into the core template then your custom application gets them without you having to do anything.

The analogy would be back in 2000 when companies copied the standard SAP GUI ALV STATUS to their own ALV reports and then SAP changed all the icons (for the better) and then all the customers had to update all their Z copies of the “statuses”: to make things consistent with standard SAP (if they used any standard SAP!).

Going back to these smart template things, the idea is that using “Fiori Elements” you add all your changes and extension at design time, and at runtime the user can move fields around a la GUIXT and rename fields a la GUIXT and save it as a personal variant. I first saw GUIXT in 1999 by the way.

Not to put too fine a point upon this, you need to be on a HANA database to use this (Fiori Eeements). So much for the separation of concerns. SAP have tried so many times to do this (recall SAP “enterprise” 4.7 which tried to break the link between the application components and the ABAP level and failed 100%) and they have never got anywhere.

In this case the Fiori Elements (a fine idea by the way) has three use cases:-

• The object list page where you have a list of monsters. If the back end system supports it you can CRUD the monsters. You need to be on at least 7.51 for this i.e. S/4 HANA
• The analysis list page where you have lots of fancy graphs at the top of the screen and then a grid at the bottom of whatever you have selected. That is great, but you really need a HANA database to make it work
• The “object page” where there are a lot of rectangles all over the screen linking you to different things. Once again a HANA database is recommended.

Steve noted that the Fiori Element concept only got mature in ABAP version 7.51 (S/4 HANA) but would recommend 7.52 as the minimum. I would say very few people are at that level.

He is using ABAP 7.53. At time of writing that is only available in “ABAP in the Cloud”. That is indeed productive in a technical sense i.e. some small number of “lighthouse” companies are using it. Don’t get me wrong – ABAP in the Cloud and such are going to be a game changing one billion tons of bananas paradigm shift – it is just not ready (for productive use in my opinion) yet.

So hats off to LEGO for using all this cutting edge stuff first, but I cannot help thinking that any first adopter will feel some pain, such as when Texas Instruments were the first to adopt XI (as it was then) for middleware. In retrospect I bet they wish they had gone second or third. I know from first-hand experience the pain being first in Australia with SEM and then a decade later being first with Ariba.

In SAP world, it’s no fun being first.

Lars Hvam – Monoliths

This was a presentation where you take a statement which is perceived as true such as “monolithic programs are bad” and then try and knock it down. This is quite a common pattern in presentations even if the presenter agrees with what he/she is arguing against. It gets people thinking.

If anyone asked me for an example of a monolithic monstrosity then I would point them at SAPMV45A which is the sales document program in SAP and uses horrors like the COMMON PART and uses global variables that are so global they can be used between different programs. Nonetheless if I debug VA01 at least I can tell what is going on. That is not the case with ME21N so even if that is written in some sort of OO fashion it is a FAIL.

Anyway let us get back on track, inside track as it were. Last year, before he got booted out of the SAP door and now has to sell matchboxes for a living, the former CTO of SAP used to say in the keynote speech at SAP TECHED “keep the core clean”:

99.99% of people interpreted that as meaning getting rid of all your Z code but Lars has a much better analogy. He notes that CLEAN <> EMPTY whereas EMPTY = CLEAN. That is, if a house is empty then naturally it is clean, but there are many houses crammed full of things which are also clean.

So to state the bleeding obvious (as Basil Fawlty would say) the walls and floor and ceiling are all SAP standard and they give you some “best practice” furniture in every room which virtually everybody throws out of the window and replaces with Z furniture.

Lars has invented several open source ABAP projects, all of which could be described as “breakthrough”. Here they come:-

• I talk about this, and indeed sing about it, in my good old ABAP book. The whole concept of “Git Hub” makes your traditional ABAP developers head spin. Nonetheless this is the future so you might as well get used to it. SAP as a company certainly have.
• The “open checks” which are additions to the ABAP Test Cockpit or code inspector or whatever you want to call it. There is – in my mind at least – nothing more important than code quality so the more checks the better. The good thing here is you get to choose which checks you want. I would note the “S/4 HANA Readiness Check”. In the past you had to have a whole new SAP system to do this, and do a remote ATC check. In addition the version Lars has built has a lot less false positives.
• abapLint – now LINT is something used by other languages to do the static code check that the ATC or Code Inspector does. If you were to try and submit a code change to the abapGit project – for example –and your source code was badly formatted then your change would get rejected as the abapLint tests would fail.

At this point we need to talk about CLEAN ABAP which is the best thing that has happened ever in the history of the universe.

https://blogs.sap.com/2019/05/03/clean-abap/

“Clean Code” by Robert Martin was one of the best books on programming I have ever read. The examples were all in Java but that did not matter to me, but mattered to a lot of people in SAP world.

Now we have a version for ABAP which is online and free, and can be contributed to, and is by SAP.

This is one of the best initiatives from SAP in a long time, if not ever.

Have a look at the rules – obviously you can disregard the ones you do not like but THINK about them. Reading “Clean Code” by Robert Martin would not hurt either. Some of the recommend solutions do not compile on 99.99% of SAP customers systems but nonetheless their heart is in the right place.

BEER

The next SAP Inside Track Copenhagen will be 02/05/2020.

Cheersy Cheers

Paul