Skip to Content

Building Extensible Composite Applications with SAP [free PDF]

Building Extensible Composite Applications with SAP - Book Cover

A couple of years back when I started blogging on SCN I wrote a series of articles about how-to develop extensible Java applications. Inspired by the Business Add-In (BAdI) framework I even came up with a concept to provide extension points for any application running on a Java EE application server such as the SAP Composition Environment (CE).

Shortly after publishing those articles I was contacted by SAP Press asking me to write a whole book about it and so I did. You can read the whole story here.

Well, a few weeks back the book was put out of print… the good news: You can now download the PDF version for free!

  • [Download] You can now download the PDF version of this book free of charge! (4.4 MB)
  • [Source] Here’s the source code (8.7 MB)

Note: While the book focuses on how-to develop Composites based on the SAP Composition Environment the underlying concept purely leverage standard features of Java EE and as such are definitely applicable to other application servers (with minor modifications.)

Matter of fact I have been thinking about porting the whole extensibility framework to the 2.x branch of SAP HANA Cloud – stay tuned! 

Building Extensible Composite Applications with SAP - Book Cover
You must be Logged on to comment or reply to a post.
  • This is really cool. I've bought the online version a few years back and it has really helped me a lot! Always had difficulties with that version though, as the web-reader isn't very user-friendly. A PDF is way better, and more portable (to other devices) too.

    I'm looking forward to reading your new ideas (book?) on how to make cloud applications extensible and pluggable. Would that be based on OSGI instead of SAPs own componentization model?

    • Hi Jan,

      happy to hear you read the book and that it helped you!

      Regarding your questions: well, the framework I build depended only on custom annotations, JNDI lookups and EJB interceptors. All of which should be available in SDK version 2.x so one would not need OSGi on the application side at all. There's no proprietary componentization model in NEO.

      The biggest caveat in porting the framework is that you'd need to deploy the app, the framework and the extensions together in order to do local look-ups. Otherwise you'd need to make remote calls...

      Some ideas to implement would be to use real AOP aspects in addition to EJB interceptors and of course I'd have to incorporate multi-tenancy...



      • Hi Matthias,

        Seriously, I don't think you have any idea how much your book has helped me to really get started with Java. Before that, I was mainly doing plain and simple webdynpro (Java) and was using componentization only for my own convenience (reduce deployment times). Only when an actual customer case popped up in which additional functionality was supposed to be pluggable, I really got started with more advanced Java technologies such as EJBs and JNDI. Your book has helped me tremendously to get grip on the components that I was developing. I don't think I'm saying too much when I say that at that time I really felt like your apprentice, even though it was through this book (and I still do feel that way btw).

        If you are going to release a new book on componentization for the new LJS-based Java environments, count me in for a pre-order! I'm very curious to read on what approach you would take as seasoned expert in this field. From your response, I can almost guess that it is going to be Spring based, but I'm sure there is still plenty of room for other surprises 🙂

        In a discussion with Samir Zeort at the Codejam Huizen, we were also discussing OSGI. Samir mentioned that many developers find it too complicated and that adoption is quite low. If I understand your response correctly, you're also implying that OSGI may not be the best way to make your application pluggable/extensible. Is SAP steering away from OSGI in general, or is this just your and Samir's personal preference?



        • Hi Jan,

          thanks for the kind words - makes me happy that the content of the book had such a positive impact for you! It's feedback like yours that make writing a book a rewarding experience after all!

          Regarding your questions: yeah, I'm a big Spring fan as you know, yet the extensibility concepts are not depending on it, but as-is rather leverage standard Java EE means. As mentioned I'm looking into using AOP pointcuts as well (e.g. AspectJ). Surely it would work fine with Spring, yet I would not make it a hard dependency.

          Talking about OSGi: well, there's definitely a learning curve here, but if you're looking to develop truly modular application(s) then it's a viable option for sure. OSGi is a great technology to make applications pluggable/extensible especially since you can install/deinstall bundles w/o downtimes etc.

          OSGi is a central aspect of our cloud runtime and consequently not something we "are steering away from". It's just that we do not promote it actively at the moment.