Having dynamic XSS homepage/areapages seems to be a common requirement for many enterprise portal implementations. In an example scenario, you will see how all the static service links in the Self Service Homepage and area pages can be made visible and invisible dynamically by using one simple Proxy class and one RFC which contains all the dynamic page rules. This way you will be able to create and maintain complicated dynamic XSS Homepage and area pages easily.
The Self Service Homepage framework configuration can be found here, just in case.
0. Example Scenario
Let’s assume we have defined two static services (Z_SERVICE1 and Z_SERVICE2) and have assigned them to an area page. Each service has one link resource that points to an application. So each employee gets two service links in the area page. However, the links should be only displayed to some employees. Here I define two very simple rules for the dynamic area page:
Rule 1: Display Z_SERVICE1 to employees with personnel number starting with 1.
Rule 2: Display Z_SERVICE2 to employees with personnel number starting with 2.
You can define any rules with several services and use the same proxy class that is used here.
1. Create the Proxy Class:
1.1 In the ABAP workbench, create a class (I call it ‘ZCL_XSS_PROXY_DYNAMIC’) and implement the interface ‘IF_XSS_SER_PROXY_SERVICE’. Three methods will be created for your class automatically under the 'methods' folder: GET_SERVICES, GET_SERVICE_DATA, and SET_CONTEXT_PARAMETERS.
1.2. Add the following attributes to the proxy class:
1.3. Fill in the method SET_CONTEXT_PARAMETERS with the following lines:
1.4. Fill in the method GET_SERVICES with the following lines.
1.5. Leave the body of GET_SERVICE_DATA empty.
2. Create the Service Availability RFC
The method SET_CONTEXT_PARAMETERS calls an RFC named 'Z_GET_SERVICE_AVAILABILITY’. This RFC will basically contain all the dynamic page rules. The RFC imports the personnel number and the service name and it exports a Boolean value determining if the service is available for the employee or not. In our simple example, the RFC will look like the following:
All dynamic page rules can be implemented in this RFC. For instance, you can hide the services based on the organization units, cities or pay scale types. To show a service, set the showservice parameter to true based the conditions that the rule states, and obviously to hide it set the showservice to false.
3. Use the Proxy class in the services
The last step is to add the proxy class name to the service definition. Before adding the proxy class, the service should be defined and work properly for all users. The proxy class applies the availability rule which is defined for the service.
4. How does it work?
Briefly, the first time the user goes to XSS home page the framework initializes all instances of the services that are assigned to the homepage and area pages. To initialize the proxy services first it calls the method SET_CONTEXT_PARAMETERS. In that method the Service availability RFC is called and the showservice attribute of the class is set based on the rules. Then the framework calls the method GET_SERVICES of the proxy class. This method adds the service to the list of services only if showservice is true. Simple!
5. Another Option
It is also possible to implement and use one proxy class for each service and implement each rule in one proxy class. It just sounds more convenient to implement and manage all the rules in one place (Service Availability RFC) and assign one proxy class name to all services than implementing many classes and having each rule in a different class. However, the performance might slightly improve if you implement a separate proxy class for each service.
