SAP TechEd Las Vegas 2017 – Day Four

It seems like a million billion years since SAP TechEd Las Vegas, it has taken me this long to transcribe my notes into blogs, due to flying around the world like a lunatic on business ever since. I am still on a business trip, I am in Heidelberg at the moment. Thus far I have done blogs relating the events of the first three days:-

https://blogs.sap.com/2017/10/21/sap-teched-las-vegas-day-one/

https://blogs.sap.com/2017/11/03/sap-teched-las-vegas-day-two/

https://blogs.sap.com/2017/11/15/sap-teched-las-vegas-day-three-goat-day/

… and now it is time for the fourth day!

001 Superhero

The picture above depicts me as a superhero. I was given such a picture as a reward for posting a load of nonsense on the SCN on a regular basis, and managing to have other people mistake that for meaningful knowledgeable contributions that further the SAP community. At least that is how I got the award – the other winners probably did contribute something meaningful.

You may have seen one of Jason Cao’s blogs in which he depicts members of the SAP Mentor program as superheros e.g. Iron Man, The Incredible Hulk and so forth.

If I had to pick a superhero to be, it would have to be “The Brown Bottle” who patrols the streets of Newcastle upon Tyne in the UK and is not perhaps quite as effective in fighting crime as he might be, almost as useless as Spiderman in the “Homecoming” film.

08:00 HANA Road Map

It might not seems obvious at first, but I think there is quite a lot of similarity with SAP coming up with the idea of HANA, and Elon Musk coming up with the idea of an electric car company called TESLA. Firstly, and I am not sure if I have mentioned this enough, presenters at SAP events like to use the buzzwords TESLA, UBER, SELF DRIVING CAR and/or ELECTRIC CAR to describe everything from the latest cutting edge machine learning algorithms to the fire evacuation procedures.

Going back to the analogy when Elon Musk first published his “master plan” and brought out an electric car everybody laughed and laughed. Over the next five or six years when each of the stages in the plan was reached the media locked onto the fact that while the events were unfolding in the correct order they were all behind schedule. They sort of lost track of the fact that whilst things were happening slower than planned they were still actually happening. In fact what was really eerie was that some of the criticisms levelled by the media were predicted almost word for word, years in advance.

Then suddenly, almost overnight, things did not seem like so much of a joke anymore and every single car making company started to get really worried.

This Gary Larson cartoon sums it up the best.

Dinosaurs laughing at furry thing

These days not a day goes by when you do not see a headline saying something like “VW to invest 4 billion dollars in Chinese battery factory” or some such. In every such story, in the same way SAP announcements have to have the term PARADIGM SHIFT within them, at some point in each automobile media story you will see the term TESLA KILLER a la “Jack the Giant Killer”.

The logic is that all the established car companies are (a) so much bigger and (b) have been making cars for so much longer that there is no doubt whatsoever that they will be able to beat this upstart and return to being undisputed kings of the hill.

You can probably see where I am going with this. People laughed at HANA when SAP brought it out – especially Larry Ellison when he said that Hasso Plattner was on drugs. In exactly the same way as with the cars, one day everyone stopped laughing and started working on their own in-memory databases. Once again though not actually bigger than SAP the competitors had been making databases for such a long time that surely once they put their mind to it they too would be able to beat the upstart and return to being kings of the hill.

The problem is both cases for the “chasers” is that aside from the embarrassment of having to admit you were wrong about something and having to chase after what you had previously been laughing at in the first place, the thing you are chasing is not standing still, but rather doing everything in its power to stay ahead. This is not to say that the pursuers cannot catch up, just that it is not as easy as many commentators think it is.

So, this leads us to the HANA road map. You have no doubt seen these SAP documents before – they give a list of recent innovations, say what is coming in 2018 (in this example) and then 2019 and then from 2020 on give a motherhood statement of what they want to do for a living when they grow up, like be an astronaut or some such.

HANA is seven years old in December 2017 and whilst no doubt Oracle would still say it is not “mature” it has passed the stage where a new revision was coming out every single week. As we have seen we have moved from HANA 1.0 to HANA 2.0. SAP loves to extend maintenance periods so they have extended the maintenance of HANA 1.0 from 2019 to 2021.

In regard to HANA 2.0 they have dropped from 2 support stacks a year which went out of maintenance after one ear, to one SS a year with a maintenance period of 2 years. They are already thinking about HANA 3.0 (of course) and say that the final SS for HANA 2.0 will last for five years.

I have to share with you a little secret at this point – I find database administration a very boring topic indeed. So the huge list of recent advances and new features and forthcoming advances and new features tends to wash right over me. The only thing of even vague relevance to me was the ongoing SQL and SQLSCRIPT enhancements, and ODATA V4 support, as that smacks of programming.

So I made no notes I can refer to here save to say that HANA is not standing still, SAP are well aware of the chasers and clearly have half a billion developers full time adding new features and what not to the HANA framework.

Mind you, one thing that SAP can do that TESLA cannot is say “Ya Boo Sucks, we are bringing out a new version of our ERP product and you can only use HANA on it”. In theory that should bring down the percentage of SAP customers running Oracle databases from about 75% to 0%.

Many people I have talked to about this truly believe SAP will back down on this, and bring back database independence in S/4 HANA, thus rendering its name a bit silly. I am not actually that convinced that SAP will make such a change of direction, though never say never.

09:15 Saving a Variant in UI5

Most TechEd sessions are about wonderful new, never seen before technology which will be available for use somewhere between five years’ time and never. Other sessions can include customer “war stories” where a real SAP customer has tried to use one of these wonderful new technologies and it did not work out of the box, and what they did to try and fix it.

This session was different yet again, describing how a customer had filled a GAP in standard SAP using custom programming. The technology in question was the HANA platform and UI5.

UI5 is not really as SAP specific as you might think, given there is an open source version, and the whole thing is a JavaScript library really, so naturally you can get round any obstacles by writing more JavaScript code.

In this case the main theme was that with the old fashioned, so ten minutes ago, ALV reports we love in the SAP GUI, you can have the end users create user specific variants and hide the columns they don’t want and put the most important ones at the front and so on. This way you do not need twenty different versions of the report for twenty different users.

So, the question arose, can you do the same in UI5? It is not a direct comparison as UI5 reports tend to have less columns anyway, due to the lack of real estate on mobile devices. You could of course say that makes this even more important as different users having different filters and different subsets of important columns solves the exact same problem.

The solution here was to create some Z tables in the HANA database to store the user specific (or global) variant attributes. This would also be a bit more “visible” I imagine, as the way ALV variants are stored is in a compressed invisible format.

As an aside, the presenter here was Tim Champagne. Usually I do not like companies replacing the traditional “we eat our own dog food” with “we drink our own champagne” but since the presenter had both created this framework and used it also – at Lockheed Martin – it could be said he was drinking himself.

Anyway this is not a thirty second job, setting this up in your own system, but this session did give you detailed step by step instructions on what to do. In addition, every time you go through such an exercise – copying code and following instructions – you get more and more familiar with the tools involved which I consider to still fall squarely in the “new” basket. I think quite possibly eventually SAP will add this (UI5 user variants) as standard, but that would take all the fun out of it.

10:30 ODATA Services V4

You might imagine that a talk about SAP’s implementation of version 4 of the ODATA protocol, would be as dull as dishwater and of interest to nobody. I think that is what the presenter was expecting.

Imagine his surprise then when it turned out to be standing room only, and people were hacking their way into the room with machetes, or going into the adjoining theatres and smashing holes in the walls with mallets.

I therefore get the feeling that “I know I’m not the only one” (as the song says) who has a burning interest in all things Gateway and SEGW. The actual song was possibly not about SAP connectivity with smartphone applications. I think.

Firstly, looking at the speech from a Toastmasters point of view, the presenter would have lost loads of points for the vast number of “ums” and “ahs” all throughout the presentation.

Moving onto the benefit of ODATA V4 the most important thing is the reduction of the payload size. When you are sending something to a mobile device the smaller the payload the better for obvious performance reasons.

If you look at the payload on a XI/PI message you will see it is as big as a giant mega-elephant with bronchial pneumonia who has been put through an enlarging machine as per that epic of cinematic history “Honey I Blew up the Baby”. This for a structure of about six fields of data.

Giant payloads like that, when arriving at the smartphone are so big they literally fill up the device, and the result is like liquid nitrogen returning to its gaseous state, whereby it expands to one hundred times its previous size and naturally there is no room inside the phone to accommodate this increased volume causing it to burst apart showering the entire room with parts of the phone flying out like shrapnel, killing everyone within one hundred feet. The SAP best practice guide notes that this is not a desirable outcome every time the end user wants to access the ERP back end system via their mobile device.

The Gateway payloads I am used to (I am on a 7.02 system) are much smaller than this, so the blast radius is much smaller when the phone explodes upon receipt of the message. In ODATA V4 the payload shrinks yet again to basically contain only the data that is actually in the message without the half a ton of accompanying nonsense, and thus the phone no longer explodes at all.

ODATA has been described as “SQL for the Web” and so in the same way SAP has been enhancing Open SQL within ABAP so that one day it will match the 1992 universal specification, the new version of ODATA supports many more options in the URL that gets sent to Gateway.

I would point out you have to code the response to such queries yourself in ABAP, but the design pattern developed by Graham Robinson gives you a generic way of doing this such that you do not have to do this manually for every service.

The point is you cannot respond to a given query if the ODATA protocol does not support it – the query simply will not get sent to the back end, there will be some sort of error on route most likely with the word “malformed” somewhere in the equation.

The GET call now supports the SQL operations GROUP BY and aggregate functions, for example. You have the terms ANY and ALL though I have forgotten the difference between them.

The filters are now much more like SQL (or select options) as you can now use “Greater or Equal” and its friends, and you can do joins. Whoo Hoo!

Gateway services have thus far been utterly independent of each other, but ion the future you can have “service groups” and you can make “cross service references”. I am not sure yet whether that is a good thing or a bad thing.

Transaction SEGW is now in maintenance mode, which is quite ironic as when I talk to ABAP developers 75% are unaware it even existed in the first place. SAP claim that changing things via this transaction will eventually be the exception rather than the rule.

Once again we get the instruction that in our code we must separate the business logic from authority checks, locking, LUW and so on. As I mentioned the other day you should do that anyway, to enable unit tests.

As a sort of vague aside at the end the presenter let slip that the SAP implementation of ODATA V4 (i.e. everything in the presentation) is nowhere near ready.

Thus to paraphrase Marty McFly talking about rock music “You guys might not get it, but your grandchildren are going to love it!”

12:30 SAP Mentors TV Show

Andy Warhol said that one day everyone would be famous for fifteen minutes. I reckon he was able to make this quite correct prediction because he smoked something funny one day and as a result managed to penetrate the barriers of time and saw the auditions for “The X Factor” or one the many billion different reality TV shows that fill our screens.

I am aware I have all the singing ability of a Block of Wood and so (although this does not seems to deter many people) you will not find me doing auditions in front of Simon Cowell.

However at TechEd they have their own TV crew, and so I got to take part in a seven minute TV show with Michelle Crapo, hosted by Jelena.

https://blogs.sap.com/2017/10/02/sap-mentors-share-magic-in-las-vegas-interviews/

In the above link the video in question is about half way down under the title “ABAPers Getting Lemonade”.

14:00 My speech about S/4 HANA

I wanted to go to SAP TECHED 2017 and I knew I would have to pay my own travel and accommodation but I did not want to pay the entrance fee as well. So I had thought the best way to do this was to go as a speaker. That is not an automatic process by any means, you have to find something that you have experience with which fits into one of the areas that SAP are pushing at the event.

If you think about it this is a Catch-22

• You need practical experience with the technology in order to speak about it
• TechEd focuses on technologies not yet available

I think you can see the problem here. This is like the rule in the UK where you cannot appear on stage unless you are a member of the actors union EQUITY, and you cannot join EQUITY unless you have had experience appearing on stage.

In both cases there are ways around this of course, otherwise there would be no actors in the UK, and no “customers” presenting at TechEd.

I was lucky enough to get accepted as a speaker and then in a twist of irony got made an SAP Mentor the month after my submission was accepted, which would have got me free admission anyway. Of course, getting made a Mentor is something I could not have predicted. In case anyone is interested the way to become a Mentor is to start acting like one. You do not do X, Y and Z because you have been made a Mentor – you get made a Mentor because you do X, Y and Z. In other words if you walk like a duck, act like a duck, and quack like a duck, eventually you will be made an official duck.

Have I gone off topic? Yes. OK, anyway one good way to find out about new technology is the SAP Cloud Appliance Library where you can play around with the latest versions of SAP. Then you can start to think about how to apply those technologies in the real world i.e. at your company where you work.

In this case I had got a trial 750 system, and this enabled me to go through an exercise where I could analyse my companies Z code to see what would break if we moved to an S/4 HANA environment. That seemed like something everybody would be interested in, given that in 2025 every current SAP customer will either have to move to S/4 or ditch SAP as their “digital backbone”.

So my abstract was:-

Hanson Australia has been creating “Z” code for close to 20 years and thus have a very large amount of bespoke functionality. By 2025 it will have to migrate to SAP S/4HANA and converting the Z code will be no small exercise. Walk through the various SAP tools available to analyse your current system and thus draw up an action plan for preparing “Z” code for the transition. Hear “real-world” examples of code as opposed to abstract theory.

When you send off your presentation to SAP, months before the event, you get a technical review. I am used to that, from my book writing life. In this case top SAP dog Karl Kessler reviewed the first version of my presentation and said it stunk. In retrospect I have to say he was correct – the exact criticism was that the content did not marry up to the abstract and the session title, so I changed things to make sure that it did. That was thus constructive criticism, and I am glad I received it.  As a punishment for him being correct, he had to endure me having a drink with him on the first night of TechEd.

I do not put lots of words on my slides – as then the audience reads them and does not listen to you. Instead I have a title and then some cryptic pictures. The audience wonders what the pictures mean and thus listen to my explanation. My entire technique, by the way, is a mixture of what I have learnt at Toastmasters (e.g. Fripp model for presenting) avoidance of bad things I have seen at SAP events experiments and utter madness.

My presentations start with the “tell them what you are going to tell them” slide – the message of the entire presentation, which has to be expressible in one sentence.

In this case the sentence is: “In 2025 the R/3 System reaches end of life, you have to migrate to S/4 HANA,  but you can start preparing your custom code right now for the transition”.

A bit of a long winded sentence, but only one sentence nonetheless.

You then have to say a bit about the organisation for which you work. That is an event rule rather than a speaking rule. In fact since usually no-one cares AT ALL you could skip this bit entirely. I have seen some speakers spend ten slides on this. Anyway, just for giggles:-

Hanson Australia is a wholly owned subsidiary of German company Heidelberg Cement, one of the three major building materials companies in the world.

With the recent takeover of the Italian cement producer Italcementi in July 2016, HeidelbergCement became the world number1 in aggregates production, number 2 in cement, and number 3 in ready-mixed concrete. With a Group revenue of €13.5 billion in 2015, Heidelberg Cement operates in around 60 countries, and has 63,000 employees working at around 3,000 locations.

HC is very SAP centric, as might be expected with a head office just a few miles from Walldorf. Happily, so was Italcementi.

HC is in the midst of a project to bring every country onto SAP using a template based approach using regional “centres of excellence” – Australia for Ready Mixed Concrete, USA for Aggregates, Germany for Cement.

Transistion : Thus far we (HC) have been concentrating on bringing all countries onto SAP, but now it is time to step up our game and look to the future – and this means S/4 HANA.

Part One: The Challenge of S/4 HANA

• We have two long standing SAP IT departments on opposite sides of the world. Two huge SAP systems with totally different configuration, master data, custom programs etc.
• Both have achieved miracles, but thus far have worked utterly independently. The time has come for Fusion, the whole becoming greater than the sum of the parts.
• This is not a ten second job. It is in fact the most difficult thing we have ever done.
• After we have done the most difficult thing we have ever done, we will then have an even more difficult task, namely the migration to S/4 HANA, and the effect this will have on 17 years of bespoke development

This leads on to the question – why is the move to S/4 HANA going to be so disruptive to existing custom development?

The first problems come after the database changes to HANA when you suddenly find your custom programs run into trouble when reading data from the database.

Queries that worked perfectly before:-

• Do not Return any data at all
• Return the data in a different order, causing your programs to react in unexpected ways
• Return the data OK, but take much longer than before, which is the exact opposite of what you expected when migrating to HAA

Not There

An enormous amount of tables are removed with the move to S/4 HANA.

This starts off with index tables like BSIK/BSAK which are just subsets of the data in BSEG, and in both finance and materials management 75%+ of the tables vanish. There is no more mixing of master data with transaction data.

The tables (such as BSIK) look like they are still there, but in reality they are now just views. This means a custom SQL read will carry on working just as before, but if you have custom Z fields in such a table they will need to find a new home.

Cluster tables like BSEG become “real” tables, and are thus much easier to access – much some Z database reads may be trying to access the underlying table, which is no longer there.

Wrong

The order the fields come back in from a database read will most likely no longer be in primary key order – and many Z programs rely on the behaviour of the former database.

Slow

If a database read was sub-optimal before e.g. SELECT * when you only need one field, it will be a thousand times worse in a HANA database.

Also, with HANA you no longer need redundant storage i.e. same field in more than one table with the same value e.g. master data values in transaction data tables, or index tables of any sort e.g. LIS

Whilst all the standard SAP tables get changed to take advantage of the new architecture, your custom tables stay exactly as they were before, and thus will need the same redesign SAP applied to their database model i.e. removal of redundancy, index tables and so on.

• SAP cannot stress strongly enough that S/4 HANA is not a new version of R/3, it is a totally new product
• From a technical (buzzword) point of view this will be a “system migration” as opposed to an “upgrade” albeit with SAP supplied tools
• You will find there are whole chunks missing in S/4 HANA, in areas where there were 3 possible solutions before, two have been removed e.g. credit control, transportation management, the general ledger and so on and so forth. This is indeed simplification, but chances are you are using one of the older choices for each solution area….
• This means it is a re-implementation for all practical purposes

Examples include the removal of transaction codes like XD01/2/3 and XK01/2/3 to be replaced with the equivalent business partner transactions which apparently confuses the user greatly. Moreover if you current vendors and customers have overlapping number ranges you are in trouble, something has got to give.

Other vanishing transactions are M1A, MB1B and most concerning CIC0. There must be replacements of some sort but they will not be the exact same thing as before just with a different transaction code.

What this means from a custom code perspective is that you probably have Z programs relying on reading from data in modules which just are not there anymore, or calling transactions that do not exist in S/4 HANA.

As might be imagined, those programs will not only cease functioning, but will in fact be riddled with syntax errors.

Transition: Those are the problems, let us turn to how to deal with them, how to build an action plan for preparing your Z code, starting with the move to the HANA database….

We mentioned three problems – no data, wrong data and slow queries.

Part 2: Dealing with Database Changes

The first step in preparing your custom code is to find what custom code is never called, so you can ignore it.

This is important, as you will perhaps be surprised to find that 75%+ of your custom code is never used at all, as it was created to address problems that no longer exist. The tendency is to just add more and more Z code each year and never remove any, even after the need for it has gone.

Knowing what is not used is very important, that way you can concentrate on not breaking the custom code that IS used.

How does one go about this? In recent SAP releases the amount of dynamic check tools have increased dramatically. If you are currently on 7.02 or above then you can start this exercise right now, though naturally higher releases have more tools.

What I mean by this is the ability to track every single thing that happens in production, by means of “Usage Procedure Logging” (UPL) for the whole year so you can take account of year end, and see how often custom code is executed right down to the subroutine level.

In higher releases (740+) there are also tools to import the productive data into the development system where you can analyse custom code for expensive SQL statements which could benefit from HANA specific features like having more logic run inside the database. Such “code push down” is a task for after the migration generally, though you can create so called CDS views on an Oracle (or whatever) database if you are on 7.4 or above, ready for the migration. Such views would not run any faster on an Oracle database though, but you could have them ready to go.

One thing my organisation does it to take two days a year where all the programmers down tools and get together to run through all the standard SAP analysis tools – like the ones  above –  looking for expensive SQL statements and the like. This is called a “CPO” after the SAP “Custom Program Optimisation” service that is offered. We paid SAP to conduct such an exercise at our company back in 2001, and learned so much we were able to do this on our own each year thereafter.

So my recommendation is to make a list of such expensive SQL statements. Some you can fix right here and now, but the others aside until after the migration.

Now you know what custom code is actually used, you can use the code inspector to do a static analysis.

SAP have created a range of new code inspector checks, so that when you do an analysis of your custom programs using the code inspector (which you do all the time I hope) potential problems that could occur when moving to a HANA database are highlighted. There are even two template check variants both starting with “FUNCTIONAL_DB”.

This finds the sort of problems mentioned earlier:-

• Presumptions as to which order records will be returned in from a database read,
• Attempts to access the underlying database table behind a cluster table, which will no longer work on a HANA database.

It is worth noting that many problems the code inspector highlights at the moment will result in even bigger problems in a HANA database – like the old chestnut where you only need two columns from a really wide table and do a SELECT * to bring every single column back. That caused big problems before, it will cause death in the new world.

Thus what my organisation has been doing, and what I urge you all to do, is to start right now, switch on the extra checks in the DEFAULT variant of the code inspector, and scan all commonly used programs until the errors and warnings have been fixed or classified as false positives.

If all goes well, then you have already changed your code (in regard to database queries) so much in advance that there is not that much to be done after the migration, which is not to say there is nothing to do after the migration.

In this example from the SAP Press book on optimising programs after a HANA migration we see the following.

• The database migration on its own reduces the runtime of a custom report by over half – but it is still not fast enough to run in dialog
• The ABAP code needs adjusting, which yields almost a big an improvement – the code inspector checks in the last slide mean you can do this in advance of the migration to S/4 HANA
• Lastly, the database access and associated logic needs to be “pushed down” to the database – two slides ago you made a list of SQL queries which could benefit from this. As also mentioned CDS views work in any database, so you could have prepared them in advance and proved they return the correct result in an Oracle (or whatever) database, even if they do not run any faster in such an environment
• The resulting runtime is 2% of the original runtime. That is fantastic, but the database migration on its own did not get us there on its own.

Transition: Difficult as the database related changes might be, they pale into insignificance compared to the application changes that come with S/4 HANA…..

Part 3: Dealing with Application Changes

As the changes associated with S/4 HANA are quite dramatic SAP have provided a tool to help you work out what will break.

You will need an SAP system that is on ABAP 7.50, either create a sandbox system for yourself or use the SAP “Cloud Appliance Library” to create a temporary system just for this purpose.

Then you install an extractor program on your current real ERP development system, and extract data about all your custom objects into a file. This involves getting the “where used list” up to date, which can take a week or more.

You then run a job whereby the 7.5 system goes and looks on the web where SAP has the most current information about the changes in S/4 HANA.

This is the “simplification database” and the latest information is stored on your 7.5 system.

Lastly you upload the file containing the information about your current custom code to the 7.5 system, it compares that information to the “simplification database” information and comes back with a big list of what is probably going to break.

When you see the list of what is going to break you will most likely have a heart attack and drop dead on the spot.

If you survive, you will come to realise what is being reported is just the same few warnings many hundreds of times, rather like the error log you get from Java programs.

For each such warning you are pointed to an OSS note which details the potential problem and what to do about it. The good news is that these OSS notes are generally rather better written than what you may have become accustomed to.

For example you are told when your custom programs are writing to Z fields in tables that no longer exist, or doing a “call transaction” to a TCODE which is simply not there in S/4 HANA, or a search help, or a database table, or whatever.

At this point you now have a complete list of what Z programs will break, due to missing modules or whatever.

With the database queries, you could prepare the Z code in advance? Is a similar thing possible here? Not only is it possible, I have already done so in my system, and I’ll tell you how to do it in yours.

• In programming often you design programs based upon what you THINK might change in the future
• In this case we know for a fact what is going to change. SAP may change it’s mind but you cannot rely on that, so if SAP say a module is not going to be in S/4 HANA, you have to proceed on that basis.
• We want to prepare our code well in advance, and make the minimum changes at transition time. This is a case for the adapter pattern.
• Change your Z code to call the ECC module which is not there in S/4 HANA via an adapter class. Then your code no longer depends on the underlying framework – this is dependency inversion.
• In advance you create a new adapter class with the same interface to your Z code, but which talks to the replacement S/4 HANA framework
• Then at go-live time, you change the configuration, or the factory class, to replace an instance of the ECC adapter, with an instance of the S/4 adapter. The calling code will not know the difference.
• If you have a Z transaction / screen / application through which your users access the functionality, you will not need end user re-training either.

At this point people 99.99% of the time recap the main points again, and end on “questions and answers”. Speaking Coach Patricia Fripp (sister of guitarist Robert Fripp from King Crimson) says to move those two around.

Since the audience only remembers the first thirty seconds and the last thirty seconds of your speech, the bit in the middle could consist of you clucking like a chicken instead of delivering the body of your speech. Nonetheless delivering the body of your talk is the traditional approach, and it is just barely possible that if you started making chicken noises 31 seconds into your presentation and the audience realised you were not going to stop, some of them might walk out. Most presenters just fire off a nonstop string of buzzwords instead of chicken noises the two approaches ae just as meaningful but the buzzwords are less obvious.

Anyway you have a choice – the last 30 seconds are going to be remembered by the audience, so those seconds could be filled with you recapping your three points, or by somebody asking you a ludicrous question and you trying to be polite and not call them names.

So it is quite possible if someone asks a guy who was in the audience two days later “What was that speech all about?” they will reply “Right at the end someone asked ‘is there an IF statement in ABAP?’ and the whole audience fell about laughing” and the next question is “What was the SPEECH about?” and they reply “I can’t remember”.

15:00 Mentor Meeting – Sam Yen (UI)

As I mentioned earlier there are about ten “executive meetings” that the SAP Mentors have with various top dogs from SAP where they get to ask them difficult questions and make them squirm. It is quite good of the SAP people to allow themselves to be put through this. As you might gather I am exaggerating somewhat, the whole process is quite amicable, but they are hard questions.

The UI has been a huge focus for SAP in recent years, as first we had 30 years of ugly grey screens which everyone moaned about, then we had the ludicrously named “Enjoy SAP” which is the phrase you see when you look up “oxymoron” in the dictionary.

Next came the short lived “Web Dynpro Java”. Shai Agassi liked Java but the huge push for Java at SAP seemed to die off after Oracle bought Sun Microsystems. Next came “Web Dynpro ABAP” which turned ugly looking grey screens with fast response times into even uglier grey screens with slow response times but that was OK because the screens appeared IN A BROWSER. Talk about “Fifty Shades of Grey”.

The next cab off the rank was “Screen Personas” where you take standard SAP transaction running in the GUI and intercept it thus enabling you to rename all the fields, move them around the screen, hide the ones you do not want, add pretty pictures, combine different tabs into one scree, do some clever scripting behind the scenes and so forth. I first was able to do this sort of thing back in 1999 which is when I first came across the product GUIXT though no doubts it was around before I discovered it. GUIXT was a free product, so SAP though at first it would be a good idea to charge SAP customers through the nose for almost exactly the same product.

At the same time SAP did their usual trick of taking an open source product and “improving” it, thus their take on HTML5 which was to be called UI5. This is a JavaScript library really, but anyway the end result was about a million times better than Web Dynpro, it ran faster and looked a lot nicer though the descriptions by SAP using the words “beautiful” and “enticing” maybe were a slight exaggeration. Initially this was to cost ten billion dollars as well.

At this point a lot of customers started pointing out that SAP was now proposing to charge people for fixing an existing flaw in their product i.e. the ugly UI, and surely fixing such flaws was what the customers had been paying many millions of dollars in maintenance fees all these years for?

Bill McDermott took the hint and dropped the price to zero. That did not help the early adopters much, as they had paid and the refund came in the form of an SAP gift voucher only redeemable by buying another SAP product of equal cost. Everyone else was laughing though.

I think I have gone off the main point somewhat, let us get back on track by talking about the only question I can remember Sam Yen getting asked, out of the twenty or thirty on the list.

The question was all about machine learning. SAP is proposing a digital assistant product called “Co-Pilot” which is rather like Siri or Cortana, and it is supposed to use AI to get cleverer over time as it learns from going about the tasks you give it and whether it failed or succeeded.

The question was that if Google and Microsoft and whoever struggle with this, how does SAP think it can do so much better? Especially as the Google and Microsoft “bots” or whatever they are called this week can learn from their entire customer base i.e. what it learns from me right now in Germany can be used in 5 seconds time when someone in Peru gives a similar request. With SAP the “co-pilot” can only learn from users within the organisation.

I think the answer was something along the lines of “Don’t Worry, Be Happy” or as an Australian would say “No Worries, She’ll be Right Mate!”

16:00 Mentor Wrap Up

This was quite odd as it seemed to comprise of going round the room asking everyone what they liked about TechEd as opposed to what they did not like or suggestions for improvements. This process also took forever, well just over two hours but it seemed like forever.

17:00 After Hours: SAP + Google Contest Results

As a result I did not get to go to the SAP / Google contest results party, though as a judge I had been invited. That was a pity as it was in a restaurant in the Venetian I have not yet been to.

Anyway the contest was to use SAP HANA and Google technology coupled with artificial intelligence and machine learning and what have you to come up with a radical new app for your mobile device.

Each of us judges had been given three such submissions to evaluate, and the results were amalgamated and the winner chosen and the awards ceremony was done at TechEd at this party. As an aside this year only people from the USA (or pretending to be from the USA using some sort of AI app to fool the judges) were allowed to participate, next year it will be a global contest.

One of the entries I had to judge was all about carrots, I was very happy when I realised that was the case. One thing the world is lacking is artificial intelligence based solutions to the daily carrot problems one is likely to encounter.

Another was all to do with grouping customer open items, and making proposal based on prior customer behaviour. The irony is I once had to write such a program, using fixed algorithms supplied to me by the chief credit manager. At the time I wondered to myself if this could not somehow be made more dynamic.

The last one I had was all about optimising truck movements by trying to impersonate a swarm of bees, who are uncommonly good at getting each individual bee to where they need to be in a hurry and getting things back to the hive. Once again my company achieves the same result using a fixed set of algorithms which do not adjust themselves based on the past. So in short two of the three were pretty much 100% relevant to actual business problems I had encountered. I have not encountered too many carrot related problems at work, but maybe I have not been looking hard enough.

19:00 After Hours Party at Gilleys / Senor Frogs

002 Goat Bull riding

The start of the closing party for TechEd was like something out of a comedy film. The law in Nevada is that if you are going to be having a party where free alcoholic drinks are going to be given out, then no-one can get inside unless they have photo ID to prove they are over twenty one. Now, I don’t think you are going to find too many people arguing with that rule once they know it exists, but the trouble is the vast bulk of TechEd people did not know about the rule, and to cap it off the instructions said that to get in you needed your TechEd pass (and a special bracelet for mentors to get in early) but no mention of photo ID.

So you had a huge stream of people (four thousand at least) crossing the bridge from the Venetian to Treasure Island, rocking up to the party venue, learning the rules, crossing the bridge back to the Venetian, going back to their room (at this point I saw one woman waving her TechEd badge at me and shouting “This does not work!” to which I responded “Don’t I just know” ) getting their ID, back down in the lift, back over the bridge, this time being able to get inside the party. If someone had hovered overhead in a helicopter it would have seemed like a stream of ants going to get some food and then taking it back to the nest, and then going back for more food.

As can be seen from the picture, Capra had a good time, it is the dream of every stuffed Goat to ride a mechanical bull. Don’t tell anyone but I think she was under 21, but no-one asked her for ID, so she was able to drink us much as she wanted.

At the end of the event I showed a rare burst of common sense – I actually went back to my hotel room so I could get up the next day for the final day of TechEd when it would have been really easy for me to keep drinking with the Mentors, a gigantic bar crawl through Las Vegas, which apparently kept going till 5AM the next morning.

As a result, I did in fact go to the final day of the event, which means there will be a fifth and final blog to conclude this series, coming up in the near future, in fact about ten minutes time.

Cheersy Cheers

Paul