Background of this blog
The reason to write the blog is recently we found that in several CRM projects in China, the ABAP Webdynpro is wrongly chosen by local partners as custom development UI technology, which has caused several issues after project is on line and led to huge maintenance effort. Many partners choose ABAP Webdynpro because they are more familiar with it and they consider Webclient UI has performance issue compared with ABAP webdynpro.
in my previous blog Webclient UI vs ABAP webdynpro – performance loss in BOL / Genil Layer discussion I made some performance discussion regarding CRM Webclient UI and ABAP webdynpro and finally my conclusion is when talking about CRM custom development, we should always stick to Webclient UI technology and avoid the ABAP webdynpro if possible.
In this blog, I will try to collect issues if ABAP Webdynpro is unfortunately used in CRM application. Feel free to raise your parts, if they are not mentioned here
Issue list
Some of the issues described here do not immediately make the application stop working, but can lead to potential issues in the future, make the application unstable, or cause inconsistent user experience for end users. All of these inconsistency makes your application really unprofessional.
Back Button
in CRM UI, there is a Back button in top right part of window, and UI developers could implement page navigation and back ( so called breadcrumb ) by implementing respective methods defined in Component Workbench.
Of course this is not available for ABAP webdynpro components. After ABAP webdynpro component is integrated CRM UI, end user would see two Back buttons – the red one is CRM standard one, and the green one is developed by developers on their own.
The issues would be:
These two buttons will make end user confused.
Additional effort must be paid to implement the back button function by developers.
It is technically impossible to register an ABAP webdynpro UI component to CRM Breadcrumb framework, so when the red button above is clicked, end user will not return to the expected search view, but to home page instead. This makes sense, since CRM Breadcrumb framework does not recognize the ABAP webdynpro component at all.
Data loss handling
in CRM webclient UI, you can follow the wiki to implement data loss. The steps are quite simple, as most of tasks are done by UI framework.
When you make some changes on UI without save and plan to navigate to other UIs for example by clicking other work center in the left navigation bar, the data loss dialog will be popped up automatically.
It is difficult to implement data loss scenario in ABAP webdynpro(See SCN discussion here). Developer have to take care the logic how to detect the ABAP webdynpro UI element is changed, which has already been done by CRM UI framework. Developers have to write lengthy and dirty code to achieve it.
The toggle between display and edit mode
In Webclient UI framework, the edit button plus switching all editable UI elements to edit mode is quite simple:
The task to switch the element into edit mode is done by method set_all_editable.
However, in ABAP webdynpro you need to do all of these tasks by yourself: The read only properties of all editable UI elements must be bound to a new context attribute POST_LOCKED, and you also need to set the content of that attribute every time the object is locked or unlocked.
Session issue
For example, when we log on to CRM system via a business role:
use tcode SM04, we observed there is only one user session for the current UI:
When we go to the integrated ABAP webdynpro page:
Go to SM04 again, we can observe there is a new user session generated for ABAP webdynpro, which means the ABAP webdynpro UI resides in a different user session, whereas the left CRM UI page in the original user session.
The technical session isolation makes it difficult to exchange data between ABAP webdynpro UI and CRM webclient UI, as they are residing in two different user sessions.
if you need to pass data from CRM UI page to embedded ABAP webdynpro UI, One approach is to define the parameters in ABAP webdynpro applications, fill those parameter in CRM and populate the URL containing the passed parameter via cl_wd_utilities=>construct_wd_url:
However, this approach is not appropriate to pass large amount of data like internal tables. It is also difficult to pass data from ABAP webdynpro back to CRM UI. What’s more, careful coding is necessary to ensure a consistent transaction state.
Inconsistent configurability
By clicking the configuration icon, we can directly enter configuration mode to make adaptations on UI layout:
When an ABAP webdynpro is displayed, the configuration icon is still enabled.
However, since it makes completely no sense to configure an ABAP webdynpro component via Webclient UI framework, once the icon is clicked,
We only get one notification saying currently no UI part is configurable.
ABAP webdynpro UI component configuration has a different development mechanism than Webclient UI. The coexistence of both leads to an inconsistent configuration experience for the end user.
Location of message area
The message raised in ABAP webdynpro via message manager will appear by default on top of the application UI page,
Whereas in CRM Webclient UI, the message appears in the right top of the UI framework, and the message text could also be collapsed or expanded by the small triangle.
Put the mouse onto the message text, then the technical information of the message could be displayed as tool tip, which is not available for the message raised by ABAP Webdynpro.
Incorrect use of underlying layer API
Let’s review the benefit of using Webclient UI framework:
The object oriented BOL API is simple, generic, uniform and easy to use.
Your UI components are decoupled from any interface changes in the underlying application specific APIs, it is even not necessary for you to know the detail of underlying API at all; Your application is easier to maintain and sustainable for future development
Development of WEBCUIF applications is made easy, since the BOL has been designed to work hand in hand with the UI parts of the framework
The built-in buffer accelerates your applications: Once data it is read, the Object is buffered and could be retrieved in nearly no time. Way faster than calling various function modules again and afterwards preparing the data for business use.
so if you choose ABAP webdynpro, you will lose all of these benefits: Your UI component would bypass the BOL & Genil Layer and directly struggle with the underlying API.
When I am supporting customer on site customer has complained to me about the “poor quality” of FM CRM_ORDER_MAINTAIN. They directly call this FM in their ABAP webdynpro view controller and complain it does not work as expected. After investigation in their system with quite a time, finally I find it is caused by the inproper importing parameters passed in. Such issue could have been avoided if using BOL API in UI layer – you just need to fire the very simple and generic BOL API and all left things like interaction with the complex underlying API will be handled by Genil implementation. Such UI component will them be easier to maintain and more robust.
Conclusion
When you plan to fulfill the customer requirement by developing ABAP webdynpro and integrating them into CRM UI( via transaction launcher), please always think twice whether it is really necessary. If you decide to do this, you have to confront with all troubles described in this blog. Please kindly raise your findings, if it is not included in this blog
