Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

ABAP - The Special Snowflake

Nigel_James
Active Contributor
‎07-02-2018 11:00 PM

ABAP - The Special Snowflake


The other day I poked the bear. Bears for the most part are things that should be left to their own devices as my Canadian friends will attest.

The bear in this case was Dennis Howlett who has been a long time friend in the enterprisey space
I met back as part of the media and influencers team at Sapphire and Teched events around 2006.

Dennis was asking about the new ESME as part of a conversation about Diversity amoungst the SAP Mentors. (That is a blog for another day)

I replied:

Now for background #ESME was a Enterprise Social Media Experiment that happened around 2006-7ish and could have been something cool. It became an apache project which was qudos to the people driving it https://esme.apache.org/.

So Den was asking about what the new cool edgy thing was around SAP these days. As I said in my tweet above it is my opinion that that is #AbapGit with a whole lot of whitespace until second.

Then (which is what I was hoping would happen ) Den looked into #AbapGit and dropped the following:

The conversation that followed continued on for days across timezones picking up a whole lot of other voices and opinions on the way through.

My attempt with this blog is to try and bring some of those opinions into one place and simulate the conversation further as to what sort of innovation we are looking for around the SAP technology space. And if you are short on time here is the tl;dr:

  1. ABAP has legacy tools

  2. ABAP has legacy culture

  3. It is stuck there and will never ever move

  4. ABAPGit is the best thing that happened to the ABAP ecosystem since ABAPUnit

  5. Adoption of both of these toolsets are woefully low (Please see point 2.)

  6. These are exactly the tools that we need to create CI/CD platforms for SAP landscapes.


There. If you want to skip to the next blog... go for it but first identify what culture is happening amongst your ABAPers or your offshore team.

If you want to enjoy the rest of the story then fasten your seat belts, return your tray table to the upright position and hold on.

#Disclaimer


Let me provide a disclaimer for those that love ABAP to a fault ( Hi c436ae948d684935a91fce8b976e5aa7, Hi jelena.perfiljeva2 ). Yes, ABAP is awesome and yes is does power half the planet if you believe SAP's marketing department but being great is not enough - all languages need to improve and get better.

Am you saying that ABAP is not doing this? I mean that is a pretty provocative, click-baity title you put on this blog there Nigel.

Yes it is provocative and no - ABAP is innovating ( Hi horst.keller ) There are incredibly talentent people inside and outside SAP pushing to improve the language, toolset and culture to become the best that is can be and when they are finished they will go some more.

The problem is that good ol' ABAP is for all intents closed source prorietory language. My other two favourite languages that include the letter P ( Python and PHP ) are not. They have continually innovated around their core. Just the other day I saw Zeev Suraski one of the co-architects of PHP saying that the next release of PHP would be 4-5 times faster than version 7. This is not bad given that version 7 was twice as fast as version 5.x that preceeded it.

What languages carry with them - more than anything else is legacy baggage. PHP certainly does - and routinely get bagged for it but many companies including Facebook, Slack, and Mailchimp have PHP at the heart of their business and serve many millions of customers. Enterprisey enought for you? ABAP, coming from its FORTRAN and COBOL roots has a very verbose nature and weird keywords. That's why we "love" it right? Many improvements over the years have been welcome and the code we write in ABAP today is not the code we wrote 20 years ago.

What they also bring is toolsets, "tecosystems" ( Thanks @sogrady ) and a culture that grows up around them.

#ABAPGit can shift the ABAP CI landscape


My thesis in this twitter thread that developed was that #ABAPGit could bring new ways of deploying code to the ABAP Ecosystem just as #UI5 has brought innovation to the Front End and HANA has brought innovation to the database.

Other believe the culture needs to come first:

Graham is right though. Enterprise mindset is hard to break down.

In other development enviroments the deploy to prod as often as required is commonplace. When I gave a talk about learning #git back at #SAPTeched in 2015 I had a guy from Github in the audience. Thankfully he identifed himself after the talk and told me how they deploy regularly with the record from issue being opened to fix in production being "2 minutes"* (Actual time may vary - but rest assured it was not 6 months)

I have since heard similar stories at Amazon, Facebook, Netflix. Why does the enterprise (read ABAP based platforms ) have to be different?

The toolsets are available


Chris Paine nailed it early on:

And there you have it:

  1. Unit Testing

  2. Decentralised Branch Based Repository

  3. Automatic Migration

  4. Branch based deployment


People like @grmpyprogrammer, Chris Hartjes, have been preaching Unit Testing to the PHP Community for years, probably 18 years. The toolsets and workflow are well established and while it has taken people like Chris years and years of banging the drum the message has gotten through.

ABAP Unit has been with us for at least a decade but how many of us unit test our ABAP code? How many of the 'offshore' code factories include ABAP Unit tests as part of their deliverable?

Where is the ABAP Unit culture? Happily there are more voices promoting unit testing recently.

Even in the Java world JUnit and friends have made testing common. Which is why Chris Paine is happy developing extensions in the cloudy world:

But to do this he is using unit testing, branched based source control and automatic deployment mechanism. ( Chris may want to chime in and correct me here I dont actually know his workflow I am assuming it based on his tweets. )

Ethan Jewett had some really great comments to add - he joined in with:

And unsurprisingly (as Ethan always has great things to say) there is another thread on modern ABAP practices starting here (from 2016) :

and again as Matt Harding pointed out that this conversation has been going on for quite some time pointing back to a tweet from Chris Kernaghan from 2014.

And the kicker which really sums up the ABAP Culture is this:



Personally - I have never wanted to stay with my own set of tools. I am not an ABAPer. I solve problems that can (sometimes) be solved with a computer program and I am happy to say that over the years I have contributed to many sucessful implementations just as I have contributed to things that have never seen the light of production.

About four years ago I took on a client who was the farthest from SAP as anyone could imagine. They were a content platform startup. Small team using PHP and a little framework called Laravel. Thankfully they didn't let me at the code. I did a more robust data replication proof of concept for them. While I was there I learned a lot about how this team used:

  1. Unit Testing

  2. Decentralised Branch Based Repository

  3. Automatic Migration

  4. Branch based deployment


Sound familiar? Every other team and platform does this. Ethan is right. ABAP is a Special Snowflake.

So here is the cultural challenge to all those who are die hard ABAPers. You need to embrace the new tools and new ways of doing things.

I hope this has raised a thought and sparked more conversation.

Let's not be doing something because it is Not Invented Here.

I will leave you with the Knights who say NIH

[and yes I wrote this blog in markdown using Sublime Text 3 and used github to version control it ]

 

Update - 4 July: Dennis has added his thoughts to this conversation and the comments are worth a read.

Update - 6 July: This post caught Hasso's attention and is asking for feedback about what is really needed:
imo scp offers all or most modern code management and deployment options of the cloud world. many of the abap improvements will show up first in the cloud, only there sap can make more radical and incompatible changes because of the separation of standard code and extensions.
- hasso
88 Comments
ChrisPaine
Active Contributor
‎07-02-2018 11:21 PM
Bravo! Nice summary, and yes your intuition was right as to my Dev/support flow... Although as you point out, it's not that hard to guess, as that is what pretty much _everyone_ outside of ABAP Dev does... ?

I'll add my additional slant on the conversation, which is that customers would possibly get a much higher ROI ditching the ABAP teams when it comes to enhancements and then using existing CI/CD tooling and SAPCP and people who understand it to support their enhancements.

But that lead on to the culture and dev/ops discussions...

And then we will just end up shouting Nih at each other ?

 
Former Member
‎07-03-2018 12:16 AM
Hi Nigel,

although i didn't participate in the topic at hand and can certainly appreciate the industrial strength of ABAP, i liked most your including of tweets, linking, and tagging other fellow SAP cummunitars on the subject.

thx, greg

 
Nigel_James
Active Contributor
‎07-03-2018 1:27 AM
Bring me a Shrubbery
Nigel_James
Active Contributor
‎07-03-2018 1:31 AM
0 Kudos
Hi Greg,

Thanks for your comments.

There is no doubt that ABAP is an industrially hardened language that is keeping the systems going in companies with billions of dollars of revenues.

We can continue to improve our practices and learn from other platforms.

"The times they are a changing" 😉

 

Cheers,

Nigel
jwood_bowdark
Active Participant
‎07-03-2018 3:25 AM
Besides the political and logistical challenges noted above, I think there's another important factor in all this that had nothing to do with ABAP as a language, the ABAP Repository or TMS. For example, if we spin out the Python or PHP comparisons above, one of the more notable differences is that those programming environments don't come with the baggage that is the AS ABAP application server. To me, it's a LOT easier all the way around to approach CI/CD if you have a flexible, microservice-based architecture to work with.

Just the other day, I had a two hour call discussing the logistical challenges of rolling out a couple of simple OData services on an embedded Gateway instance. Here, I had to state my case to system owners concerned that this could interfere with month--end financial close activities, etc. Even though these services were innocuous and 100% unrelated, you can understand the trepidation because we've all had experiences where the smallest of changes break production.

Now, compare that experience with say Python. Here, I can create my services individually, package then up in Docker containers, and deploy them in isolation. And, if my services need more oomph, I can scale them horizontally without having to go stand up another app server instance.

To me, there's really no debate here as to which approach makes the most sense. What's interesting to note here though is that there's nothing really that special about Python or Node that sets them apart from ABAP. It may be a little verbose, but we could definitely accomplish similar things in ABAP if we had access to a more lightweight runtime environment. Maybe we're headed that way with the ABAP environment on SAP CP, but the question there I think is whether or not ABAP is better/more productive than other modern environments.

Anyway, that's my two cents: until you break up that huge monolith that is the AS ABAP, I'm skeptical about how much traction we can really hope to expect on the agility front with ABAP.
matt
Active Contributor
‎07-03-2018 6:12 AM
" the code we write in ABAP today is not the code we wrote 20 years ago."

Unfortunately, for many it is. Standard tables are used in favour of hashed or sorted. My anti-favourite FOR ALL ENTRIES is used in favour of joins. And if people won't spend time to get to grips with OO, then unit tests are a distant dream.

But! The code I write in ABAP today is radically different from what I wrote 20 years ago. And, since I did the ABAP Unit Test course on OpenSAP earlier this year, quite different from what I wrote last year!
Nigel_James
Active Contributor
‎07-03-2018 6:21 AM
0 Kudos

Yes I am with you James – at one level they are just server side languages. ABAP has comes with a whole DB slapped on the back and for historical reasons that Vijay mentioned https://twitter.com/vijayasankarv/status/1013636904607076352 it is a whole box and dice that does a great job and is stable as .

JavaScript could get its own special snowflake award for changing frameworks every 3 seconds.

CI and CD are areas for improvement in the ABAP stack and awareness of ABAPGit and ABAP Unit and developers using these tools will force change on the C-suite.

(At least that is my hope – I am really looking forward to learning more about ABAP on SCP.)

N

qmacro
Developer Advocate
Developer Advocate
‎07-03-2018 8:59 AM
Very interesting conversation, thanks for summarising it so far and extending it, Nigel!

A minor point, but I wanted to add some comment to the historical angle, only to provide background to where things are (and where things came from). My memory is rusty in parts, so I'll do my best.

ABAP didn't come from R/3, it came from R/2. Saying that it came "with a whole DB slapped on the back" doesn't feel quite right to me. It was added as a simple reporting language that was originally interpreted outside of the main stack (in batch jobs!), but as it evolved, modulpools (codebases behind transactions) and other functional and structural units that had existed in assember were rewritten in ABAP. For a time in R/2 there was a hybrid world of assembler and ABAP (I remember writing exits linking ABAP and transactional assembler code).

When R/3 came along the transition away from assembler was complete, and the core existed in ABAP, where the ABAP engine was a fundamental part of the entire R/3 architecture, including the major parts of the R/3 work processes: the task handler (which was the entry- and coordination-point for the dispatcher), the dynpro processor (that handled the PBO/PAI logic) and then, at the bottom of the stack, the ABAP engine. This in turn was closely linked with the data dictionary which provided not only an abstraction layer to all the different RDBMS systems that R/3 supported (remember Informix, SQL Server?) but also facilities that today we find directly in programming languages themselves, i.e. structure definitions and so on.

There's obviously a lot more to it than that, but I wanted to at least set the scene for ABAP's origins, a scene that at least qualifies to some extent where we are today. None of this background means that it's impossible to get to where we want to be, but I thought it worth sharing anyway.
UweFetzer_se38
Active Contributor
‎07-03-2018 12:30 PM
Hi Nigel,

exactly my thoughts (and yes, I've read the thread on Twitter, too of course).

A note to Den (I doubt he's reading this): contributing <> commiting. I know many Mentors and non-Mentors who contribute to abapGit (incl. me) by talking to the devs (in person, vial mail or even twitter  or by raising an issue) without commiting one line of code.

To change the situation in the direction for CI/CD you (we) have to change a) the mindset of the ABAP devs and b) the technical environment.

a) is hard. As you may know I'm an employee since a year now (after 20 years of freelancing). Changing the mindset of "my" developers is very hard if not impossible. I think I've reached less than 50% during my trainings (OO, Clean Code. Eclipse, Unit tests,...). That can't be my fault only 😉

b) is even harder I think. As long as we only have ABAP development on a central development server it's quite impossible. I'm preaching since years that we need separated runtimes for every developer, let it be local or on the server itself. (this would also solve the problem, that ABAP in SCP needs a whole ABAP stack for every customer)

Hoping the best for the future.

And as always: #ABAPsNotDead
Jelena
Active Contributor
‎07-03-2018 6:22 PM
Here we go again...
So here is the cultural challenge to all those who are die hard ABAPers. You need to embrace the new tools and new ways of doing things.

But why do we need to embrace anything? Just because "other languages are doing it"? Um... If other languages jumped off the bridge then should we too? 🙂

With backwards compatibility, SAP makes it too easy to program like it's 1999. Today, I can write a horrible program using FAE, binary search, tables with header lines, use obsolete FMs - ain't nothing stopping me, unless you put some mandatory checks in the transport release. (Which many companies don't do.)

As long as the program runs and doesn't cause huge performance problem (and if it does we'll just hide it in a background job), the business users won't care either. And business is paying ABAPers salaries.

The older ABAPer generation is moving to retirement. There is little incentive for them to care about what happens after they retire. Not saying that about everyone over certain age but let's just be realistic and honest here.

Slightly younger ABAPers are looking around nervously since, as you're saying, we should just all be fired and replaced with people who know better how to do stuff. And SAP is sending us mixed messages. One year ABAP is dead, everything is Cloud. Next year - hold on a sec, where are you going, we're not dead yet. But then, realistically, how many current SAP customers are going to drag current ABAP with them when they go to S/4HANA (assuming they even remain SAP customers)? It'd make more sense to go "greenfield" and just shed all custom ABAP.

So if ABAPers chose to make as much money right now using good old knowledge instead of investing in the skill that will become obsolete soon - that seems like a rather rational decision.

In Marxism theory, there is a term revolutionary situation. To start a revolution, you need that kind of situation: when "the bottoms don't want and the tops cannot live in the old way". I don't think we're at this point in the ABAP world. There are some sporadic upheaval here and there but overall, as I mentioned, it's entirely possible for "the bottoms" to carry on while "the tops" are content with that.

Not sure how long this will continue but I'm guessing until everyone abandons their ECC and most ABAPers will be sent to the farm upstate (much to chris.paine 's chagrin 🙂 ). Natural selection will sort out the rest. I.e. evolution vs. revolution.

...aaaand to learn more ABAPosaurus Evolution make sure to book a TechEd LV ticket and attend my session (which I hope won't be scheduled for Friday). : )

Cheers!
UweFetzer_se38
Active Contributor
‎07-03-2018 7:36 PM
(only a short reply from my side because I'm just waiting in my car on a parking lot waiting for my son)

You asked "why?"

Because your don't have the time anymore to understand unreadable code.
Jelena
Active Contributor
‎07-03-2018 10:06 PM
0 Kudos
I'm assuming you meant jwood_bowdark . Please know that he won't be notified of this comment. We have to click the Reply button on the specific comment or use a mention, like I did here. Unfortunately, it's rather difficult to have a discussion in the comments on this platform as we're only notified of direct replies. 😞

 
Nigel_James
Active Contributor
‎07-03-2018 11:10 PM
0 Kudos
Yes I did. Thank you jelena.perfiljeva . I only noticed that I hadn't replied to him later.

N

 
Nigel_James
Active Contributor
‎07-03-2018 11:14 PM
ABAP is most certainly not dead. It not deadness is one of it's most enduring attributes.

As you say the central development model of ABAP is one the key things that makes it tricky for CI/CD.

Thanks for your comments.

Cheers,

Nigel
Nigel_James
Active Contributor
‎07-03-2018 11:24 PM
Let me quote bjoern.goerke from the post you mentioned.
Very nice! Indeed, it’ll be tough to win in today’s world with yesterday’s skills only. And it’ll be impossible to survive in tomorrow’s world with only the skills from the day before yesterday. Keep moving!

Other languages are not "jumping off a cliff".  They are on the TGV fast track to innovation.

In many ways ABAP is tied to the train track.

The business users care when the FAE fails - loads a millions of records and then due to a logic fault ignores those millions of records and then keeps running but an order of magnitude slower. Perhaps an automated test could have found that error?

We all love ABAP. We all want it to continue to innovate. We all need to improve. #LifeLongLearning

Cheers,

Nigel
Nigel_James
Active Contributor
‎07-03-2018 11:29 PM
0 Kudos
Which is exactly why Robbo and I write posts like this and his "Call to arms" from 6 years ago.

And yes ... I am glad that the ABAP Unit Test course is on openSAP.

Thanks for your comments Matthew,

Nigel
Nigel_James
Active Contributor
‎07-03-2018 11:37 PM

Certainly DJ and thanks for jumping in here.

I think what I was leaning toward is that the code is compiled into the DB (if I am not mistaken) so the code artifacts are not file system objects in the way that they are in say Java.

For where it came from and the historical context ABAP certainly was groundbreaking.

Let’s not rest on our laurels.

N

GrahamRobbo
Active Contributor
‎07-04-2018 1:42 AM

It is impossible not to like jelena.perfiljeva2 – but ….

I am not interested in working in a stagnant industry. One of the great things about this industry is that it is always changing. Not interested in working for Kodak, Blockbuster or a fax machine manufacturer either.

I am not interested in working with stagnant tools. I have my favourite text editor – but it regularly changes as better ones come along. Abobe Flex was awesome in it’s time – not so now.

But I do want to be better at what I do – and doing the same thing over and over again wont make me better.

I want to improve my tools, techniques, knowledge, experience, etc.

I want ABAP to be better too. I want it to continually improve. And it has been improving quite a lot – apart from a few years in the early 2000’s when SAP was distracted by shiny moving things.

And if my tools improve I want to learn how to use the improved tool in the best way possible. Why would you try and chop down a tree the same way you did it with an axe when you have a chainsaw?

Maybe it is just me? Perhaps it is all about my short attention span?

For those that have taken the decision to just coast through – whether to retirement or otherwise – I can’t criticise that as long as the reasons make sense to you. After all “enhancement framework wont give you a hug” and no one on their deathbed ever said they wished they spent more time at work.

For me – I believe in lifelong learning. So I am afraid coasting through wont work for me.

On my deathbed I am 100% certain I won’t be saying “ABAP” – but I might be saying “learn”.

Nigel_James
Active Contributor
‎07-04-2018 2:07 AM
0 Kudos
hear hear!
former_member586827
Explorer
‎07-04-2018 3:22 AM
Hey Nigel,

I totally agree with you. We must start moving towards innovation and find smarter ways of doing things rather than JUST doing things !

 

Cheers,

Pradeep G.
qmacro
Developer Advocate
Developer Advocate
‎07-04-2018 7:11 AM
Definitely, let no laurels be harmed in this process.
hardyp180
Active Contributor
‎07-04-2018 9:38 AM
I was at the abapGit meeting in Southern Germany last Saturday. It is literally amazing how good abapGit is already and it gets better with every single passing day.

This is also a snowball. The more people who use it, the more problems they will find and then - hopefully - the more they will start contributing.

How I explained it to my wife was that there are two sorts of custom development - specialised for your industry - concrete, automotive, chemicals or what have you - which give you a competitive advantage, and boilerplate code like logging and the like used by every single company.

So if there are 200,000 companies with SAP development departments, that means that 200,000 different custom Z logging frameworks have been developed, all wrapping the standard BAL function modules in some way. In fact there may be more, with different developers in the same company creating their own Z logging frameworks.

The answer is to have the boiler plate things be open source projects, managed by abapGit. You also would not belive how many side projects Lars (inventor of abapGit) has going, all of them revoluntary in their own way.

I am also doing TDD in my day job for the first time and you would not belive how well that is working. It is forcing me to design my program properly.

Here is an example of the maxim “as the tests get more specific, the code gets more generic”.

In this case I had a business requirement that after the user enters the customer the ship-to list must automatically appear – but only once. If they exit out of the list then they must press F4 to get the list again. Otherwise you get an endless loop.

So I handled it by a “global” (member) variable to say if the list had already been called.



Now I have another requirement that after the customer and ship-to have been entered, a box appears with the customer header text (if it exists). If that box appears it is also a once-off event.

I have written my test as to whether the text box appears, of course that test fails at the moment.

Now I need to fix my problem. I could have another member variable saying whether the text box had been called, but down that path lies one hundred member variable flags.

Instead I need to enhance my popup handler class so it keeps track of what pop-up screens (each screen is a process in this example) it has displayed thus far in a good old internal table. Thus the popup class is keeping track of what it has done rather than the main application which is a better distribution of responsibilities.

The calling code is changed to:-



And in the popup handler the one-off check is made.



I can now add my new check to see if the customer text pop up is required.



I will end up renaming everything ten times, but the principle is clear. Instead of relying on an ever increasing number of flag variables, I now have a generic way of handling as many one-time pop-ups as are required. Moreover I have been forced into following the single responsibility principle, whether I like it or not (which I do).

This is proving the point that the more tests you write the better the code becomes.

Yesterday the colleague opposite me said he got bored and so wrote a few unit tests on code he had written that day. He quickly discovered that about four assumptions he had made were wrong. So in some ways the automated regression testing, though wonderful, is not the main benefit - the main benefit is better written code.

In summary if whacky radical things like "test driven development" and "github" are bridges that programmers in other languages have been jumping off like lemmings for ages then I am with James Borown on this one i.e. I want to shout "Take me to the Bridge!|"

Cheersy Cheers

Paul
joao_sousa2
Active Contributor
‎07-04-2018 9:59 AM
I’m a strange “ABAPer” in the sense that I also work with node, angular, Apex (Salesforce) and .Net. With all those tools Git is a critical part of my workflow. I would be the most direct use case for AbapGit when in the SAP world.

So do I use it when working with ABAP? Not really, so I started wondering why , why don’t I  feel the need to use a tool I already use in other contexts?

1) Culture for sure. I can’t be the only one to use abapgit (and unit testing, OOP) so I have to convince everyone else... huge challenge.

2) STMS is actually great. I’ve had to setup huge CI/CD landscapes from scratch, and a lot of time is spent maintaining them . This comes for free. Unless you want to run unit tests ... why bother with anything other then STMS? (And unit testing could be added to stms)

3) You need an environment to run the CI pipeline. The way SAP is built this is not easy/reliable.

4) Unit tests are not reliable enough to do CD on a business critical system like SAP. Is anyone actually doing CD in S4HANA?

SAP gives you for free some of the tools other frameworks don’t. With .Net I need a version control system which SAP provides out of the box, the same for deployment. As someone who shifted from a pure SAP world to a more broad landscape, I have to say SAP has spoilt us with the ABAP AS.
joao_sousa2
Active Contributor
‎07-04-2018 10:06 AM
I would wager most companies won’t allow their employees to sharing their IP as open source.

Maybe some newer players , but large enterprise are usually very strict about it. For professional development I always use private repositories because of that .

I do use Github but if you look at my profile (jgsousa) it’s all hobby development all the pro stuff is hidden because it must be.
joao_sousa2
Active Contributor
‎07-04-2018 10:12 AM
For CI look at how Salesforce is doing it with DX. You have a “scratch org” model where the CI process can spin up an environment from zero (cloud) , run the unit tests and then delete the instance.

This is critical for CI the hability to generate clean environments on demand. SAP is the opposite of this.
hardyp180
Active Contributor
‎07-04-2018 10:17 AM
As I said there are two sorts of development.

One is the sort I do in my day to day job. That is the intellectual property of which you speak, the programs that make my company different from the competitors. There is no way you would open source that sort of thing on the internet, as you would lose your competitive advantage.

The other sort of development I do at work is the boilerplate sort of thing which is a waste of time when I could be doing something that actually adds value to the company.  Why should I write a framework to dowload data to Excel in a lovely way when I can just install ABAP2XLSX instead?

This is of generic tool development is typically done by people outside of work hours, and is the sort of open source project abapGit was designed for. That way instead of 10,000 people all working independantly on the same thing, you have several dozen people all working on the one thing (and 9,900 people hitching a ride) and a better quality boilerplate solution.

I don't think the management at most companies actually care what sort of version control or unit testing or logging tool you use as that is internal to the development department and not perceived as any sort of benefit to the business....
joao_sousa2
Active Contributor
‎07-04-2018 10:48 AM
Even if it’s outside of work hours, it’s can be tricky if you work in a large enterprise. Did you use your company laptop? Is it related to work you do during the day?

I’m being the devils advocate here (the annoying one) but sharing abap code may not be that straight forward.

But yes, the company doesn’t care what tools you use. It may care if their IP is publicly shared (even if it is a logging framework).

 
nabheetscn
Active Contributor
‎07-04-2018 10:49 AM
Wow nigel.james , so here it starts!  Let me put my 2 cents here from my experience, Most of the ABAPers I feel 99%, suffer from is a very common disease which i call as  "#ABAPInertia". I myself was suffering badly from it 3 years back, infact SAP in itself was suffering from it i feel.

Everything was built around ABAP whether webdynpro, module pool, webui etc. which sadly did not work. The real game changer was actually when #SAP themselves adapted to WWW world of Javascript via UI5.  This is where we started embracing the #OpenSource the world outside SAP.

Today we have reached a stage where #ABAP is fighting for its existence( It is the closest to my heart), the only way to survive in the world of cloud/mobile/AI/Blockchain etc is to innovate and move forward.

I will be the happiest person if we can use ABAP to create a Blockchain, AI, mobile apps etc. etc. But if it does not then we will have to embrace the new technology no other way around. I believe "#ABAP is like a slow moving elephant with each step forward it leaves a deep imprint behind".  

Good thing is  ABAP is moving forward slowly and steadily, I hope someday we will be using #ABAPForEverything.

Thanks

Nabheet
Nigel_James
Active Contributor
‎07-04-2018 12:07 PM
Thanks for your thoughts Nabheet and as much as I love ABAP it is just a tool.

The point I was trying to make in the blogs when said I am not an abaper is that I will look to the right tool for the job. Sometimes that is ABAP - particularly if the context is ABAP, most of the time it is PHP is the context is web and if there is a sniff of data science I will be reaching for python. If there is a joke to be had I  reach for Monty Python (Is this the 5 minute argument of the full half hour?)

One of my larger points here is that SAP not play NIH with #ABAPgit and actually make good on their promise of integrating it into the ABAP stack. They are often shouting about how much they love and contribute to opensource so this is one great opportunity they can actually do so.

Cheers,

N
Nigel_James
Active Contributor
‎07-04-2018 1:04 PM
Thanks for this contribution Paul and I was really glad to be able to link to your other material here on SAP Community. Keep it up it is awesome.

There is a bit mental shift to writing tests and that is the journey that ABAPers must go on. It is not enough to say if it runs a bit long you put it in a batch job. How do you know that it won't fail and take out your servers?

"Keep us all honest." He says as he smiles and passes you a Vegemite sandwich.

Cheers,

Nigel
nabheetscn
Active Contributor
‎07-04-2018 1:10 PM
I will agree here, the contribution towards open source is something SAP shall work on rather than shouting loudly. Let the contribution shall speak louder than the words. the direction in which SAP is planning to go #ABAPGit is a must.
They are often shouting about how much they love and contribute to opensource so this is one great opportunity they can actually do so.

 

Thanks

Nabheet
jwood_bowdark
Active Participant
‎07-04-2018 10:08 PM
Jelena,

While I definitely agree with your comment about not just blindly following the latest trends, I do think that this particular trend is much different than some of the ones we've seen in the past. In my opinion, the evolution we're seeing now has very little to do with whether or not one language is better than another. I am actually a big fan of ABAP, just as I'm a fan of Java and C#. In many ways, I think that all three of these environments are at a crossroads due to the large amount of baggage they carry from the 90s and early 2000s. Realistically, I just don't think there's much of a place for app servers and complex, monolithic landscapes in the cloud-based world we live in today.

Also, I do think there are lessons to be learned from watching what's going on with Java/Spring and .NET Core. These programming environments are evolving to become much more lightweight and flexible. And yet, the sourcecode looks largely the same. ABAP can achieve similar things, but both SAP and the community supporting it must embrace change to do so.
mmcisme1
Active Contributor
‎07-05-2018 11:57 AM
The code I write today is so different from what I wrote 20 years ago. So very true.  It is amazing.  There are so many more tools.  Switch from ABAP logical databases, ABAP lists to ABAP ALV to ABAP objects to ABAP CDS.  Some where in there is WebDynpro, Workflow, and Sequel reporting tools.  The reporting tools can be used by the end user.  But to support them I learned that as well.  Look at just the syntax.  It is different.  It is still a growing and changing language unlike COBOL Or Fortran.

Now let me add my next paragraph.  There is nothing wrong with having many different options.  There are times when I will use a different language.

  1. When it makes sense.

  2. When I have that elusive thing - time.

  3. Yes I am learning other languages.  Simply because it is fun.  Then add usability to it or I would forget what I learned.


So yes, I still believe ABAP is worth learning.  AND yes, go see ABAPGit.   Oh boy are you missing out if you don't use this.
mmcisme1
Active Contributor
‎07-05-2018 12:15 PM
“Greenfield” sheds old ABAP code.   Mmmmm... There was a reason that code was written in the first place.   Is the reason gone or still there?  😉

Yes, dragging some of the code is worth it.

Auto-code checkers are the bane of my existence.  Sometimes that don't quite work with performance.   So you will be adding things like

  •  ##NEEDED

  • "#EC CI_NO_TRANSFORM

  • Sometimes a break is needed and used.   #EC NOBREAK


I think I've used needed the most.   The no_transformation one the second most.   Anyway be aware when you are moving "old" code to a new environment - some of it isn't pretty.  You may not have the time to try to understand what on Earth was written.   Sigh.  So you bring bad code to the new environment.

Also some of the times the checker is wrong.  Sometimes it is correct.
mmcisme1
Active Contributor
‎07-05-2018 12:16 PM
0 Kudos
True.  But learn from what someone else has "just" done.  Be smart about applying new languages.   Understand the if it is supportable.
mmcisme1
Active Contributor
‎07-05-2018 12:21 PM
Github is amazing.  I seem to remember something here about ABAP code/snippets.  GitHub is so much better.   Changing the code and starting projects is fun.  (I've just used it so far, no adds from me yet.)

Test driven development - no I haven't done that - that's a big mindset change for me.  However, I have added test to my code.  (Just started doing that)  🙂  This is hard when not using the test driven development as it adds more time to put it there.  Why do it?  Yes, I've caught errors before production.
mmcisme1
Active Contributor
‎07-05-2018 12:25 PM
Have your laptop beside you - log in via an open network.  Then you are ready to rock.  Even using your cell might be helpful if you are stuck on something.

The code you wrote for your company.  I guess I could argue I would get a huge benefit from using it and downloading more code than I added.  (Of course, I haven't added anything YET)

My company has wormholes where we can look at outside info and download.  Plus I work at a small company.
mmcisme1
Active Contributor
‎07-05-2018 12:30 PM
The mental shift is small compared to the learning time needed.  I believe we all want to do better.  The  change management with our company could be large.  Meaning I may want to learn it but there are only 2 other programmers.  I have to convince them to learn it to.  Otherwise there will not be any backup.  And sorry - yes at times it is that big of a change.

So I may be a cheerleader and want to change.  They have to want to change, AND we all have to have the time to change.   Doing it gradually is nice.  Keeping the pace to all of us even better.  However, now we have consultants that are great and are completely using the new tools.  Or the flip side consultants that are using the old tools....  That gets to be a juggling act as well.  🙂
joao_sousa2
Active Contributor
‎07-05-2018 2:55 PM
I think tests brings with it several advantages:

  1. It forces you to modularize the code;

  2. It forces you to provide clear error messages;

  3. 1 and 2 saves you a lot of debugging time.


I started using tests a lot with another software as it forces you to have 75% code coverage, and I have to say I have basically cut down my debugging time to zero. I just run the test, look at the error, and if the test is well created, it shows what happened. In the end, it saves time.

Much more effective and scalable, then optional debugging. On big advantage of the other software over SAP, is that all data created during tests is deleted after the test runs, so you can easily test inserts, updates, etc (database layer). In SAP, testing the DB layer is a bit trickier.

 
mmcisme1
Active Contributor
‎07-05-2018 3:01 PM
Hint:  I see another volunteer.   Do you have a nice business example?  Did tests help you out?  (Yes)   A blog... Yes, another blog in the making.

I love reading the blogs out there with simple examples.  They help a lot.
Jelena
Active Contributor
‎07-05-2018 8:31 PM
I have nothing against learning in general. Quite the opposite. Even though I still use SAP GUI and don't clamor for ABAP Eclipse at all (although I switched to new editor last year - that counts as an achievement 🙂 ), I always want to do my best. Just like you, Nigel, and many other people commenting here and contributing on SCN. But, as matthew.billingham correctly pointed out, we seem to be in minority. Essentially, Nigel seem to be preaching to the choir here.

Reaching the other part of population - that's where the challenge is. How do we best reach them? So far simply waving the "you should learn" flag from the barricades doesn't seem to be effective, from what I see.
Jelena
Active Contributor
‎07-05-2018 8:45 PM
"Is the reason gone" - that opens the whole other can of worms. 🙂 E.g. we have the whole "suite" of Z programs that were written back in the late 90s I'm guessing. They may have been great at that time but since then SAP added some new functionality. E.g. most, if not all, of what that code does can probably be replaced by a proper WM implementation. But, of course, that would be another project, so instead we are just dragging around the existing Z code. (Which, at this point, looks like a zombie that's been shot multiple times but is still dragging their feet.)

As a side note, I believe rarely customers have a systematic review process of the enhancements delivered by SAP. For example, we implemented a user exit in VA01 for some additional validation. 2 years ago SAP actually delivered an enhancement in the note that allows to do it without even any ABAP. I no longer work at that company but I bet the user exit is still there. Because not only you need to know about the replacement. You also need a ticket, a business person to test and sign off on that, etc, etc.
Jelena
Active Contributor
‎07-05-2018 8:52 PM
Just came here to say this - yes, the concerns about the employer's take on your extracurricular activities is the major reason why I refrain from sharing any code. Even if I use a personal laptop (obviously), there are still some grey areas. "Better safe than sorry". I'm glad others are sharing for my consumption though. 🙂
mmcisme1
Active Contributor
‎07-05-2018 8:57 PM
This is code we originally were not taking to the new system.   We were going to start vanilla.   How's that work for anyone?

OK so that said did we originally take any custom code over?  Only a handful made the cut.

Now the realization - Yes, our business is different than most companies because...

Next:

Do we want to pay for that option?  Does it still belong in our system?   Look at the "new" integration test.  See if it fits anywhere?  If we need it, and there isn't a solution in standard SAP <Gasp>, then we bring it along.  If we don't it goes into save mode in case we did need it and didn't know we needed it.  You know the old "If you don't know what to ask for - you may not know what is needed.

So - to your point many programs went into the graveyard.  But we still needed other ones, because there is something special about our company.  Also we are taking a big leap into S/4 HANA.

Take a second and think.  I bet you can think of a program that is needed, and is not covered by standard SAP.

Dragging bad programs around - HA! - leave those in the save in case we have to have them pile.

During an upgrade, it's a great time to take inventory.
Jelena
Active Contributor
‎07-05-2018 9:08 PM
+1 to c436ae948d684935a91fce8b976e5aa7 - if you have a success story / specific example to share please do so. The examples used in openSAP course were not very helpful IMHO. But so far it seems Paul Hardy is the only one on SCN who've actually shared his practical experience. Others are just claiming this is the best thing since sliced bread and I remain skeptical. But then I don't think sliced bread is that great either. 🙂
Nigel_James
Active Contributor
‎07-05-2018 11:34 PM
So the experiences of other languages and platforms is not enough?

I have worked on codebases that have test coverage and those that have 0 . Guess which one I am happier to make a change to.

I totally get that it is a journey and it is a mindshift but as joao.sousa2 says - there are benefits.

But "Why should I change?"

No idea Jelana - that is a question for you alone to answer. After all the tools have only been around for 12 years in ABAP ( probably longer ).

Happy days,

Nigel
Nigel_James
Active Contributor
‎07-05-2018 11:35 PM
Thanks for your comments Michelle.

Come on in the water is fine.

 

N
matt
Active Contributor
‎07-06-2018 8:01 AM

Programming is commonly treated as a commodity service- all programmers and all programming are/is of equal value.

Until the powers that be recognise that an intelligent, trained group of developers will produce considerably better programs that are cheaper (in terms of Total Cost of Ownership), I see little chance of change.

The outsourcing companies and there consultancy partners are making far too much money to want that kind of change and will actively fight against it.

It's clear, however, given the way ABAP is going, that SAP at least do not have this mindset, so maybe there's some hope. And in one of my clients, after discussion with the quality group, we now have a set of development standards that state that TDD and ABAP Unit Tests are best practice. (I also managed to get the old-style non-DSAG recommended prefixes removed!).

joao_sousa2
Active Contributor
‎07-06-2018 8:46 AM
The reason I can’t really share is because the experience is mostly with another software stack not SAP, one that forces me to write unit tests, either I like it or not.

As I’m being forced the rest is a result of that, I have to write modular code because I’m forced to do it. After I while I just started doing it because I realized I actually used the tests a lot instead of debugging, and it was simpler/faster.

I don’t think it’s something you can explain, you do have to experience it.

That said I don’t think it’s the best thing since sliced bread. From my experience there are a lot of types of bugs it doesn’t catch (it’s unit tests after all) so I don’t trust them to do CD.

And we are mixing a lot of stuff in one post:

- Git : no brainer for code sharing, but with caveats for IP restrictions.

- Unit Tests : not the best thing since sliced bread, but some will find useful.

- CI : running unit tests automatically after every change. I find this very hard to do in SAP without something like scratch instances.

- CD : deploying code to production after every code commit and CI run. This I would like to know ONE real story. Just one. I don’t believe anyone is actually doing this (sorry, skeptical one here )

When people talk about CD they are mostly talking about automatic integration into a test server but in ABAP AS this is automatic.

I have spent the last 2-3 years with half a foot outside SAP. If I thought these things were absolutely critical to my abap work I would use them, but I don’t .

 
joao_sousa2
Active Contributor
‎07-06-2018 9:20 AM
The experience of other languages is not enough because the context is very different.

- Most are not server based like ABAP. They don’t have build/deployment infrastructure or a version control system “by default”.

- Unit tests are mostly suited for stateless tests. ABAP program are highly reliant on state/DB which is almost impossible to test .

- Core SAP has no separation of concerns. Most of your code interacts with standard SAP, mocking those APIs is close to impossible.

- Doesn’t have Dependency Injection which is testing 101.

Does it have it have advantages? Yes. Are they the same as other languages? I don’t think so. That’s why my success story is not with SAP.
Labels in this area
Popular Blog Posts