SAP TechEd Las Vegas – Day Five

Friday 29^th October 2017 was the final day of SAP TechEd Las Vegas 2017. I would estimate that 75% of people who attended the conference used this day to fly home instead of going to the final sessions in the morning. Recently I posted blogs about the first four days of the conference:-

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/

https://blogs.sap.com/2017/11/25/sap-teched-las-vegas-2017-day-four/

I could have gone out drinking with my fellow Mentors all through Thursday night and not go to sleep at all and end with breakfast at 5AM and then sleep it off. A lot of Mentors did just that but I had a rare burst of common sense and went to bed relatively early (i.e. before midnight) and thus was able to go to my final four hour workshop on the Friday morning.

Being a goat, Capra had no such qualms.

Goat Drinking Goat Beer

08:00 to 12:00 Upgrade to S/4 HANA Workshop

I mentioned earlier that the good thing about everyone going home early is that in any workshops on the Friday you do not have to share a PC….

Anyway, at work I sit near the BASIS department and though I am no expert by a very long shot I have always had a vague interest in the subject.

This stems primarily from the 2000/2001 time period where our SAP system kept crashing all the time and by necessity many people in the IT team, myself included, became experts on all the system monitoring / performance monitoring tools.

However the only involvement I have ever had with upgrades is doing the SPDD/SPAU exercise, and of course fixing Z programs that break during upgrades. Mind you, I have found that if a Z program passes the extended program check in the source version it most likely will work fine in the target version. At least until now – S/4 HANA changes all the rules.

For this reason I signed up to the four hour workshop on the Friday morning where you went through a simulation of upgrading an ECC 6.0 system to an S/4 HANA system. At this point I would stress that SAP do not call this an “upgrade” but rather a “system conversion”. In the same way putting in an enhancement pack into an ECC 6.0 system was not an “upgrade” either.

There is a famous quote about this:-

Is this an upgrade?

In any event, hats off to whoever designed this workshop, as we know the investigation part of an upgrade can takes weeks (months) and the technical conversion the whole weekend (or more) and they managed to condense this into four hours whist still getting us attendees to use the actual tools.

This was achieved by what I call the “Blue Peter” technique. You go through the wizard (or whatever) for a given stage, and normally the results take six hours to come back, but in the workshop there was “one they had prepared earlier” so you could see the results directly after you had finished whatever upgrade step was at hand.

The first point was that this is by no means a simple exercise. There are about twenty million steps and even with the wizards it makes your head spin. My conclusion is that the BASIS people earn their money.

The second point was that everything I was seeing was clearly cutting edge. You could spot that because during the morning the facilitators kept importing OSS notes into the development system we were using, presumably every so often a developer from Walldorf (or wherever) would contact them to let them know the bug fix/new feature had just been coded, can you test it please? What better place to test it than right in front of a room full of picky TechEd attendees on the lookout for the slightest flaw in the system.

In any event the aim of the game was to upgrade an ECC 6.0 system to a S/4 HANA system and there were a series of exercises where we has a crack at using the various tools you need to achieve such a task. Obviously condensing what can take a year into four hours is going to have to skimp on some of the details, but we could get the general idea.

The vast bulk of the exercise is not really a BASIS task at all, but rather what could be called the investigation phase where you run various tools to tell you what is going to break during the upgrade, and then you can fix this in advance of the technical part of the upgrade – the bit that takes a weekend.

The very first thing to is to run the so called UPL (Usage and Procedure Logging) in your productive system (the UPL runs in Solution Manager and monitors your production system). How long should you run this for? A year. Honestly. SAP says you need a year so you include all the year-end procedures.

This will generate data as to what is actually used in production. In my company for example we are going to start this from January the 1^st next year, even though we will not be migrating to S/4 HANA till 2025. The point is to identify the 75-90% of custom code in your live system which never gets run at all during the year. If we do this exercise now, it will make life a lot easier when we do the real thing in six or seven years’ time, given we have about twenty years’ worth of Z development already.

Now comes the confusion. I am sure I have got this wrong, I really hope I have got this wrong, but the diagram we were given clearly implied that you need different web browsers for different tools.

It must be wrong, but it said that you need a Chrome browser to access the HCP, and a Firefox browser to access the “maintenance planner”. That would be crazy, would it not, so it can’t be true?

Next, in the solution manager you run – via SE38 – program SOLMAN_AGSRC_START_ANALYSIS which will give you all sorts of handy hints regarding what is actually used in your system and is likely to stop working. I imagine you turn this over to the functional analysts and programmers to have a look at so they can find alternatives. You can tell when something is brand new, as it does not have a transaction code yet and is not embedded in some sort of cockpit transaction.

Now this is where I start getting confused. You have just done that, and now you do it again, once for standard code, and once for custom code. Why twice for everything, with three different tools?

The next tool works only for systems on 7.31 and above, and the transaction code is /SDF/RC_START_CHECK. This tells you what standard SAP code in your system (that you currently use) is going to break. That sounds odd until you realise that many standard modules in ECC simply do not exist in S/4. If there are three possible solutions – e.g. for credit control – two of them get nuked and only one remains as part of the “simplification”. So in such cases you have to start migrating form SD credit control (for example) to the “financial supply chain” equivalent.

In the same way many people forget they have to migrate to the “new” general ledger (a process that has to be done at year end, and can take a year of planning and execution all by itself) before you can move to S/4 HANA.

The next tool is all about seeing what custom code (that you use) will break when you move to S/4 HANA. This is done by extracting all the Z code in your current system, and merging this with UPL data to restrict it to code actually used.

You then upload that data into a 7.50 plus system and merge THAT data with the “simplification database” that lives in the cloud, and the end result is a list (a very long list) of what Z code will break when you upgrade.

At least that is how is has been in recent times. That is how I proceeded with a 7.02 source system for example, running transaction SYCM in a 7.50 system (EHP8) to look at the results.

In this session I am told that sort of behaviour is so ten minutes ago, SAP has a brand new approach to this.

Transaction SYCM is no longer to be used, now the analysis system needs to be 7.51 or above (i.e. S/4 HANA) and you go through the ABAP Test Cockpit (Transaction ATC) which does an RFC into the source system. The whole idea is exactly the same as before though, checking all used Z code against the “simplification database”.

As a funny joke, you need to be able to specify the target level which you are upgrading to, but that field (target release) is not on the selection screen yet, an OSS note was being worked upon at the same time the workshop was occurring. This is of course, cutting edge stuff which is not ready for real life use as yet. Personally I am fine with this, I would rather see what is coming, even if it does not work as yet.

Now we were promised some worked examples of possible results you might get and what to do about them. Sadly the examples given were not all that realistic.

As an example you probably know by now that the material number data element MATNR is going from 18 characters to 40 characters. You might think there could not be many problems with extending the length.

Unless of course you find Z code like this (which was the example given).

DATA: MATNR(18),

WERKS(4).

Followed by some data retrieval and then WRITE statements.

I started programming in 1997 and even by then code like that was thin on the ground. I have never written code like that naturally I always do something like:-

DATA: material TYPE mara-matnr …… and then call an ALV.

I have no doubt some companies might be crawling with Z code that is over twenty years old, and hence might be in trouble, but I personally feel I am too young to know how to write a program using WRITE statements in the same way I cannot program using punch cards. I am 49.

I would say there are two possibilities:-

1. There are loads of common problems you will find with relatively recent code (10 years or less) and if so, examples should be easy to come up with, or
2. As long as you have code which passes the extended syntax check and code inspector, you should be pretty much right

I wonder which it is. If SAP are struggling to come up with realistic examples, which they clearly are, it hints at the second possibility, but just to be safe I would really like clarification on this.

Harry Potter and the S/4 HANA Chamber Pot

The first exercises were thus about generating lists of code that would break during the upgrade, be it standard SAP or custom. When you have figured out what to do about all these problems, you fix up your development system and then the time arrives to “convert” it into an S/4 HANA system.

As I may have mentioned until recently, amazing as it may seem, this involved dumping tons of data from SAP R/3 into spreadsheets and then uploading those spreadsheets into S/4 HANA. You probably recall this process from when you went from your “legacy” system to SAP R3. This time SAP is the legacy system.

Luckily what I was seeing was cutting edge – that is, still under construction hence the OSS notes getting applied during the workshop. This means no more downloads and uploads.

Instead there are a string of “wizards” to help you through the “upgrade” process. This simplifies things somewhat but it is still a fairly complicated process with tons of steps, and of course in real life each step is likely to run into some sort of fatal error half way through. Thus I do not envy my BASIS colleagues one little bit. We are currently upgrading to EHP8 and that is bad enough.

Aunty Climax

For those of us who actually go to the events on the morning of the last day it is always a strange feeling when the event ends, as it ends not with a bang but a whimper. Last year the Australian Ariba conference lasted two days and had a party at the end of the second day. That is always risky in case everyone wants to go home (possibly in a different country) the instant the conference ends, but in the Ariba conference that did not seem to be the case. It just suddenly occurred to me that Ariba and AirBnB are spelt very similarly. You never see the two companies together, maybe they are one and the same.

In conclusion that rings to the end my series of blogs about SAP TechEd Las Vegas 2017. I will not be able to afford to go to another one for a few years, unless I am living in Germany next year in which case I shall rock up to the Barcelona one. However, this one was great, everything I could have asked for. I hope this blog series showed you how varied the content of this event is, and this was just my set of choices in a seemingly infinite number of presentations and workshops and so on.

Cheersy Cheers

Paul