Understanding System Aliases
Aliases are names that system administrators define for each system they create so that portal components can reference these systems. They are a means of retrieving the information stored on database servers without having to know the name of the server.
-
Each system must have at least one system alias through which it can be accessed.
-
There can be any number of aliases pointing to the same system.
-
During content creation, the developer can choose to connect through any of the system aliases associated with the particular system that the content is to access.
-
-
A system alias should reference only one system.
-
The first alias created is automatically defined as the default system alias, which stores that system's unique parameters.
-
You can reassign the default status to another alias.
-
You cannot remove a default system alias until you have designated another system alias as the default, unless the alias you are removing is the only one defined for that system.
-
The system reverts to the default system alias to make its connection if all other aliases are removed.
-
If you remove a default alias that is a single system alias, you then cannot access the system during runtime.
-
-
A single system alias remains the default system alias.
System Aliases and User Mapping
Systems are represented by their default alias in various interfaces, such as the User Mapping dialog that displays during personalization. To make a system available for user mapping, you must:
-
In the System Aliases Editor, define a default alias for each system that you create. For information about creating system aliases and default system aliases, see Managing System Aliases .
-
Set the User Mapping Type property, either from the System Aliases Editor or in the Property Editor for the specific system, to one of the following:
-
User: Only the end user can set user mapping
-
Admin: Only the administrator can set user mapping
-
Admin/User: Both the end user and the administrator can set user mapping
-
Changing the default system alias does not affect user mapping. However, if all system aliases are removed, user mapping is lost to that system, even if a new system alias is created with the same name as the previous default.
System Alias Behavior During Transport
Aliases do not get exported during a transport operation.
-
An alias must be a unique identifier of a system
-
Content created for a specific portal may not be viable in another portal if continues using the same aliases that it used in the original portal. iViews that access a back-end system through a certain alias may not retrieve the desired data, or any data, once they are in another portal, because their aliases may not access the correct systems.
Working in Portal One, you create a JDBC system whose default alias is jdbc . The content in Business Package AAA of Portal One uses the data retrieved by this system. Business Package AAA is then transported to Portal Two, which contains Business Package BBB. The content of Business Package BBB uses a system whose alias also happens to be jdbc , but which does not reference the same back-end application as the system used by Business Package AAA. Had Business Package AAA been transported with aliases, you would have a situation whereby aliases would not necessarily be connecting to the correct systems.
System Alias Behavior During Portal Catalog Operations
Copying a system is basically the same as transporting one. When you create a copy of a system, the new system does not retain the aliases defined for the original system.
When copying a system, or transporting content, you need to define new system aliases.
System Aliases and SAP Systems
For SAP systems (BW, CRM, and so on), it is recommended to use a system alias that has as its name parameter the logical system name as defined in the SAP system itself. The logical system is specified in Table T000 in the SAP system.
System Aliases and Dynamic System Resolution
Portal components generally connect to a back-end system by referring to a system alias defined in the PCD for that system. The portal also provides the possibility for dynamic system resolution, which enables portal components to refer instead to a system alias that is resolved to a system at runtime. Such an alias is not defined in the PCD.
When a portal component refers to a system alias, the portal checks the portal registry to determine if a custom service exists that can resolve the alias. If no entry is found for the alias, the portal retrieves the system that is associated in the PCD with that alias.
If an alias is defined in the PCD, as well as designated for dynamic system resolution in the portal registry, the system landscape service returns the PCD system.
This means that an administrator who deploys a resolving service must verify that no identical alias is defined in the PCD; otherwise, the service will never be called.
This also means that an administrator who creates a system (and alias) in the System Editor may accidentally override a resolving service that has already been deployed. To avoid such an occurrence, check the portal registry for currently deployed resolving services. From the top-level navigation
bar, choose
System Administration 
Support Portal Registry Browser 
, and then navigate to
ROOT/runtime/alias.mappers .
Use Case Example
It may be advantageous to override the defined alias mapping in situations such as the following:
In order to speed up the connection, a physical system path can be chosen according to the geographical location of the user. A user located in New York would connect to a physical system in the U.S.A., while a user in Rome, working with the same iView, and using the same alias, would connect to a physical system in Europe.
For more information about dynamic system resolution, see Dynamic System Resolution .