1 2 3 40 Previous Next

SAP Enterprise Portal

597 Posts


We have all on different occasions encountering notification popups when utilizing the Enterprise Portal. These can vary from notification popups such as logoff prompts and Work Protect Modes or may highlight something more sinister i.e. error exceptions. If you encounter a Popup which you are not familiar with underlying the root source and meaning behind it before hitting the panic button is essential. On some occasions new system changes such as SP implementations or upgrades may cause different visual popups to come to the forefront and here we will address one of these.

Session Management will not work! Please check the DSM log file for details.


From an end users perspective utilizing the enterprise Portal is a straightforward process. We simply logon, fulfill our work obligations and logoff. As an end user we are only concerned with the graphical representation of the Portal that we are delivered with through our monitors representation and we are not truly troubled by what underlying functionality is taking place.



As we know the Enterprise Portal (EP) from a high level perspective can become quite a complex session environment for users over a time-period due to increased utilization of resources such as applications, data management provisions and documents. With each-user session enacted on the Portal comes a set of different connection requests which are handled by the Portal's session management mechanisms.

Why would such a popup occur?

This popup can arise as a direct result of different changes which may have subsequent effects on the domain. If a recent system copy, migration or upgrade has taken place this would in theory become the primary point of interest in the investigation. For the case of a working example let us imagine that you have completed a system copy which went through success however afterwards on each occasion that a User logs on to the Portal they encounter the full popup "Session Management will not work! Please check the DSM log file for details".


What do I need to check?

If a system copy has taken place you need to determine whether or not the Portal domain has changed as a result of this. Session Management itself does not work for different domains. For example if AI iViews are involved here we need to determine their source and where the message is coming from.  When session expires or logoff is invoked or browser is closed, no matter what, the connection is not terminated but returned to the pool and kept open a as defined in the Connection Lifetime property. In short, the connection stays open for the predefined amount of time by design and this is not an unexpected behavior. It remains in the pool, it is no longer used by another service e.g. the UWL and it is available for other clients.

The J2EE Engine uses hierarchical security policy domains and requesting an application or source (residing in a different domain or sub-domain) will require the user to re-authenticate.


  • This would obviously create a new "security session" if we take the working example above.


From the perspective of the DSM Terminator which is the reference you are seeing. This is a  special script called the Distributed Session Manager that is responsible for handling the session management on the page.



As we know the UWL in itself plays host to a wide range of different parameter settings and properties. These vary from underlying XML properties to fully functional-based performance parameters which dictate how the UWL operates and performs. In this blog posting we are going to cover the "Optimized Delta Retrieval for Single User" as a property option which is not to be confused with the "Delta Pull".

Optimized Delta Retrieval for Single User....

From a high level perspective the Universal Worklist follows the concept of two primary pull operations in terms of it's functional makeup. Firstly tasks and workitems are pulled from the backend systems (through configured connectors) into the UWL Cache. These workitems are then pulled a second time from the Cache into the UWL's interface i.e. the Inbox where they are subsequently presented to users. The "Optimized Delta Retrieval for Single User" is focused on a particular set of workitems. This option has been established for singular users (those who have been designated) and is used to pull workitems that have been created (new), changed (edited) or deleted into the Users inbox.

Important Points on the Optimized Delta Retrieval for Single Useruwl1.JPG

Important Points on the Optimized Delta Retrieval for Single User

It’s important to mention that by default UWL does not use the Optimized Delta Data Retrieval for Single User for any connector .


  • This means that by default the option is deselected (as a checkbox)


This new feature is only supported for standard connectors which support the Delta Pull functionality:

  • The standard connectors in this case include the WebFlowConnector,  BPMUWLConnector, AlertConnector and GuidedProceduresConnectors
  • This feature is not supported for custom connectors.


Where is the option Located ?

Within the UWL Administration screen:

  • System Administration -> System Configuration -> Universal Worklist & Workflow -> Universal Worklist - Administration.


I cannot see the Option displayed ?

If you encounter this type of behaviour the first recommendation would be to check if the option appears visible after navigating through the UWL's standard PCD Path location:

Log on to the portal with an id that has tasks in the UWL and can access the PCD. Go to Content Administration ---> Portal content


  1. Content provided by SAP
  2. End user content
  3. Standard Portal users
  4. Iviews
  5. com.sap.netweaver.bc.uwl.iviews
  6. Open the folder
  7. Right click on the Universal Worklist
  8. and display a preview.


If the option continues not to be displayed the recommendation would be to perform a full UWL Restart (this does not entail restarting the entire Portal).


  • SAP KBA: 1894284 - How to restart the UWL Portal application.

If a restart fails to resolve the issue you can proceed to perform a UWL Component Redeployment


  • You can Redeploy the UWLJWF component in accordance to SAP KBA: 1921719: How to deploy same version of software/development component into java system via telnet command for 7.1x onwards java system.



As frequent Portal Users we are all aware of the important of session management and the pivotal role it plays towards adherence to security standards and best practices. Undoubtedly we may have all come across problematic scenarios with Session Management in association to the Enterprise Portal and these "problematic" scenarios can be mind boggling and pose serious threats to business processes and operations. In this blog posting we are going to troubleshoot and explore the DSM itself and some issues with different Web Browser Platforms.

What is the DSM?

DSM is short for Distributed Session Manager and is a key player in the whole process of using the Enterprise Portal.  In true essence we can consider the DSM to be a "Special Script" which is solely responsible for handling session management on an individual Portal Page.

DSM Mechanics

So let's say we have a user using the Enterprise Portal on a daily basis. When this user closes the browser window or navigates to another position, the browser sends a mass request to a dedicated portal component to end one or more open sessions (by default DSM.Terminator).

  • This component distributes the corresponding termination commands to the component systems. The Termination command then closes the server session.


To close the sessions, a small additional window is generated in the browser outside the visible screen area. This window is automatically closed after two seconds if the Transmission command has been processed. Since ITS-based services cannot be used directly in session management, the Automatic Server Session Termination works with a wrapper technique. A main page consists of:

  • An iFrame that displays the content coming from the ITS
  • A special script called the Distributed Session Manager (DSM) that is responsible for handling the session management on the page

DSM is simply...

  • Responsible for releasing both back-end sessions and Web Dynpro sessions.
  • If you run a HTTP Watch Trace you can validate the DSM in operation through noting the "DSMTerminator" calls within the trace.

Disabling DSM Popup's


So now we have established that DSM is responsible for session management handling on the page and on some occasions there might be a requirement to make the DSM run silently i.e. hide the popup which signifies its presence. On some occasions performance of the Portal Landscape plays a major role in how long the Popup may remain open and visible. There is an informative blog posting on this topic outlined below for your d cross-referencing:


Just remember that the DSM is not only for releasing backend-sessions but also webdynpro-sessions on the portal host.  The steps on how to disable the popup along with a comprehensive overview on the DSM ARE covered, described and outlined in the following documentation:


  • SAP KBA: 1805818 - How to permanently disable the Session Management alert popup in EP
  • SAP Note: 868477 - Disabling Session Management Alerts
  • SAP Note: 1830713 - Disabling Session Management Alerts in 7.3


As per the documentation outlined above for 7.3 there has been follow on issues with not being able to suppress the popup. In the symptom highlights we see that after disabling the DSM and restarting the Portal or logging out/and subsequently in again the DSM appears once more. In case of a Portal restart the default setting saved in the service configuration:


  • /applications/com.sap.portal.appintegrator/services/Common_Configuration for the entry "AlertSessionManagementMismatch" is used.

The path to set the parameter in SAP Netweaver 7.30 portal is as follows (and should be in the same in your instance):

    • /nwa > Configuration > Infrastructure > Application ModulesIn "Module List" search for "com.sap.portal.appintegrator" and highlight it. Scroll down to "Web Module Details" and select "Common_Configuration"Scroll down to "Portal Service Details" and set the property called "AlertSessionManagementMismatch" to false.


If web servers and the client applications of the portal run on different domains, this affects important functions of the Client Framework, for example Client Eventing, Client Data Bag, Cross Navigation, Work Protect Mode or Session Management.


A system landscape that covers different domains in addition causes problems regarding the security. This restriction comes from client side(browser) due to the javascript same origin policy, it is not from portal side.



DSM Popup will not close

With Internet Explorer 7+ versions there are documented issues with the DSM Popup remaining open and this can be resolved via the application of:

  • SAP Note: 1401567 - DSM popup window pointing empty.gif does not close on IE7 and above


Previously I have written a mini blog series focused solely on themes, theme creation tools, theme issues and subsequently troubleshooting those type of issues. In this blog posting we are going to discuss a particular "masked" theme issue associated primarily to the CSS files holstered within the theme itself.


High Level Analysis

So as we discussed in the first theme based troubleshooting blog postinghttp://scn.sap.com/people/troy.cronin2/blog/2016/02/06/ep-themes-issues--breaking-the-issue-down-high-level-analysis there are several ways to help simplify a theme based issue.


3 Principles To Follow - If you encounter an issue

  1. Determine firstly if the issue happens in all web browser platforms (Internet Explorer, Google Chrome, Mozilla).
  2. Determine if the issue occurs in both SAP Standard Themes & Custom Themes.
  3. Determine if the issue can be reproduced in all Portal Framework & Theme Combinations.


If you've followed the three principles above you already have a better understanding of your issue and can delve quickly into further analysis to get a solution.

Theme CSS returns a page not found

This issue has been reported on a few occasions in my experiences and in truth its occurrence can be random and intermittent thus making it a little mind boggling.

This issue can occur directly through Portal navigation across role selection or element navigation. These occurrences can effect the end users interaction with Web Dynpro Java and lead to further rendering issues.

Such an occurrence usually relates to a server node issue and SAP KBA: 2195099 - Portal theme is inconsistent after upgrade is a vital important of reference here.

With theming as we know there are multiple file folders at play and on some occasions small discrepancies in association to the servers will occur.


In the KBA outlined above which is the core means of resolution guidance there are two documented solutions.


If you follow the server approach this should "cleanse" any small discrepancies that could be causing the issue to arise initially.


However please bear in mind (complimenting solution 2) that from our side SAP always recommends ensuring that ALL the latest SP fixes are implemented as these are focused on preventing such issues from occurring.


  • https://support.sap.com/swdc
  • Important: make use of the dependency tool provided to ensure there are no system discrepancies if you implement a Patch/SP.


In my experience working with Knowledge Management (KM) scenarios in association to the Enterprise Portal I have handled many different queries regarding TinyMCE as a text editor, it's utilization and subsequent support as a content creator and editor.


Is TinyMCE Supported?

Perhaps the most common query surrounding TinyMCE as a Text Editor is whether or not this can be integrated within the SAP Enterprise Portal. In true essence TINY_MCE is provided by a third party and its utilization is not supported by SAP therefore we do not hold a position in terms of advisory consultation on the text-editor itself.


I've Integrated TinyMCE & have some issues?

Any issues, which occurs in conjunction with the use of TinyMCE in WPC, would not be supportable by SAP as a result. Support regarding TinyMCE would be considered as remote consulting and can not be handled by the standard support service under the SAP maintenance agreement.


Although the possibility is available to use TinyMCE editor in place of HTML Editor in WPC, TinyMCE is not provided by SAP and therefore it cannot be supported by SAP. The maintenance agreement only covers software or system errors in the delivered standard Enterprise Portal product.

Guidance Documentation


There is an official guidance document which can be utilized as a great reference point here:

  • SAP KBA:  2274004 - Integrating TinyMCE HTML Editor for Web Page Composer (WPC) within the SAP Portal


Let me also highlight SAP Note 2274004 "When using the new WPC editors" as a very important point of reference here.


As we see the newly "revamped" editors are available from NW Versions 7.40 onward and require no additional TinyMCE integration steps to achieve the desired functionality. However  the new editors in this instance wont offer the same dynamic extra functionality as a scenario in which the TinyMCE Editor was integrated inside the new WPC editors has limited functionality and does not provide more functions then the standard HTMLB Editor within the standard WPC editors.


If you want to carry out further testing you should: Go to System Administration > System Configuration > Knowledge Management > Content Management > Web Page Composer > Editor >Editor Configuration and mark the checkbox "New Web Form Editor".


- Keep in mind that the new WPC editors cannot be customized, for instance the integrated editor cannot be replaced by another editor. Also as the new editors depend on the SAPUI5 and it must be available too.


For more information about the new editors you could check this document:


When using the SAP Enterprise Portal (EP) within an NW Environment in a large organizational landscape business requirements may require different linguistic and language settings for multiple user bases.

As Fiori is relatively new & "fresh" in terms of large scale utilization it is beneficial to cover the basics before delving into anything too complex .


Portal - How Language Settings are maintained


Now regarding this scenario and the languages used in the Enterprise Portal there are a few important points to highlight. The language that the portal is displayed in depends on the following hierarchy, with the languages at the top of the list taking precedence over those at the bottom.


  1. Component (iview) language (defined in the portalapp.xml)
  2. Portal Mandatory language (defined in the prtDefault.properties)
  3. User language (defined in the user#s profile).
  4. Request language (defined by the browser).
  5. Portal Default language (defined in the prtDefault.properties)
  6. System Default language (default locale defined by the OS).


So for example, if you have your portal user language (as in point 3) set to German, but the language of the iView that is the logon page (as in point 1) set to English, that logon page will be displayed in English.


Fiori Launchpad on Portal - How Language Settings are maintained

The SAP Fiori Launchpad adds a fresh dimension to iView display as such a presentation is returned to the END-User in the form of Fiori Tiles as opposed to the familiar Portal iView standard. In solely Portal based scenarios organizations may choose to provide users with a degree of flexibility when it comes to changing Portal language setups e.g. through "Personalization" however with the SAP Fiori Launchpad on Portal it is not that simple.


Example Scenario - Fiori Launchpad on Portal - How Language Settings are maintained

Lets take a working example and imagine you are utilizing the SAP Fiori Launchpad on Portal in a large landscape environment. Such a setup means that your "Group" is composed of company's based in different geographic locations all of which hold their own native preferred language. Understandably you would like to offer these end-user bases the option to change the language of the Fiori Launchpad on Portal based on which country they reside. Ideally you want such a language setup to apply directly across the landscape itself .e.g on the Launchpad, WINGUI, GUI for HTML, Web Dynpro ABAP and JAVA etc.

If you had experience with the Classic Framework Page or Ajax Framework page you will be fully aware that achieving such a setup was indeed possible through "Personalization" however you've yet to see this function added in the Fiori Framework Page.

In the SAP Fiori Launchpad on Portal if you navigate to "User Preferences" you do not see an option listed which presents end-users with the chance to change their desired language.

Why can we see the Language Change option?


Firstly regarding the Fiori Launchpad itself the FLP does not support change of locales by user options through the “User Options Menu -> User. No singular user can do this or perform this action simply because this functionality as it is not supported by FLP.


  • A Portal administrator can configure the local of the users through UME and it will take effect in FFP.


There are scenarios in which "Personalization" through extended API's and Custom Code have been configured to support such a Language setup however from a supported SAP Standard point of view only administrators can change language for users or end users with the content admin role assigned.


Currently, there is no way to change the language for users via the FLP.

You can at present use one of two ways to change languages as a workaround resolution:


  1. Via the user management.
  2. Set the browser language for the desired language


There has been discussions to add this functionality as Standard in newer Fiori releases and this is presently under consideration as a feature request.


As we know the Universal Worklists boast's a wide range of different customization elements which can be tweaked and tailored to suit your own business preference and requirements. The backdrop to which theses "customized elements" are formed is built upon custom XML Files which are uploaded through the UWL Administration Page. Recently I've been working on different scenarios in which customers were losing these configuration files as a result of an upgrade or fallback testing and in this blog I want to address how XML's themselves are managed and how we can implement a workaround to such an occurrence.


XML's & The UWL - 2 Key Principles

  • XML files in association to the UWL follow the notion of precedence. If you have a custom XML file which is based upon a SAP Standard XML this file needs to be re-uploaded into the UWL with a Priority setting of "High" in order for changes to take effect. In addition to this the UWL Cache should also be cleared and then subsequently the desired changes will come into the Interface.
  • Always ensure that you backup original SAP Standard XML files if you need to make custom changes or create custom XML's using Standard files as the foundation. The reason for this is simple in that you can revert changes if required.

How do I clear the UWL Cache?


  • Steps to clear the UWL cache, please go to "System Administration" "System Configuration" -> Universal Work list & Workflow -> Universal Workflow Administration -> Click on cache administration page -> Click "Clear Cache" button.


Losing Custom XML's post upgrade?

Upgrades are part & parcel of operational enhancements and fixes when it comes to the Enterprise Portal as we know. With the UWL as the reference point here it is not uncommon to notice functional changes in appearance across different versions. Let us imagine that you have performed an upgrade / SP Deployment or fallback testing e.g. AIX Cluster Resources. After doing so you noticed that all UWL Customizations (made through XML's) were reset to standard.

Why Did the Custom XML's revert to Standard?

After an upgrade standard UWL XML Files as delivered as part of the UWLJWF Component itself therefore custom XML's will not be inherited automatically. One important factor to note is that all xml files that come pre-configured with the Universal Worklist as standard include the following:

  • uwl.webflow
  • uwl.bpem
  • uwl.standard
  • uwl.collaboration


The files listed above are installed when the UWLJWF package is implemented. These configuration files will be at priority LOW on the system.

If you've experienced the behavior noted above i.e. custom XML files have been overwritten by standard files post system change the workaround resolution is to proceed to re-upload the file and follow the two principles I outlined at the beginning of the blog posting.



Preventing Custom XML's from being overwritten ?


In terms of a means of retaining custom XML files between upgrades there is no standardized method of doing so apart from the workaround i.e. backing up the file before re-uploading.


As per standard UWL functionality during an upgrade or connector registration there is a change. At the time of the connector re-registration, the UWL issues an update in the database to delete the XML files which start by e.g.  uwl.webflow.<system_alias>.


This is made like this because the re-registration must regenerate the Low priority version XML file whose name is exactly uwl.webflow. <system_alias>.


As in the given example, as the custom XML file was uploaded with name uwl.webflow.SLRCLNT200_custom, it got deleted at the time of the re-registration.


In theory in order for custom XML files not to be deleted at the time of a connector re-registration, do not use as a prefix for your XML file the string uwl.webflow. <system_alias>.


Remember overwritten Custom XML's might be an inconvenience but in true essence this is not an issue. Once a backup has been kept and maintained it is simply a case of re-uploading the file to attain the desired functionality.


In the modern world of computing and IT Security is perhaps one of the important aspects of assured business practices and conformance to business practices. Without necessary security measures and protection mechanisms as we know the consequences can be consequential in all walks of life and the Enterprise Portal is no different. In my experience with the Enterprise Portal I've dealt with many different scenarios in which customers have been performed security scans and updates in a bid to identify vulnerabilities and make correction measures were necessary. Such processes are encouraged as they help ensure Portal Environments are fined tuned when it comes to protection against harmful and malicious threats from diverse sources.


What is Clickjacking

Clickjacking is something I've seen noted by customers on multiple occasions as a result of running vulnerability scans. In true essence click-jacking is essentially a clever means of tricking users into performing hidden actions through disguised links and context elements.



Clickjacking - Protection Step 1

If you have conversed with SAP you will be aware of the important of the latest Patch Level Release & Support Package implementation. Applying the latest Patch Levels & SP's provide resolutions into easily avoidable issues and offer preventive measures against potential issues. In terms of "potential issues" this can indeed include security breaches and threats therefore the recommendation is always to ensure the latest SP's & Patches have been applied.


Clickjacking - Protection Step 2

Now if you run security & authorization checks from a Portal perspective you may come across possible concerns across a wide range of Portal Component areas and in many cases these have to be checked independently. In this case we are going to try and lay the foundation (following Step 1) to ensure we have a solid Clickjacking protection setup in place. Here we are essentially implementing preventive measure guidelines to ensure your Portal setup and environment has the correct security settings.

A core aspect to click-jacking protection is the surrounding platform in which the Portal operates which is the Browser.


From the Portal's perspective in terms of intended utilization it is of vital importance that the Web Browser Platform being used is supported from SAP's perspective. In order to support optimal browser performance you will need to ensure that the current Product Version being utilized (IE, Chrome, Firefox, Safari) supports your NW Version and vice versa. In relation to optimal browser performance here I am making reference to two difference aspects:


  • Rendering: how the presentation is presented to the end user in terms of EP components & elements
  • Security & Navigation: functionality setup and essentially "click-ability" and "select-ability"


The primary means of checking whether or not your present Web Browser Platform version is supported is through the SAP PAM or Product Availability Matrix. On the PAM we are given insight into which different Product Versions support Web Browser Versions and vice-versa. The PAM will also provide an informative outlined into the limitations (if any) which may exist which a potentially unsupported setup.


Although we can refer to the risk of using an supported Browser Platform as a lack of common sense in many cases we inadvertently open ourselves up to potential threats. For example if you are using standardized company software and are participating in a project perhaps you want to make use of a free software to offer an extra degree of detail to your project. This could be anything from grammatical process setups or perhaps a graphical generation software.


If you have experiencing with downloading any software program you would have encountered the launch program and .exe files on many occasions. Here we often navigate quickly through the launch tool as we only want to make use of the final product. In doing so we might accidentally install a host of third party tools such as browser plugins, and toolbar setups. In true essence you are never quit sure as to what you are downloading if not from a trusted source. Upon downloading any third party software even for temporary use inadvertently you could be installing spyware and phishing mechanism to which you are "none the wiser".


The recommendation is to install only what is supported and seek consultation from Admins regarding any potential queries you may have regarding the intended utilization of programs or tools which may not be available as standard in an organizational setup.



Combining Protection Step 1 & Protection Step 2


I would strongly recommend reviewing the following guidance documentation to add an extra degree of comprehensive insight as this will help set a solid protection measure foundation against clickjacking.


Protection Step 3 - Applications & Elements

The first point of reference here comes in the shape of SAP Note: 1781171 - ClickJacking vulnerability in WebDynpro Java. In theory it is of adequate practice to set the property "ClickJacking" to "true" and "X-FRAME-OPTIONS" to be set as "SAMEORIGIN". This will make sure that the functionality is constant on all of the WDJ server responses and calls.

  • SAP Note: 2319727 - Clickjacking protection framework in SAP Netweaver AS ABAP and AS Java


However, do note that this X-FRAME-OPTIONS is not compatible with all browsers. Refer for more details.:



Protection Step 4 - Iframes & Forbidden Framing References

Many of us as Portal end-users have come across and encountered the infamous message "This content cannot be displayed in a frame. To help protect the security of information you enter into this website, the publisher of this content does not allow it to be displayed in a frame. What you can try: Open this content in a new window which can arise for a whole range of different issues. Sticking to the topic of clickjacking here on the Web Dynpro front in many cases the root source is actually that of the Web Browser Platform and cannot be avoided by us.


Both documentation links outlined above share additional details about the Allow-From attribute. Such issues meant the creation of the X-Frame-Options to avoid click jacking vulnerabilities in WD setups which again is complemented by SAP Note: 1781171 - ClickJacking vulnerability in WebDynpro Java.

By definition the Portal allows itself to be framed into another third-domain page. This ability is required in order to support the Interoperability mode. (Integrating SAP Portal Content into Other Portal Servers.


For more informaton on this: http://help.sap.com/saphelp_nw73/helpdata/en/24/68b6dff7be4d6a98d0d49eba920096/content.htm )


This is the reason we can't control the X-Frame-Options header variable (which disables/limits framing options). In order to avoid clickjacking it is possible for you to use reverse proxy in order to prevent SAP NW Portal framework page being framed. You can configure the reverse proxy to use a parameter 'X-FRAME-OPTIONS' to disallow framing. To prevent clickjacking, a Website Owner (Google) can send a HTTP response header X-Frame Option "Deny". Then the browser prevents the page from rendering in a frame and you get the error message "This content cannot be displayed in a frame". Again to highlight it is a browser limitation.


One example of such reverse proxy can be apache reverse proxy. See more details on X-FRAME-OPTIONS here:




Reference Point - Fiori & Clickjacking.


The primary driver behind the utilization of the Fiori Launchpad on Portal is to provide end-users with the practical experience that Fiori itself offers. The utilization of the Fiori Launchpad on Portal shares the same approach delivered within the normal Enterprise Portal environment although the way such an experience is display is different!




If you are familiar with the Universal Worklist from an end-users perspective you will know that the UWL itself serves as a centralized task management platform for a wide array of processes.The purpose of such task types or work-items varies surrounding business operations and can include sales orders, travel requests, leave requests or tracking setups. The management of such tasks is of vital importance as you can imagine due to the association they share to an organizations business operations and general practices.


Sample Scenario: You need to remove task types?


Lets imagine you have a workitem approval scenario for managers which revolves around different managers approving and rejecting overtime requests for employees. Now the way in which this process is configured means that when a "request" is either "approved" or "rejected" the employee will receive a confirmation.


So let us imagine


  • User A (Employee) sends a request (overtime) for approval to their manager.
  • User B (Manager) receives the request and approves it (meaning notification and confirmation is sent to the employee).
  • However the workitem (despite being approved) remains in the end-users (employees) UWL Inbox and therefore appears active (when it should be completed).


For the reason the employee follows the obvious approach and attempts to find a means of removing the workitem since in fact it has been completed. If we add a degree of further complexity to this sample scenario we can imagine the same behavior happening for "Rejected" requests which undoubtedly means task duplication will occur and the employees & managers Inbox will be overflowing with "dormant" tasks. The status of the these overtime requests may remain as "released for approval" and if these are not approved on time financial impacts may occur.


Lets Remember: How the UWL works.

The UWL follows two primary pull operations as its baseline means of functionality. When an end-users firstly opens the UWL tasks are pulled from the backend systems (across connectors) into the UWL Cache. A second pull operation then takes place and the workitems/tasks are pulled from the cache into the UWL Interface. If you intend on removing any tasks from the setup you need to firstly remember the key question here of whether you want to remove workitems from the UWL or the actual workflow?


UWL - Task Management - Can We Really Delete Tasks?


So after some discussion you confirm that you need to remove some invalid tasks from the UWL Worklist for the manager specifically related to overtime. Firstly you may have heard that should be able to view and access the workflow overview through the following navigation path:


  • Logon to the Enterprise Portal
  • Navigate to Content Administration & Workflow Content
  • Select Workflow Tasks & Locate the workitem


These reports are part of Collaborations and are supported by the UWL.

  • However in true essence these are not documented and we do not promote & support such a deletion method.

The steps outlined above are a typical approach for the deletion of worktasks but not recommended. Outlined below is a comprehensive guidance document highlighting how to hide, remove and manage workitems accordingly.



uwl2.JPGIn relation to the deletion of tasks themselves. There is no official walkthrough documentation provided by SAP as this is not encouraged

unless there is no other means of solution. If the tasks we are dealing with are  Java Workflow tasks, meaning that there is no backend system involved in the scenario for these particular items,then the "task" of interest is part of a Task List, which has have created through the "Create Task" uwl button.

If you want the UWL to manage workitems accordingly to ensure the Inbox is kept "current" the Refresh option can be used to bring the recent workitems that are generated and available in SWPR but not in the UWL itself. The workitems once processed properly will be automatically removed from the UWL and their associated status will change.



SAP KBA: 1577547 - UWL Performance Tips and Considerations

UWL Refresh & Performance Parameters:

There are many configuration options that affect the performance and in the process of creation, the sizing guide determines the hardware requirements.


  • Number of users
  • Total number of items per user
  • Number of connectors


Performance Degradation Factors

  • Sometimes specific connectors (BPMUWL) cannot fulfill the get items request. There is 30 seconds timeout defined for the connectors (configurable)
  • Communication channel between UWL and providers (Network, JCo)


Performance Configuration Recommendations

  • Use Delta Pull mechanism (where applicable)


  • Delta Pull period should be no longer than the time that task is required to be updated in the UWL for all new items from the backend. If the items are created more frequently, the period should be shortened and the opposite. Better results for performance will be with higher values but the items may not be always up to date.The minimal value is 60 seconds and it is default value as well.


  • Cache validity should have a longer period value than the delta pull.If cache validity has expired then a call to backend will be performed regardless of the fact that delta pull has occurred.


  • Page refresh rate, that is accessible from data properties of Personalize Tasks, specifies how often UI will be refreshed with data from the cache. Note that the cache validity period takes precedence.Then the Page refresh rate should have less period value than cache validity. Last comes the Delta Pull period. In short: Cache Validity > Page refresh rate > Delta Pull period.


  • The number of users per channel depends on the number of the tasks and the number of theusers. Default value is 40 users per channel. Increasing this number will decrease the number of the invocation to the backend. Note that the higher the number of users per channel, the higher volume of data per invocation will be transferred.


  • The IView property “Wait duration for UI refresh while waiting for update” can be increased if UI is not responsive. If the value of this property is set to 0 then user interface will be blocked waiting for the call to the backend to complete.  In this case after call is completed and  cache is updated, items are read from cache displayed in the UI. Assigning value to the property allows  the UI to read the last data found in cache and display it immediately, this  way unblocking UI while the call to backend is performed in background. After the time defined in the property passes, presumably cache already updated with the latest items in background, UI is updated again from cache showing the latest items.


  • The number of the custom attributes should be decreased.For every additional attribute an additional call to backend is performed. The setting “Retrieve custom attribute via primary pull” should be switched off.


Portal Runtime errors can on occasion be more commonly encountered than we would like as Portal end-users. Often upon being presented with a Portal Runtime error we are baffled by its occurrence and actively seek its root cause and subsequently its resolution. If you have had experience with the Enterprise Portal for some time the likelihood of you being involved in such a scenario is high. This blog posting aims to look at a specific Portal Runtime error and will touch base on the steps to follow in the quest for a quick and straightforward resolution.

Portal Runtime Error - Popup Principles

When a Portal Runtime error occurs the primary troubleshooting hints are normally provided to you as an end-user within the error exception details. From a high level perspective Portal Runtime errors can occur for a wide array of reasons e.g. invalid system configurations or application discrepancies. However troubleshooting Runtime error exceptions should always begin with labeling the "Exception ID" as the core point of interest.


If you match the Exception ID to the trace file and application log you are already on you're way to finding a resolution. Often breaking the issue down into small steps is the best means of troubleshooting analysis.

Example - Portal Runtime Error

We are going to take the principles above and apply it to a sample problematic scenario and follow a troubleshooting resolution approach. Let us firstly imagine that you have recently performed a system change of some sort. This can be related to upgrades, system migrations, data transfers, SP implementation etc.

Reproducing the Popup:


  1. Login to the portal from desktop.
  2. http://<host>:<port>/irj
  3. Perform some navigation across the Portal Role menus which will prompt the issue to occur.


You find an Error in Trace - The "Old URL is Null", what does this mean?



If you proceed to analyze the default trace file based upon the Portal Runtime error Exception ID  you will have seen the following reference

  • "NavigationService.redirect.recieved exception when calling to redirectors with URL".

The NavigationRedirector provides a method to retrieve redirected node names. A re-director must be registered in a means that recognizes the prefix of the navigation target. In this case the exception is occurring due to caching of the NavigationService.redirect recieve request when calling redirectors with the defined URL.


The Navigation Cache is responsible for caching the navigation of the Portal, starting from the “Entry Point” level. As it caches navigation data like title, merge ID, sort priority:

  • If you make a change to the navigation of the user, the change might not be immediately visible causing subsequent errors.

To resolve this issue you need to clear both the Navigation Cache along with the FPN Cache.


  • Navigation Cache:
    • To clear this firstly login to the portal from desktop (http://<host>:<port>/irj).
    • Go to System Administration > Navigation > Navigation Cache before clicking on the Clear Cache button.
    • Clear the cache for the ROLES connector.


  • FPN Cache (if applicable)
    • Login to the Consumer Portal wherein the federated portal cache needs to be synchronized.
    • Navigate to System Administration > Federated Portal > Myself as Content Consumer > Cache Management.
    • Under Clear Cache followed by the Synchronize Content, click on 'clear the federated Portal cache'.
    • Select “Synchronize all content (if you have consumed large amounts of content, this may take a long time to complete).”
    • Select the “Synchronize with a selected producer” option.
    • Select the federated Portal (Producer) from the dropdown list that needs to be synchronized.
    • Click on the “Synchronize” button.
    • Please restart the Portal session by closing all the browser windows before logging into the Portal again.


A common occurrence with KM (Knowledge Management) problematic based scenarios can often be traced to Hot-Deployment occurrences especially when we are dealing with configuration setups. Hot Deployment references can be encountered in the form of exception highlights within default trace files or also lead to on-screen graphically represented errors. Such occurrences are often associated with recent upgrades, migrations and system restarts involving component configuration changes.

What is Hot-Deployment?

As the name hot-deployment might suggest this process refers to an abrupt & quick means of transferring underlying KM/KMC Code within a KM Service Landscape. The catch with Hot-Deployment is that such a process involving the code does not require the end-user or system admin to perform a restart of the corresponding container base. To elaborate further on this point if we take the Enterprise Portal as the backdrop we know that such an environment consists of multiple core component areas. From solely the perspective of KMC, hot-deployment means you are able to redeploy KMC Components freely without touching the corresponding Portal Components which provide the platform base on which KM runs.


In the image above we depict the process basis of how KM interacts with the Portal through run-time technology conduit channels. All KMC Components interact with the Enterprise Portal's classloader elements i.e. the Portal Runtime Technology (PRT) which is supported through delegated communication from the CRT (Component Runtime).

Hot-Deployment - Concerns ?

The major point of highlight surrounding Hot-Deployment is that such an action is NOT supported, encouraged or recommended as it can lead to a wide array of different issues. If you come across hot-deployment references within the default trace files you're findings will be identical or similar to the sample exception outlined below:


  • #0-500#Error#com.sapportals.wcm.crt.CrtClassLoaderRegistry# #EP-KM-FWK-RF#sap.com/com.sap.netweaver.bc.crt##sap.com/com.sap.nw.r#com.sapportals.wcm.crt.CrtClassLoaderRegistry[HT T P Worker ,5,Dedicated_Application_Thread]#Plain.Stacktrace of classloader registration attempt. [EXCEPTION] java.lang.Exception #0-500#Error#com.sapportals.wcm.crt.CrtClassLoaderRegistry#



These exceptions can come into play with visual representation errors




  • #EP-KM-FWK-RF#sap.com/com.sap.netweaver.bc.crt/global~wpc~tiny_mce#com.sapportals.wcm.crt.CrtClassLoaderRegistry#Thread[HTTP Worker [@842428700],5,Dedicated_Application_Thread]Plain Registration of classloader with id ignored, as hot-deployment is not supported (see OSS Note 894884). Please restart the server to enable newly deployed components.##2.0#2015 09 02 11:09:31:935#0-500#Error#com.sapportals.wcm.crt.CrtClassLoaderRegistry#

In the Hot-Deployment sample exceptions  outlined above we see the references to the Component Runtime & Portal Classloaders. The significance of such exceptions is that component discrepancies and functional issues may appears as a result.

Correcting Hot-Deployment

The exception above we see a reference being made to hot deployment. An overview on this particular exception along with its root source and means of resolution is covered in the following SAP documentation:

- SAP Note: 894884 - Hot-deployment of KMC components - Clarification


In order to resolve hot-deployment you will need to proceed to restart the J2EE engine in order to clear the hot deployment and then subsequently check if KM is accessible.

  • This restart requirement is outlined as a hint in the exception itself and will appear as "Please restart the server to enable newly deployed components".


In addition to the note documentation outlined above kindly review the guideline WIKI's below which offer a more comprehensive overview:


Hot Deployment in the Enterprise Portal: http://wiki.scn.sap.com/wiki/display/KMC/Hot+Deployment+in+the+Enterprise+Portal

KMC - Hot Deployment Checker: http://wiki.scn.sap.com/wiki/display/KMC/KMC+-+Hot+Deployment+Checker


If you see exceptions pertaining to the "Registration of classloader with id" the reasoning behind this is sourced to incomplete deployment. A restart should in theory resolve this occurrence and resulting exception (as this restart subsequently redeploys the component).

So the bottom line here is that Hot Deployment is not supported and the J2EE should be restarted if it occurs. From a preventive standpoint you can use the Hot Deployment checker tool to see if your application is Hot deployment safe, see the note as well.


Points Of Consideration

If you find a restart does not resolve the issue there are various troubleshooting notes and resolution documentation available. However in true essence as this is a non-supported action there is not much we (SAP) can do in terms of offering consultation. SAP Note: 894884 should be used as the primary source of reference here. As per this note SAP Delivered components have not been Hot-Deployment "aware" since SP12+ onward.

If then you come across Hot-Deployment this means that the likely cause is a manual trigger or by Custom Developed Components. If it is the former i.e. (Custom) I need to emphasize that Hot-Deployment in any way, shape or form is not supported and therefore we advise such an action is never conducted ESPECIALLY in Production based Environments.

  • Custom Developed Components also fall outside the scope of the Support Channels therefore from our side consultation is not available.

If Hot-Deployment was caused by the Deployment of a custom service, this can be resolved by performing a full system restart. If however, it is being called by the actual coding of this custom application, then it will reoccur even after the system restart has been performed.

  • In this case, you will need to discuss this with the associated code developer responsible for the application in order to redesign it so that it is not causing an init or triggering a classLoader at runtime.

Basically, anything causing a restart of the CRT (component run-time) without a corresponding PRT (portal run-time) restart will result in Hot-Deployment being caused.



If hot deployment has occurred it will ordinarily be the cause of discrepancies and subsequent loss of functionality.



As we've covered previously Substitution is a key part of functional association to the Universal Worklist (UWL) from an operational standpoint. In a previous blog posting I covered and outlined the methodology behind managing substitution rules and how they can be disabled in the most optimal way (http://scn.sap.com/community/enterprise-portal/blog/2016/01/28/ep-uwl-substitution--unable-to-delete-a-substitution-rule). 


This blog posting covers a different viewpoint surrounding substitution and focuses solely upon trying to hide the "Manage Substitution Rule" option from different end-users.


From a high level perspective customizing an interface and the option elements it holsters is common practice among organizations in order to suit business requirements and preferences.


Manage Substitution Rule - Background

The "Manage Substitution" option you see in the dropdown image outlined above is an Action triggered directly by the UWL (Universal Worklist) itself. This is part of the standard UWL Functionality and the association Action Name is "launchSubstitutionManager".

Manage Substitution Rule - Trying to Remove it

If you have a requirement to removal total support for substitution and its functional association a cross-reference check of the configuration in the iView Property "Display Substituted User" within (PCD Content) should reveal the current value to "yes/no". If you want to keep tje substitution feature itself active but do not want to display the "Manage Substitution" option then add the "launchSubstitutionManager" to the iView Property of "List of UWL Actions to exclude".



Navigate to the UWL Iview in the PCD that the end users are seeing in your standard business scenario setup.


  • E.G. pcd:portal_content/users/JoeBloggs/Roles/UWL/com.sap.netweaver.bc.uwl.uwl_iview


When you select UWL substitution from the dropdown, next to Property Category, what is displayed here for the following parameters?


  • Add ALL Substitution Profile as default: Yes/No?
  • Disable Substitution Profiles: Yes/No?
  • Disable turn on/off buttons: Yes/No?
  • Display Create/Delete buttons: Yes/No?
  • Hide Rule Activation column: Yes/No?



Substitution Buttons & Further Pointers

Please see the help.sap.com article for reference, see the table at the bottom.


Here you will see the standard options which indicate whether Create and Delete buttons are displayed or not. As you should see as standard the Default setting is "Yes". This flag provides an option to hide the Create Rule and Delete buttons from the business user.


Manage Substitution Rule - Important

If your goal in this instance remains to make users unable to create/delete rules as this functionality is not needed i.e. remove the 'Manage Substitution Rule' option there are some important points to highlight.


From NW 7.31 operating with the LATEST SP you can indeed remove the "Manage Substitution Rules" option from view but earlier Product Versions do not boast such a removal functionality. With the I-View Property "Display Substituted User"  you can remove the option as this property hides the Substitution Selector and the Menu Item.

Additional Guidance Documentation & Points

If we re-reference the property we discussed previously "Add All Substitution Profile as default" you will find the parameter that I am mentioning in the following:

  • SAP KBA: 1577579 - Facts and limitations about Substitution in the Universal Worklist


I've come across issues regarding this option before and you will see that in older UWL Component Versions that in some cases the option remained visible despite its edited exclusion.


For your reference kindly also see SAP Note: 1258676 Point 25. At UWL Substitution 'All' profiles used to be added automatically even if it was excluded from backend profiles. Adding 'All' profiles now can be properly set by the appropriate iView property as this should allow you to implement a coded fix to achieve the desired setup and subsequent display.


In my experience perhaps one of the most commonly encountered issue scenarios in my discussions with customers relates to session management and inadequate session retention. I like to use the term "classical" session retention to describe a connection issue such as the working example outlined below:

  • User A logs into the Enterprise Portal and performs some activity
  • User A proceeds to finish this activity and navigate away or close the browser (whilst clicking logoff)
  • User B logs into the Enterprise Portal and is presented with User A's session details i.e. the information last accessed by User A.


The Portal, Sessions & BI/BW

With regards to the Enterprise Portal, BW in itself along with Business Intelligence (BI) is one of the most heavily utilized application interfaces. Business Warehousing along with running BW Reports is often an activity associated with interaction & integration through the Enterprise Portal.

  • For example you could have BW Reports accessed through Portal iViews

Let us expand on the working example above and imagine that a BW ABAP Production System and notice via Transaction SM04 that RFC Connection Sessions are not closing & getting disconnected from the Enterprise Portal. In true essence these type of occurrences come down to two particular factors which are either a discrepancy in the setup or a mis-configuration in terms of parameters.


With respect to a BW based scenarios here you need to determine whether or not the root source of "session retention" resides with the Portal itself or in fact the BW perspective.


From an end users perspective utilizing the enterprise Portal is a straightforward process. We simply logon, fulfill our work obligations and logoff. As an end user we are only concerned with the graphical representation of the Portal that we are delivered with through our monitors representation and we are not truly troubled by what underlying functionality is taking place.

The Portal - How It Manages Sessions

From the perspective of the Enterprise Portal and session management there are some important points to highlight. When session expires or logoff is invoked or browser is closed, no matter what, the connection is not terminated but returned to the pool and kept open as defined in the Connection Lifetime property. In short, the connection stays open for the predefined amount of time by design and this is not an unexpected behavior. It remains in the pool, it is no longer used by e.g. the UWL and it is available for other clients.


The connection lifetime pool can be reset to a different value.When you use transaction SM04 to check sessions what are you seeing? In many cases when the portal is closed (via logoff) a reference is stored.



Use Transaction SM04 - What Do You See?

From using the SM04 transaction it may appear that the sessions remain open but in fact they will only be references.


  • But you are seeing the transaction field remain filled? Are you closing the browser after the users logoff?


Now the WIKI outlined below concerning the RFC Sessions and the SM04 Transaction screen is the core point of reference for resolving session retention.



Essentially SM04 as a transaction provides us with a view on the different connection types. With reference to SM04 the connection type means what kind of user (and their connection) is connecting to the SAP System e.g. the Portal.


Connection Types


  • Connection types include that of RFC, GUI, Plugin (HTTP/SMTP).


RFC Connections


This particular connection type references users which are connected up to the system (Portal) via an RFC Connection. (See RFC's using the SM04 transaction), a simplistic view on a RFC connection type user is someone who is utilizing the connection using external based RFC clients.


GUI Connections

As the title implies this particular connection types makes references to users who utilize access to the Portal via a GUI based connection platform.



The Portal - Connection Lifetime Property

The Netweaver Administrator (NWA) and the Connection Lifetime Property in older versions twas managed through the Visual Administrator but from 7.3+ you can find, review and maintain this property through the following path:

  1. Login to Netweaver Administrator (/NWA)
  2. Go to Configuration > Infrastructure > Application Resources
  3. Click at the resource you'd like to change, for example of type 'JCA Connection Factory'.
  4. Do your changes (if needed) in 'Resource Details' > 'Connection Pooling' and save.


Note: The RFC connection will be removed from the connection pool if it is unused for a longer time than defined in the connection lifetime:


In true essence when we are dealing with a session retention issue from the perspective of the Enterprise Portal (EP) the primary points of analysis are to ensure that the correct parameters and configurations are being maintained and that the .DSM Terminator is called and reference accordingly.


The Portal & BW - Resolving Connection Issues

Now taking what I have written above into account we know that the connection itself is not terminated but rather returned to the connection pool. So here now we must determine where the issue is sourced from i.e. the Portal or BW.


  • Are you closing the browser after user logoff? When a user logs off from your company Portal by choosing the Log Off button, a logoff action should be triggered on the SAP Portal Side (Portal & Connected back-end systems).
  • Although the SAP Netweaver Portal comes with an out-of-the-box mechanism that terminates a session when the user closes the browser or navigates out of the SAP iFrame the mechanism itself does not handle logoff. Instead your company Portal must raise the terminating event when logging off from the SAP Portal.


Portal Resolution Notes


  • SAP Note: 1261669 RFC connections are not closed
  • SAP Note: 1903478 -Session remains open after the logoff on enterprise portal && SAP
  • SAP Note: 1660720 - Session remains open after the logoff on enterprise portal



BW Resolution Notes


  • SAP Note: 2177121 - Common issues with RFC sessions and time out handling in BI Java Web


Full Overview Blog Series on Sessions & Related Issues

EP: Sessions Part 1 (RFC, GUI, HTTP Plugin) A Brief Overview


EP: Sessions Part 2 (RFC, GUI, HTTP Plugin) Common Ground & Issues


EP: Sessions Part 3 Frequent Issues & Solutions




Several of my blog postings thus far have been aimed at troubleshooting performance based issues and pinpointing the root causes and this blog will follow the same notion except with particular reference to the AccessStatistic Service in association to KM (Knowledge Management).

What is the AccessStatistic Service?


Upon being involved with KM based performance issues or timeout scenarios one of my key areas of focused is based on the AccessStatistic Service and whether or not this is enabled on a customers landscape. Now in short the AccessStatistic Service is a mechanism responsible for recording accessed KM resources in a Portal Landscape environment. The AccessStatistic Service is utilized to track the type of resource accessed, the ID used to access it i.e. (whom the resource was accessed by) and the resources last read access.


Should You be Using AccessStatistic Service?


From a high level perspective the functionality offered by the AccessStatistic Service is indeed beneficial from a logging and performance standpoint. However in true essence in order to conform to best practice standards (performance wise) it is officially recommended that the service itself be "deactivated". This may seem peculiar but I will explain why such a service is recommended NOT to be utilized as standard and put more simply as default. As we know the Portal in itself plays host to a wide variety of application, information and all branches of associated information. Such diversity in the content holstered by the Portal combined with a large end-user base means a simple concept becomes a complex and diverse environment.

Now taking the sample "environment" that we have created into consideration let us add the activation of the KM AccessStatistic Service into the mix.  KM Folders are utilized as the base platform in which KM Documents are stored.  For example through KM End-Users can access, obtain, manage and review data information through documents sourced from the business  intranets, external WWW feeds, and file servers. The KM Documents themselves are presented in the standard formats of PPT, excel, word documents and html. With KM the underlying baseline operation through which the entire setup functions is based on "accessing" information.

If this AccessStatistic Service is activated and setup in your environment you will not see associated information appearing in a dialog box and there will be masses and masses of DB Accesses. Such a setup has resulted in several scenarios in which time outs and poor performance where something all too frequent and familiar.

I have been encountering timeouts, could this be the AccessStatistic Service?


In short from a purely KM standpoint the answer to this question is indeed yes and checking your configuration is the best means of analysis so the AccessStatistic Service can be ruled out or identified as a potential culprit as early as possible.

To reaffirm performance decrements and time-out issues from the perspective of a KM Setup on any occasions share the same primary cause within the KMC and this is the activation of the AccessStatistic service on the KM repositories.


The resolution in such a scenario is this services deactivation within the configuration of the KM repository managers as per:


  • SAP Note 1025290 (restart required after service deactivation).


As outlined in SAP Note 1025290 this repository should be removed from the configuration of all CM repositories where possible.


This should be done by navigating to System Admin -> System Configuration -> Repository Managers -> CM repositories





From here you can access the configuration of each of the CM repositories. These should be opened for editing and the AccessStatistics repository removed from the list of repository services.

  • In the sample image above  you can see that it’s assigned to the /documents repository in this case. By selecting ‘edit’, you can then select/deselect the checkbox next to whichever services you want enable on the repository.





Once the configuration of each of the CM repositories on which this service is currently active has been active have been updated, a system restart will be necessary for the changes to take effect.


AccessStatistic Service - Further Reading


You can find additional information in the documentation outlined below:



KM  - Optimal Performance


Now regarding the KM Setup and the performance issues alongside the KM Folders rooms I've outlined some core reference documentation below for your convenience:


I would also recommend in this case from the perspective of document storage and KM utilization is to make use of the baseline principles and guidance material in the documentation below as this will allow you to create an optimal setup so performance degradation is not a risk and timeouts are no longer encountered:


This blog is for portal end-users and content administrators who would like to learn about the new features developed in the latest Enterprise Portal SP for FLP on EP, their benefit, and the configuration required.


Important note: This SP is the first to use the stable SAPUI5 release 1.38, which is the recommended version for productive usage of NW 7.50. It is highly recommended to consider SP04 for upgrade. For more information, see note 2261419 - Maintenance Strategy for FLP on Portal


SP04 includes the following features:


  1. Home page update options
  2. Clear personalization
  3. Browser history support
  4. Accessibility Settings through User Preferences Menu
  5. Merge of identical EP tiles
  6. Display user image (from UME)
  7. Dialog for unauthorized tiles (enhanced)
  8. Remote Content Management (enhanced)
    1. Assignment in a non-unit role
    2. Desktop filter ID support
    3. New guidelines for UI5 library source configuration
  9. SAP Business Client new connection type
  10. Video.

1 Homepage Update Options (sync enhancements)

As an administrator, you can control the ability of end users to see the updates done for the iViews properties, role assignments and content, changes in administrative groups, i.e. the changes done by an administrator and affecting the end user’s homepage.

The options are as following:



  • Automatic update (default): on FFP loading the homepage will be updated automatically. This may cause delay on every logon, hence this option is not recommended in production.


  • Manual update: a menu item Check for updates is available in the Options menu. When a user wants to trigger an update, he should click on this menu entry and to get a pop-up with a summary of updates:



The updates can be viewed in details and either applied or not:



  • Notifications for end users: provides a similar to manual updates pop-up on FFP loading:



A user can accept or defer the changes. The pop-up will come up until the changes are accepted. This is the recommended option as it has minimal impact on logon performance and gives the end user control on his homepage, while keeping it up-to-date with administrator’s changes.

Check for updates menu item is available in the Option menu as well.


  • Never check for updates: this option means the user will not get any updates done by the administrator.

Changes that administrators make to home page content do not override end user personalization.

2 Clear Personalization

Clear Personalization menu item can be added to the Options menu. With this item an end user can undo all changes that have been made to the home page.


An administrator can show or hide this menu item for a Fiori Framework Page:



3 Browser History Support

An end user can now navigate between a launched application and the launchpad using the browser's standard back and forward buttons. In order to enable this option, please follow the instructions in note 2269227 - Application Integration parameter to support browser history mechanism.


4 Accessibility Settings through User Preferences Menu

  End users can now activate accessibility features by choosing an Options menu item User Preferences and then Accessibility



If you set it to true:


The relevant accessibility parameter will then be transferred from FLP on EP to the launched applications to enable their accessibility features


An administrator can show or hide the Accessibility item by configuring in the Fiori Framework Page an option Show ‘Accessibility’ in ‘Options’ Menu:



5 Merge of Identical EP Tiles

An administrator can remove duplicate tiles, both in portal or remote content from ABAP FES, by activate this option in Fiori Framework Page. The implementation logic for remote and EP content is different: remote content tiles are merged if Title, Subtitle and Information properties are identical; for Portal content the implementation relies on the merge ID logic.


6 Display User Image (from UME)

User image, uploaded in UME, can be shown in the Home page header by configuring a new option in the Fiori Framework Page, Show User Images:


The Homepage for an end user could then look like this:



7 Dialog for Unauthorized Tiles (enhanced)

This error message appears in the following scenario:

1. An administrator has removed a tile(s) from an end user role

2. The tile(s) appears in FLP on EP Homepage or was saved as a browser bookmark

3. End user launches the tile from the Homepage or browser bookmark.

In case you launch the app from the Homepage  the dialog will suggest to remove the tile:




Suggestion will not appear in case of launching directly from the browser bookmark.

8 Remote Content Management (enhanced)

8.1 Assignment to a non-unit role


In the previous releases the remote content could be assigned only to the unit role, which is not flexible enough for portal administration.

This new feature was developed to make the management of remote content easier for complex assignment cases.

Now you as an administrator can combine the remote content assigned to several roles in the hierarchy under one unit role, which will be assigned to a user.



You have created 2 roles and assigned remote content to each one of them:




Now you define a unit role, which will be assigned to an end-user:





  • in design time you do not see the remote content of non-unit roles and you cannot edit it;
  • in run-time the remote content from all non-unit roles will be displayed for the end user, to whom a unit role is assigned.

8.2 Desktop Filter ID Support

As an administrator you can filter portal content so that only certain content is displayed in a given desktop. Now this logic can be applied also for remote content. To do this you should set the Filter ID property for the role which the remote content is assigned to:



8.3 New guidelines for UI5 library source configuration

As of 7.5 SP4 the guideline is to use Java as the SAPUI5 library source for all productive scenarios. For more detailed information refer to note 2261419 - Maintenance Strategy for FLP on Portal


9 SAP Business Client New Connection Type

SAP Business Client 6.1 implemented a new Fiori Launchpad connection type, which can be used starting from SP04:



Within this connection type, the only parameter relevant for a Portal backend would be the connection URL:




The transactions launched from SAP Business client 6.0 with Fiori Launchpad connection have native look (not SAP GUI for HTML UI).



To learn more:


Filter Blog

By author:
By date:
By tag: