Back to the Future – Part 07
In my prior blogs:-
I talked about the historical background that caused me to want to re-write an application in a modern way, steps I have already taken to try and make custom programs more “portable” between SAP systems, and how I am going about building the new “modern” version of the example application.
The aim was to find a consistent way to make programs “universal” via the object orientated framework. I got some good feedback from the SDN community, and I think this problem can be described as solved, at least at a high level. One of my other aims to give a talk on this subject and this I did last week.
This is the end of the road. I managed to get through my speech at the Australian SAP User Group conference in Melbourne without being pelted by rotten tomatoes, which is a good thing.
I will end this blog, and this blog series, with my presentation and a sort of transcript of what I said but before that, and mixing up subjects in a totally uncontrolled manner, here are some random things I jotted down during the course of the SAP event.
– It was 27 degrees yesterday morning in Melbourne, but there was a hailstorm in the afternoon
– You can tell it is Melbourne and not Sydney, as people talk to each other in the street
I had some drinks with him on the Sunday evening and he did some demonstrations of what he is working on which is all basically ABAP programming but are as impressive as hell. This just gives me an idea of what is possible.
I was moaning about how when running a Web Dynpro transaction from within the SAP GUI you had to re-log into the same client you are already logged into. Often you then get the good old message that you are already logged in. I was thinking this made Web Dynpro not really a candidate for replacing the standard SAP GUI based screens.
He says there are two parameters that need changing in our system and then if you are already logged in to the client the Web Dynpro application wants to run in you will no longer be asked to re log on. If we get this going, at the very minimum that will be a good thing when playing with BRF Plus, as the developer user interface runs as a web Dynpro screen.
It turns out the parameters are set in our system but we need some sort of digital certificate also.
Graham doesn’t like search helps in SAP. He was showing me a custom quotation entry screen where you start typing the customer name and it did a Google like thing where a list appeared with suggestions as to what customer you might be searching for. Apparently that’s possible with what we have now technology wise, so I shall do some investigating. We have so many ship-to’s in our system that this most likely would not work too well for us in this particular example, but maybe another area could benefit.
SAP seem to have a very chaotic approach to user interfaces. One of their solutions is the Netweaver Business client, which will eventually be bundled in with the SAP GUI. A new version comes out next month which I will look at with interest.
I saw a presentation from ETSA – the electric utility company in South Australia – where they showed off what they had done with the Business objects front end, i.e. starting off with a big overview screen showing the state of the whole company – in this case all in-progress projects and whether they were on track or not – and then you could start drilling into details of problem areas, eventually ending up inside SAP in a transaction where you could start to do something about the problem. I imagine my company must have something similar, as we have a full BO licence, but I haven’t seen anything flash as yet.
On an unrelated note, he was using some sort of URL redirection where the user typed BOBJ into their browser and got redirected to the reporting home page and as far as I could see were even logged in as themselves without having to type their username and password. If you could extend this to all internal – or even external – URLS then the internet would then just be like SAP, where you type a transaction code in the white box at the top of the screen and get taken to the appropriate place. I don’t know if that is a good or bad thing…..
It is clear that HANA does what it says on the box – AGL (big utility company in Australia) got one of their batch jobs reduced from 60 hours to 6 minutes – but the product seems as if it is still years away from being stable. For example the latest version – service pack four – was announced at SAPPHIRE in may this year, and as of yesterday it needed to have 37 sets of patches / support packs (revision is what SAP call the patch fixes for this) since that point. For a mature product like R3 you would expect maybe two a year. I imagine SAP would also have to stop charging ten billion dollars also if they ever wanted anyone to seriously consider replacing their Oracle database with this.
Internet Connection Framework
This has been around for the last twelve years apparently. I just had a look in our system and it is active, running all the HTTP / HTTPS / SMTP thingies which I don’t really understand except that this is how the internet and email talk to things.
The basic premise is that SAP can talk to any sort of URL and get a response, and also reply to questions sent by an external system to a URL inside the SAP system, without any need for middleware such as PI.
Something is transaction SCOT was demonstrated which I did not know was there. If someone sent our SAP system an email (not sure how they would do that, what is the email address of our SAP system?) you can set up some configuration entries to say that based on the target details of the email / fax / whatever you call a certain ABAP class to read the contents and deal with it however you want. You can set the classes as exclusive (deal with the message and stop) or not (deal with the message and then pass it on to any other classes set up which may want to do different things with it).
Transaction SICF works in the same way with incoming messages from the internet. Based upon the URL that is sent to the SAP system (again, whatever the URL of our system starts with) you can have one or many classes dealing with this i.e. reading the content, doing something and responding.
This is something from the same company that makes RevTrac that was free and we have installed, and is supposed to look for custom objects that are in production only, or test only, or different between production and development and yet are not currently being worked on etc.. I don’t think it works properly yet i.e. it tells me every single object in production is different to its equivalent in DEV and I know that is not the case – and so I am in a constant dialogue with their support people. I had a big victory two weeks back and they now acknowledge one problem I pointed out and will put the fix in the next release.
This is not really very relevant to my company, but as we are curently implemeting the Ariba procuremet solution it has some parallels, anyway it was interesting who the “cloud” vendors try to fool people when negotiating contracts e.g. in the case of Success Factors
– They start charging when the project starts, not when the project goes live
– They charge based on the number of employees in the company, not the number of SAP users.
That caught out Transfield services, by the looks of things, according to the lady who talked about this.
A German woman from SAP kept on and on about how there are now more mobile devices in the world than toothbrushes. According to a survey 22% of people would rather give up brushing their teeth for a week than spend a week without their mobile gadget. 33% said they would be prepared go without *** also, though the question arises as to whether the sort of person who spends every waking second playing with an IPAD would be getting any in the first place.
I like torturing the people on the SAP stand by asking them questions about what the speakers from SAP have just claimed on stage ten minutes earlier. Naturally the people on the floor who have to deal with real humans are not informed as to what the content of the speeches is going to involve. A fine example is a claim I have heard many times on SAP presentations, and once again this week from an SAP speaker, and that is that SAP are now bringing out improvements e.g. new functionality to the ECC 6.0 core product every quarter. The examples on the slide on the screen were clearly function inside R3 not in any external product, and it was clearly saying this came out march 2012, this came out June 2012 etc. however an enhancement pack only comes out once a year. How do the two things tie up? They don’t, clearly, and it was a mystery to the SAP people on the floor why their high level executives keep claiming this.
As people may know there was no financial crisis in Australia – though you would not know that by reading the papers here – but as I have been living in the UK recently I can tell a real crisis like the one in England to a minor slowdown in the growth of the economy like the one in Australia.
At the SAP conference there were the usual representatives from the mining industry giving speeches – in this case Fortesqueue metals, and Brazilian Mining company Vale. They were both laughing at the headline in yesterday’s papers which said that the mining boom was over in Australia because BHP had cancelled 60 billion dollars’ worth of expenditure. Vale is particular are almost as big as BHP and they claimed yesterday the mining boom had only just begun for them. Fortesqueue were of the same opinion, they are intending to triple in size in the next two years, and they seem pretty big already by the looks of things. They both clearly believe China’s claim that by the year 2020 China will be building 20 new cities every year. That does seem a bit ambitious,it usually takes the government in the UK one year to repair one street in a city.
Talking about building, there was a talk by AP mentor John Moy about the so called “gateway” that SAP uses to talk to some external devices. The analogy used was based upon a quote from an architect from about 1992 who said there was no such thing as a building. That would seem fairly easy to disprove as you can point and say “look – that’s one there”. Anyway the logic was that you have the foundations, which are supposed to last 80 to a hundred years or more. Then you have the outer structure, which you can knock down every 30 years or so and build something else on the same foundations. Then you have the inner walls, which in an office building can be re-arranged every so often, and lastly you have the furniture, which you move around all the time. This was called ‘pace layering’ in that certain things changed faster than other things.
The analogy was that software was like that with some bits changing faster than others. Traditionally you upgraded every five years and all the parts changed together.
In my opinion SAP have tried and tried to separate this and never succeeded. For example you can’t have the latest version of the ABAP language without upgrading your applications also, and vice versa. There is a new development tool for writing programs in ABAP called ABAP in eclipse, but you have to upgrade your entire system to use this i.e. change the 95% you don’t want for the 5% you do. So, now once again SAP claim the “gateway” means that you can connect SAP data with any sort of mobile device, and as the UI changes you don’t need to change anything in your SAP system. Yes, yes, heard it all before. Ironically, the only thing SAP ever seems to have successfully separated from the core is the “software update manager” which you use to upgrade your system, and now sits outside of the system to be upgraded. However SAP’s dream they waffled on about some years back of an “Enterprise Services Architecture” with different elements evolving at their own speed all sort of fell totally flat, mainly due to SAP marketing insisting all the elements had a unified release cycle.
SAP’s latest user interface technology is called UI5, based on a technology called HTML5. The explanation of why this is good goes right over my head, it is something to do with caching things differently and caching a lot more, right down to a web page being able to function even if the connection to the internet goes down for a short while (seems like black magic to me). What is clear is that SAP are already losing interest in Web Dynpro, which is just not fair I have not even got my head around how to use it yet, and already it’s obsolete.
Things are not funny unless they are true, and Graham Robinson was giving a talk about user interfaces and he was talking Business server Pages and about using the pre-configured array of elements that SAP supply when building web pages. He advises not to use them because “it comes out looking really bad, it is difficult to describe how ugly it looks. In fact it is as bad as Web Dynpro ABAP – yes, honestly, it’s that bad”. He does have a point, Web Dynpro applications to me look just like your normal SAP gray screens like VA01, only in the Web, so they run slower, and not as pretty, and just different enough from SAP GUI transactions to confuse the users.
Lastly, to end on a funny note, people kept trying to sell me “BCM” which is SAP’s call centre solution (i.e. the equivalent of GENESYS which interfaces incoming phone calls into SAP). I even saw a talk about this, about a medical company who have implemented this, just to see what this was like. I have several points to make
– I can’t see how you could improve on what we in Hanson Australia have got at our Customer Service Centre, and we use the same CIC0 transaction from within the ERP system that we used in the year 2000
– Despite the claim ‘this is all within SAP” it is not. It looks like this was a product SAP bought and then pretends it’s a native SAP product that talks to SAP via Web Services
– It presumes you use CRM
– It is still very new – only two customers in Australia
– In the speakers presentation his company had to put their project on hold for five weeks – earlier this year – whilst they waited for SAP to fix a show stopper bug in the product
– They had another five week pause two month latest this time the bug could not be fixed and is still unresolved, so they only went live with a subset of the functionality
– What was the missing piece? Phone calls. The product can’t handle them they come out with the sound all funny. However both the client company and SAP are optimistic that “one day’ this will work.
And then, second from last, it was my turn…..
I’ve just spent the last two years in the historic town of Heidelberg, Germany, right next door to SAP headquarters in Walldorf
On the morning of the last day of the SAUG Summit 2012 the keynote speaker was the CIO of PABST brewery in the USA (he was though, an Australian). The brewery Pabst was created 1848 and he described this as “being around forever”. That is a long time, but to put this in context, back in 1720 an Italian dwarf whose nickname was “Perkeo” got a job in Heidelberg castle as court jester. At that point Heidelberg had already been a university town since 1386. The first mention of Heidelberg was in 769AD.
Anyway, the most important thing about Heidelberg castle is that it had – and still has – the biggest wine barrel in the world. There is a dance floor on top of it these days. Perkeo claimed to the prince that he could drink the entire contents, and so it was decreed only he could drink for it, and so he started drinking wine all day every day, as fast as he could.
A year on, he was making good progress, but asked if he could have one day off. This was granted, and on his day off he drank water, caught cholera, and died the next day.
That was his story – this is mine
When I joined the organisation in 1990 it was called Pioneer Concrete and the prime focus was ready mixed concrete. In the year 2000 Pioneer was acquired by Hanson, which was primarily an aggregates (quarry) company. In 2007 this was in turn acquired by Heidelberg Cement and you can guess from the name what their focus is. So, we make all manner of building products.
Heidelberg Cement is listed on the German DAX stock exchange, and is active in about 50 countries. For all IT solutions SAP is the solution of choice.
Hanson certainly was not acquired for its IT systems, but by a happy accident it turned out all the development we had been doing in Australia was perfectly complimentary to that done in Germany. This is rather like buying a house and all its contents, and finding a treasure chest hidden in the cellar that nobody knew was there. Anyway, we had not bothered enhancing the FI/CO part all that much and they had, we had poured all our effort into sales and distribution for concrete and aggregates.
When Hanson was acquired by a co-incidence the UK IT system was dying of old age, so that country was an ideal guinea pig for the new global solution.
The global SAP system will take the best of both existing SAP implementations – Europe supplying the cement part, and Australia is supplying the aggregates / concrete part. Finance and controlling are per the global head office, SEM is used for global consolidation, Business Objects is used for front end reporting.
The Australian SAP system is independent, as we are an acquisition, the main system is on a single instance in Europe, as of now 18 countries all live on FI/CO and the Cement Business line, UK is the only country with the full global template installed, in the future other countries will get the global solution rolled out to them.
So the challenge was to ascertain the parts of the Australian solution best suited to the global template, ensure they could run in any country, and then copy them over to the European system. A piece of cake surely – or is it?
I have been on a lot of global rollouts. In every case the head office develops a global company and thinks that this will fit every country perfectly without any need for change. Every target country, conversely, thinks the global template is wholly inappropriate for their special needs and wants to change everything. This could be called the irresistible force vs the immovable object.
Naturally a compromise is reached eventually. One way is to have a different version of the same program for every country to do the exact same thing slightly differently. Instead, we want to have a “core” system shared by every country plus country specific bits, instead of having many different versions of the same program for many countries. Having many versions of the same program is bad because:-
– more to develop
– more to test
– more to troubleshoot
– more to maintain
The other key constraint is that one day, even if it is ten years away, the Australian instance may be absorbed into the global instance, and then we will have the global template rolled back into our system. given that, we want to export something that will still be in a recognisable form when we get it back.
There is a quote on this subject from Shell – once you put in electronic concrete, it is hard to get it out.
– customising values can change over time – you can have three item categories which get treated differently, and the one day you need to add another one, and then change ten programs, and you miss one
– customising values are different in different systems – it is almost guaranteed the material group for concrete will have a different value in one SAP implementation than that chosen by another
– the same customising value can mean different things in different SAP systems – the value ZXYZ might been one thing in Australian and something totally different in Germany
– it makes code hard to read – what is an ZXYZ item category anyway?
– the “magic numbers” that tend to be found in custom program code – the SAP programming guidelines in the code inspector pick up on this now. The very day before I gave my speech I spotted a change in our system where one of the programmers changed some code from adding a hard coded value of five to adding a hard coded value of ten. A casual reader would have no idea what that number meant – at the very least it should have some sort of semantic variable name to tell you it was unloading time, and moreover that value clearly changes over time, and you need to change the program each time, and also the value is most likely different in different countries
The solution is to abstract business rules from being hard coded in programs via the greater use of Z customising tables, just as SAP does in it’s programs ( or use BRF plus going forward, I am still experimenting with that, it is a bit flaky at the moment but shows promise).
We now also use a global customising table that I created, to enable any given program to run in different SAP systems whilst the code remains the same. In the example above we have country specific values for the concrete material group, and as a bonus the code becomes easier to read as we have a variable saying what it is as opposed to a meaningless term like ‘0005’ or ‘ZZBB’.
This is good even if a program does not have to be copied between systems as subsequent business requirements e.g. new order types – can be added with no programming changes.
I went through all my custom programs which had even a remote chance of being copied and made sure I removed all the “assumptions” from them – hard coded magic numbers and customising values. There were so many in all shapes and forms – even down to assumptions that purchase order numbers always started with “45” when it turned out that in the European system they started with “045”.
Moving from right to left, if we want to have the same program work in different ways in different countries we could do worse than look at how SAP itself solves a similar problem. Industry solutions used to live in separate add-ons totally independent from the core, but now they have been moved inside the ERP by means of the “enhancement framework” which works by using BADIS.
“BADI” implementations are filter dependent, which means in plain English that the underlying program reacts differently depending on what country (or sales organisation given a cement and an aggregates company are in the same country) the program is running in. This is also handy as it is the only way to redefine static methods.
Then we can make the model, view and controller react differently in different countries.
Now we take this concept down to the next level. The main class is the default BADI definition, the subclasses are the country (or whatever) specific implementations. All are based on the same abstract interface i.e. they all have the same signature and methods, which is how BADIs work. Note the abstraction of the persistence layer is important as then the data source can be different in different systems i.e. Z table in one system vs Characteristics in another for a particular application.
It is of course possible to implement a similar thing in a non OO way using remote PERFORM calls, but SAP recommends against this for a very good reason (i.e. no control of the interface). This problem is that this may lead to short dumps whenever a change is made and a new parameter is needed.
As SAP has evolved there has been a progression into from static to object orientated user interface technology. A good example of the former is the “fake” enjoy screen in ME21N which looks really dynamic by having one million static screens which appear and disappear so it looks like you are expanding and contracting parts of the screen.
Prior to ECC 6.0 the screen layout was very fixed, now the new OO ALV model and Web Dynpro can make the appearance of a screen much more dynamic i.e. able to respond to the environment (country) a program finds itself running in. This means, for example, that the model can tell the view what commands it can respond to, and the view can then programmatically put them at the top of the screen.
So, I have to identify areas where things are likely to change from place to place – a guess naturally, but an educated one – and put “stubs” (BADI calls) in. If you miss areas it is not the end of the world to put another stub in later. In real life I didn’t know how to do this at the time, but I do know thanks to much advice from the SDN, and going forward we can avert most of the problems that will occur if and when our two development systems are merged.
So now I knew the sort of thing to change in my existing programs in order to make them more portable, it was time to get them ready to be copied between systems.
Tobias Trapp always talk about the package concept which would make this sort of thing really easy, but we had put every single Z object in one package called “ZENGENERIC” so we were sunk.
A good feature ofthe ABAP workbench is the “where used list”. Using the standard database tables and functions (in reverse) I wrote a program to analyse dependencies between custom objects in order to make sure you identify every single object to be transported i.e. you start with a program and get back all the Z functions it needs, which in turn need Z tables, which in turn need Z data elements which may need Z domains etc…
I always talk about how naming and lack of documentation can make programs incomprehensible to other developers, I say that copying from the requirements document into the SAP object documentation adds 3 minutes to the development cycle for each object but it is never done.
Lucky for me, I had nine months in the UK whilst the business case was being written where I could not start copying things to the new system, so I went through every single Z object in our system and documented them. That also tells you what is not used – if you cannot work out what something is used for, it most likely is not being used at all.
How many people get an opportunity like that? Not many, which is why most objects in SAP systems have no documentation at all, including standard SAP objects.
So, the once in the life opportunity was over, but how do I avoid never documenting anything new ever again? We use a product called RevTrac to control transports between our system and I wrote a user exit to, at the point where I release my developments for testing, to shove a screen in my face showing me what things I have not yet created documentation for.
This whole approach had an unintended beneficial effect – every used object in the Australian ended up with documentation within SAP, lots of obsolete objects identified just in time for the upgrade.
How to copy over vast amounts of custom objects from one system to another – well SAPLINK is not news to anyone on the SDN but it took me longer to convince the powers that be that this was safe than it did to copy over all the objects.
I won in the end, so what would have taken months to copy manually – hundreds and hundreds of objects – took hardly any time at all
Once programs are copied they can easily start diverging like nobody’s business. This is often considered an insoluble problem so you have to live with it.
Now what if we could keep the two SAP systems in synch at least for “core” elements? Again we went to RevTrac and they told us how this could work. This is used in real life quite a lot by companies which have a special “project” development system as real as a real development system. The underlying idea is really simple using RFC calls to lock objects between systems. This is how RevTrac works within one SAP landscape, locking an object until it is in production, when normally as soon as a transport is released the object gets freed for other developers to work on, leading to possible overwrites and overtakes of newer versions by older ones.
Once the programs are fully “portable” you should only need two types of changes – bug fixes which neither side can argue with, if something does not work it need fixing, and stubs i.e add a new call to a BADI with an empty default implementation. Then each country can change their behaviour without influencing the core.
Conclusion – always end a speech by telling the audience what you have told them!.
The public speaking expert that Eventful Management got to give me a free lesson when I gave a talk a few years back said that really a presentation cannot have more than three points to make, otherwise the audiences brains will melt. The three points all have to relate to the same thing also.
The sentence that sums up the presentation is “what are the main challenges writing custom programs for use in multiple countries?”
The three points are:-
• Remove Assumptions from custom programs – before copying from one system to another, or just anyway as a general Good Thing
• Aim for 1 Core Program – encapsulate anything that may vary between countries using the enhancement framework. Again, does this anyway, just in case.
• Tools are there, or can be written in ABAP, to help at every stage!
As always, any feedback gratefully received….
Other OO Blogs:-