Skip to Content

New in Portal SP11: Dynamic System Resolution

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

          <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
    • 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.

  • checkUser():

    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:

You must be Logged on to comment or reply to a post.
  • Great ,thansk for nice weblog.

    i am having similar issues with System alias,i found some help documenation and also your web log is very interesting, but every thing seems correct to me,but tested iview with two users
    but iview is not pointing to right system based on logic i wrote in the method.

    send email to your email id,please advice me as soon as you get time.


  • hi,

    is it possible,  to determine the System depending on ClientProtocol, request.port, request.server or request.serverport?

    how can i read these variables?



    • Hi Yusuf,

      As this is a service, it is not tied to the request, and only the IUser and the alias are sent into the method. So technically, the answer is no.

      I’m not sure if there are any other services that you could call to provide you with this info.


  • I was confused with the creation of systems and the definition of aliases.  We wanted to use DSR to point SRM business package training participants to client A and normal SRM business package users to client B.  As it turns out, the naming of the system aliases turns out to be very important.  We configured two systems, one for client A and one for client B.  Let us call the system, which points to client A: SYSTEMA, with the alias SYSTEMA_ALIAS.  Let us call the system, which points to client B: SYSTEMB, with the alias SYSTEMB_ALIAS. Since the SRM package uses the default alias SAP_R3_Procurement, the DSR service must register this alias in the Portal Registry (after deployment).

    Hence, now in the Portal Registry, we have SAP_R3_Procurement, which gets resolved by our DSR; SYSTEMA_ALIAS, which points to client A and used by training participants and SYSTEMB_ALIAS, which points to client B, and used by normal users.

    If SYSTEMA had defined SAP_R3_Procurement as its alias, and the DSR registers SAP_R3_Procurement as an entry, the Portal logs an ambiguous system alias error, since it will find SAP_R3_Procurement defined in both the PCD and the Portal Registry.

    I hope this helps. 

    P/S: many thanks to your blog 🙂  Keep em coming.

    • Just to be clear, does your DSR return the alias or the PCD system object? Daniel’s blog says to return the PCD object, but you seem to be saying to return the alias.

      Also, does the SRM BP start and backend transactions etc?


      • Just to be clear, does your DSR return the alias or the PCD system object? Daniel’s blog says to return the PCD object, but you seem to be saying to return the alias.

        My DSR is returning the PCD object.

        Here is a portion of my portalapp.xml, which shows that the DSR is registering SAP_R3_Procurement as an alias in the portal registry:


        My getAlternativeSystem method returns the Id if the PCD object.

        Also, does the SRM BP start and backend transactions etc?

        Due to configurations of the package and user authentication issues, I am not able to verify if the SRM BP is starting or whether the backend transactions are starting.  However, I am able to verify that the correct client is being reached, as directed by the implemented DSR..

  • Does this require a restart?  What might be the result if it returned null instead of a PCR location?

    I am having limited luck with this, but failing to point to the right pcd system.

    Seem like if there is an alias on the system definition and you try to use the same in the portalapp.xml it ignores the dynamic code written.

  • HI Daniel,

    The webblog is really helpful and easy to understand. I have a question, I want to switch system based on user used protocol (http or https). Is there any method to do this… this is client’s requirement…. any help will be appreciated.



    • Hi Shruti,

      As I have not worked on the portal for almost 5 years, I cannot answer the question anymore, 🙁 . But I have referred the issue to some colleagues here at SAP, and usually they answer such questions within a couple of days.