Migrating Webdynpro Java Appl From SAP NWDS 7_0 to 7_1

CE206 Migrating Web Dynpro

Applications From SAP NetWeaver 7.0 to CE 7.1

© SAP AG 2007, SAP TechEd ’07 / CE206 / 2

Contributing Speakers

Bertram Ganz SAP NetWeaver UI, Web Dynpro Development, SAP AG

Marco Ertel NetWeaver UI Product Management, SAP AG

Chris Whealy NetWeaver RIG, SAP (UK) Ltd


Learning Objectives

As a result of this workshop, you will be able to:Understand the Web Dynpro Compatibility Contract in SAP NetWeaver CE 7.1Migrate existing Web Dynpro Development Components to SAP NetWeaver CE 7.1Understand the changes of the New Web Dynpro component modelUnderstand Component Controller Patterns and Anti-PatternsMigrate existing Web Dynpro components to the new component model utilizing the Web Dynpro component migration tool (Cheat Sheet)

Migrating Web Dynpro Components

Summary

Web Dynpro Backward Compatibility

Migrating Web Dynpro DCs

Web Dynprro Backward Compatibility


Summary



Backward Compatibilty in Web Dynpro Java

Backward CompatibilityBackward CompatibilityYou can still run existing Web Dynpro applications developed in SAP NetWeaver 04 and SAP NetWeaver 7.0 within an SAP SAP NetWeaver CE 7.1 environment.

Source CompatibilitySource CompatibilityYour Web Dynpro application will run after re-generation, re-compilationand re-deployment of all Web Dynpro DCs it consists of requiring nosource code adaptations.Binary Compatibility: Binary Compatibility: Not supported

Web Dynpro Compatibility Contract

The Web Dynpro Foundation for Java in SAP NetWeaver CE 7.1 is backward source-compatible with SAP NetWeaver 04 and SAP NetWeaver 7.0.

Presenter

Presentation Notes

IMPORTANT NOTE on Source-Compatibility Source-compatability does not mean, that an unsupported invocation (hijacking) of internal Web Dynpro Runtime FPIs (Framework Programming Interface) is still supported. In case your FPI invocations cannot be refactored using official Web Dynpro Runtime APIs you must explicitly skip the invoked function. In many cases the Web Dynpro Runtime API provides the required functions. See also: SDN WebLog „Never Ever Hijack Internal Web Dynpro Classes and Interfaces“, https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1222


Summary




Migrating Web Dynpro Applications (DCs) to SAP NetWeaver CE 7.1

Web Dynpro DC Migration Process

SAP NetWeaver 7.0 SP13 NWDI Valid Track for SAP NetWeaver CE 7.1 is set up (the required Net-Weaver SCs are added)

Set up DevelopmentInfrastructure

Create Active Projects for Web Dynpro DCs to be migratedRepair Project Structure and Classpath of Web Dynpro DCs in Web Dynpro ExplorerRefactor/Delete Broken or Deprecated Public Parts of Used Library DCs

Migrate DC Dependencies

Eliminate all un-supported coding (e.g. typecasts to "forbidden" internal Web Dynpro FPIs).Based on the new Web Dynpro Facade conceptsuch code cannot be compiled any more. Rebuild your Web Dynpro DCs

RebuildWeb Dynpro DCs

Redeploy your Web Dynpro DCsRun your Web Dynpro Application

Deployand Run


Migration Step 1 –

Set up Development Infrastructure

Web Dynpro DC Migration Process Step

SAP NetWeaver 7.0 SP13 NWDI Valid Track for SAP NetWeaver CE 7.1 is set up (the required Net-Weaver SCsare added)

A SAP NetWeaver Developer Studio for SAP NetWeaver CE SAP NetWeaver Developer Studio for SAP NetWeaver CE 7.17.1 must be used as a designtime environment. SAP NetWeaver CE 7.1 does notdoes not come with an installation of the SAP NetWeaver Development Infrastructure (NWDI). Two main scenarios for a valid development and production infrastructure exits:

Use an existing SAP NetWeaver 7.0 Development Infrastructure with valid tracks for SAP NetWeaver CE 7.1 set up. Use a third party development and production infrastructure.

Set up Development Infrastructure

1

Presenter

Presentation Notes

NOTE - Using a Third party development and production infrastructure. The SAP NetWeaver Composition Environment command line tool (CECLT) is an add-on to the NetWeaver Developer Studio. Using the CECLT, you can build and package development components (DCs) and SCAs files. You can use the command line tool to run an automated build on a collection of DCs that belong to a certain development configuration or if you do not have your own build infrastructure with a build engine. For further information see SAP NetWeaver CE 7.1 Online Help: „Composition Environment Command Line Tool“ - http://help.sap.com/saphelp_nwce10/helpdata/en/45/5a3613dca22a4ce10000000a11466f/frameset.htm






The initial Library DC dependencies for Web Dynpro DCs have changed in SAP NetWeaver CE 7.1A new Web Dynpro Library DC (Web Dynpro Façade) was introduced only exposing the public Web Dynpro Runtime APIs

Forbidden typecasts to invoce internal Web Dynpro FPI (Framework Programming Interfaces) are no longer possible

Manually added DC dependencies might have changed also. They must be migrated to the new DC Public Parts manually


2

Presenter

Presentation Notes

Web Dynpro Facades The New Web Dynpro Facades only affect those Web Dynpro applications which invoke internal Web Dynpro FPIs



Create Active Projects



Open Development Infrastructure PerspectiveSelect Web Dynpro DCs of your application to be migratedSelect context menu item ““Sync / Create Project Sync / Create Project –– Create Create Active ProjectActive Project””


2



Repair Projects



Web Dynpro Explorer opens autmaticallySelect Web Dynpro DCs of your application to be migratedSelect context menu item ““Repair Repair –– Project Structure and Project Structure and ClasspathClasspath””


2

Presenter

Presentation Notes



Repair Project Result


Create Active Projects for Web Dynpro DCs to be migratedRepair Project Structure and Classpath of Web Dynpro DCs in Web Dynpro ExplorerRefactor/Delete Broken or Deprecated Public Parts of Used DCs

After ““Repair ProjectsRepair Projects”” new Library DC usages are addedDeprecated DC usages still exist and will be deleted in next step


2

Repair ProjectRepair Project

Presenter

Presentation Notes



Delete Deprecated Library DCs


Create Active Projects for Web Dynpro DCs to be migratedRepair Project Structure and Classpath of Web Dynpro DCs in Web Dynpro Explorer

Delete Deprecated Public Parts of Used Library DCs

Open Development Infrastructure PerspectiveOpen ““DependenciesDependencies”” TabRepeatedly select single Web Dynpro DCDelete Deprecated Library DC usage relations


2

Presenter

Presentation Notes



Set Build Time Dependency


Create Active Projects for Web Dynpro DCs to be migratedRepair Project Structure and Classpath of Web Dynpro DCs in Web Dynpro Explorer

Set Build Time Dependency of PP gci in Web Dynpro Library DC tc/wd/api

Open Development Infrastructure PerspectiveOpen ““DependenciesDependencies”” TabRepeatedly select single Web Dynpro DCSet “Build Time” dependency of Public Part gcigci in required Web Dynpro Library DC tc/wd/apitc/wd/api


2

Prior to Prior to SAP SAP

NetWeaver NetWeaver CE 7.1 SP3CE 7.1 SP3

OnlyOnly

Presenter

Presentation Notes

NOTE – Workaround for Bug in SAP NetWeaver CE 7.1 before SP3 This manual change of the „Build Time = true“ dependency of public part gci in the required Web Dynpro Library DC tc/wd/api is only required in versions of SAP NetWeaver CE 7.1 prior to SP 3. The bug is first fixed in SP3.



Migrate Manually Added DC Usages


Create Active Projects for Web Dynpro DCs to be migratedRepair Project Structure and Classpath of Web Dynpro DCs in Web Dynpro ExplorerRefactor broken or deprecated Public Parts of used External Library DCs or used Web Dynpro DCs

Open Development Infrastructure PerspectiveOpen “DependenciesDependencies” TabRepeatedly select single Web Dynpro DCMigrate deprecated Public Part usages of manually added External Library DCs or other Web Dynpro DCsApply QuickfixQuickfix (CTRL + 1) in case a Public Part successor is defined


2

Presenter

Presentation Notes


Open Development Infrastructure PerspectiveOpen “DependenciesDependencies” TabSelect Web Dynpro DCs of your application to be migratedSelect context menu item ““BuildBuild””


Rebuild Web Dynpro DCs


Eliminate all un-supported coding (e.g. typecasts to "forbidden" internal Web Dynpro FPIs).Based on the new Web Dynpro Facade conceptsuch code cannot be compiled any more. Rebuild your Web Dynpro DCs

Rebuild Web Dynpro DCs

3

Presenter

Presentation Notes

Web Dynpro Facades The new Web Dynpro Facades no longer expose Web Dynpro framework-internal classes and interfaces the previously referenced SAP NetWeaver 04 and NetWeaver 7.0 Library DCs contained. The new Web Dynpro Facades only affect those Web Dynpro applications which invoke internal Web Dynpro FPIs Source-compatability does not mean, that an unsupported invocation (hijacking, see SDN WebLog on Never Ever Hijack Internal Web Dynpro Classes and Interfaces - https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1222) of internal Web Dynpro Runtime FPIs (Framework Programming Interface) is still supported. In case your FPI invocations cannot be refactored using official Web Dynpro Runtime APIs (see JavaDoc in SAP Online Help: https://help.sap.com/javadocs/nwce/current/wdr/index.html) you must explicitly skip the invoked function. In many cases the Web Dynpro Runtime API provides the required functions.


Open Development Infrastructure PerspectiveOpen “DependenciesDependencies” TabSelect Web Dynpro DCs of your application to be migratedSelect context menu item ““DeployDeploy””


Deploy and Run Application


Deploy your Web Dynpro DCsRun your Web Dynpro Application


4


Open Web Dynpro ExplorerWeb Dynpro ExplorerOpen Web Dynpro DC comprising your Web Dynpro application entitySelect context menu item “RunRun” for application entity




Deploy your Web Dynpro DCs

Run your Web Dynpro Application


4


Migrating Web Dynpro DCs to

SAP NetWeaver CE 7.1


Enhanced Web Dynpro Component Model

SAP Recommendations on Component Migration

How To Migrate Web Dynpro Components

Further Migration Aspects


Web Dynpro Component Migration at a Glance

What is Web Dynprocomponent migration?

The Web Dynpro component programming model was significantly changed in SAP NetWeaver CE 7.1!

Existing Web Dynpro component created in NetWeaver 04 or 7.0 can be migrated to the new component model.

?

What about Web Dynpro component compatibility?

SAP NetWeaver CE 7.1 is sourcesource--compatiblecompatible to all your existing Web Dynpro components created in SAP NetWeaver 04 or 7.0. After repair, rebuild and deployment of Web Dynpro DCs your can run exsting components in CE 7.1.

?

Must all myWeb Dynpro componentsbe migrated?

No! Based on the given sourcesource--compatibility compatibility you can run existing Web Dynpro components without migration.

Under certain conditions component migration should or must be applied (e.g. to use new functions).

?

How can I migrate my Web Dynpro components?

Read the Component Migration Process Steps described in this presentationRun the Web Dynpro component cigration tool (Cheat Web Dynpro component cigration tool (Cheat Sheet)Sheet) assisting you in successfully migrating existing components to the new component model.

?

Presenter

Presentation Notes







Modified Web Dynpro Component Architecture –

Overview

There are significant changes in the Web Dynpro component programming model in SAP NetWeaver CE 7.1

The changes are sourcesource--compatiblecompatible. Existing Web Dynpro components can be rebuilt, rearchived, redeployed and will then run.Old components will look visibly different (grey component icons) and will further be based on the old programming model.Old Web Dynpro components will further be supported All Web Dynpro components which are newly created in the SAP NetWeaver CE 7.1 Developer Studio are based on the new programming model

The migrationmigration of existing Web Dynpro component is supported by the Web Dynpro Tools but can potentially be a complex task.

SAP recommends not to migrate existing Web Dynpro components by default. Component migration is only recommended in specific use cases.

Web Dynpro Components in SAP NetWeaver CE 7.1 !


Modified Web Dynpro Component Architecture (2)

New Window Controller

Replaces former Component Interface Controller classImplements one ore many Interface Views defined in Local or Standalone Component Interface DefinitionsThe 1..1 relation to former Component Interface View is no more mandatoryNew Window Plugs for Simpler Cross-Component Navigation

!


Modified Web Dynpro Component Architecture (1)

New Local Component Interface Definition

Local Component Interface Local Component Interface DefintionDefintion is purely abstract

Defines IExternal-API of a component implementationComponent Interface Controller Class no longer exists

Component controller implements LocalLocal and StandaloneStandalone Component Interface Component Interface DefintionsDefintionsView containers in component interface viewsComponent interface inheritance

!


Web Dynpro Component Anatomy –

SAP NetWeaver 7.0













Starting The Web Dynpro Component Migration Tool

Components which are based on the old component model are displayed with a greygrey component icon component icon

Old Web Dynpro components can be migrated with the semisemi-- automaticautomatic Web Dynpro Component Migration ToolWeb Dynpro Component Migration Tool based on a user user assistance cheat sheet assistance cheat sheet

Start the Component Migration Tool with context menu item „Migrate …“

Presenter

Presentation Notes

Using the Web Dynpro Component Migration Cheat Sheet The process is partly automated and partly manual; the user will be guided through it by a cheat sheet that will list all actions that need to be performed to accomplish the needs of the new programming model.


Web Dynpro Component Migration Cheat Sheet

The Component Migration Cheat SheetsComponent Migration Cheat Sheets assists the developer in preparing a Web Dynpro component for migration

Migration can be started after successful component preparation

Presenter

Presentation Notes

Using the Web Dynpro Component Migration Cheat Sheet The process is partly automated and partly manual; the user will be guided through it by a cheat sheet that will list all actions that need to be performed to accomplish the needs of the new programming model. The Cheat Sheet is dynamic, this means it adapts its function to the actual component implementation. In case a function is not needed for a given component implmentation it is not displayed in the component migration cheat sheet.


Potential Side Effects of Web Dynpro Component Migration

IrreversibleProcess

The Component Migration Process cannot be reverted.

Impo

rtan

t N

ote

!

Migrated Components might change behaviorally post-migration testing required.Carefully migrate heavily used components!

BehavioralChanges

Hook MethodInvocationChanges

Hook methods doBeforeNavigation() and doPostProcessing() are only called with pending action might affect application logic

Context Specific Changes

Invocation of IWDNode.bind() now throws a runtime exception when a corresponding suppliy function is defined.

Table UIElement Changes

Table Selection Change Behavior will change when selectionChangeBehavior was set to values auto or nw04 (not nw04splus) before.

Naming UIElement IDs UI element IDs MUST NOT start with ‘_’

Presenter

Presentation Notes

Potential Side Effects of Web Dynpro Component Migration Irreversible Process: There is no way back. Once the Web Dynpro component has been migrated to the new programming model, you cannot go back to the original programming model later. Behavioral Changes: The migration process might slightly change how the Web Dynpro component behaves at runtime. Therefore you will need to intensively test your component's functionality after the migration. This is especially relevant for reusable components that are used within other Web Dynpro components which are most probably stored in separate Web Dynpro Development Components.�Migrate those components that are heavily used by other components with extreme care! Hook Method Invocation Changes: For components with the new programming model the hook methods doBeforeNavigation() and doPostProcessing() will only be called when an action is pending (up to the migration they were always called). This may affect the runtime behaviour of your component and cannot be checked by the migrator. Context Specific Changes: Do not Invoke IWDNode.bind() for context nodes that have a supply function. The method bind() for context nodes that have a supply function must not be called any more for the new programming model; doing so will cause a runtime exception. This may affect the runtime behaviour of your component and cannot be checked by the migrator. Table UI Element Changes: The Table UI element has a slightly different runtime behaviour for the new programming model when the selectionChangeBehavior property of a Table UI Element was set to auto or nw04. When the user clicks on a button within a row that is not selected the lead selection will only change if the table is in read-only mode. This may affect the runtime behaviour of your component and cannot be checked by the migrator. See SDN article „Enhancing Web Dynpro Table Performance in NetWeaver 04 SP Stack 13“ to get more details. New Naming Convention for UI Element IDs: In the new programming model it is no longer allowed to programmatically create UI elements with IDs that start with '_'. Doing so will cause a runtime exception. This may affect the runtime behaviour of your component and cannot be checked by the migrator.


How to Simplify and Accelerate Component Migration

RESOLVE all Component Controller Bypass AntiComponent Controller Bypass Anti--PatternsPatterns in Your component implementation before migrating it!

ADHERE to the Component Controller Delegation PatternsComponent Controller Delegation Patterns! This accelerates and simplifies Your Component Migration Process!

ONLY Define Indirect Usage Relations To the Interface Controller using the Component Controller as Delegator!

►NEVER Define a Usage Relation from a Non-Component Controller to the Interface Controller directly!

ALWAYS Define Indirect Controller Usage Relations from the Interface Controller to NON-Component Controllers using the Component Controller as Delegator!

►

NEVER Define a Usage Relation from a Component Interface Controller to a Non-Component Controller!

Patterns Anti-Patterns


Component Controller Bypass Anti-Patterns

NEVER Define a Usage Relation from a Non- Component Controller to the Interface Controller!

applies to SAP NetWeaver 04 and 7.0

Presenter

Presentation Notes

Component Controller Bypass Anti-Patterns The Component Migration tool cannot automatically re-define component usage relations from the component interface controller to non-component controllers (custom controller, interface view controller) bypassing the component controller and vice versa. These controller usage relations must manually be re-defined pointing to the component controller (Component Controller usage pattern) so that the component controller acts as delegate/delegator between non-component controllers and the component interface controller. A Non-Component Controller directly uses the Interface Controller bypassing the component controller non-component controllers directly map their context to the the interface context non-component controllers invoke the IPublic-API of the interface context non-component controllers fire an event defined in the interface controller IMPORTANT NOTE RESOLVE all Component Controller Bypass Anti-Patterns before component migration


Detecting Anti-Patterns in Your Web Dynpro Component

To easily detect the Component Controller Bypass AntiComponent Controller Bypass Anti--PatternPattern You can apply the Inverse Search Function Inverse Search Function provided by the Web Dynpro Tools:

Impo

rtan

t T

ip►

Select Component Interface ControllerOpen context menuSelect Menu Item „References – Project“

Presenter

Presentation Notes

Finding NON-component Controllers Using the Component Interface Controller Bypassing the Component Controller To detect defined controller usage relations from NON-component controlllers in the same component to the component interface controller, bypassing the component controller, apply the inverse search function provided by the Web Dynpro Tools: Select Component Interface Controller Open context menu Select Menu Item „References – Project“ Note The Inverse Search of usage dependencies is not yet applicable for the Web Dynpro entity „component interface view“


Component Controller Delegation Patterns

ONLY Define Indirect Usage Relations to the Interface Controller using the Component Controller as Delegator!

►


Presenter

Presentation Notes

Component Controller Delegation Patterns Component Migration is highly accelerated and decisively simplified when your component implementation strictly adheres to the following component controller delegation patterns: Non-Component controllers have not defined a direct component usage relation to the component interface controller so that they do not bypass the component controller. Non-Component controller use the component controller as an delegator to the component interface controller (indirection) Non-component controllers map to the component context but not to the interface context. The component context potentially maps to the interface context when external context mapping is applied. Non-component controllers invoke the IPublic-API of the component controller but not of the interface controller. The component controller delegates to the interface controller to fire an interface controller event IMPORTANT NOTE STRICTLY ADHERE to the Component Controller Delegation Patterns! This highly accelerates and decisively simplifies Your Component Migration Process!


Component Controller Bypass Anti-Patterns

NEVER Define a Usage Relation from a Component Interface Controller to a Non-Component Controller!


Presenter

Presentation Notes

Component Controller Bypass Anti-Patterns Continued� The Component Migration tool cannot automatically re-define component usage relations from the component interface controller to non-component controllers (custom controller, interface view controller) bypassing the component controller and vice versa. These controller usage relations must manually be re-defined pointing to the component controller (Component Controller usage pattern) so that the component controller acts as delegate/delegator between non-component controllers and the component interface controller. The Interface Controller uses non-component controller bypassing the component controller The Interface Controller invokes the IPublic-API of another non-component controller: custom controller, component interface view controller. The interface controller maps ist context to a custom context The interface controller subsribes an event handler to a custom controller event IMPORTANT NOTE RESOLVE all Component Controller Bypass Anti-Patterns before component migration STRICTLY adhere to the Component Controller Delegation Patterns! This highly accelerates Your Component Migration Process!


Component Controller Delegation Pattern A

ALWAYS Define Indirect Controller Usage Relations from the Interface Controller to Non-Component Controllers using the Component Controller as a Delegator!

►


Presenter

Presentation Notes

Component Controller Delegation Patterns Continued Component Migration is highly accelerated and decisively simplified when your component implementation strictly adheres to the component controller delegation patterns: The interface controller only uses the component controller but no non-component controllers like custom or interface view controllers The interface controller strictly delegates its own application logic to the component controller The interface controller invokes the IPublic-API of another non-component controller: custom controller, component interface view controller. The interface controller maps its context to the component controller context The interface controller does not define an own data context The interface controller defines externally mappabel context elements (isInputElement=true). Only the component context maps to these elements The interface controller subsribes an event handler to a component controller event IMPORTANT NOTE STRICTLY adhere to the Component Controller Delegation Patterns! This highly accelerates and decisively simplifies Your Component Migration Process!


Quick Fixes for Interface Controller Implementation Errors

Apply Quick FixQuick Fix to resolve a broken implementation relation from the Component Controller to a Local or Standalone Component Interface Defintion

Presenter

Presentation Notes

Quick fixes for component interface implementation errors On most entries in the Eclipse problems view regarding the implementation of component interfaces there are now quick fixes available They can be started by right-clicking on the problems view entry and chosing "Quick fix..." from the context menu. Example: A method that is declared in an interface but is missing in the implementation can be automatically created in the implementation by calling one of the quick fixes.


How to Migrate a Web Dynpro Component –

Process Steps

Post-Processing Steps after Component MigrationComponent MigrationPreparative Steps

before Component Migration

Check Package Namespaces of Component Entities

Start Web Dynpro

Component Migration

Analyze and PrepareComponent Interface

Controller

Analyze and PrepareComponent Interface Views and Controllers

Implement Window Controllers

Invoke IPublic-API of Window Controllers


Analyze and PrepareImplemented Interfaces

Presenter

Presentation Notes

IMPORTANT NOTE The developer should do a complete check-out of the project's src folder before doing component migration!


Real Life Component Migration Scenarios

The component migration process steps described in this presentation are all potential steps to be applied.

Most Web Dynpro component implementations can be migrated to the new component model more easilymore easily by applying a small subsetsmall subset of component migration process steps!



Start Web Dynpro Component Migration

Analyze and Prepare

Component Interface

Controller





Analyze and Prepare

Component Interface

Controller

Analyze and Prepare

Component Interface Views and Controllers

Implement Window

Controllers

Invoke IPublic- API of

Window Controllers




CheckPackage Namespaces

of Component Entities


Analyze and Prepare

Component Interface

Controller


Analyze and Prepare

Implemented Interfaces Model ComponentModel Component

Migration Migration Visual ComponentVisual ComponentMigration Migration Faceless ComponentFaceless Component

Migration Migration

Scenario 1Scenario 2

Scenario 3

Impo

rtan

t N

ote

!


Component Preparation: Names and Packages

Preparative Steps before Component Migration

Check Names and Packages of Component Entities


Controller


Move Views, Windows and Custom Controllers

Check Conflicting Window Names

Check Component Package

Analyze and PrepareComponent Interface Views


* dynamic cheat sheet step


Presenter

Presentation Notes

Check Names and Packages of Component Entities Check Package Namespaces of contained component entities: Does the component comprise entities (views, custom controller) which reside in another package outside the component's package namespace? Check Conflicting Window Name: Is there any Window with the same name like the component, ending with the suffix Comp? Check Component Package: Does the component comprise entities which do not belong to the component itself like models, dictionary types etc.? NOTE: Dynamic Steps in Web Dynpro Component Migration Cheat Sheat A Dynamic Cheat Sheet step is only displayed to the user when certain conditions are fulfilled. The dynamic steps „Move Views, Windows and Custom Controllers” and “Check Component Package” are only visible in the migration cheat sheet when needed. The Web Dynpro Component Migration Cheat Sheet automatically detects these conflicts itself and requests the application developer to fix them.


Component Preparation: Move Component Entities




Controller



Check ConflictingWindow Names





Presenter

Presentation Notes

Moving Component Entities to be stored in a Common Component Namespace (Dynamic Step) The component comprise entities (views, custom controller) which reside in another package outside the component's package namespace? ________________________________________________________________________________ If Yes … Step : Move Views The new programming model for Web Dynpro components requires that all views of the component are physically stored within the same package as the component itself (sub-packages are also not allowed). The views for which the packages have to change are listed in this step of migration Step : Move Custom Controller The new programming model for Web Dynpro components requires that all custom controllers of the component are physically stored within the same package as the component itself (sub-packages are also not allowed). The custom controllers for which the packages have to change are listed in this step of migration. Step : Move Windows The new programming model for Web Dynpro components requires that all windows of the component are physically stored within the same package as the component itself (sub-packages are also not allowed). The windows for which the packages have to change are listed in this step of migration. Caution! Keep in mind that renaming an object that is visible from the outside might break the build of using components.


Component Preparation: Check Conflicting Window Names




Controller



Check Conflicting Window Names




Presenter

Presentation Notes

Check Conflicting Window Names Is there any Window with the same name like the component, ending with the suffix Comp? ________________________________________________________________________________ If Yes: Rename Window with Suffix 'Win' The new programming model for Web Dynpro components requires that all windows of the component have a window controller. These controllers will be created during the migration. On the other hand there must not be two controllers with the same name within one Web Dynpro component. The step lists windows for which the precondition is violated. The window or the object with the conflicting controller has to be renamed. Caution! Keep in mind that renaming an object that is visible from the outside might break the build of using components.


Component Preparation: Check Component Package




Controller



Check ConflictingWindow Names





Presenter

Presentation Notes

Component Package Check (Dynamic Step, Available Since SAP NetWeaver CE 7.1 SP3) Does the component comprise entities which do not belong to the component itself like models, dictionary types etc.? ________________________________________________________________________________ If Yes … The new programming model for Web Dynpro components requires that a package is solely reserved for a component and its sub-objects. The sub-objects refer to windows, views and local component interface controller. The step lists the objects which were found within the package of the component conflict with this requirement. Either the component has to be moved into another package or the conflicting objects need to be moved away. Note: 1. Moving component might break using components. 2. The step list two alternatives. Either the component can be moved or other objects can be moved. a) If you choose to move the component then you need not move other objects. Simply mark movement of those objects as "done" by clicking on the status icon. b) If you choose to move the other objects. Move the other objects manually and mark the status as "done" by clicking on it. After all the objects are moved, simply click on the step of movement of component 3. In step 2.b: If all the objects are not moved and steps marked as done, clicking on icon for movement of component will trigger movement of component. If all the objects are moved and steps marked as done, clicking on icon for movement of component will simply mark it as done.


Component Preparation: Component Interface Controller



Controller


ImplementInterface Controller inComponent Controller

Re-DefineController

UsageRelations

Analyze and PrepareInterface Context

Analyze and PreparePublic Interface

Methods

Analyze and Transfer Interface Controller

Coding




Analyze and PrepareInterface Events and

Event Handlers

Presenter

Presentation Notes

Analyze Component Interface Controller� Main Purpose of these Preparatives Steps To migrate an existing Web Dynpro component from SAP NetWeaver 7.0 to the new component model the component controller must fully implement the existing component interface controller in respect of exposed methods, events and context elements. Additionally all custom code implemented in the component interface controller must be transferred to the component controller. To fulfil the above requirements we propose to take the following four steps: Analyze Interface Context Analyze Interface Eventing (Events and Event Handlers) Analyze Public Methods Analyze Interface Controller Coding and Transfer User Coding Areas IMPORTANT NOTE STRICTLY Adhere to the Component Controller Delegation Patterns! RESOLVE all Component Controller Bypass Anti-Patterns before! This highly accelerates Your Component Migration Process!


Adhere to the Component Controller Delegation Patterns

STRICTLY Adhere to the Component Controller Delegation Patterns! RESOLVE all Bypass Anti-Patterns before!This highly accelerates Your Component Migration Process!

►


Component Preparation: Component Interface Controller



Controller



Re-DefineController

UsageRelations





Analyze and PreparePublic Interface Methods

Analyze and Transfer Interface Controller Coding


Event Handlers

Presenter

Presentation Notes

Analyze Component Interface Controller Important Cheat Sheet Functions Use 'Check implementation relation' to find out which objects defined in the interface controller are not implemented within the component controller and if there are any conflicts; Use 'Implement interface controller' to automatically copy all relevant objects from the local interface controller to the component controller in order to fulfill the necessary implementation relation. Use dynamic migration cheat sheet steps 'Replace References' and 'Delete References' to refactor component usage relations. ��Since for the new programming model for Web Dynpro components the implementation aspects are stored in the component controller instead of the interface controller also at runtime the data storage is now the component controller. This means that all references to sub-objects of the interface controllers within the component have to be replaced with references to the newly created associated objects in the component controller.��Note: After performing these steps the component will not run any more. If you redefined some of the context elements during the previous step, this list might be out-of-date. Restart the cheat sheet in this case


Component Preparation: Interface Context


Re-DefineController

UsageRelations



Controller









Event Handlers

Presenter

Presentation Notes

Analyze Interface Controller Controller Context Does the Interface Context contain mapped context elements? If the interface context is mapped to the component context just delete the mapping relation. The interface context must not be mapped to non-component/custom data contexts: Delete Mappings to custom controller contexts bypassing the component context Define data context in component controller or map component controller context to custom data context and delete interface context mapping relation. Does the Interface Context contain externally mappable input elements? Analyze all contexts in the same component which map to this isInput=true interface context elements Do not bypass the component context: Do not directly map non-component contexts to these isInput=true interface context elements. If only the component context maps to these isInput=true interface context elements delete the mapping relation and set property isInput=true in component context elements with same name. Does the Interface context contain data nodes or data attributes? Analyze all contexts in the same component which map to these interface context data elements Component Context maps to interface data context: Delete mapping relation and define component context as data context Do not bypass the component context: Do not directly map non-component contexts to these isInput=true interface context elements.


Component Preparation: Interface Event Handlers


Re-DefineController

UsageRelations



Controller




Event Handlers






Presenter

Presentation Notes

Analyze Event Handlers in Interface Controller Is an interface event handler defined? ________________________________________________________________________________ If Yes … Move this code to the component controller as public method and invoke this method from all controllers which previously fired the event to which the interface controller event was subscribed. The interface event handler does not fire an interface event but just implements component-internal application logic perhaps affecting the context state?�Implement logic of the interface event handler in the new public component controller method. The interface event handler itself just fires a component interface event?�Fire the interface event in the new public component controller method.


Component Preparation: Interface Events


Re-DefineController

UsageRelations



Controller




Event Handlers






Presenter

Presentation Notes

Analyze Events in Interface Controller Is an interface event defined? ________________________________________________________________________________ If Yes … The interface event is exposed in the interface controller's IPublic-API or can be fired via a public interface method. Component Controller Delegation Pattern Only the component controllers fires this event directly? �Fire this interface event in the component controller invoking its IPrivate-API Component Controller Bypass Anti-Pattern NON-component controllers fire this event directly?�Define a public method to fire this event from outside the component controller. In the method implementation fire the interface event with the component controller's IPrivate-API. Redefine component usage relations now pointing to component controller.


Component Preparation: Public Interface Methods


Re-DefineController

UsageRelations



Controller




Event Handlers

Analyze and PreparePublic Interface

Methods





Presenter

Presentation Notes

Analyze Public Methods in Interface Controller Does the component interface controller implement a public method exposed in its IExternal- and consequently IPublic-API? ________________________________________________________________________________ If Yes … Component Controller Delegation Pattern The public method implementation just delegates to the same method in the component controller? View and custom controllers do not invoke the interface controller's IPublic-API directly but the counterpart methods in the component controller's IPublic-API instead?�If yes, Nothing to do. Component Controller Bypass Anti-Pattern The implementation does not delegate to the same method in the component controller but implements it itself or even delegates to other custom-controller? �Move method code to component controller. NON-Component controllers directly invoke this method bypassing the component controller? �Move method implementation to component controller and invoke the component's IPublic-API in other non-component controllers adapting the controller usage relation.


Component Preparation: Interface Controller Coding


Re-DefineController

UsageRelations



Controller




Analyze and Transfer Interface Controller

Coding





Event Handlers

Presenter

Presentation Notes

Analyze Interface Controller Coding and Transfer User Coding Areas In the new programming model for Web Dynpro components there is no implementation coding allowed for the component local interface controller. The coding that was stored there in the old programming model has been transferred during one of the previous steps ('Transfer User Coding from Interface Controller to Component Controller') to the component controller. Now the no longer used coding in the interface controller will be deleted. Simply click to perform this automatically. Make sure you transferred all necessary coding to the component controller before proceeding.Note: After performing this step the component will not run any more. Step : Delete Implementation Coding from Interface Controller The step lists the user coding sections of the local component interface controller which are not empty and may contain Java coding that needs to be transferred to the component controller. These user coding areas has to be copied manually to the appropriate sections of the component controller. Is there any application code implemented in the methods wdDoInit() or wdDoExit()? �Implement this logic in component controller Is there any application code implemented in the //@@begin others user coding area? �Implement this logic in component controller Does the interface controller implementation invoke the IPublic-API of a custom controller? �Do not invoke methods of non-component controllers but implement logic in component controller or delegate to custom controllers from there.�Define custom-controller usage in component controller and invoke custom-controller's IPublic-API there. For context data nodes in interface context: are supply functions or calculated context attributes defined? Are dispose functions implemented?�Implement these functions in the component controller


Component Preparation: Component Interface Views



Controller


and their Controllers



Note Outbound, Exit and Suspend Plugs

Analyze and Copy Interface View

Controller Coding Invoking IPublic-APIs


Controller Code Handling Plugs

See Step Post-Processing Steps

after Component Migration

Presenter

Presentation Notes

Analyze and Prepare Component Interface Views and their Controllers Note: The current Web Dynpro Component Migration Cheat Sheet does not implement the following preparative steps dealing with Component Interface Views and their controllers.


Component Preparation: Outbound, Exit and Suspend Plugs



Controller






Analyze and Copy Interface View Controller Code

Handling Plugs

Analyze and Copy Interface View Controller Coding Invoking IPublic-APIs



Presenter

Presentation Notes

Analyze Outbound, Exit and Suspend Plugs in Component Interface Views and Note all Invoking Controllers firing these Plugs Are Outbound, Exit, Suspend plugs defined in a Component Interface View? ________________________________________________________________________________ If Yes … Other controllers like view-controllers or the component controller defined a controller usage relation to the interface view controller to trigger interface view navigation (exit, suspend, outbound i.e. inter-component navigation)�Note all occurrences of controller code in other controllers (view, component, custom controllers) where a component interface view’s outbound-, exit- or suspend plug is fired. These navigation plugs must now be fired by the window controller after the component migration is completed. Controller usage dependencies must then be adapted correspondingly, this means a view-controller for example must invoke the IPublic-API of the new window controller to fire an exit plug instead of the former component interface view controller which no longer exists. See Post-Migration Step.


Component Preparation: Interface View Controller Coding



Controller






Controller Code Handling Plugs


Analyze and Copy Interface View Controller Coding Invoking IPublic-APIs



Presenter

Presentation Notes

Analyze and Copy Interface View Controller Code Handling Inbound, Resume, Startup Plugs Are Inbound, Resume, Startup plugs defined in a Component Interface View? ________________________________________________________________________________ If Yes … The interface view controller has defined a controller usage relation to another controller to invoke its IPublic-API to dispatch navigation event handling to Custom Controller Interface View Controller, Interface Controller or Component Controller�Copy source code implementation to notepad to be pasted to the new window controller (not yet existing) after component migration is completed. The interface view controller handless inbound-, startup- and resume-plugs itself, not delegating this application logic to another controller.�Copy source code implementation to notepad to be pasted to the new window controller (not yet existing) after component migration is completed.


Component Preparation: Interface View Controller Coding



Controller





Analyze and Copy Interface View Controller Code

Handling Plugs



Controller Coding Invoking IPublic-APIs



Presenter

Presentation Notes

Analyze and Copy Interface View Controller Code Invoking IPublic-APIs of another Controller Does the interface controller implementation invoke the IPublic-API of a custom controller? ? ________________________________________________________________________________ If Yes … Do not invoke methods of non-component controllers but implement logic in new window controller�Copy source code implementation to notepad to be pasted to the new window controller (not yet existing) after migration is completed. �Define custom-controller usage in Window controller and invoke custom-controller's IPublic-API there.


Component Preparation: Implemented Interfaces


Check Native Interface Inheritance



Controller







Start Component Migration


Component Migration

Start Web Dynpro

Component Migration

Presenter

Presentation Notes

Start the Actual Component Migration Step in the Web Dynpro Component Migration Cheat Sheet.


Post-Processing Steps after Component Migration

Post-Processing Steps after Component Migration



Implement Inbound-, Resume- and Startup- Plug Event handlers



See Step Component Preparation:

Component Interface Views

Presenter

Presentation Notes

Post-Processing Steps after Running the Component Migration Command � Implement Window Controllers Implement Inbound-, Resume- and Startup-Plug Event handlers in new window controller previously implemented in the component interface view controllers Paste source code implementation from notepad and handle incoming navigation events (interface view's inbound, resume, startup plugs) in new window controller, previously implemented in component interface view controller class Invoke IPublic-API of Window Controllers in other Controllers Precondition: Outbound, Exit, Suspend plugs were defined in previous component interface view controller? Define controller usage relation to new window controller and invoke fireplug methods in other controllers. The wdFire<plug name>Plug()- methods are exposed in the window controller's IPublic-API.


Complete Web Dynpro Component Migration Process

Preparing your Web Dynpro Components for MigrationPreparing your Web Dynpro Components for MigrationRefactor Component Controller Bypass Anti-PatternsMake sure, that the Component Controller Delegation Pattern is strictly applied!Copy Component Interface View Controller Implementation to Notepad

Applying the Web Dynpro Component Migration ToolApplying the Web Dynpro Component Migration Tool

Component Migration PostComponent Migration Post--ProcessingProcessingPaste Interface View Controller Implementation from Notepad to Window ControllerRedefine broken interface controller usages pointing to new window controllerInvoke the window controller's IPublic-API to fire exit, outbound and suspend plugsM

igra

tion

Pro

cess

Sum

mar

y

Presenter

Presentation Notes







SAP Recommendation on Component Migration at a Glance

Do not

Migrate Web Dynpro Components By Default!

You can still run existing Web Dynpro Components in CE 7.1SAP recommends not to migrate existing Web Dynpro components by default. In many existing Web Dynpro application scenarios there is no mandatory necessity for component migration.

Do

Migrate Web Dynpro Components In Specific Use Cases Only!

Existing Web Dynpro component should only be migrated to the newcomponent model in specific use cases:

Ease of maintenance: Developers only deal with new component modelSimplified cross-Component NavigationApply inheritance of Standalone Component InterfacesImplementation of Standalone Component Interface using new functionDevelopment of pure layout components referencing UI components

►

Presenter

Presentation Notes

SAP recommends not to migrate existing Web Dynpro components by default SAP recommends not to migrate existing Web Dynpro components to the new Web Dynpro component model of SAP NetWeaver CE 7.1 by default this means in most cases. The Web Dynpro Runtime and Designtime environments support all existing Web Dynpro components and it is possible to develop cross-component scenarios containing both Web Dynpro component types. This means you can define usage dependencies between old and new Web Dynpro components in order to embed component interface views, define context mapping relations, subscribe event handlers or invoke the interface controller's IExternal-API. This recommendation is motivated by the fact that a component migration process cannot be fully automated by the existing Component Migration Tool in most cases. The application developer must potentially do some specific (perhaps time-consuming) refactoring and declaration steps to successfully migrate a Web Dynpro component with the Component Migration Tool. Additionally existing Web Dynpro components will be supported in a long-term perspective so that a component migration step is not mandatory. SAP recommends to migrate existing Web Dynpro components in specific use cases only Web Dynpro component migration is only recommended in specific use cases which are described in the next slides


SAP Recommendations on Web Dynpro Component Migration

MandatoryMigration

An existing Web Dynpro component must implement a new standalone component interface definition utilizing new functionsAn existing Web Dynpro component must utilize component interface inheritance which is only supported in the new component modelAn existing Web Dynpro component must support the generic secondary help service

OptionalMigration

Web Dynpro component developers are not familiar with the old Web Dynpro component modelYou want to simplify your cross-component navigation by applying the new window navigation plug concept

NotNecessaryMigration

An existing Web Dynpro component must implement a new standalone component interface definition not utilizing new functionsUtilizing View Containers in Component Interface ViewsYou want to apply the new default plug property for Web Dynpro view usagesYou want to use the new universal context nodes



MandatoryMigration

An existing Web Dynpro component must implement a new standalone component interface definition utilizing new functionsAn existing Web Dynpro component must utilize component interface inheritance which is only supported in the new component modelAn existing Web Dynpro component must support the generic secondary help service

Presenter

Presentation Notes

When Web Dynpro Component Migration is Mandatory An existing Web Dynpro component must implement a new standalone component interface definition utilizing new functions �Think of a multi-component based Web Dynpro application architecture which makes use of Web Dynpro component interface definitions. We 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 (like 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. 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. An existing Web Dynpro component must support the generic secondary help service�To utilize the new secondary help service in Web Dynpro application running in the SAP NetWeaverPortal you must define help links on window controller level inside a Web Dynpro component. Help links cannot be defined in the SAP NetWeaver 04 and 7.0 component model.



OptionalMigration

Web Dynpro component developers are not familiar with the old Web Dynpro component modelYou want to simplify your cross-component navigation by applying the new window navigation plug concept

Presenter

Presentation Notes

When Web Dynpro Component Migration is Optional You want to simplify your cross-component navigation by applying the new window navigation plug concept�The new Web Dynpro component model allows to define inbound and outbound plugs on window level. This decisively simplifies navigation across component borders, because a non-view but window-triggered navigation does not require server side eventing combined with a navigation dispatcher view like in SAP NetWeaver 04 and 7.0. As plugs can now be defined inside windows and as plugs can be fired by the new window controllers the implementation of cross-component navigation logic is decisively simplified. Nevertheless this simplification does not make component migration 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 Web Dynpro component model of SAP NetWeaver 04 and 7.0 the total cost of learning might outbalance the total cost of component migration. The component migration must naturally be done by a Web Dynpro developer who is familiar with the old Web Dynpro component model in SAP NetWeaver 04 and 7.0.



UnneccessaryMigration

An existing Web Dynpro component must implement a new standalone component interface definition not utilizing new functionsUtilizing View Containers in Component Interface Views to develop Layout ComponentsLayout Componentsreferencing UI Components

Presenter

Presentation Notes

When Web Dynpro Component Migration is Not Necessary … 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 definition 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. Utilizing View Containers in Component Interface Views�View Containers in Component Interface Views are an additional new function in the new Web Dynpro component model. It is needed to develop so-called Web Dynpro layout components in SAP NetWeaver CE 7.1. A Web Dynpro layout component embeds and positions (layout) other visual Web Dynpro components without managing the related component instance lifecycles. In SAP NetWeaver 04 and 7.0 it was not possible to develop such layout components because it was not possible to decouple component instance lifecycle management and component interface view embedding in separate components. Instead, the layouting of component interface views must be defined within the root component which itself also managed the instance lifecycles of its embedded visual components. Based on the facts above there is no practical use case for migrating an existing Web Dynpro component to the new component model in order to extend it to a Web Dynpro layout component in the new component model. It makes no sense to migrate an existing root component to a layout component. Instead, such a Web Dynpro layout component will be newly created from scratch so that no component migration process is required. Migration is only mandatory, in case an existing Web Dynpro component must implement a new component interface definition utilizing new functions.



UnneccessaryMigration

You want to apply the new default plug property for Web Dynpro view usagesYou want to use the new universal context nodes

Presenter

Presentation Notes

When Web Dynpro Component Migration is Not Necessary … You want to apply the new default plug property for Web Dynpro view usages�In SAP NetWeaver CE 7.1 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 invoke the related inbound plug event handler without a navigation link pointing to the inbound plug. As this new feature is also applicable for all view layouts inside existing Web Dynpro components a component migration is not required. Example A view controller has the lifecycle property framework_controled. 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 the wdDoInit() hook method. When the view layout again disappears from the view assembly (triggered by navigation) the view controller instance still keeps alive. Consequently the wdDoInit() hook method will not be invoked again when the view layout re-appears in a later view assembly. 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 can make sure that the associated inbound plug event handler gets invoked by the Web Dynpro Runtime whenever the view becomes a member of a new view assembly. Note, that a view layout can also get visible in a view assembly without a navigation link directly pointing to it. This is the case for view layouts which are embedded in ViewContainerUIElements of layout views or which are embedded in a component interface view.


Migrating Web Dynpro

Components from SAP NetWeaver 7.0

to CE 7.1


Sample Component Migration Scenario

1

4

2

3

5

6

Pattern Description

Window Name Conflicts with Component Controller Name

Exit plug defined in Component Interface View

View controller fires exit plug invoking the interface view controllers IPublic-API

View controller by- passes component controller

Component context is mapped to interface data context

Interface context is mapped to the component context

1

2

3

4

5

6


How to Migrate a Web Dynpro Component –

Process Steps




Start Web Dynpro

Component Migration


Controller

Analyze and PrepareComponent Interface Views and Controllers




Presenter

Presentation Notes

IMPORTANT NOTE The developer should do a complete check-out of the project's src folder before doing component migration!







Migrating Component Interface Definitions

1. SAP recommends not to migratenot to migrate existing Web Dynpro component interface definitions by default. In many existing Web Dynpro application scenarios there is no mandatory necessitiy for component interface definition migration.

2. Existing Web Dynpro component interface definitions should only be migrated to the new component model in specific use cases.

SA

P R

ecom

men

dati

on►

Presenter

Presentation Notes

Migrating Component Interface Definitions The new Web Dynpro component model is combined with a new component interface definition model. Two component interface definition types exist: Local Component Interface Definition: A local component interface definition is part of a Web Dynpro component implementation. It is the default component interface exposed to other Web Dynpro components. Standalone Component Interface Definition: A standalone component interface definition is defined independent from a Web Dynpro component implementation. In addition to its local component interface definition a Web Dynpro component can implement one or many standalone component interface definitions. The new Web Dynpro component interface definition model provides the following new functions which were not available in the previous version: Component Interface Inheritance: In a new component interface definition you can define inheritance relations to other Web Dynpro component interface definitions. It is possible to inherit an old component interface definition in a new component interface definition. View Containers in Component Interface Views: In a new component interface definition you can define view containers within component interface views. Like Web Dynpro component implementations you can also migrate existing Web Dynpro component interface definitions. This can easily be done by selecting the context menu function Migrate.... After confirming a warning message the interface definitions gets instantly and irreversibly migrated to the new component interface definition model. The migration of component interface definitions is fully automated by the Web Dynpro Tools (context menu item Migrate ...) so that no additional efforts must be done by an application developer.


Migrating Web Dynpro Controller Contexts

No, the component migration tool does notdoes not migrate former context model and value elements to the new universal context elements itself.

You must explicitly trigger this context migration in a separate step.

Does the component migration tool also convert the former context model and value elements to the new universal elements??

I know that there is no difference between context model versus value elements (nodes and attributes) any more in SAP NetWeaver CE 7.1. Both element types are merged in the new universal context nodes and attributes.

Migrate complete controller context hierarchy separately via context menu item Migrate Context Tree on context root node level.


Migrating Deprecated UI Element Associations

In SAP NetWeaver CE 7.1 the following UI element associationsUI element associations of the TableTable UI elementUI element were deprecateddeprecated:

Deprecated Association New Association Association Target UI Element

Column GroupedColumn IWDTableColumnIWDTableColumnGroup

MasterColumn RowArrangement IWDTreeByNestingTableColumnIWDTableRowGrouping

Migrate deprecated UI element associations of the Table UI element with context function „Migrate Columns“


To run Web Dynpro Applications using Adaptive RFC Models in SAP NetWeaver CE 7.1 a System Landscape Directory (SLD)System Landscape Directory (SLD) is required.

In SAP NetWeaver CE 7.1 the SLD combined with the SLD Administration UI is first available in CE 7.1 SP Stack 3CE 7.1 SP Stack 3 together with the ESR (Enterprise Service Repository)ESR (Enterprise Service Repository) AddAdd--OnOn.

Regarding the compatibility of an existing SLD running on a separate SAP NetWeaver Application Server Java or on an SAP Backend System with Web Dynpro Adaptive RFC CE 7.1 see SAP Note see SAP Note 954820954820

Migrating Applications Using Adaptive RFC Models

CE 7.1

SLDC

Not

e►

+ ESRCE7.1 SP3

ASLD

CE 7.1

BSLD


Summary




Summary

The Web Dynpro Foundation for Java in SAP NetWeaver CE 7.1 is backward source-compatible with SAP NetWeaver 04 and 7.0

The migration of Web Dynpro applications to SAP NetWeaver CE 7.1 is made very simple:just repair, build and deploy related Web Dynpro DCs and then run your Web Dynpro application

The Web Dynpro component model was subject to significant changes in SAP NetWeaver CE 7.1.

Abstract component interfaces (views, controller) are now implemented by component and new window controllers.

Existing Web Dynpro components can be migrated with the semi-automatic Web Dynpro Component Migration Tool

SAP Recommendation on Web Dynpro component migration: Do not migrate components by default!Migrate components in specific use cases only!


Further Information

SAP Public Web:SAP Developer Network (SDN): www.sdn.sap.com

and

www.sdn.sap.com/irj/sdn/developerareas/webdynproBusiness Process Expert (BPX) Community: www.bpx.sap.com

Related Workshops/Lectures at SAP TechEd 2007CE110, “Web Dynpro Java –

What's New in SAP NetWeaver 7.1

Composition Environment”, 1 hour lectureCE351, “Designing Low TCO Applications in Web Dynpro Java”,

CE352, “Getting the best from the Web Dynpro Framework”, CE252, “Moving J2EE Applications to SAP NetWeaver Composition

Environment Made Easy”

Related SAP Education and Certification Opportunitieshttp://www.sap.com/education/

http://www.sdn.sap.com/

http://www.sdn.sap.com/irj/sdn/developerareas/webdynpro

http://www.bpx.sap.com/

http://www.sap.com/education/


SAP NetWeaver, Development Subscription

The SAP NetWeaver, Development Subscription offers a cost effective total solution for developers to build applications for the SAP NetWeaver platform.

Subscription gives you one year access to …SAP NetWeaver platform software, patches, and updatesDevelopment license for SAP NetWeaver to evaluate, develop and test Standard software maintenanceOnline sessions from SAP TechEdAccess to SAP Enterprise Services Workplace for testingPremium presence in forums

Purchase the SAP NetWeaver, Development Subscription today at the TechEd Community Clubhouse, or online at https://www.sdn.sap.com/irj/sdn/subscriptions

Show us you are a subscriber and get a reward!

https://www.sdn.sap.com/irj/sdn/subscriptions


THANK YOU FOR YOUR

ATTENTION !

QUESTIONS –

SUGGESTIONS –

DISCUSSION

Q & A


Please complete your session evaluation.

Be courteous — deposit your trash, and do not take the handouts for the following session.

Feedback

Thank You !

Migrating Webdynpro Java Appl From SAP NWDS 7_0 to 7_1

Documents