Skip to Content

About “Java BAdIs (Part II) – Concept Study on a Generic Framework”…


For those who attended TechEd this year it got obvious that SAP is serious about Composite Applications; and SAP NetWeaver Composite Environment (CE) is a powerful development system to build them (among many other things as well, of course.)

So, whether developing composites or other applications the design prinicples applied are quite similar. Some of the most interesting articles on the matter have been recently published by CE PM Axel Schuller:

Flexible by Design

Some of the concepts introduced in the above articles, such as the Backend Connectivity Layer clearly emphasize on the importance of keeping composites flexible. Typically, the process flow of a composite is modelled with Guided Procedures (GP), hence making it possible to alter the processing logic (e.g. by inserting new process steps, etc.) as dictated by ever-changing business needs.

Even though it’s certainly possible to directly consume Enterprise Servcies (ES) and BAPIs directly from GP via the corresponding Callable Object (CO) types, it remains questionable if one should do so. I’d tend to say that directly calling backend systems – by-passing the business logic layer – is something we should have learnt to handle with care/caution since the introduction of multitier architecture. Hence, I’d say that best practices should be to “route” all calls from UI or Process layers through the business logic layer (just to remain flexible.)

So, in the end the business logic layer – usually implemented via CAF Application Services or plain EJB Stateless Session Beans – provides what is known as Session Facades (actually, with Javae EE 5 the better-suited term would be Service Facade) and should be the single point of contact to the UI and Process Layer.

As each CAF Application Service is a potential candidate for being exposed as a new Enterprise Service (please consult this article for more information), the question arises if the Application Services themselves should also be flexible. If one takes a look at the ABAP implementation of SAP’s Enterprise Services published so far, one would spot the usage of customer extension points within the ES coding in the form of BAdIs.

Java BAdIs

Here’s where the article I refer to in this blog comes into play. Part I shows how the BAdI concept known from the ABAP world can be ported to the Java stack. Part II builds upon the introduced concept of EJB JNDI lookups as the base technology for a BAdI and takes it to the next level – in numerous ways:

  • the demo application shipped with part 1 has been ported to SAP NetWeaver Composition Environment
  • switch to the next Java (EE) release (Java 5 brought a lot of new features to ease the pain of us humble developers. A short overview of these features can be found here.)
  • the coding passages that are in charge of the BAdI handling have been factored out and separated into a dedicated and reusable development component (DC)
Recipe for a generic BAdI Framework

So, here’s a list of ingredients I’ve used within the concept study on a generic BAdI framework:

  • 1 fresh installation of SAP NetWeaver Composition Environment 7.1 SP3 (sneak preview available as download on SDN)
  • 1 home-grown annotation
  • 1 spicy EJB 3.0 (AOP-like) interceptor
  • several plain-vanilla usage of Java Reflection API
  • a handful of well-defined naming patterns, default values and coding conventions (configuration by exception)
Mise en place

So, if you want to get your hands dirty and make the most out of the article I would recommend the following:

  1. download the source code (available here)
  2. import the demo application by following the installation instructions provided
  3. download the article here
  4. get yourself a quiet little corner and make yourself familiar with the concept
Request for Feedback 

As stated in the article already… I truly would love to hear your thoughts, opinions, concerns… whatever and I believe that every feedback would be a valuable addition – especially if it leads to discussions 😉

You must be Logged on to comment or reply to a post.
  • Hallo,

    ich finde den Part II einen guten Ansatz, aber wie wird die Versionierung der Signatur (Request oder Response Objekt ändert sich) gehandhabt?

    Generische Interceptors (wie z.b. der TracingInterceptor) kommen auch ohne die spezifischen Signaturen aus (Reflection Method Call), wird dies auch deklarierbar sein (oder nur über EJB3?).

    Im Around Fall kann ich nicht entscheiden ob der wigentliche Service aufgerufen werden soll oder nicht (im Preprocessor?).


    • Hi Bernd,

      thanks for sharing your thoughts on this with us. You certainly raised valid questions!

      I’ll translate the questions prior to replying to them for all the non-German speakers hopefully getting across the original intention.

      1.) How-to handle versioning of the method signature (request and/or response object should be changed)?

      2.) Generic Interceptors (e.g. TracingInterceptor) can live w/o specific signatures (reflection method call); can this be declared somehow?

      3.) In the AroundInvoke case, I cannot set a switch whether or the original Service should be called.

      Well, before I get into more details, let me just remind you that this was just a concept study and not a full-fledged, ready-to-use solution intended to run in productive environments. Hence, I left out a lot of possible features to be able to focus more on the main idea.

      1.) I’m not sure I understand the question completely? What do you mean exactly by versioning? Here, we certainly need to distinguish between the capabilities of ES Services and the request/response objects used by a BAdI Framework. Let me elaborate on this further: The BAdI request/response objects are internal parts of a Business Service API and reside in the same deployment unit as the application that uses them. A change in these objects usually has impact on (or is even driven by) business requirements that the application needs to accommodate to.  As all Development Components (DCs) within the deployment unit (the Enterprise Application in this case) only reference the request/response objects, such a change is transparently reflected instantly within the entire application. Please note, that the request/response objects used internally may not be the identical to the ones you expose via any kind of Service Facade or even Enterprise Service!

          Here, I clearly see the need for versioning. However, if you have a WS exposed that is based on dedicated request/response objects it should be possible to add fields to these objects without breaking the contract. Clients that have been generated against older versions of the     corresponding WSDL would simply send a subset of all possible data. Certainly, the business service would have to be able to cope with older versions and may apply safe-defaults. But that’s another story…
      2.) Here, the possibilities are endless and I just showed an easy approach. In general, one could think of a BAdI Interceptor that can digest any kind of method signatures by leveraging Java Reflection API. One could also add further attributes to the @BAdI annotation or create a custom BAdIConfigProvider that obtains further declarative information about the method signatures from any repository. Furthermore, the substitute type does not rely on any particular convention at all.
      3.) Well, basically what has been said in the answer to question 2 fully applies here as well. If one requires such features it’s simply a task of incorporating corresponding config parameters and to adjust the BAdI Interceptor accordingly.
      Hope these replies are helpful to you.

      Best regards,

      • Yes my main point about the versioning was, that the changed request/reply objects will work in most cases (additional methods), but some might require a recompile.

        With an XML Instance (or DOM or SAX or whatover) based method as in WS calls, this is less of a problem.

        • Well, as stated above I see the BAdI as an internal part of the Service Facade “balck box”, hence the re-compile does not break any interface/APi contract with potential clients.

          The XML based method calls are one layer above/one step before we get into the executing of the Service Facade. During the transition of the WS SOAP call the payload (represented as XML) is transformed to POJOs via JAXB. This happens transparently and the Service Facde (in form of a Stateless Session Bean) acts on simple POJOs. The approach seems solid for me. If you need to be more flexible you have multiple options:

          – add further configuration options to be less restrictive on the expected method signature shandley by the BAdI Interceptor
          – use XML DOM objects (or maybe SDO) as generic structures (depends on the scenario!)

  • Hallo,

    ich finde den Part II einen guten Ansatz, aber wie wird die Versionierung der Signatur (Request oder Response Objekt ändert sich) gehandhabt?

    Generische Interceptors (wie z.b. der TracingInterceptor) kommen auch ohne die spezifischen Signaturen aus (Reflection Method Call), wird dies auch deklarierbar sein (oder nur über EJB3?).

    Im Around Fall kann ich nicht entscheiden ob der wigentliche Service aufgerufen werden soll oder nicht (im Preprocessor?).