As some of you might know SAP is a contributor in the OpenSource project Eclipse. As part of that engagement we also organize so called "Eclipse DemoCamps" to show what one can do with this great development platform which is used a lot in the IT industry and is also the IDE of choice for SAP HANA Cloud Platform.

This year's Eclipse DemoCamp will be held at the day of planned release date for Kepler, the release name of Eclipse V4.3.

In case you are interested in joining the event you can register for free or even propose a speaking slot at the Eclipse DemoCamp and join speakers like Mike Milinkovich, the Executive Director of the Eclipse Foundation.

You'll be able to listen to interesting talks, get free drinks & food and a lot of possibilities to connect with other developers during the event.

So register today and join us in Walldorf for the Eclipse DemoCamp.

Best,

Rui

In this blog post we'll look at how one can use Spring Security framework together with the usual way of securing a JEE application on NetWeaver 7.3 and what this can bring us. Here are the useful links :

• Pre-Authentication with JEE container
• Spring MVC
• Securing web applications

For the reference, I've tested this setup with Spring Security 3.1.3.RELEASE (which in turn depends on Spring MVC 3.0.7.RELEASE).

Spring Security is a popular and very flexible framework which allows to configure and manage all aspects of securing a web application : authentication, authorization, access control to domain objects. One of the many useful things which this framework provides is a spring-security-taglibs module which allows one to protect the various pieces of the JSP page using security tags tied to the user's role membership (authorization). For example, we can have a JSP like this :

<%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags"%>

<p>Hello, this page is accessible to all users with ROLE_EVERYONE</p>

<sec:authorize access="hasRole('ROLE_SFLIGHT_USER')">
    <p>This text and link below should only be visible to users with
    ROLE_SFLIGHT_USER</p>
    <a href="<%=request.getContextPath() %>/secure">secure page</a>
</sec:authorize>

Notice the use of sec:authorize tag which protects access to the part of the page depending on whether or not the current user has a role SFLIGHT_USER. We'll discuss below how we can configure Spring Security to work seamlessly with the security services provided by out JEE container. The idea behind this integration is quite simple: NetWeaver already handles the user authentication for us, there is also a mechanism to map the UME roles of the portal user to the roles referenced in the web.xml of our application. All we have to do is to find a way to make Spring Security framework recognize these roles as the "granted authorities" associated with the authenticated user.

We start with a simple web application set up. Here are the interesting parts of our starting web.xml :

<login-config>
    <auth-method>TICKET</auth-method>
</login-config>

<security-role>
    <role-name>EVERYONE</role-name>
</security-role>

<security-role>
    <role-name>SFLIGHT_USER</role-name>
</security-role>

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Spring Security Integration Test Application</web-resource-name>
        <url-pattern>*</url-pattern>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint>
        <role-name>EVERYONE</role-name>
    </auth-constraint>
    <user-data-constraint>
        <transport-guarantee>NONE</transport-guarantee>
    </user-data-constraint>
</security-constraint>

We chose a "tiket" authentication method for our web application meaning that the user will be considered authenticated if he or she previously logged in on the portal and that there is JSESSIONID and MYSAPSSO2 cookies are present in his or her browser session (usual SAP SSO via SAP Log on ticket). We declare two security roles "EVERYONE" and "SFLIGHT_USER" for our example. The first one is a general role assigned to every UME user. The other one is an example role which we can create and assign to some test user. We then protect any access to our web application by setting url-pattern of the security constrain to "*". The idea is that we let the JEE container to manage the authentication of the user but the finer granularity access protection within the application we will delegate to Spring Security. For the mapping between the UME roles and the web application security roles we also need this in the web-j2ee-engine.xml file of the web application module :

<security-role-map>
    <role-name>EVERYONE</role-name>
    <server-role-name>EVERYONE</server-role-name>
</security-role-map>

<security-role-map>
    <role-name>SFLIGHT_USER</role-name>
    <server-role-name>SFLIGHT_USER</server-role-name>
</security-role-map>

Now we need to set up and configure the filter chain used by Spring Security. This is done by specifying a Spring's application context file containing all the security configuration in our web.xml file :

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/context/security-config.xml</param-value>
</context-param>
<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

The security configuration file, security-config.xml, uses Spring Security namespace for convenience. It uses the security scenario of "pre-authentication" and relies on two classes provided for us by the framework: J2eePreAuthenticatedProcessingFilter and  which integrates with the container authentication process by extracting user principle from the HttpServletRequest and J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource which is responsible to map a configured set of the security roles specified in the web application descriptor file to the set of GrantedAuthorities provided the user membership in these roles has been established. Here is the security-config.xml file :

<beans:beans xmlns:beans="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.springframework.org/schema/security"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.1.xsd">

    <http auto-config="true" use-expressions="true">
        <jee mappable-roles="EVERYONE,SFLIGHT_USER" />
        <intercept-url pattern="/**" access="hasRole('ROLE_EVERYONE')" />
        <intercept-url pattern="/secure/**" access="hasRole('ROLE_EVERYONE')" />
    </http>

    <authentication-manager>
        <authentication-provider ref="preAuthAuthenticationProvider"></authentication-provider>
    </authentication-manager>

    <beans:bean id="preAuthAuthenticationProvider"
        class="org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationProvider">
        <beans:property name="preAuthenticatedUserDetailsService">
            <beans:bean
                class="org.springframework.security.web.authentication.preauth.PreAuthenticatedGrantedAuthoritiesUserDetailsService"></beans:bean>
        </beans:property>
    </beans:bean>
</beans:beans>

Notice the use of "jee" element in the "http" configuration, it is a shortcut for configuring an instance of J2eePreAuthenticatedProcessingFilter filter and registering it with the defaulf filter chain. Also, by default all the JEE security roles specified in the "mappable-roles" attribute will be mapped to the GrantedAuthorities with the names prefixed by "ROLE_".

Once the pre-authentication mechanism is successfully configured we can protect URL access using expressions of the kind "hasRole('ROLE_FROM_UME_HERE')" in the global "http" configuration element and in the security tags in our JSPs. For the reference, this is the Spring MVC configuration file, mvc-config.xml, which I've used for the the web application, it uses "mvc" namespaces for convenience :

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:mvc="http://www.springframework.org/schema/mvc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans 
        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/mvc 
        http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd">

    <mvc:annotation-driven />

    <bean id="viewResolver"
        class="org.springframework.web.servlet.view.UrlBasedViewResolver">
        <property name="viewClass"
            value="org.springframework.web.servlet.view.JstlView" />
        <property name="prefix" value="/WEB-INF/jsp/" />
        <property name="suffix" value=".jsp" />
    </bean>

    <mvc:view-controller path="/" view-name="index"/>
    <mvc:view-controller path="/secure" view-name="secure"/>
</beans>

It could be referenced in the web.xml file in the standard way :

<servlet>
    <servlet-name>springMvcServlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/context/mvc-config.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>springMvcServlet</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

Using Spring Security in the standard JEE web application can be very useful. Other than the use of the security tags in the JSPs, described in this post, one can think of securing method's access in Java beans or using Access Control Lists (ACL) management for example.

In this blog I'll share with you an alternative to the SAPUI5 development on the NetWeaver platform. SAPUI5 is an interesting and innovative effort from SAP on the front of modern UI development. But at the time of writing this post, it is still in an evaluation beta stage and it seems like there is still no decision about the licensing scheme that SAP will adopt for this technology. Since NetWeaver has been able to take advantage of Java 5 and JEE 5 and especially since it has become very easy to deploy a third-party JARs with a webapp deployed on this platform, we have a multitude of free and open source alternatives available for developing modern UI in the same way SAPUI5 has been designed. I will describe a way of using a very cool JavaScript framework, Dojo, together with my favorite MVC framework, Spring, to build a simple hello world webapp which demonstrates how these technologies can be used together on NetWeaver 7.3.

The sources for this webapp can be found in the Code Exchange project dojoui.

Note: I assume that you are already at least somewhat familiar with Spring MVC and Dojo frameworks.

Download a Dojo distribution from their site. I used the latest release, 1.8.1. You'll need to create a JAR containing these packages under the path /META-INF/resources/. The idea is that we will delegate to Spring the care of serving and caching these JavaScript files from this JAR for us, instead of bundling them as is in our WAR.

You also need to get all the JARs necessary for Spring MVC setup. There many ways to do this. I use Apache Ivy for this purpose. You can create a simple Java project in NWDS, import the single build.xml file from the Ivy's site and create a simple target which will retrieve Spring's libraries and their dependencies for us from the Maven repository. Here is the target:

<target name="resolve-and-retrieve" depends="install-ivy" description="--> resolves dependencies decalred in ivy.xml file">
    <ivy:resolve file="${basedir}/ivy.xml" transitive="true"/>
    <ivy:retrieve/>
</target>

It will resolve the dependencies declared in ivy.xml file, download them and put then in lib folder. Here are the contents of ivy.xml file:

<info organisation="your.org" module="anything" />
<configurations defaultconfmapping="default->default"></configurations>
<dependencies>
    <dependency org="org.springframework" name="spring-webmvc" rev="3.1.0.RELEASE" />
    <dependency org="cglib" name="cglib" rev="2.2" />
    <dependency org="org.codehaus.jackson" name="jackson-mapper-asl" rev="1.9.10" />
</dependencies>

You might need ivysettings.xml file, as well, here it is:

<ivysettings>
    <settings defaultResolver="chain" />
    <resolvers>
        <chain name="chain">
            <ibiblio name="central" m2compatible="true"></ibiblio>
            <!-- uncomment if you want to use Spring's milestone libraries -->
            <!-- 
            <ibiblio name="spring-milestone" m2compatible="true"
                root="http://repo.springsource.org/milestone"></ibiblio>
            -->
        </chain>
    </resolvers>
</ivysettings>

After retrieving the libraries you should have all the JARs (together with the dojo-1.8.1.jar created above) needed to create a simple webapp. You can see all the JARs needed in the image of the webapp structure at the end of this post.

Create a simple webapp project in NWDS (tmp~dojo~web) and assign it to an EAR (tmp~dojo~ear). Copy all the JARs into /WEB-INF/lib directory of your web project, they will be deployed to the server. Now we need to set up Spring's MVC for our webapp. This requires registering Spring's Dispatcher servlet in our web.xml file. Here it is:

<servlet>
    <servlet-name>SpringMvcDispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextClass</param-name>
        <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
    </init-param>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>ch.unil.dojo.web.config.WebConfig</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>SpringMvcDispatcher</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

Spring MVC can be configured using Java annotations, this is how I have done it:

/**
 * Web context configuration to be processed by {@code
 * AnnotationConfigWebApplicationContext} and specified as {@code
 * contextConfigLocation} parameter for {@code DispatcherServlet}, see {@code
 * web.xml} file.
 * <p>
 * {@code EnableWebMvc} annotation configures default MVC infrastructure
 * including an instance of {@code MappingJacksonHttpMessageConverter} Json to
 * Java converter for request handlers. {@code ComponentScan} annotation
 * specifies the base package which will be scanned for the {@code Controller}
 * annotated classes.
 * 
 * @see org.springframework.web.servlet.DispatcherServlet
 * @see org.springframework.web.context.support.AnnotationConfigWebApplicationContext
 * @see org.springframework.web.servlet.config.annotation.EnableWebMvc
 * @see org.springframework.http.converter.json.MappingJacksonHttpMessageConverter
 */
@EnableWebMvc
@Configuration
@ComponentScan(basePackages = "ch.unil.dojo.web")
public class WebConfig extends WebMvcConfigurerAdapter {

    // set up the default view resolver, mapping logical view name
    // to a JSP with the same file name
    @Bean
    public ViewResolver viewResolver() {
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setPrefix("/WEB-INF/pages/");
        viewResolver.setSuffix(".jsp");
        return viewResolver;
    }

    // add handlers for the static resources (js, css, images),
    // will look up and cache Dojo files from the jar on the classpath
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/resources/**").addResourceLocations("classpath:/META-INF/resources/")
            .setCachePeriod(31556926);
    }

    // set up the redirection to the main view if the root URL is accessed
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/").setViewName("index");
    }
}

Notice how we are setting up a special ResourceHandler for all the Dojo JavaScript files which will be served from the JAR on the classpath and even cached for faster subsequent accesses.

Now we can create our JavaScript font-end UI using Dojo. Create a JSP page called index.jsp in /WEB-INF/pages/ folder. The Spring will automatically use this view for all requests to the root of the web application. Here are the contents of this file:

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Testing Dojo</title>
<link rel="stylesheet" type="text/css"
    href="<%=request.getContextPath()%>/resources/dijit/themes/claro/claro.css">
<script src="<%=request.getContextPath()%>/resources/dojo/dojo.js"
    data-dojo-config="async: true,
    packages: [{name: 'js', location: '<%=request.getContextPath()%>/resources/js'}],
    gfxRenderer: 'svg'"></script>
</head>

<body class="claro">

    <script type="dojo/require">at: "dojox/mvc/at"</script>
    <div data-dojo-type="dojox/mvc/Group" data-dojo-props="target: model">
        <div data-dojo-type="dijit/form/TextBox"
            data-dojo-props="value: at('rel:', 'name'), placeHolder: 'First Name',
                properCase: true, trim: true"></div>
        <div id="submitBtn" data-dojo-type="dijit/form/Button"
            data-dojo-props="label: 'Submit'"></div>
        <div id="surfaceDiv"></div>
    </div>

    <script>
    require(["js/utils", "dojo/_base/kernel", "dojo/when", "dojo/parser", "dojo/json", "dojo/Stateful", 
             "dojo/on", "dojo/mouse", "dijit/registry", "dojox/gfx", "dojox/gfx/fx", "dojo/colors"],
            function(utils, kernel, when, parser, json, Stateful,
                    on, mouse, registry, gfx, gfxAnim, Color){

        //create a model
        var model = kernel.global.model = new Stateful();

        //parce the document, then connect the submit button
        when(parser.parse(), function() {
            //create SVG surface
            var surface = gfx.createSurface("surfaceDiv", 400, 100);
            registry.byId("submitBtn").on("click", function(evt){
                //make Ajax request
                when(utils.ajaxRequest("<%=request.getContextPath()%>/greet",
                        json.stringify(model)), function(data) {
                     //clear previous shape
                    surface.clear();
                    //crete text shape
                    var text = surface
                        .createText({x: 200, y: 50, text: data.greeting, align: "middle"})
                        .setFont({family: "Arial", size: "20pt", weight: "bold"})
                        .setFill(Color.named.skyblue);
                     new gfxAnim.animateTransform({
                         duration: 1500,
                         shape: text,
                         transform: [{
                             name: "rotategAt",
                             start: [0, 200, 50],
                             end: [360, 200, 50]
                         }]
                     }).play();
                });
            });
        });
    });
    </script>
</body>
</html>

This is a simple hello world webapp but with a little Dojo twist. It collects the user's name and sends to the Spring's controller in a form of an Ajax request with the name serialized as a Json string. On the cotroller's side the Json string from the body of the request is automatically converted to a POJO of the corresponding structure by the MappingJacksonHttpMessageConverter instance registered with Spring MVC by default (it's a part of EnableWebMvc configuration). Once the greeting message is generated it is stored as a value of the POJO's property and the POJO is serialized to the body of the HTTP response in the form of a Json string again automatically by the Jackson mapper. The returned Json response is parsed by Dojo which displays the greeting message as a rotating SVG text shape.

As you can see, we don't actually use a lot of JSP's functionality, it is mostly a plain HTML page with some JavaScript. However, we need a reference to the context path of the webapp which we can obtain by using a scriplet <%=request.getContextPath()%>. We also use a custom module, "js/utils", which Dojo is instructed to look up under /resources/js location. I have put this file on the classpath (src folder) under /WEB-INF/resources/js/utils.js this way the Spring's ResourceHandler servlet can pick it up as well. Actually, this is the only way that I found to reference my custom module on NetWeaver if I wanted to have it served by the Spring's resources servlet. Here are the contents of this file, it's just a simple utility to generate an asynchronous Ajax request to the server using Dojo's handy "dojo/request" module.

define(["dojo/request", "dojo/Deferred"], function(request, Deferred){
    return {
        ajaxRequest: function(path, data, sync){
             var def = new Deferred();
            request.post(path, {
                headers: {"Content-Type": "application/json"},
                data: data,
                handleAs: "json",
                sync: (sync || false)
            }).then(function(data){
                def.resolve(data);
            },
            function(error){
                def.reject(error);
            });
            return def;
        }
    };
});

The controller class which is responsible for handling the Ajax request is given below:

/**
 * Controller which will handle all incoming HTTP requests. Registered in the
 * MVC infrastructure via {@code ComponentScan} annotation used in the web
 * context configuration class.
 */
@Controller
public class AjaxController {
    private static final Logger logger = Logger.getLogger(AjaxController.class);

    /**
     * Request handling method applicable to any POST request with a header
     * {@code Content-type: application/json} and the path {@code /greet}.
     * Spring automatically converts the Json string from the body of the
     * request via {@code MappingJacksonHttpMessageConverter} to an instance of
     * {@code Greeting} form and serializes it back to a Json string set to the
     * body of the response.
     * 
     * @param form person data
     * @return greeting data
     * 
     * @see org.springframework.http.converter.json.MappingJacksonHttpMessageConverter
     */
    @RequestMapping(value = "/greet", method = RequestMethod.POST, consumes = "application/json", produces = "application/json")
    public @ResponseBody
    Greeting greet(@RequestBody Greeting form) {
        logger.debug("Processing Ajax request for /greet with form: " + form);
        form.setGreeting("Hello, " + form.getName() + "!");
        return form;
    } 
}

As you can see Spring makes it very easy for us to work with this kind of requests and thus it is a particularly good choice for the server-side Ajax processing.

Here is an outlay of the entire webapp project in NWDS for reference:

We can recap the things that we have used in this showcase and the advantages of this architecture.

1) Dojo front-end

Dojo is an excellent JavaScript framework, it is reach and constantly growing, uses AMD module loading, has a vibrant community and it is open source. The learning curve for Dojo is probably not much steeper than the one for learning SAPUI5 considering that you would have to learn JQuery with SAPUI5 at some point. The advantage of using Dojo is that you don't need to use the NetWeaver at all. I actually developed the entire webapp in STS with a Tomcat 6. Of course you will not get the code assist for the JavaScript files as you have with SAPUI5 plugin but at least it is free.

2) Spring MVC

Spring MVC framework allows to configure a clean separation of concern, RESTfull architecture for a webapp very easily, especially when it comes to conversion to and from Json requests. It all happens behind the scenes with Jackson mapper allowing one to implement server-side logic with simple POJOs. If you like this setup you can easily imagine using Sprin's Security to make your webapp secure or to use Spring CCI with an EJB session facade to connect to an ABAP backend.

As Matthias Steiner already mentioned in his blog post SAP NetWeaver Cloud & Open Source - A match made in heaven on Monday, we organized the third SAP Open Source Summit last week Thursday and Friday. While this was an internal event, the topic obviously is not. We also had five external keynote speakers -  it was great to get their perspective and to use the opportunity for more in-depth discussions on trends and future opportunities. More on that the next episodes.

A theme that I heard more than once from our guests is that they recognize from the summit sessions and discussions (as well as from earlier interactions) that SAP is a quite active open source consumer and contributor, but only very few people outside of SAP know about that. It seems to be one of the best kept secrets - even though there is no reason to keep it secret. Point taken. This post is an(other) attempt to change that.

Let me start with an example. One that Mike Milinkovich mentioned during his keynote about Foundations 2.0: SAP is the third-largest committer to Eclipse projects. As of today, 31 committers from SAP have done 63,867 commits to 26 Eclipse projects with together 3,127,480 lines of code. I don't think that we are or need to be in a race here to compete for the second or third place. I think that the numbers just say that open source contributions are a normal course of action for SAP and become increasingly important from a product development perspective.

The other example I saw last week is the discussion around best practices for open source contributions. At the past open source summits (2009 and 2010, those days organized by Erwin Tenhumberg) we talked a lot about how to become a committer at an open source project. This time, we had a number of committers and even project leads on stage sharing their experience and recommendations. It is interesting to notice that Stephan Klevenz (committer to odata4j at Google Code), Matthias Sohn (co-lead for EGit and JGit at Eclipse), Krum Tsvetkov (co-lead for Eclipse Memory Analyzer, originally initiated by SAP), and Florian Mueller (chair and VP for Apache Chemistry) all work for SAP. And now the discussion was much more about effective project management, IP management done by open source foundations or procedural questions like how to report and handle security vulnerabilities in open source code (a topic that is better not discussed in the public until a fix is available).

Now, instead of overloading this blog post, my plan is to write a series on the Open Source Summit 2012 as follows:

1. Overall Impressions (this post)
2. What we think - SAP Open Source Strategy
3. Insights from keynotes
4. What we do next

I hope this will be interesting for a broader audience and look forward to your feedback.

When the SAP Java Virtual Machine team decided to join the OpenJDK project last year, they first of all wanted to understand the overall direction and governance structure of the project. After Volker Simonis and other team members contributed a few bug fixes and minor enhancements, they quickly observed that their contributions were not only welcomed, but that there are many similar interests among the different OpenJDK project members - the most important one being to protect the future of Java. What a bold statement ... in practice this means that through active participation and contribution from a broader group of participants, the work can be shared and innovation for the Java platform can jointly be defined by means of one standard implementation. An interesting observation is obviously that the participants include key vendors such as Oracle, Red Hat, Apple, IBM, and SAP that in various regards are competitors in the marketplace. But there is less and less reason to compete on Java Virtual Machine and Java Development Kit features where the same requirements are implemented differently.

Based on this experience, SAP today decided to significantly incresae its contributions. Please read Volker Simonis' blog post on the OpenJDK mailing list about a new project proposal. We now plan to contribute whole platform ports in a belief that it is economically better to standardize our own implementation than to keep it proprietary. The first platform port that we are going to contribute is Linux on PowerPC. Based on that, we will work together with IBM and others and also use it as a basis for the AIX on PowerPC port. Depending on the outcome, other ports for other platforms might follow. This will also help us to better integrate and align our own platform ports and extensions with current Java developments, and it will let the OpenJDK community profit from SAP’s longstanding experience in Java and Java VM technology. Every OpenJDK user will be able to benefit from a broader choice of platforms, an important consideration for many SAP customers. SAP’s commitment to deliver a high class, commercially licensed Java Virtual Machine remains unchanged. SAP is currently delivering its commercial Java based products with SAP JVM, a certified Java Virtual Machine (JVM) and Java Development Kit (JDK), compliant to the Java Standard Editions 1.4, 5, 6 & 7 on all 14 platforms supported by SAP.

In the part 1 of the series we have set up an EJB session facade with the Spring's CCI utility code for communicating with the ABAP back-end via JRA adapter deployed and configured on the AS. In this post we will look at the way we can deploy the web front-end of the application based on JSF 2.0 reference implementation. In addition, we will try to use a popular UI components library for JSF, Primefaces.

The reason for this (unusual) combination of technologies, is that NW 7.3 supports only JSF 1.2 out of the box, with a custom UI components library for the SAP look-and-feel. However, the JSF technology has greatly progressed since the JSF 1.2 edition, and the multitude very useful UI components libraries have been created for developing the UI with this technology. Here are some of them: Tomahawk, Richfaces, Primefaces, IceFaces, just to name a few. For our proof-of-concept I have chosen a popular combination of Mojarra JSF 2.0 implementation combined with Primefaces library.

Now available part 3 of the series. Source code is available on Code Exchange project jsf20-nw73-showcase.

Deploying Mojarra to the AS

First we need to substitute the JSF 1.2 library used by default by the AS with the Mojarra 2.1.7 implementation of JSF 2.0. I'm reproducing below the steps described by Schindler Ingo in the forum post: JSF2 on Netweaver 7.3 (see the correct answer, and the remark at the end of the thread about "gzip-compression of the AS"), whose insight proved invaluable in this task.

Another very interesting article by Goran Stoiljkovski explains well how the AS resolves classpath dependencies and what is needed to deploy an application using so called heavy resource loaders. After several attempts, I settled on the Ingo's proposed method of deploying and referencing Mojarra as a library on the AS.

Download Mojarra library JAR. I chose javax.faces-2.1.7.jar, the latest at the time of the writing of this post. Create a simple General --> Project project in the NWDS workspace. Add the following files and folders to the project (Ingo's suggestion):

What we are doing here is creating by hand  the contents of the SDA file (mojarra217.sda) which will contain our JSF 2.0 library in order to deploy it to the AS. Later our application's EAR will reference this (deployed) library in it's application-j2ee-engine.xml descriptor. The easiest way to go about creating such SDA is to locate any library SDA already deployed on the AS, copy it locally, change the extension to .zip and unzip it. Then all the one needs to do is to adjust slightly the contents of the relevant files. Another way is to create the library SDA using the batch script make_SDA.csh found in <path_to_java_instance>/j2ee/deployment/scripts directory on the server. Look at ReadMe.txt for usage guidelines, and library.properties or primary-library.properties templates in the same directory.

Here are the contents of the SDA's files shown above:

application-j2ee-engine.xml

<application-j2ee-engine xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="application-j2ee-engine.xsd">
<provider-name>local.j2ee</provider-name>
</application-j2ee-engine>

Provider name is arbitrary, but you should be consistent throughout the SDA.

MANIFEST.MF

Manifest-Version: 1.0
Implementation-Title: javax~faces~2.1.7
Implementation-Version: 1
Implementation-Vendor-Id: local.j2ee
Specification-Vendor: SAP AG

Notice the Implementation-Title and Implementation-Vendor-Id entries.

SAP_MANIFEST.MF

Manifest-Version: 1.0
Ext-SDM-SDA-Comp-Version: 1
softwaretype: library
JarSAP-Standalone-Version: 20090803.1000
JarSAPProcessing-Version: 20090907.1000
deployfile: sda.xml
archivetype: DC
keyname: javax~faces~2.1.7
keyvendor: local.j2ee
keylocation: Deployment Manager
keycounter: 1
componentelement: <componentelement  name="javax~faces~2.1.7" vendor="local.j2ee" componenttype="DC" subsystem="NO_SUBSYS" location="Deployment Manager" counter="1" deltaversion="F" updateversion="LB-20120413181800" componentprovider="Deployment Manager" archivetype="DC"/> 
JarSL-Version: 20100616.1800
compress: true

Notice the softwaretype, keyname entries and the name and vendor attributes in the componentelement.

sda-dd.xml

<SDA>
<SoftwareType>J2EE</SoftwareType>
<engine-deployment-descriptor version="2.0">
    <substitution-variable>
      <variable-name>com.sap.dc_name</variable-name>
    </substitution-variable>
    <substitution-variable>
      <variable-name>com.sap.dc_vendor</variable-name>
    </substitution-variable>
    <substitution-variable>
      <variable-name>com.sap.sld.GatewayHost</variable-name>
    </substitution-variable>
    <substitution-variable>
      <variable-name>com.sap.sld.GatewayService</variable-name>
    </substitution-variable>
</engine-deployment-descriptor>
</SDA>

sda.xml

<SDA>
    <SoftwareType>library</SoftwareType>
    <engine-deployment-descriptor version="2.0" />
</SDA>

Standard content for SDA deployment descriptor.

provider.xml

<!DOCTYPE provider-descriptor SYSTEM "library.provider.dtd">
<provider-descriptor>
    <display-name>javax~faces~2.1.7</display-name>
    <component-name>javax~faces~2.1.7</component-name>
    <major-version>2</major-version>
    <minor-version>1</minor-version>
    <micro-version>7</micro-version>
    <provider-name>local.j2ee</provider-name>
    <references>
        <reference type="library" strength="weak" provider-name="sap.com">servlet</reference>
    </references>
    <jars>
        <jar-name>lib/javax.faces-2.1.7.jar</jar-name>
    </jars>
</provider-descriptor>

Hint: one can find DTD files useful when creating some of these XML files by hand in <path_to_java_instance>/j2ee/cluster/server0/dtd directory on the AS.

Zip the project root directory and rename the resulting file with .sda extension (mojarra217.sda). You can now deploy the resulting SDA to the AS using Deploy View, External Deployable Archives.

Using the steps from Goran's article we can now check if the library was successfully deployed on the AS. Use SAP Management Console of NWDS to find out which is the port for the telnet on your AS, by looking at the Access Points, usually it is 50008. Login to the telnet using the administrator account. Use the command to list the library loaders of the AS (see man LL for help).

If you see your library listed with library: prefix then it was successfully deployed to the server.

Creating JSF 2.0 Dynamic Web Project

Now we are ready to create and deploy the web module of our application which will use the above Mojarra library and Primefaces UI componet library.

First we need to create a User Library in NWDS with the javax.faces-2.1.7.jar, this will be needed during JSF Facet selection of our Web project. For this, go to Preferences --> Java --> Build Path -->User Libraries and create new user library adding the Mojarra JAR to it.

Create new Dynamic Web Project. In the Configuration group, choose Default Configuration for SAP Libraries and click Modify button. Add JavaServer Faces 1.2 facet to the project (we will later change the JSF version by hand). Do not forget to add the Web project to the EAR project created in part 1 (tmp~sflight~ear).

When prompted to specify JSF capabilities, deselect the SAP Component Library for JSF and select the Mojarra user library you've created previously. This is needed only for compilation (access to javax.faces.context.FacesContext, etc), since at runtime it is the library deployed on the AS that will be used.

Once the project has been created it should have the following structure (with some of the files which will be added later) :

The project needs to reference the EJB and Java modules created in part 1. For this go to the project Properties --> Java EE Module Dependencies and select the EJB and Java modules. Now the Web module should have compile-time access to EJBs and DTOs.

We need to modify the web.xml file.

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    id="WebApp_ID" version="2.5">
    <display-name>tmp~sflight~web</display-name>

<!-- Configure listener for Spring web application context -->

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/applicationContext.xml</param-value>
    </context-param>

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

<!-- Your default application web page, index.xhtml, for example, see example below -->

    <welcome-file-list>
        <welcome-file>layout.xhtml</welcome-file>
    </welcome-file-list>

<!-- Faces servlet and mapping of xhtml pages -->

    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>

</web-app>

The only non-standard entry in this file is the reference to Spring's web application context loaded from the WEB-INF/applicationContext.xml. This file contains the jndi-lookup reference to the local stateless session EJB from the tmp~sflight~ejb project which will be deployed in the same EAR. We can find the exact JNDI name of the EJB using the technique described in part 1.

applicationContext.xml

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:jee="http://www.springframework.org/schema/jee"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
    http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee.xsd">
    <!--
        Look up JraManagerBean EJB from the the JNDI    
     -->
    <jee:jndi-lookup id="jraManager"
        jndi-name="unil.ch/tmp~sflight~ear/LOCAL/JraManagerBean/ch.unil.sflight.ejb.JraManagerLocal" />

</beans>

We now modify faces-config.xml file to manually set the version of JSF to 2.0.

faces-config.xml

<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
    version="2.0">

<!-- application, converters, etc... -->

</faces-config>

We now are ready to create some views (xhtml pages) and corresponding JSF managed beans. For example, SearchFlights.java is shown below

//JSF 2.0 allows for annotation-driven specification of managed beans
@ManagedBean
@SessionScoped
public class SearchFlights implements Serializable {
    private static final long serialVersionUID = 1L;
    private static final Location loc = Location
            .getLocation(SearchFlights.class);

//we need to manually retrieve this bean from the application context, see init() method
    private transient JraManagerLocal jraManager;

    private String airlineId;
    private String destFrom;;
    private String destTo;
    private Collection<FlightData> flights;

//getters and setters are omitted

//will be executed once the bean has been initialized
    @SuppressWarnings("unused")
    @PostConstruct
    private void init() {
        jraManager = Utils.getBean("jraManager", JraManagerLocal.class);
    }

//action event called from the view
    public void search(ActionEvent event) {
        SimpleLogger
                .trace(
                        Severity.DEBUG,
                        loc,
                        "Search for flights with airlineId {0}, destFrom {1}, destTo {2}",
                        (Object) airlineId, (Object) destFrom, (Object) destTo);
        try {
            flights = jraManager.searchFlights(airlineId, destFrom, destTo);
            SimpleLogger.trace(Severity.DEBUG, loc, "Found {0} flights ",
                    (Object) flights.size());
            if (flights.size() == 0) {
                FacesContext.getCurrentInstance().addMessage(
                        null,
                        Utils.makeFacesMessage(FacesMessage.SEVERITY_INFO,
                                "info", "no_flights_found"));
            }
        } catch (BapiException e) {
            flights = null;
            Utils.processBapiErrors(e, loc);
        }

    }

}

The reference to the EJB has to be wired manually since we have chosen to let the JSF manage the scope of our beans, and so we cannot use @Autowired mechanism of Spring DI. You might be asking why didn't I just annotated the EJB reference with @EJB annotation, following the standard pattern. The problem is that when we deploy the EAR we will see the following error (which can be ignored).

Text:
May 2, 2012 3:20:32 PM com.sun.faces.spi.InjectionProviderFactory getProviderFromEntry
SEVERE: JSF1051: Service entry 'com.sap.faces.injection.InjectionProvider' does not extend DiscoverableInjectionProvider.  Entry will be ignored.

This error is expected since, the com.sap.faces.injection.InjectionProvider registered with Mojarra JSF 2.0 implementation does work with the default mechanism for EJB injection provided by the AS out of the box and configured for JSF 1.2. But to retrieve a been from the Spring's web application context is rather simple in the context of the JSF managed bean, we can use org.springframework.web.context.support.WebApplicationContextUtils for this purpose.

Utils.java

public class Utils {

    /**
     * Retrieves a bean with id given by <code>beanName</code> from current {@linkplain WebApplicationContext}.
     * @param <T> any type
     * @param beanName id of the bean
     * @param beanClass type of the bean
     * @return typed bean from the application context
     * @throws IllegalStateException if application context could not be retrieved
     * @throws BeansException if the bean with the given id could not be found
     * @throws ClassCastException if the retrieved bean cannot be cast to the provided type
     */
    public static <T> T getBean(String beanName, Class<T> beanClass) {
        WebApplicationContext appContext = WebApplicationContextUtils
                .getWebApplicationContext((ServletContext) FacesContext
                        .getCurrentInstance().getExternalContext().getContext());

        if (appContext == null) {
            throw new IllegalStateException(
                    "Cannot retrieve Spring web application context");
        }

        return beanClass.cast(appContext.getBean(beanName));
    }
}

Adding Primefaces UI component library

The real added value of all the work done above, comes with the ability to use third-party UI component libraries for JSF 2.0 framework. There is multitude of them, most of them are free or open-source and they allow for high quality, professional UI creation based on some leading edge client side scripting technology available. This not to mention the obvious advantages of using JSF 2.0 with it's improvements to navigation, AJAX support, and Facelets.

To add Primefaces UI components library, you normally just need to add it to the set of Web App Libraries of the Web Project located in WEB-INF/lib directory. I've tried with primefaces-3.2.jar but got a following error during deployment.

Text:
[JLinEE reported following erros for unil.ch/tmp~sflight~ear application.
ERRORS:
 * JSF Application Test: cvc-complex-type.2.4.a: Invalid content was found starting with element 'source-class'. One of '{"http://java.sun.com/xml/ns/javaee":system-event-listener-class}' is expected., file: tmp~sflight~web.war#META-INF/faces-config.xml, column 27, line 17

Apparently, the AS cannot validate the faces-config.xml packaged with the Primefaces JAR. But this is relatively easy to correct. You need to extract the contents of the primefaces-3.2.jar archive and edit the META-INF/faces-config.xml file. It need to be valid with respect to the declared javaee schema. This is just a matter of rearranging the order of some elements, for example, a system-event-listener element on the line 16 is

<system-event-listener>
    <source-class>javax.faces.application.Application</source-class>
    <system-event-class>javax.faces.event.PostConstructApplicationEvent</system-event-class>
    <system-event-listener-class>org.primefaces.webapp.PostConstructApplicationEventListener</system-event-listener-class>
</system-event-listener>

but should instead be

<system-event-listener>
    <system-event-listener-class>org.primefaces.webapp.PostConstructApplicationEventListener</system-event-listener-class>
    <system-event-class>javax.faces.event.PostConstructApplicationEvent</system-event-class>
    <source-class>javax.faces.application.Application</source-class>
</system-event-listener>

Once the validation errors are corrected, you can repackage the contents of the Primefaces JAR, which is now ready to be included as part of Web App Libraries of the project. To test if Primefaces are working you can use a simple index.xhtml page. If everything works well, you will be able to see the spinner UI component.

index.html

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:p="http://primefaces.org/ui">

    <h:head>
    </h:head>

    <h:body>
        <p:spinner />
    </h:body>

</html>

One more thing is needed for Primefaces to work on the AS. As Ingo mentions at the end of this forum post, we need to set the CompressedOthers property of HTTPProvider to false. Otherwise Primefaces will hung (until the connection timeout) trying to access some resources. For this login to /nwa interface with administrator, go to Configuration --> Infrastructure --> Java System Properties. Select Services tab and search for HTTP Provider. Set the CompressedOthers property to false (if needed). You might need to restart the AS for the changes to take effect.

Deploying the application

Before you deploy and run the application, you need to reference Mojarra JSF 2.0 library we deployed on the AS in the EAR's application-j2ee-engine.xml file.

<application-j2ee-engine>

    <!-- 
        This is the reference to the JSF 2.0 library,
        notice the prepend="true"
    -->

    <reference reference-type="hard" prepend="true">
        <reference-target provider-name="local.j2ee"
            target-type="library">javax~faces~2.1.7</reference-target>
    </reference>

    <!-- 
        This is only needed if you use com.sap.mw.jco.jra.ResultMap
        in tmp~sflight~java, see part 1
     -->

    <reference reference-type="hard">
        <reference-target target-type="application"
            provider-name="sap.com">tc~bl~jra~api</reference-target>
    </reference>

    <!-- 
        Cange to match your provider name
     -->

    <provider-name>unil.ch</provider-name>

</application-j2ee-engine>

At this point, it is likely that NWDS will complain that the XML file is invalid. You can disregard the error, but if you want to remove it, you can add an inline DTD declaration with prepend attribute specified as legal attribute of reference element.

<!DOCTYPE application-j2ee-engine [
<!ELEMENT application-j2ee-engine (reference*, classpath?, provider-name?, modules-additional?, fail-over-enable?)>

<!ELEMENT reference (reference-target)>
<!ATTLIST reference reference-type (hard|weak) #REQUIRED>
<!ATTLIST reference prepend (true|false) #IMPLIED>
<!ELEMENT reference-target (#PCDATA)>
<!ATTLIST reference-target target-type (application|library|service|interface) #REQUIRED>
<!ATTLIST reference-target provider-name CDATA #IMPLIED>

<!ELEMENT classpath (#PCDATA)>

<!ELEMENT provider-name (#PCDATA)>

<!ELEMENT modules-additional (module+)>
<!ELEMENT module (entry-name, container-type+)>
<!ELEMENT entry-name (#PCDATA)>
<!ELEMENT container-type (#PCDATA)>

<!ELEMENT fail-over-enable EMPTY>
<!ATTLIST fail-over-enable mode (disable|on_request|on_attribute) #REQUIRED>
]>

Once you've deployed the application, you should check the loaders for the application using telnet interface.

The reference to the library:local.j2ee~javax~faces~2.1.7 should be listed in the list of Direct Parent Loaders, and it should figure above the EAR's library loader, since we specified the prepend="true" in the application-j2ee-engine.xml file for this reference.

Summary of part 2

You should now have a working JSF 2.0 web application with Primefaces. You can use JQuery Themeroller to create a custom theme for the UI components of Primefaces which goes well with SAP look-and-feel. I'll try to add some screenshots of the application running on the AS portal soon.

This year, SAP is again sponsoring and participating in the Open Source Business Conference (OSBC), which is scheduled for May 21-22 in San Francisco, California. The conference is centered around three major themes that SAP - no real suprise here - has already been focusing on for quite some time: mobile, big data and cloud computing. In the different conference tracks, it will be explored how open source software and open source development principles support key innovations in these areas.

For SAP it will be interesting to find ways on how to combine key SAP technology innovations with relevant open source technologies to eventually utilize innovation from the open source community and create more complete solutions for our customers. In this regard, we are preparing a demo how SAP HANA can interoperate with key open source technologies such as Hadoop and R. While Hadoop is gaining traction in the industry, one scenario to explore further is how to enable the growing number of data nodes that support the Hadoop Distrbuted File System to act as a data source in HANA. Having a common and reliable approach on how to implement this scenario might be of interest to customers in various industries. As for R, there is already quite some interest and experimentation on the In-Memory Business Data Management and SAP HANA space on how to make use of R (the language) and its statistical and data mining features. The interesting fact about R is that many end users (mostly statisticians) share and co-develop many packages that include algorithms for specific purposes. Allowing these packages and the statisticians' skill sets to be reused in an SAP context does make a lot of sense and will represent the second part of the demo. Please note that both integration scenarios are still in an experimentation phase, but we are looking for interest and feedback from SAP and non-SAP users.

Also, together with Steve George, General Manager, Canonical and Paolo Juvara, CEO, Openbravo, I will participate in a panel on Success Factors for Enterprise Open Source Adoption. We want to explore how end-user organizations are adopting open source - pretty much along the lines of what I recently presented in my webinar on the same topic.

So, if you are interested to come to OSBC as well, attend the various sessions and meet the SAP gang, please let me know at claus dot von dot riegen at sap dot com - I have a few free tickets still avaiable.