Enterprise Geeks Podcast – What the CRUD

Photo from Wacky Ads by Norm Saunders

Season 3 Episode 19

Running Time: 01:21:47

Show Links

If you have questions, suggestions, or topic ideas for future episodes, give us a shout here.

Apple Fans Chopping Off Hands In Anticipation Of New iHand

15 responses to “Enterprise Geeks Podcast – What the CRUD”

  1. Matthias Steiner says :

    Hi enterpriseGeeks,

    just checking in to comment on your latest podcast and some of the topics you covered.

    1. Caffeine. It’s only a technology demo so far and I do see some sense in the vision of it. With all these seasoned ABAP developers who are experts in their respective modules (aka Process Components) and the hype for mobile apps the question arises on how to “mobilize” all the functionality of the Suite. One pain point is the divergency between those developers that know the processes and the business logic of the intended app on the one hand and then those hip new mobile developers that know about the target OS and how to build apps with a great UX on the other hand – the iHand if you will ๐Ÿ˜‰

    (I’m somewhat stereo-typing here, but simply for the cause of illustrating the concept.)

    From this perspective it sounds like a valid idea to have the seasoned ABAP developers code the business logic of the app. As Ed states in this podcast it only took him two days to write a very effective report. That’s where all these ABAP veterans shine and bring unmatched expertise and value to the table. But what do these people know about native mobile OSs or UX? Little, if at all…

    So, letting the pros write the library (in their known domain language) that can then be embedded into native apps on multiple devices sounds like a valid approach in my book. The mobile developers are hereby allowed to focus on their respective field: developing a mobile app that is simple and fun to use.

    2. BOL vs BOPF.I really enjoyed that part of the podcast. Having been focusing on the Java side of things I get sick of all that ABAPer trash-talk about how simple and effective it is to develop in ABAP. True, if you just need a simple report to do your thing then you’re having a blast and everything is super easy and convenient. But according to what I heard you say, once you want to develop something bigger – introduce new business objects and the like – hey suddenly you are facing the same questions we’ve been dealing with on NWCE for years now. Suddenly we are getting into an architecture discussion on how to best-build an application. Suddenly we are talking about separating data access and encapsulating it from business logic processing. And this is when the difference between a downhill developer and a properly trained developer matters… it’s no longer a (rather useless) debate about programming languages or development frameworks… it’s about fundamental architecture topics, about what it takes to build enterprise(!)-ready software…

    Keep it up!

  2. Gregor Wolf says :

    Hi Ed and Thomas,

    the best I could find on BOPF is currently the Release Notes for SAP SNC 7.0 Enhancement Package 1 available on
    http://service.sap.com/~sapdownload/011000358700000740112010E. There on Page 15 (PDF Page 24) you find even more strange acronyms like FBI which stands for FPM BOPF Integration. So FBI actually is Floor Plan Manager and
    Business Objects Processing Framework Integration :-). But that continues and brings us PBI which stands for POWL BOPF Integration. So PBI completely unzipped is Personal Object Worklist and Business Objects Processing Framework Integration 8-). And if that is not still enough we got GUIBBs Graphical User Interface Building Blocks. These two pages are just a hilarious mess of acronyms.

  3. Chris Paine says :

    A very interesting discussion guys!

    First, some thoughts on objects as a abstraction layer for DB access (persistent objects) in a non-transactional use. Firstly a little background: Recently I’ve been working on a tool to allow users to graphically navigate their organisational structure and report on the detail of the positions displayed.
    There is some work here in firstly manipulating the data set – as data is not stored in a “A” reports to “B” format but a “A” manages “C”, “B” is part of “C” format, but users want to see the “A” reports to “B” layout. In order to do this manipulation I created some objects which represented types of data, person, position, etc, and then used these. By abstracting the routines to get the relationships into methods of the objects, suddenly my code becomes incredibly easy to read. If I had NW7.02 and could method calls, it would be even easier… eg to get name of manager of a person (simplistic case, where all positions filled and person is not manager of org unit themself) : person->get_position->get_org_unit->get_managing_position->get_holder->get_name

    To get data about the objects I implement a series of getter methods to retrieve, for example, the name, type of employee, user id. These methods all then cache the results in the object. As my user drills up and down the organisational chart, any piece of data is only ever extracted once, and then persisted. So far this means that retrieving data is fast, and re-reading it even faster. Now potentially this is a huge amount of memory used. (we’ll see how this design performs in the real world soon), but it is perhaps the neatest and most easily readable code I’ve ever written.

    I’d argue that by abstracting the database access and associated data manipulation, one of the main benefits is in making the resulting code much easier to understand – and therefore easier to reuse and easier to maintain. A database table doesn’t tell you how it should be used or what purpose you can put it to, or how it relates to other tables, or even itself (DB keys etc excluded) this is a layer of information that the programmer has to know. But by abstracting the table into an object, we can start to provide some of that useful information.

    perhaps not exactly the same thing as you were discussing with, and I agree, it is all a matter of knowing where the benefits are.

    as for BOL, BOPF: A good pattern is one that can be understood easily and is transparent. I would fear that something that “evolves” out of business suite development is going to be neither of these. Simpler is better. (but simpler doesn’t have to mean no framework at all!) Code that has evolved out of a previous usage is in my experience never as easy to understand as code that that been has been designed to support the solution in the first place.

    @Matthias, rather than have the ABAP coder taken outside of their NW environment, why not have them expose that data, service, etc via a Gateway or RESTful ICF “interface” or even a web-service. Then anyone, can take advantage of the abstraction and not just those using that particular caffeineated application.

    perhaps (re-reading your post) it is just that you believe that the ABAP coder is a good business process expert, and that they can implement the business process part of the application well, because they understand the process? If the application that is being developed cannot have the business logic occurring on the SAP side (my ideal as this then means ease of porting app to different platforms and allows for better separation of the View in the MVC.) then perhaps they should be used in the BPX role to advise the iHander what to do!

    I’m sure this podcast will provoke a reasonable amount of discussion, interesting topics guys, keep it up.

  4. Daniel Vocke says :

    Hi Ed, Thomas,

    let me also comment on your brief coverage on the Caffeine project.

    Matthias Steiner already captured nicely what I wanted to say and I do not want to repeat it. Let me just add a few comments:

    1. ABAP Developer & Eclipse don’t match well. Agreed. The decision to go with Eclipse was more a pragmatic one. I wanted to be able to show the complete roundtrip from coding over testing, debugging (yes, we can do ABAP line by line debugging with variable inspection and modification) to exporting the actual libraries. Implementing that in SE80 would have been way more effort and I would not have been able to get people to try it out “hands on” as easily. But I am sure if this “project” makes it to a “product” then SE80 support will be a serious consideration.

    2. Why use an ABAP developer at all? Well, if your task does not require any business process / business data knowledge and you have a Java developer “handy” to do the job then I agree, why bother. But if it is more about the need to implement something on the client / mobile side that requires the ABAP guy’s knowledge and skills then you can’t. Also, you do not always want to have all kinds of business code on the backend. Especially with “fun” smartphone apps in mind you will most likely not want a (multi second?) server roundtrip to validate each input field for instance. Using the Caffeine approach enables the developer to port parts of the business logic to the client/mobile side while still maintaining the “single source of truth” (i.e. not having to replicate business logic to each supported client platform). I’m not arguing against the Gateway approach but believe that it makes sense to have both options.

    3. Using ABAP outside its domain. I think that would not be a good idea and that’s not what I envision. You say that ABAP “is a domain specific language for business processing within the SAP environment” and I couldn’t agree more. I’d describe the the subset I went for same way without the “within the SAP environment” part. Caffeine-ABAP should be used to implement client side business logic and business data processing and certainly no UIs or other general purpose stuff.


  5. KK Ramamoorthy says :

    Was a great episode to tune in to, as usual. Sorry, haven’t been able to drop in my comments regularly these days because of my commute coast to coast but that also gives me ample time to tune in to the podcasts. Comments or not, you can definitely count me in as a regular listener.

    1) Regarding persistent objects, when Tom did the ‘How to’ in his 5 part series two years back, I had the same concerns as Ed had. My question was ‘What’s the point?’. But then when I did use JPA (Java Persistence Architecture) in one of my projects where I had to build a quick web app in Java, the architecture did make sense. As we all know, ABAP is very forgiving and it masks all the pain we have to go through to connect to a database, maintain connection pooling etc. I found JPA more useful in Java development but as far ABAP goes, thanks, I am going to stay with my select statements. One area where Persistence objects may make sense in ABAP is for e.g., if I have to change the underlying table names, but how many times does that happen in real life. Also, with “where used” list and forward navigation, it is easier to change it globally in ABAP anyway.

    2) Regarding Caffeine, “being cool but impractical” applies well. Being an ABAPper I was definitely hyped when I saw ABAP code compiling within Dalvik but it stopped right there. One of the biggest advantages of ABAP is not only that it is a great business programming language (as you said) but also its ability to integrate with other SAP applications. Now, will it be possible to write full fledged ABAP code within an external JVM to do RFC calls for example?, probably not. As Tom said, Gateway offers more than Caffeine, in my honest opinion

    3) Regarding BOL interface, I am currently working on a CRM project and the real cool thing I found was the BOL buffer. There is a tight integration between CRM and ECC through replication so BOL buffer comes in very handy when dealing with “Interaction Center” type transactions and providing an abstraction layer for the data. Because of replication, some objects are stored locally in CRM and some are fetched through RFC from ECC. By having a BOL layer, the developer doesn’t have to worry about where the data comes from but just deal with the business objects. Regarding abstraction, BAPIs did it for us way in the past but cool thing about BOL is that it can be nested objects with parent/child relationships (Contract Header/Contract Items etc) and yes, uses OOPS.. so got to be good ๐Ÿ™‚

    4) You guys cracked me up with the secret message. The lady next to me in the flight thought I was nuts when I laughed at the jokes through out the podcast but the secret messages sealed the deal…she was totally convinced that I was insane ๐Ÿ™‚

    Great job again, love the show.


  6. Chris Paine says :

    Al Templeton tweeted that my example “(simplistic case, where all positions filled and person is not manager of org unit themself) : person->get_position->get_org_unit->get_managing_position->get_holder->get_name” is a train wreak and goes against the Law of Demeter (LoD).

    I don’t really disagree with him – but is it a bad thing?

    The alternative is of course to define a get_manager method in all objects (I’m sure we wouldn’t consider get_manager_name…) and each object chain to the next in exactly the same way as above. (of course, then we’d need to add some parameters, a position can’t manage itself, etc. This ensures that we have a clean access – I’m only dependent on one interface not multiple – yet I still want to make those other methods public as I’d want to use them… So have I created an additional method, with inherent dependency on methods in other classes to solve that very problem? I want to keep this simple, not complex don’t I?

    I’m sure Al and I will debate this over a coffee (yes I know it’s dangerous to feed him coffee, but it’s fun too). Does anyone else have a take on the whole LoD within OO programming idea?

  7. Matthias Steiner says :

    @Chris, I was more concerned in explaining the vision of Caffeine as it sounded “eerie” in the podcast.

    I do agree with you that Gateway is regarded the better option, guess that’s also why Gateway has a whole team behind it and will become part of SAP’s portfolio, while Caffeine is more or less just a technology demo. As such, I was not trying to “sell” it as an alternative to Gateway or the like – but just wanted to explain where Caffeine is coming from or where it could fit in.

    I see your point about turning the seasoned ABAP developer into a BPXer, but the veterans I know would rather die than convert to the “dark side” ๐Ÿ˜‰

    See, I really know lots of guys that are great (procedural) ABAP developers and who know their domain inside-out… but who probably never even heard about REST or HTML5 or the like. How-to get these guys into the 21st century and leverage their expertise?!?

    Just some thoughts…

    Cheers, Matthias

  8. Rich K says :

    Since the other comment were mostly about ‘enterprise stuff’ I wanted to zero in on the conspiracy theory of the week.

    1. Men who stare at goats is a movie about the gov’t trying to create ‘jedi’ warriors through secret experiments? Holy crow, now I gotta see it. No I don’t live under a large rock.

    2. Is Men who stare at goats a ‘re-make’ of Jacob’s Ladder? I assume you have seen it?



  9. Ed Herrmann says :

    Awesome comments, guys! I believe there is enough content here to dedicate our next podcast to these discussions.

    @Matthias – thanks for bringing in some perspective from the Java side of the house. I too get tired of the ABAP vs. Java debate. You should always pick the best tools, framework, and architecture for your current situation and future investments. You just hope and pray that SAP will support that decision long enough for it to be a good decision (eg Guided Procedures).

    @Gregor – hilarious throwing around of acronyms by SAP as usual. Thanks for the link!

    @Chris – It’s true that your example seems to be “non-transactional”, but at the same time, it is still reading one object at any given time as opposed to mass data retrieval for reporting or analysis. It seems that your example is more about leveraging the power of a well designed business object layer (ie an org unit), which can be independent of using a persistence layer below it. You could still use sql in your business object layer methods if it was impractical to use a persistent layer to access the db tables. One of my arguments about the SAP generated persistent objects was that it only generates simple setter and getter methods, so for anything more complex than that, it becomes more trouble than it’s worth, unless you need some of the other advanced benefits like asynchronous updates, etc as Thomas mentioned in the podcast. One of the other points, was exactly what you are doing for your example. You cannot generate a persistent object and be finished with it. A good business object layer still needs to be implemented on top of it to truly work. This is where the disussion of BOL and BOPF begin.

    @Daniel – thanks for chiming in. Certainly any additional tools for a developer is not a bad thing. Maybe it would clear things up if you could explain in more detail how a Caffeinated ABAP development does it’s backend access? I say ABAP is a great domain specific language for the SAP environment mostly because of the easy access to data, functions, and other SAP objects, not so much the language construct itself. Perhaps there is a plan for seamless integration for backend access and communication, but I would see that as darn near impossible. I suspect you still have to use web services or RFC for all communication, which then would make the same argument of why would someone use ABAP outside of it’s domain? Please don’t take my skepticism as being negative, as I applaud your efforts to a project that is pretty damn impressive. I just want to be pragmatic in evaluating it’s true potential and practicality.

    @KK – Thanks for letting us know you are still out there; it’s good to hear your voice! I really enjoyed hearing your thoughts since you have experience on both sides. It’s also good to hear about your real experience with BOL. I still plan on getting you on the podcast sometime soon, so perhaps you can talk in more thoughts on the subject.

    @Rich – I will leave all conspiracy theory responses to Thomas, although I did enjoy both movies Men who stare at goats and Jacobs Ladder. ๐Ÿ™‚

  10. Jeron says :

    Thanks for the discussion on Persistent Objects. It helped moderate the strictly academic and sometimes impractical view of those who chant everything is an object mantra.

    However, one question that remains unanswered for me is, the right approach while developing reports for applications which use persistent objects. Examples are APO, CRM, CHARM etc. Most regular ABAP’ers i know go about figuring out the relationship between relevant tables (there are a lot of them !) and the relationship between the various GUID’s. Is there a better way ?.

    It seems difficult, to figure out the class framework of the application and hence we cannot employ std persistent objects for querying purposes. Another concern is performance, it seems to me that regular ABAP reports would score over persistent objects in performance. This would be because we tend fetch data in one go rather than break them up to smaller individual queries as its done in Persistent objects.

  11. Jon Reed says :

    Guys – looks like the comment thread is pretty well covered this week, so I retaliated with a tweet for Ed I know he’ll be glad to get, LOL. Sorry, but it was low-hanging fruit. Next time move the goalposts. That’s the net-net of it.

    Thomas- bravo for citing a real conspiracy and plans for more. I like the conspiracies that aren’t proven also but the real ones add some truth to the proceedings. Sometimes people do plot and #evilplans are not always harmless or productive.

    I like this theory that Blackberry users are repressed freaks desperately trying to channel their freakdom into corporate pursuits. That doesn’t resemble me at all!


    your fellow Facebook fan.

  12. Daniel Vocke says :


    as a matter of fact there are plans for seamless backend access for Caffeine. I agree with you that one of the core strengths of ABAP is the simple integration with SAP data of different sources and I certainly am planning to port this strength to the client side. Caffeine itself does not come with anything like the DDic itself but rather tries to “attach and map” to any backend type systems it interacts with. Let’s look at a simple example: For the last TechEd Demo I wrote an integration with the River platform (which was comparably easy because it exposes all its data and metadata via REST interfaces). You can simply use backend type definitions once you’ve setup your backend connectivity:

    data my_sflight_table type river table of SFLIGHT/SAIRPORT.

    The compiler resolves the metadata and generates (clientside) representations of the table, so you can use it just as if it was defined locally (or in the DDic if you are in the real ABAP world). You can then also call backend services almost like you would call local services:

    call service SFLIGHT/SAIRPORT destination river exporting name = ‘Paris’ importing result = my_sflight_table.

    A programmer now can easily write a client library that calls different services and merge the results to return them to the UI programmer for instance. Caffeine takes care of all the connectivity, format and type system mapping and lets the ABAP programmer concentrate on what he does best: processing business data and implementing business logic on it.
    You can even do asyncronous calls by simply adding an “async” keyword after “call”. The runtime will then make sure to wait for the call once you actually try to read the result variable, so you do not need to worry about threading at all. I have explained some of this in more detail in this blog post (http://bit.ly/gRaQR5) but I guess I will need to go into more detail in my next one.

    So how does all this relate to actual SAP backend systems? Well, not yet at all, but I strongly believe that you could do the exact same thing with the DDic and/or RFCs and Webservices. I have just implemented a (very simple) ABAP SQL support which is eventually implemented using a JDBC connection but one could also think about routing that through the DDic. However, I believe that communication to and from the backend systems should be through well defined channels (like RFCs or webservices).

    In the end I believe that I am using ABAP outside its “comfort zone” but not outside its domain. ๐Ÿ™‚ And again, I do not see this in competition to the Gateway approach but as an additional option that adds value in certain use cases.


  13. David Greengas says :

    Comment on the +1 Tweets. Since we are the enterprise geeks, I would think it would ++ for the Java developers and a good old “add 1 to” for the ABAP developers.We do not need LOL speak.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: