Decision to Migrate a Component

An existing Web Dynpro component must implement a new standalone component interface definition utilizing new functions.

You need to assume a multi-component Web Dynpro application architecture which makes use of Web Dynpro component interface definitions. You have to further assume that this component interface definition is based on the new Web Dynpro component model.

In case a new component interface definition applies a new feature of the new Web Dynpro component model (such as view containers in component interface views, or component interface inheritance), all implementing Web Dynpro components must also be based on the new component model. Without migrating existing Web Dynpro components to the new component model, they cannot be used as implementing components inside an enhanced Web Dynpro component architecture.

Mandatory

An existing Web Dynpro component must implement a new standalone component interface definition not utilizing new functions.

Existing Web Dynpro components are compatible with the new standalone component interface definition model as long as the component interface defintion does not utilize a new feature. This means existing Web Dynpro components (based on the old component model) can still implement or are compatible with a new component interface definition (based on the new component) model, as long as no new functions are applied in this component interface definition.

Not necessary

An existing Web Dynpro component must utilize component interface inheritance, which is only supported in the new component model

Component interface inheritance can only be applied in the new component model. To embed an existing Web Dynpro component in a Web Dynpro component architecture utilizing component interface inheritance together with standalone component interface definitions, the existing component must be migrated.

Mandatory

An existing Web Dynpro component must support the generic secondary help service

To utilize the new secondary help service in the Web Dynpro application running in the SAP Portal, you must define help links at the window controller level inside a Web Dynpro component. Help links cannot be defined in NW04/7.0 component model.

Mandatory

Web Dynpro component developers are not familiar with the old Web Dynpro component model

Depending on the technical knowledge of your Web Dynpro application developers, it might be advisable to migrate existing components to the new component model. In case a Web Dynpro application, developer is not familiar with the WD component model of NW 04 and NW 04s, the total cost of learning the old architecture might outweigh the total cost of component migration. The component migration must be done by a Web Dynpro developer who is familiar with both the old and new Web Dynpro component models.

Optional

You want to simplify your cross-component navigation by applying the new window navigation plug concept

The new Web Dynpro component model allows you to define inbound and outbound plugs at the window level. This greatly simplifies navigation across component borders, because a navigation event triggered at the window level does not require server-side eventing combined with a navigation dispatcher view as was formerly the case in NW04 and 7.0. Since plugs can now be defined inside windows and fired by the new window controllers, the implementation of cross-component navigation logic is much simpler. Nevertheless, this simplification does not make component migration mandatory.

Optional

Utilizing View Containers in Component Interface Views

View Containers in Component Interface Views are an additional function in the new Web Dynpro component model. They are needed to develop so-called Web Dynpro layout components in SAP NetWeaver CE.

A Web Dynpro layout component allows you to embed and position other visual Web Dynpro components without needing to manage the related component instance lifecycles.

In NW 04 and NW 04s it was not possible to develop such layout components because it was not possible to decouple the lifecycle management of component instance from a component interface view embedded in separate components. Instead, the layouting of component interface views had to be defined within the root component because this is where the instance lifecycles of its embedded visual components were managed.

Based on the above facts, there is no practical use case for migrating an existing Web Dynpro component to the new component model simply to extend it to a Web Dynpro layout component. It makes no sense to migrate an existing root component to a layout component.

Instead, such a Web Dynpro layout component should be newly created from scratch. This avoids the need to perform component migration.

Migration is only mandatory in cases where an existing Web Dynpro component must implement a new component interface definition utilizing new functions.

Not necessary (but see use case description)

You want to apply the new default plug property for Web Dynpro view usages

In SAP NetWeaver CE it is possible to define a default plug for all views embedded in a Web Dynpro Window either in a window directly, in a view area or in a ViewContainerUIElement inside a layout view.

The purpose of the default plug is to let the Web Dynpro Runtime start the related inbound plug event handler without first needing to traverse a navigation link. As this new feature is also applicable for all view layouts inside existing Web Dynpro components, a component migration is not required.

Example

For a view controller having the lifecycle property of framework_controlled, when the view layout is first displayed in a view assembly, the Web Dynpro Runtime creates the view controller instance and initializes it by invoking its wdDoInit() hook method.

When the view layout disappears from the view assembly (as a result of navigation) the lifecycle property value causes the view controller instance to persist. Consequently the wdDoInit() hook method will not be invoked again when the view layout re-appears in a later view assembly[1] .

To implement application logic for the re-appearance of a view layout which is not based on a navigation link pointing to this view you can apply the default plug concept. By defining a default plug you ensure that the associated inbound plug event handler is invoked by the Web Dynpro Runtime whenever the view becomes a member of a new view assembly.

You need to be aware that a view layout can also become visible in a view assembly without a navigation link directly pointing to it. This is the case if a view layout is embedded in a ViewContainerUIElement or it has been embedded in a component interface view.

Not necessary