Skip to Content
When implementing a dynamic role-based portal environment, we usually end up with multitude of portal roles. With users assigned to several roles, dynamic merge does its magic and produces unique content built for that particular user.   It works okay when there are only two or three roles combining large pieces of functionality (e.g. an ESS Role and a MSS Role) and user-role assignment is a pretty much static.  But once we try to reduce granularity a little and provide more precisely targeted content, we end up with multiple elementary roles that we combine later to generate the required content for Employee, Manager, Time Approver, those who fill out online timesheets and who do not, those who can initiate certain type of requests from the portal and those who cannot, etc. One of my customers had several different timekeeping systems that all should have been accessible in the ESS portal via the same link, but that link should point to Time System A; for employees of business unit 1, Time System B; for business unit 2, and so on; so we have created many elementary roles mapped to different pieces of functionality and then assign combinations of them to users (directly or via user groups) to generate dynamic content corresponding to their specific composite role.   The problem is that in real life users tend to move around org. structure, change positions, responsibilities and jobs, get terminated and re-hired; and an unfortunate side-effect of this is the amount of maintenance required to assign and re-assign thousands of users to multiple different portal roles to match their current status.  In my experience, it turned out to be a full-time job in itself. When one of my clients had implemented a very nice and user-friendly ESS/MSS portal with a dynamic content built around only six main functional roles, they had to literally hire another person just to take care of user/group assignments on a daily basis;  Hundreds of employees joining and quitting every day, changing positions, jobs, and responsibilities, translated into a non-stop flow of (re)assignments of users to a different groups and roles. And the worst part is, that there is no way to automate the process.   So I thought – it would be nice to have a portal environment that could adjust itself based on at least a user HR master data, and/or maybe on some other business logic. I shared the idea with my customers and they instantly loved it. A couple of weeks later, the Adaptive Content Framework concept was formed, and shortly after they were enjoying their highly-adaptive virtually zero-maintenance SAP Portal environment based on the Adaptive Content Framework. 

What is the Adaptive Content Framework

Adaptive Content Framework (ACF) virtually eliminates any portal-side user/roles/group assignments maintenance by introducing dynamic content management based on business logic from a backend HR system. Adaptive Content Framework is capable of instantly adjusting a portal content, according to customer logic whenever master data change occurs in the backend system.  With the DFP precisely targeted content can be made available to users based on their current authorization level, job, org. assignment, login time, or any other criteria.   The initial idea for Adaptive Content Framework came from Homepage Framework, introduced by SAP with the ECC5 release, but then it morphed into something totally new. There two kinds of dynamic pages forming the framework (for now): Overview and Detailed pages. 

Overview Page

Overview page is similar to a combined Group/Area page from the SAP Homepage Framework, and provides a “home page” for a functional area within a portal. It has a description, and references to one or more functional sub-categories. Each sub-category can represent another functional area, that is they can be nested indefinitely. With that, Overview page can act similar to Group Page in the SAP Homepage Framework (when it refers to other functional areas) or to Area page in the SAP Homepage Framework (when it refers to own functional sub-categories.  Here are examples of “Portal Overview” and “Org. Management Area Overview” pages. The “Org. Management Area Overview page” refers to two other nested functional areas: Recruitment and Org. Structure. One or several “default” options can be defined for each functional area/sub-area – those options would appear in the “Quick Links” section and are always visible on the top-level page in case of multiple level nesting. And if any area has other services besides “default”, then the ‘More…’ link will appear at the end of the section pointing to the selected Area Overview/Detailed page.   Figure 1: Dynamic Page Framework: Portal Overview Page. Notice how “Submit Position Requisition” Quick Link appears on the top page through 3 levels of nesting.     Figure 2: Dynamic Page Framework – Org. Management Area page  

Detailed Page

Detailed Page is conceptually similar to Area page in the SAP Homepage Framework and normally used to provide an access point to services within a single functional area. Similar to Overview page, Detailed page shows functional sub-areas and Quick links for the most important functions, but in addition to that it also provides a full navigation menu for the Page’s referenced functional area.  We found it to be really convenient design as the single area may include quite a few services in several subcategories, and instead of overloading the main frame with all of them users will only see the most important ones (Quick Links). But at the same time they will have full access to all services through the built-in navigation menu. Another advantage of this approach is that the ACF navigation menu is fully controlled by the Dynamic Page Framework manager and a user business logic residing in the backend system, and thus, can be dynamically adjusted to include of exclude any options “on-the-fly”.    Figure 3: Detailed Page showing Quick Links and full option list  

Structure

Adaptive Content Framework is based on the existing three levels ESS menu tree structure (tables T77WWW_*) configurable via IMG as explained below:

Menus

Menus correspond to functional areas. In the example on the Figure 3 above, “Recruitment” is defined as a menu.

Categories

Categories are functional sub-areas within a single area. Categories can contain services or refer to other Menus to enable nested structure. In the example on the Figure 2 above, “Recruitment” and “Org. Structure” are defined as categories for the “Org. Management” menu, which refer to the “Recruitment” and “Org. Structure” lower level menus correspondingly.

Services

Services refer to actual portal applications. For the integrity reasons I have decided not to create multiple types of services with different launching mechanisms (e.g. ITS, BSP, WebDynro, etc.) but instead reference only portal components from the PCD (iViews and Pages), so an actual PCD location of a corresponding iView or Page is specified in the IMG ESS Service configuration as shown on the Figure 4 below.   Figure 4: ESS Services configuration in IMG

Adaptive Content Framework Manager

The Adaptive Content Framework manager is a BSP application that provides two main controllers: for an Overview page and for Detailed page.  When an Overview or Detailer page is called, the page controller calls ACF Handler that reads corresponding menu content from ESS Service Menu repository and calls a customer BAdI exit to adjust default services list. The filtered list is then passed back to the page controller that generates a final portal page.    Customer BAdI exit controls whether to show or hide any particular menu option.  The “Check_Option” method has two input parameters: Username and Service ID, and an output Result parameter which returns “True” is the option should be shown, or “False” otherwise. Simple! But it makes a whole lot of difference creating a truly dynamic content.

Using Adaptive Content Framework

To use it in a portal one would simply need to create a BSP iView and point it to one of the ACF manager’s controllers for an Overview or Detailed version. In the BSP part of the iView configuration we will need to specify a Menu ID in the “Parameters” section and a menu style (controller) in the “Start Page” field: Overview.do or Detailed.do  Example on the Figure 5 below shows an iView configuration for the “Recruitment” page shown on the Figure 3.   Figure 5: ACF iView configuration  As a standard feature both Overview and Detailed pages have Double Submit protection that prevents the most impatient users from clicking 1000 times on the same link while it’s already loading. Often times a direct result of a double submission was locked user HR master data in the backend system (SM12), so the Double Submit protection effectively eliminated at least half of support calls from users.

Conclusion

The Adaptive Content Framework(C) is a concept that provides a way to deliver a dynamic portal content adjustable “on-the-fly” based on the user/session parameters and/or backend business logic, where content generation is controlled from R/3 backend system.   It helps create dynamic user-friendly applications and virtually eliminates need for labor-intensive portal user-role assignment maintenance.     

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply