Web Channel Experience Management – Advantage of using Java Server Faces
In SAP Web Channel Experience Management (WCEM) a decision was taken to use Java Server Faces (JSF) as UI technology. In this blog I’ll show the arguments behind this decision and try to provide a short comparison between the Java Server Pages (JSP) as used UI technology in Internet Sales and JSF.
After several years investment in JSP technology we saw that although JSP has made a great leap forward compared to Servlet-based rendering, more complex business processes (and based on that more complex UIs) lead to troublesome JSP structures. Even if the JSP tag technology allows Java code abstraction, sooner or later Java code will be integrated directly onto the JSP pages again. Any problem analysis there will turn into a nightmare because debugging of the JSPs directly or the generated Servlets is a complex and often poorly supported task. In JSF, especially when using the Facelet technology, there is no Java code on XHTML pages, which are parsed from JSF. This makes JSF generated HTML code more transparent and clear.
Taking closer look at the UI components in JSF we see that not only clear HTML rendering process has been established. Recurring tasks like Data Binding (save request data in in the corresponding object), conversion, validation are integrated into the JSF life cycle by well-defined interfaces which can be implemented uniquely dependent on the processed business logic. JSP gives not such strong answer for these questions so that individual code is needed or other frameworks will be integrated additionally.
Futuremore, with the introduced UI compositions in JSF the separation of UI structures is much better possible. By this it is possible to implement layouts which can be reused for many pages. Based on the standard JSF composition framework even dynamic exchange of page contents is feasible and leads to very flexible structures.
As we started to design the new framework for the SAP Web Channel Experience Management solution we were faced with the situation that the JSF 2 specification was already in an advanced stage, but unfortunately it wasn’t released and thus the implementation in Java community wasn’t finally available yet. Because of that we had to find a way to provide a satisfied solution for the WCEM 1.0 release but at the same time foresee a technical way how a switch to JSF 2 could be possible in one of the future WCEM releases.
Already in the WCEM 2.0 development time frame a stable JSF 2.1 implementation was available so that we could do such switch. With this step we focused on reuse of standard JSF 2.1 features so that we could replace lot of special implementations by standard JSF 2.1 functionality. For example we adopted the Composite Components, AJAX support and bookmark support.
Additionally, because JSF 2.1 provides much better extensibility concepts, we could close many gaps simply by using the available extension points so that the WCEM 2.0 implementation could be realized compatibly with the JSF standard. This allows for example usage of other 3rd party components in custom projects. Due to the modification free extensions, future adaptations of new JSF frameworks should be less complex as well.
As already mentioned, some features aren’t available in standard JSF 2.1 so that the following extensions were incorporated in the WCEM framework:
- Besides the standard UI Components SAP implemented additionally more complex UI elements like Breadcrumbs, Data Grids, Calendar Control, etc.
- For the HTML and JS code rendering the Velocity Template Engine is used. This generates code from plain text template files and by this allows to change the generated HTML without code in Java. So you do not need a Java development environment. The compile and deploy cycle becomes obsolete.
- Extendible and customizable UI Themes support ease and flexible CSS implementations.
- Based on JSF standard Composite Components so called View Components were introduced which enrich Composite Components with a View Component Handler. The View Component Handler acts like a backing bean for the view by hosting controller logic and providing separation from the Business Object logic. Additionally this concept allows better reuse of views like generic UI
fragments on different pages.
Of course several other features are available in the WCEM framework but to mention them all in this blog would go beyond the scope of this blog. For more details I recommend to read the WCEM Development and Extension Guide available on http://help.sap.com/wec
I'm not sure I understand why SAP feel the need to introduce yet another UI technology into their offerings. 😯 This can only server to increase the TCO for customers trying to acquire the skill sets required to maintain and support their SAP systems.
Do SAP plan to consolidate web UI technologies around a smaller subset - such as SAP UI5 - or will the use of JSF become another orphan like the CRM WebUI?
Hi Graham,
thanks for the feedback.
The WCEM platform and their UI technology cannot be seen on the same level as CRM Web UI or Web Dynpro and it won't be positioned in this direction. WCEMs JSF UI is especially built for external facing scenarios so that a typical usecase for this technology is a B2C shop where highest UI flexibility is required. Some of the main points are: CSS themes (down to the level on "single pixels"), SEO, bookmarking, browser back, etc.
Because of such different focus we have to go in a direction of different technology. To keep the efforts and TCO on the customer side small, we base on standard technology (JSF2, MyFaces, Velocity, jQuery, etc.) to ensure faster knowledge rampup.
Best regards,
Adam
Hi Adam,
perhaps I didn't explain myself very well. I was not comparing JSF to CRM Web UI or Web Dynpro but rather with the SAPUI5 initiative which seems to me to have the same attributes and the flexibility you describe for JSF as its goal.
Cheers
Graham Robbo
Hi Graham,
as you probably know, SAPUI5 is a JS-based client-side library. Even if such JS solution brings lot of benefits (rapid development, highly dynamic and interactive UI, ...) on the other hand side you'll recognize some limits especially for B2C business. One example is the SEO support.
Additionally we shouldn't mix these technologies because WCEM framework is providing a JEE server focused platform with much wider scope. Besides the pure UI rendering layer you have configuration-based multi backend support, admin tools, search framework, user management, and so on.
Best regards,
Adam
Hi Adam,
sounds reasonable. Does the WCEM UI support mobile devices such as tablets and smartphones?
Cheers
Graham Robbo
Hi Graham,
This question is asked very often. Please I wrote a comprehensive answer in the FAQ blog (see section "Multichannel"):
http://scn.sap.com/community/crm/web-channel/blog/2012/05/10/sap-web-channel-experience-management--faq
Best regards,
Ingo
Thanks Ingo
We're implementing the new WCEM, replacing webChannel and our legacy JSP solution. Due to many many changes, the UI and parts of the business logic will completely be rethought and reimplemented.
At first I had a good impression. But now I am trying to implement a functional prototype, and have some really serious concerns about using it.
First of all, it creates the worst, most cluttered invalid pseudo-HTML/CSS/JS mix I've ever seen. It violates every single rule I learned in web-development. Furthermore it throws together, what never should be so tightly coupled: Layout, Design, Logic and Communication with the server. I don't see how I should be able to use this output in any way, whether styling using CSS, some UI candy like configurable hot-keys, drag-and-drop widgets or whatever.
Secondly, it is way to complicated. Its complexity is outstanding. If you ask me, it's a poor abstraction of basic web technologies, crippled and useless in the end. What benefits do I have? None, if you think about. Hundreds of components? I see ten-thousands of HTML/CSS snippets, ten-thousands of JavaScript snippets and thousands of jQuery plug-ins in addition. It solves really many problems - we wouldn't have if you wouldn't use JSF.
I'm really disappointed and your explanation of the technology switch does not hold water.
Hello Shirley,
thanks for the feedback. I understand your frustration which we see especially in situations where expert developers are deeply familiar in the former JSP solution and now switch to the new JSF-based solution. It seems that you're in a similar situation.
The major point is, that we have huge technology difference between JSP and JSF at all. This is based on the fact that JSF is a component-based framework which is realizing the processing of web application in a very different way. At this point I would encourage you to get deeper knowledge in the area of JSF2 (nothing specific to SAP). Because WCEM is strictly relying on JSF standard and their extension points, I'm sure that you will get better understanding how WCEM is proceeding any kind of data. Additionally I want to emphasize that WCEM is mainly integrating common open source solutions for providing the required features, so for example JQuery for JavaScript or Velocity for template-based rendering of XHTML, and so on. Even that are again new technologies compared to the former JSP world, you should be able to find lot of information of these technologies in the web.
Additionally, we all know, nobody is perfect. That means, in case you have any open points or suggestions, feel free to discuss it in this community, mainly in the forum. On the one hand side you can get here support on a short time frame and additionally your feedback will be for sure addressed to the responsible development teams at SAP as well.
Best Regards,
Adam