Skip to Content

Enterprise JavaBeans Redirection

Enterprise JavaBeans Redirection

The Extensibility concept springs up from the continual customers’ needs for specific extensions. It has a long history within SAP, originating from the ABAP world and the so called Business Add-Ins. Now this concept is making its way in the SAP Java world.

At the moment the Extensibility concept is developed in two main directions:


    1. The idea of Adaptability

As the environment, knowledge and expectations continuously vary, there is always a need for custom changes (e.g. in the UI). But a change leads to a lot of manual adjustments in order to adapt the backend appropriately. Here comes the necessity of a technology to implicitly adapt the whole stack so that to properly fit to the (UI) change without any manual intervention. The requirements and expectations are under research, there are a lot of open topics and discussions and still there is no clear idea for the solution.


    1. The idea of Redirecting

In general the idea is to provide a way a predefined part of an application to be replaced by a custom implementation. In other words, if component X is using component Y by default, the idea is to redirect X to refer to another (custom provided) component Z. There is an open standard in this direction – the Service Component Architecture (SCA).


In the context of the component redirection, we have recently developed the EJB redirection option, which is the subject of this blog. The EJB redirection is based on administering EJB references at runtime. The solution is using only Java EE standard artifacts, there is no proprietary metadata at all. This is not a global extensibility solution. It just fulfills some specific requirements, using the standard mechanisms.


How to redirect an EJB reference

Each EJB reference is displayed in the SAP NetWeaver Administrator and can be modified to point to another EJB, which fulfills certain requirements. You have to open the SAP NetWeaver Administrator and choose Configuration Management → Infrastructure → Application Modules. An annotated EJB reference is redirected by changing its mappedName string value. An xml-specified EJB reference is redirected by changing its jndi-name string value.

In both cases, an EJB reference will be changed if all of the following requirements are fulfilled:

    The custom provided string value is a legal EJB lookup scheme. For more details on the EJB lookup scheme, refer to: EJB Lookup Scheme .

    The custom provided EJB lookup scheme contains all appName, jarName, beanName and interfaceName elements.

    The fully qualified name of the interfaceName in the new EJB lookup scheme is the same as the original one.

      If any of the requirements is not fulfilled, the EJB reference will not be changed and a warning will be displayed.


      When the change is saved, in order for it to be applied, either the whole referencing application or only the runtime of the changed referencing bean is restarted. The latter can be switched by means of the <restart-at-runtime-change> property of the ejb-j2ee-engine.xml.

      The default values can be restored by choosing Get Default in the Environment & References tab in the EJB Module Details section.


      The EJB redirection is a small step towards the extensibility concept realization, but in the right direction.

      You must be Logged on to comment or reply to a post.
      • Hi Alexandrina,
        It is a good blog about extensibility related to backend connectivity topic.
        I have some doubts on this such as
        1. would you please add some more light on SCA based approach and how is it different from EJB redirection approach.
        2. Both these approaches are possible with NW CE EhP1?
        3. Which one to choose in which condition for better results.
        • Hi Aparna,
          Thank you for your comment.
          1. The SCA based approach provides a way to enable an EJB to start referring to custom provided implementation, which is NOT obligatorily to be exactly another EJB but an arbitrary SCA component, could be in another application that could appear at a later stage. This redirecting is described in a “transportable” artifact, i.e. is applied by no manual changes (in NetWeaver Administrator for example) but by deployment of an application.
          2. Yes, both these approaches are supported in NW CE EhP1.
          3. The EJB redirection is suitable to be used for already existing applications as no preconditions in the application code are required. Or generally – for applications that are clean Java EE applications, with no special or additional metadata. The redirection is realized just by changing the mapped-name/jndi-name of an EJB reference to the custom (already deployed) EJB in the NetWeaver administrator.
          To enable the base EJB to refer to an SCA component, some SCA specific metadata should preliminarily present in the base application. In the code of the base EJB, the EJB reference to be redirected to an SCA component should be also annotated with the SCA specific reference annotation By default, the EJB that is specified in the EJB reference is referred. But as soon as the target SCA component of the SCA reference is deployed, the base EJB starts to refer to the target SCA component. (Of course the target SCA component should implement the same interface as the annotated field.)
          Please feel free to contact me for more details about the EJB-SCA integration or how to refer an SCA component from an EJB.
          Best regards,