Introduction
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/blog:
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)
So, if you want to get your hands dirty and make the most out of the article I would recommend the following:
download the source code (available
here)
import the demo application by following the installation instructions provided
download the article
hereget 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 😉
