The following is one in a series of weblogs on new features in SAP Enterprise Portal 6.0 SP11.
In the past, whenever you created an iView that needed to connect to some back-end system, you provided a system alias. The alias was assigned to a specific system in the PCD, which was assigned to a specific back-end system.
Though an administrator could re-assign the alias to a different system during design time, during runtime the system was fixed. In other words, the back-end system for that iView was hardcoded and could not be changed during runtime.
SP11 now provides a mechanism — Dynamic System Resolution — that enables you to create a service that takes the alias and resolves it to a system during runtime. The logic for selecting the system is generally based on the current user, but could be based on any logic.
How Dynamic System Resolution Works
An iView that needs to connect to a back-end system contains a reference to a system alias. The iView — via the Connector Gateway or other service — calls the system landscape service method getSystemId() in order to resolve the alias to a specific system defined in the Portal Content Directory (PCD). By default, the system landscape service simply queries the PCD for the system that is associated with that alias, and returns the PCD path to that system.
In the PCD, a system alias is associated with only one system.
In order to resolve an alias to a different system, you can create a system resolving service for a specific alias. When an iView calls getSystemId() to resolve the alias, the system landscape service first checks if a custom service exists for the alias. If one exists, the system landscape service calls the resolving service — instead of querying the PCD — in order to get the corresponding system.
The resolving service — which receives from the system landscape service the name of the alias and a reference to the current user — can resolve the alias to any system based on any logic.
How to Create a System Resolving Service
A PAR file that defines a system resolving service must contain the following two parts:
- java class that implements the following interfaces:
- IService: The standard interface for all services
- IDynamicSystemService: The interface for a system resolving service. This interface exposes one method, getAlternateSystem(), which returns a string that represents the PCD path to a system defined in the PCD.
- A portalapp.xml file that defines the following:
The entries in the portal registry to create in order to indicate to the system landscape service the aliases for which to invoke this service.
The following is an example that indicates to the portal that the service named System1Service should be used to resolve the alias named DynamicSystem1:
<registry> \ <entry path="/runtime/alias.mappers/DynamicSystem1"
name="System1Service" type="service"/> \ </registry> \
- The application properties that allow the service to function as a resolving service, such as the startup property (true) and the ServicesReference property com.sap.portal.ivs.api_dynamicSystemService).
- The name of the resolving service and the class within the PAR that implements the service (as is required for any service that you implement)
Example of a Resolving Service
The following code sample shows the following methods:
- getAlternativeSystem(): You must implement this method, as required by the IDynamicSystemService interface.
This method returns a string, which is the PCD address of a system.
This method is used for this example only, to separate the logic for choosing the system.
This method uses the UME service to determine to which group the current user belongs. The system landscape service provides the current user as an IUser object passed into getAlternativeSystem().
If the user is a member of Group1, then one system is returned; if the user is a member of Group2, then a different system is returned.
The following is the entire sample java class for creating the system resolving service.
For more information about Dynamic System Resolution, see Dynamic System Resolution in the Portal Developers’ Guide.
The articles in this series: