cancel
Showing results for 
Search instead for 
Did you mean: 

Is ABAP considered "good" ?

Former Member
0 Kudos
924

I have been learning ABAP with the NetWeaver trial for a week or so now

and I am frankly shocked by this platform.

There are some good ideas here but they are outweighed by bad ideas and bad execution!

I cannot see that it is possible to create high quality software using this system.

The SAP development tools themselves are terrible - the applications created with them even worse.

Does anybody consider this platform to be "good" ?

Moderator message - Moved to the correct forum

Edited by: Rob Burbank on Jun 7, 2010 5:34 PM

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

This thread's been dead for a week, but I can't help replying. I sense that FireBean500 comes from a similar background to me -- trained in another, more mature object-oriented programming language, and at first shocked by some of the design choices in ABAP. I've often been tempted to write a post like the one he has over the years. (Fair warning: this is so long it's in three posts to preserve formatting.)

A lot of his criticisms are correct. When evaluating whether SAP/ABAP is "good", I think we need to make a distinction between SAP as a technology suite, ABAP as a language within that suite, and ABAP as a stand-alone programming language.

SAP is a remarkable technology suite, and has no true competitors in terms of its scale. It provides (decent to excellent) support for more business processes than most of us can conceive of, across corporate services departments and dozens of industry verticals. Olivier mentions its administrative tools, which are generally hugely mature and useful. Far better than what you get out of the box with some other platforms. So, when we try to use arguments like, "Look at how successful SAP is! All the big companies run it!" we've not proven anything about ABAP. What we have proven is that the SAP platform as a product is a staggering achievement. And it is.

ABAP, historically, has fulfilled its role within that suite very well. We need to consider that the vast majority of development tasks undertaken by customers in ABAP are simple interventions to extend small, localized pieces of code or add elementary new functions. Even when the enhancements are larger, they have tended to follow a particular pattern well-established in standard SAP code, and customers have been happy to live with the limitations this has created because the rest of the product is so useful. This method has made SAP development rapid and simple and ABAP has certainly been up to the task.

I think this is changing. Customers want to be able to customize SAP to a much larger extent than they have before, and are used to their IT departments providing them with choice and large-scale development interventions to give them whatever they want. It's in this task that we need to evaluate ABAP as a language, competing against other languages in which these sorts of large developments are delivered. And it's in this task that FireBean500 correctly points out that it is found wanting.

Former Member
0 Kudos

It seems he's dived directly into dialog programming, which is unfortunate -- it's like some dark corner of ABAP largely untouched by the transition to objects. But he's not incorrect in many of his assertions - there is a lot of fragile, breakable code in ABAP. The fact that calls to local function modules are not checked at compile-time is odd (I don't know if there's some reason for this I'm unaware of). Moreover, there are several basic glitches in the transition to objects: only in the very newest version of the language are chained method calls or using the results of method calls as expressions legal. I'm glad it's there now, but it was a baffling omission.

Perhaps most disheartening of all is the paradigm inertia on the part of SAP itself, which seems to prevent it from writing its own OO code. Certain high-visibility developments (think ALV) have made the transition, but they've been stillborn. There's a sticky thread on the top of the ABAP Objects forum begging Walldorf to add essential functionality that is missing in the new OO ALV, but present in its procedural predecessor. We have an interesting, improving, hybrid OO-procedural language, but we end up using the procedural half most of the time, because the standard tools are all procedural. I won't even get onto the use of SE80 as an "IDE" -- it's terrifying. (A somewhat frightening aside: ABAP is playing catchup with Java, which it's kind of adopted as its object-oriented mentor language. Meanwhile, Java developers are collectively terrified that their language is obsolete, and will quickly lose ground to more nimble, productive, modern languages like Scala and Ruby. Makes you think.)

Before you say that SAP was developed in ABAP, so it must be good, consider that very impressive systems have been developed in COBOL for decades. It doesn't mean it was easy, and it doesn't mean that the language is more productive than more modern ones. It's a credit to the system's developers -- not their development language.

In fact, I wish I had a better understanding on how SAP makes design decisions affecting the core of the language. For one thing, the intricacies of its mechanics seem to be largely undocumented. Horst's ABAP Keyword Documentation is by far the most useful free, on-line resource for the language, but I understand that he has to maintain it alone, and it's peppered with notes about irregularities that he seems to have discovered by trial and error.

Former Member
0 Kudos

Development technologies aside, it's no longer quite good enough to say that SAP "isn't about wonderful user experience". You can run large companies and still provide their users with a productive, attractive, intuitive experience. SAP knows this. I'm sure that Oracle knows it too, which is probably what scares them. (I'll concede that SAP have made great (if localized) strides in reaching that goal.)

In short, FireBean500, I sympathize. And you're going to have an interesting time with Web DynPro: some of the design is even more baffling than ABAP Objects. But give the SAP platform a chance. It's improving, and its scope can be truly awe-inspiring.

Former Member
0 Kudos

Hi James

thanks for the interesting posting

my original plan was to translate my home-made accounts system from microsoft platform to netweaver as a learning exercise

but I didn't enjoy the experience

and frankly I am relieved to get back to microsoft-land

FireBean500

Former Member
0 Kudos

Hi James,

Thanks for this very interesting and very well argumented post.

I said there are excellent features on SAP products but I also think that a lot of things could be and should be improved.

I think also that most SAP customers should be more critical and ask for more improvements on the technical side.

The problem is that the management does not buy any SAP product from its technical characteristics. They only look at the. functional features. So if SAP corrects the RZ10 bugs that I've known since R/3 2.1 and that still exists in ECC 6.0 EHP4, they will not sell one single more ECC6 license. There is a workaround to the RZ10 bug, techies can live with it...

Regards,

Olivier

matt
Active Contributor
0 Kudos

The fact that calls to local function modules are not checked at compile-time is odd (I don't know if there's some reason for this I'm unaware of).

Historical reasons. If you dig into some of the old HR code, for example, you find that there are function module names written into the configuration tables. Hence, CALL FUNCTION was from the first designed to allow dynamic calls. ( To an extent - parameter screw the idea up a bit)

If CALL FUNCTION had been invented some years later, it would have been CALL FUNCTION z_some_function_module, and the dynamic form would have been CALL FUNCTION (v_fn_name).

Perhaps most disheartening of all is the paradigm inertia on the part of SAP itself, which seems to prevent it from writing its own OO code. Certain high-visibility developments (think ALV) have made the transition, but they've been stillborn.

I do most of my development in BW. I've just been writing some stuff for manipulating InfoObject hierarchies programmatically. That is mostly using SAP developed classes. It makes life so much easier. But I do agree with you about the inertia. The analysis authorisations, introduce in BI 7.0, are implemented using... function modules! BPS is full of object oriented code. So what do we get for Exit Functions ... that's right. Function modules again. I mean - for goodness sake! How long had ABAP Objects been out when these things were being designed? Quite a few years!

And even with object oriented stuff, like Process Types of Process Chains. Which cry out for subclassing. Guess what - they're all final!

ABAP Objects does not compare well with modern OO languages. As a procedural language, however, it was (and is) certainly one of the most powerful and flexible. Not bad for something that started life as a 4GL report writer!

Anyway - I program in Java and ABAP (and in many other languages). As far as I'm concerned, I'll use whatever gets the job done. And when it comes to tinkering with SAP standard - there isn't any competition for ABAP. You're forced to use it.

Former Member
0 Kudos

Olivier: I agree with you that SAP customers should be more critical of SAP. I secretly enjoy it when I see posts like FireBean's: it means someone is actually thinking critically about the software they're using and how it can best be employed. This sort of interaction with the community is what drives technology development by other language vendors, and SAP is getting better at it. We just need to tell them what we think.

As for technical characteristics not driving sales, I think you're both right and wrong. Certainly, when a corporation chooses an ERP, functionality is their first consideration (besides, perhaps, the cost of licensing and implementation). But if a development platform gets a reputation for being buggy, hard to use, and outdated, that will influence purchasing decisions -- as it contributes to the maintenance cost of the system. If SE80 were a real IDE, and not the dinosaur that it is (we've just received code completion, for God's sake) my clients would have saved tens of thousands of development hours and a ton of money. That's got to count for something.

Matt: Thanks for filling me in on the FM checking. That makes sense. It's another instance of SAP's downward-compatibility policy making it hard to tighten things up. I understand the policy, but wonder if it doesn't need some amendments -- they should consider enforcing the standard bracket syntax for dynamic calls in all new developments.

I just cut short my semi-irrelevant ranting in a question I posted in the OO forum (shameless plug: ) about how so many SAP-developed classes are marked final. There are so, so few valid reasons for making methods (let alone classes) final. At least they followed the virtual-by-default idea used in Java and not C#'s final-by-default idea (which is boneheaded and enfuriating). But then they go and check the final checkbox by default. It's maddening, and speaks to this bizarre paranoia SAP has that it needs to protect developers from themselves. Believe me: they succeed in screwing things up in ways SAP could never have imagined, so the effort is futile.

You're right -- ABAP's come a long way. And I don't mind working in it. I just think we need to shout a little louder sometimes about the improvements we think are required. After all, it's not just that improvements take a long time -- the design decisions SAP seems to take sometimes just seem wrong.

matt
Active Contributor
0 Kudos

>

> Hi James

>

> thanks for the interesting posting

>

> my original plan was to translate my home-made accounts system from microsoft platform to netweaver as a learning exercise

>

> but I didn't enjoy the experience

>

> and frankly I am relieved to get back to microsoft-land

>

> FireBean500

Try redoing it using Flex Island technology embedded within Web Dynpro for the UI. Where you might need to have some entries in configuration tables entered in the back end (i.e. via SAPGui), use table maintenance generator, rather than creating your own UI.

matt

koolspy_ultimate
Active Contributor
0 Kudos

Hey i am maddy from INDIA and i have completed by B.Tech in Computer science Engineering (May 2010 passout).

I am a little bit weak in programming like java, but i know the basics of c, c++ .

So i am thinking of opting for SAP (ABAP).

So can you please suggest me whether i can opt for it , or is there any other opportunity for me.

My Educational qualifications are

B.Tech (CSE-MAY 2010) 61.7%

Xll (MPC) 85.6%

X (SSC) 81.30 .

matt
Active Contributor
0 Kudos

Programming is programming. The language itself is pretty much secondary. Though OO programming is different from procedural programming, and could be described as a seperate skill. Don't underestimate the secondary part though - detailed understanding of the language and environment is essential to being an expert.

For further discussion, about your career, you should post in the Careers forum. But you're likely to find similar questions have already been answered - so search first. You can "opt" for any language you like. Getting a job doing that language is another matter. SAP is notoriously hard to break into, and there's a lot more to ABAP development than just the language. Probably the environment is of equal importance.

Former Member
0 Kudos

I'm kind of jumping track here and may still be in the wrong area in the forum for this question; however, the discussion threads seemed to me to be speaking to the essence of where my answer may lie. My question is about ABAP code, in so much as, how does it differ from Oracle in its most basic functionality, given the understand of its relevance to the cube schema and in our case the GCSS-Army ERP solution, its ECC, and BI application.

My ultimate goal is to derive business rules that are representative of the "Z" custom files we currently are having inserted into DSO tables that satisfy Legacy Army data element requirements. These custom data are derived from the ECC by SAP BI application programmers and placed into DSO tables provided for our use in Oracle. Not that I'll ever get my hands on the proprietary code but a clear understanding of its logic and function may give us some clues as to the business rules used to derive non SAP type data. There is no single SAP programmer, analyst or BI developer that knows as much about any particular business area with SAP to speak completely to the understanding of any other given business area and how there synergy may translate to data solutions for an enterprise type metadata. Any ideas are greatly appreciated.

matt
Active Contributor
0 Kudos

I'm sorry to say that I have absolutely no idea what you are asking.

matt

Former Member
0 Kudos

Programming is programming. The language itself is pretty much secondary.

An astute observation, Matt. As one of my former clients once said, "Programming is 90% knowing how and 10% syntax. If you know how, I can teach you the syntax."

About ABAP/programming being hard to break into: I question that after reading so many of the posts in the ABAP General forum. I have come to the conclusion that SAP clients around the world still don't know how to identify competent ABAP practitioners and the client shops appear (once again) to be overflowing with freshers. Sadly, it's obvious that some are much more suited to being Wal-Mart greeters than programmers; it's obvious that they don't know how and don't know syntax either.

Former Member
0 Kudos

>

> I have come to the conclusion that SAP clients around the world still don't know how to identify competent ABAP practitioners

No - but they are quite able to identify the cheapest.

Rob

matt
Active Contributor
0 Kudos

Where "cheapest" usually turns out to be very expensive, because you pay for the initial development and then again for someone who knows what they're doing to come in and fix it - and the damage caused. On the other hand, I've made quite a lot of money over the years off the back off such.

Former Member
0 Kudos

>

> Where "cheapest" usually turns out to be very expensive

But if you are only interested in this quarter's profits and intend to be gone shortly thereafter, some might consider it the wise thing to do.

Rob

ChrisPaine
Active Contributor
0 Kudos

>

> But if you are only interested in this quarter's profits and intend to be gone shortly thereafter, some might consider it the wise thing to do.

and unfortunately you see a lot of that these days - and it's not just where the liability horizon is as short at 1 quarter. Imagine the case where you SAP system is running as SaaS - but you want to innovate with it, but the cost of innovation with the provider is high. In order to justify bringing your system in-house you're looking at 5 year type reasons. People don't personally think in those sort of terms these days. Companies might want to, but those responsible certainly have a number 1 to look out for, and it isn't the company!

Sorry to deviate from the main gist of the thread.

Back to the thread - almost any language can be corrupted by bad programming practices - even machine code can have good and bad ways of doing things, and almost any language can be built in good way. Is ABAP bad because it allows this flexibility? No - but those who are responsible for ensuring quality who let it through - they are.

My thoughts,

Chris

matt
Active Contributor
0 Kudos

I'd like to live in a world where each individual development was monitored to find out its Total Cost of Ownership. Then quality would improve.

Former Member
0 Kudos

>

> I have been learning ABAP with the NetWeaver trial for a week or so now

> and I am frankly shocked by this platform.

>

> There are some good ideas here but they are outweighed by bad ideas and bad execution!

Can you be more specific?

>

> I cannot see that it is possible to create high quality software using this system.

Bear in mind that SAP applications were created using it.

>

> The SAP development tools themselves are terrible - the applications created with them even worse.

Again - be specific

Pretty insightful for only a week or so's experience.

Rob

Former Member
0 Kudos

I was researching SAP hoping to discover a platform that was high quality and a joy to develop on

But that isn't what I found

What I found was a hodge podge attempt at an enterprise version of Microsoft Access

with way too much influence from old, flawed IBM technologies

I like some of the ideas:

CTS is interesting, but misses alot of tricks and no support for online updates

Lock Objects and the SAP LUW are interesting - but this can be duplicated on any platform with little effort

There is a SAP project at work - all deadlines missed - nothing in production after two years

I just don't see that SAP platform is any good - am I wrong?

Former Member
0 Kudos

Hi,

You get the usual feeling when discovering SAP technologies and knowing other software tecnologies.

There are bad things in SAP technology and some very good ones.

But it is very different from other systems because it is integrated in an application software and a lot of system utilities are ambedded. The ergonomy is very "German" (special when used to American software) but it needs time to get used to it and to apreciate its power.

ABAP is a very good developement system for its intended use : extending the SAP abap stack softwares.

Yes, the language shows its age but it was able to evolve nicely (OO abap, web services, web applications, etc...)

In my personal case, when I discovered SAP R/3 for the first time, I hated it and wanted to stop working on it as soon as possible. I was shocked to discover "transaction codes" which seemed prehistorical to me.

Well, that was 14 years ago and even if I'm known here as a "grumpy administrator" because I make a lot of critics, I'm still working on SAP technologies and I am enjoying my job.

Think about an application server technology released in 1992 and still completely current.

As an administrator, when I discovered the J2EE technology, I thought that it would be much better than an abap stack because it was designed much later. In fact it is completely the opposite : SAP admins used to abap are shocked by the primitive J2EE adminitrative tools...

Regards,

Olivier

matt
Active Contributor
0 Kudos

ABAP is brilliant. It's kept me and my family, clothed, fed and housed for over 14 years now.

>The SAP development tools themselves are terrible - the applications created with them even worse.

Which applications have you seen? SAP isn't about wonderful user experience - it's about running (generally) very large businesses.

Former Member
0 Kudos

> It's kept me and my family, clothed, fed and housed for over 14 years now.

That's also quite a very good argument. We don't always work for intellectual pleasure but also to earn our living.

And I hope the next years after the 14 first years will last until retirement !

Olivier

OttoGold
Active Contributor
0 Kudos

joy to develop on

Try sand, that is a platform where you can feel joy when building the sand castles:)))))) Otto

OttoGold
Active Contributor
0 Kudos

By the way... I remember myself thinking the same when started my first SAP part time, when still studying. Used to Visual Studio and NetBeans I didn´t understand why would anybody use such think as SAP. After the years... I enjoy my job (and of course taking part in this SDN fun...) and understand that my colleagues are true pros and SAP can help the company run a really big business (currently working on a second public sector project and both have/had dozens of tousands of users). There is no competition for this on Microsoft platform for example... You´d better stop the professors talks and build something on the platform to understand.

Regards Otto

matt
Active Contributor
0 Kudos

>

>

joy to develop on

> Try sand, that is a platform where you can feel joy when building the sand castles:)))))) Otto

I prefer building castles on clouds.

To be fair, I think FireBean500 is asking some fairly interesting questions.

OttoGold
Active Contributor
0 Kudos

is asking some fairly interesting questions

I can ask plenty:)))) Can we answer some?

If you can come up with something interesting, I am convinced that it is possible to reach Thomas Jung directly and share the ideas with him. In my eyes he is one of the top guys from SAP that listen to the complains and asking for improvements. By the way, you all have already heard that in 7.01 and 7.02 the largest set of improvements to the ABAP was introduced, right? At least I have read that in the officials.

Otto

Former Member
0 Kudos

I started my career with ABAP.. and frankly speaking i liked it on the very 1st day.. 5 years down the line i still like it...

its not like any other programming language...I always wanted to work on something different than others..

and am very glad that I got to work on ABAP

Sharayu

matt
Active Contributor
0 Kudos

>

you all have already heard that in 7.01 and 7.02 the largest set of improvements to the ABAP was introduced, right?

> Otto

In my opinion, the biggest improvement was the new editor. It's not quite eclipse, but it's what I would have liked to have seen ten years ago... 😄

Former Member
0 Kudos

>There is no competition for this on Microsoft platform for example

And it is known that Microsoft as a company is a SAP ECC6 user...

I am pretty sure that Microsoft hires its own abapers !

Former Member
0 Kudos

it is interesting to learn ABAP - it is so different - like an alien software

but the way it does things rings so many alarm bells

little things like binding screen controls to abap programs based on the name of variables

where is the validation and type safety?

where is the dependency tracking?

what happens when you have a typo - silent error!

so much of ABAP seems to be a bodge up - like things I have done as a developer

and thought to myself "well if it works it works who cares right?"

but those sort of approaches can lead to chaos

and weird syntax like:

DESCRIBE TABLE itab LINES fill

urgh! that is horrible - like so many ABAP constructs - they just make it up as they go along!

and PAI event handlers based on ... you guessed it ... strings again!

case OK_CODE.
 when 'SOME STRING TYPED INTO A GUI TOOL SOMEWHERE'.

that is just not acceptable for so many reasons

oh yes - and the OK screen element - just sits there until you give it a name - what is that?

I was hoping to learn something from SAP - but SAP could learn more from me - and I'm just an average developer

lock objects generating function modules that have to be called ... using another string literal!

call function 'enqueue_is_this_a_joke'

and I can see no way to validate that locking is implemented correctly - got to read the code?

no way of checking that COMMIT WORK only affects records that are locked ?

the whole approach is fragile and opens the door to a thousand subtle mistakes

first SAP apps go live at work soon - I will enjoy the fireworks

OttoGold
Active Contributor
0 Kudos

you´re right in too many things, I agree, but one gets used to it:)) the changes cannot be made easily and changing of the whole concept is not possible. Maybe you could study some computer science and offer some quick wins for ABAP? Would be cool to talk about it and would be even better to find an improvement or two. Maybe you can offer some answers instead of questions? Few years ago I would stand next to you, shouting, waving the flag etc. ...but now I know the show must go on and you cannot change everything in one moment. If you don´t like ABAP, go for Java and hope not to see ABAP again (impossible in SAP imho) or quit SAP world. There is not other way...

Otto

Former Member
0 Kudos

Hi,

All you are saying is true but you are just obsessed by the "not perfect" abap syntax. You have to look much beyond at the complete architecture and for what it was designed.

I would never use or buy an abap system as a developement tool to build a new software from scratch but, to enhance the standard SAP software it is OK and much better now than 10 years ago. You will also see that the concept of storing "all" (data, customizing, data dictionnary, source code, byte code) in the database is very powerfull and quite unique.

And if you look at the execution platform (the runtime environment), I think it is the most robust and scalable one available on the market.

I think that an abap developer should get more satisfaction to know the fact that his application is used for very important business processes in his company than from the "beauty" of his source code. It is also much better for his career because end users and managers don't care about source code !

Why do think that 70 to 80% of the world biggest companies all use SAP software for critical applications ?

Olivier

matt
Active Contributor
0 Kudos

Without wishing you any disrespect FireBean500, but the fact is, from what you've written, you're simply not competent to make declarations about the utility, usefullness or stability of ABAP, not because you are unskilled or stupid, but simply because you do not (yet) possess enough knowledge about the subject.

Most of your critique is based on the VERY OLD technology that still exists in ABAP for compatability. Before OOP was a twinkle in anyone's eye.

Who uses DESCRIBE anymore? I use the inline function lines( itab ). Check out WebDynpro to see how UI is dealt with now. Type safety? look at ABAP Objects.

And as for SAP producing fragile applications. Have a look in real world.

matt

Former Member
0 Kudos

I understand

The platform is good, the SAP applications are well designed

old style ABAP & DynPro is not good (but works if you take care)

new style ABAP Objects & Web DynPro is better (and were designed to overcome the problems with old ABAP)

The answer to my original question is therefore "no"

Now lets see if I can get NetWeaver Web DynPro to work ...

Thanks for your efforts to educate me

matt
Active Contributor
0 Kudos

That's a fair summary, I think. Up until the mid 90's ABAP was good. It did what was required of it, and did it well. When new programming paradigms started to creep into the business world, very slowly they crept into ABAP.

matt