The portal treats Web Dynpro iViews like any other iView, so the role definition not different.
With the delta-link mechanism it is possible to configure a Web Dynpro iView (one or more of the iView parameters) for a specific page, workset, or role.
The set of parameters that defines the used configuration is application-specific. With the Web Dynpro iView Wizard any set of these parameters can be defined in the Application Parameters dialog window as iView parameter (see Create a Web Dynpro iView).
In the SAP NetWeaver version of the pattern engine, the configuration is defined with the parameter configurationId. By calling the pattern engine with different values of the configurationId parameter, the pattern engine executes the different scenarios.
Therefore, you have to specify the configurationID using the Application Parameter dialog window of the iView parameters. The value can be customized using the delta-link-mechanism and becomes a role-based pattern application.
With SSO the user logs on to the portal once and does not have to log in to every iView later on.
SSO for a Web Dynpro-based iView can use one of the following mechanisms:
· Ticket authentication
The following steps are necessary to switch to ticket authentication:
¡ You must maintain the definition of the system running the Web Dynpro application. You have to define the logon method and the user mapping type:
¡ The ticket provided by the portal system is accepted by the system running the Web Dynpro application.
¡ The portal and the Web Dynpro system have to have the same set of users. Either both systems use the same user store or the users have to be manually added on both systems.
· User mapping
The following steps are necessary to switch to user mapping
¡ You must maintain the definition of the system running the Web Dynpro application. You must define the logon method and the user mapping type:
¡ The portal user must log in (on the system running the Web Dynpro application) during the start of the iView. To prevent this, the user can define the following logon data using the User Mapping section of the personalization dialog:
The administrator can set this user mapping for a whole user group or for specific roles.
As user mapping does not need as much configuration effort as the ticket authentication, this is very useful for test environments. For production scenarios, you should normally use the ticket authentication.